Merge branch 'slab/for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/penberg/linux
Pull slab update from Pekka Enberg:
"Highlights:
- Fix for boot-time problems on some architectures due to
init_lock_keys() not respecting kmalloc_caches boundaries
(Christoph Lameter)
- CONFIG_SLUB_CPU_PARTIAL requested by RT folks (Joonsoo Kim)
- Fix for excessive slab freelist draining (Wanpeng Li)
- SLUB and SLOB cleanups and fixes (various people)"
I ended up editing the branch, and this avoids two commits at the end
that were immediately reverted, and I instead just applied the oneliner
fix in between myself.
* 'slab/for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/penberg/linux
slub: Check for page NULL before doing the node_match check
mm/slab: Give s_next and s_stop slab-specific names
slob: Check for NULL pointer before calling ctor()
slub: Make cpu partial slab support configurable
slab: add kmalloc() to kernel API documentation
slab: fix init_lock_keys
slob: use DIV_ROUND_UP where possible
slub: do not put a slab to cpu partial list when cpu_partial is 0
mm/slub: Use node_nr_slabs and node_nr_objs in get_slabinfo
mm/slub: Drop unnecessary nr_partials
mm/slab: Fix /proc/slabinfo unwriteable for slab
mm/slab: Sharing s_next and s_stop between slab and slub
mm/slab: Fix drain freelist excessively
slob: Rework #ifdeffery in slab.h
mm, slab: moved kmem_cache_alloc_node comment to correct place
diff --git a/CREDITS b/CREDITS
index 2346b09..206d0fc 100644
--- a/CREDITS
+++ b/CREDITS
@@ -761,6 +761,10 @@
S: NN1 3QT
S: United Kingdom
+N: Massimo Dal Zotto
+E: dz@debian.org
+D: i8k Dell laptop SMM driver
+
N: Uwe Dannowski
E: Uwe.Dannowski@ira.uka.de
W: http://i30www.ira.uka.de/~dannowsk/
@@ -953,11 +957,11 @@
S: USA
N: Randy Dunlap
-E: rdunlap@xenotime.net
-W: http://www.xenotime.net/linux/linux.html
-W: http://www.linux-usb.org
+E: rdunlap@infradead.org
+W: http://www.infradead.org/~rdunlap/
D: Linux-USB subsystem, USB core/UHCI/printer/storage drivers
D: x86 SMP, ACPI, bootflag hacking
+D: documentation, builds
S: (ask for current address)
S: USA
@@ -1510,6 +1514,14 @@
D: Cobalt Networks (x86) support
D: This-and-That
+N: Mark M. Hoffman
+E: mhoffman@lightlink.com
+D: asb100, lm93 and smsc47b397 hardware monitoring drivers
+D: hwmon subsystem core
+D: hwmon subsystem maintainer
+D: i2c-sis96x and i2c-stub SMBus drivers
+S: USA
+
N: Dirk Hohndel
E: hohndel@suse.de
D: The XFree86[tm] Project
@@ -1572,12 +1584,12 @@
S: USA
N: Harald Hoyer
-E: harald.hoyer@parzelle.de
-W: http://parzelle.de/
+E: harald@redhat.com
+W: http://www.harald-hoyer.de
D: ip_masq_quake
D: md boot support
-S: Hohe Strasse 30
-S: D-70176 Stuttgart
+S: Am Strand 5
+S: D-19063 Schwerin
S: Germany
N: Jan Hubicka
diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX
index 8afe64f..0c4cc68 100644
--- a/Documentation/00-INDEX
+++ b/Documentation/00-INDEX
@@ -2,7 +2,7 @@
This is a brief list of all the files in ./linux/Documentation and what
they contain. If you add a documentation file, please list it here in
alphabetical order as well, or risk being hunted down like a rabid dog.
-Please try and keep the descriptions small enough to fit on one line.
+Please keep the descriptions small enough to fit on one line.
Thanks -- Paul G.
Following translations are available on the WWW:
@@ -20,24 +20,33 @@
Changes
- list of changes that break older software packages.
CodingStyle
- - how the boss likes the C code in the kernel to look.
-development-process/
- - An extended tutorial on how to work with the kernel development
- process.
+ - how the maintainers expect the C code in the kernel to look.
DMA-API.txt
- DMA API, pci_ API & extensions for non-consistent memory machines.
+DMA-API-HOWTO.txt
+ - Dynamic DMA mapping Guide
DMA-ISA-LPC.txt
- How to do DMA with ISA (and LPC) devices.
+DMA-attributes.txt
+ - listing of the various possible attributes a DMA region can have
DocBook/
- directory with DocBook templates etc. for kernel documentation.
+EDID/
+ - directory with info on customizing EDID for broken gfx/displays.
HOWTO
- the process and procedures of how to do Linux kernel development.
IPMI.txt
- info on Linux Intelligent Platform Management Interface (IPMI) Driver.
IRQ-affinity.txt
- how to select which CPU(s) handle which interrupt events on SMP.
+IRQ-domain.txt
+ - info on inerrupt numbering and setting up IRQ domains.
IRQ.txt
- description of what an IRQ is.
+Intel-IOMMU.txt
+ - basic info on the Intel IOMMU virtualization support.
+Makefile
+ - some files in Documentation dir are actually sample code to build
ManagementStyle
- how to (attempt to) manage kernel hackers.
RCU/
@@ -66,10 +75,16 @@
- description of various trees and how to apply their patches.
arm/
- directory with info about Linux on the ARM architecture.
+arm64/
+ - directory with info about Linux on the 64 bit ARM architecture.
atomic_ops.txt
- semantics and behavior of atomic and bitmask operations.
auxdisplay/
- misc. LCD driver documentation (cfag12864b, ks0108).
+backlight/
+ - directory with info on controlling backlights in flat panel displays
+bad_memory.txt
+ - how to use kernel parameters to exclude bad RAM regions.
basic_profiling.txt
- basic instructions for those who wants to profile Linux kernel.
binfmt_misc.txt
@@ -80,8 +95,14 @@
- info on the Block I/O (BIO) layer.
blockdev/
- info on block devices & drivers
+braille-console.txt
+ - info on how to use serial devices for Braille support.
+bt8xxgpio.txt
+ - info on how to modify a bt8xx video card for GPIO usage.
btmrvl.txt
- info on Marvell Bluetooth driver usage.
+bus-devices/
+ - directory with info on TI GPMC (General Purpose Memory Controller)
bus-virt-phys-mapping.txt
- how to access I/O mapped memory from within device drivers.
cachetlb.txt
@@ -90,6 +111,12 @@
- directory with information on the CD-ROM drivers that Linux has.
cgroups/
- cgroups features, including cpusets and memory controller.
+circular-buffers.txt
+ - how to make use of the existing circular buffer infrastructure
+clk.txt
+ - info on the common clock framework
+coccinelle.txt
+ - info on how to get and use the Coccinelle code checking tool.
connector/
- docs on the netlink based userspace<->kernel space communication mod.
console/
@@ -114,24 +141,42 @@
- information on the Dell Systems Management Base Driver.
debugging-modules.txt
- some notes on debugging modules after Linux 2.6.3.
+debugging-via-ohci1394.txt
+ - how to use firewire like a hardware debugger memory reader.
dell_rbu.txt
- document demonstrating the use of the Dell Remote BIOS Update driver.
+development-process/
+ - how to work with the mainline kernel development process.
device-mapper/
- directory with info on Device Mapper.
devices.txt
- plain ASCII listing of all the nodes in /dev/ with major minor #'s.
+devicetree/
+ - directory with info on device tree files used by OF/PowerPC/ARM
+digsig.txt
+ -info on the Digital Signature Verification API
+dma-buf-sharing.txt
+ - the DMA Buffer Sharing API Guide
+dmaengine.txt
+ -the DMA Engine API Guide
dontdiff
- file containing a list of files that should never be diff'ed.
driver-model/
- directory with info about Linux driver model.
dvb/
- info on Linux Digital Video Broadcast (DVB) subsystem.
+dynamic-debug-howto.txt
+ - how to use the dynamic debug (dyndbg) feature.
early-userspace/
- info about initramfs, klibc, and userspace early during boot.
edac.txt
- information on EDAC - Error Detection And Correction
eisa.txt
- info on EISA bus support.
+email-clients.txt
+ - info on how to use e-mail to send un-mangled (git) patches.
+extcon/
+ - directory with porting guide for Android kernel switch driver.
fault-injection/
- dir with docs about the fault injection capabilities infrastructure.
fb/
@@ -140,12 +185,24 @@
- info on the vfs and the various filesystems that Linux supports.
firmware_class/
- request_firmware() hotplug interface info.
+flexible-arrays.txt
+ - how to make use of flexible sized arrays in linux
+fmc/
+ - information about the FMC bus abstraction
frv/
- Fujitsu FR-V Linux documentation.
+futex-requeue-pi.txt
+ - info on requeueing of tasks from a non-PI futex to a PI futex
+gcov.txt
+ - use of GCC's coverage testing tool "gcov" with the Linux kernel
gpio.txt
- overview of GPIO (General Purpose Input/Output) access conventions.
+hid/
+ - directory with information on human interface devices
highuid.txt
- notes on the change from 16 bit to 32 bit user/group IDs.
+hwspinlock.txt
+ - hardware spinlock provides hardware assistance for synchronization
timers/
- info on the timer related topics
hw_random.txt
@@ -162,10 +219,14 @@
- directory with info about Linux on Intel 64 bit architecture.
infiniband/
- directory with documents concerning Linux InfiniBand support.
+init.txt
+ - what to do when the kernel can't find the 1st process to run.
initrd.txt
- how to use the RAM disk as an initial/temporary root filesystem.
input/
- info on Linux input device support.
+intel_txt.txt
+ - info on intel Trusted Execution Technology (intel TXT).
io-mapping.txt
- description of io_mapping functions in linux/io-mapping.h
io_ordering.txt
@@ -182,6 +243,8 @@
- directory with info on the Linux ISDN support, and supported cards.
java.txt
- info on the in-kernel binary support for Java(tm).
+ja_JP/
+ - directory with Japanese translations of various documents
kbuild/
- directory with info about the kernel build process.
kdump/
@@ -192,6 +255,12 @@
- listing of various WWW + books that document kernel internals.
kernel-parameters.txt
- summary listing of command line / boot prompt args for the kernel.
+kmemcheck.txt
+ - info on dynamic checker that detects uses of uninitialized memory.
+kmemleak.txt
+ - info on how to make use of the kernel memory leak detection system
+ko_KR/
+ - directory with Korean translations of various documents
kobject.txt
- info of the kobject infrastructure of the Linux kernel.
kprobes.txt
@@ -208,6 +277,8 @@
- semantics and behavior of local atomic operations.
lockdep-design.txt
- documentation on the runtime locking correctness validator.
+lockstat.txt
+ - info on collecting statistics on locks (and contention).
lockup-watchdogs.txt
- info on soft and hard lockup detectors (aka nmi_watchdog).
logo.gif
@@ -220,16 +291,28 @@
- list of magic numbers used to mark/protect kernel data structures.
md.txt
- info on boot arguments for the multiple devices driver.
+media-framework.txt
+ - info on media framework, its data structures, functions and usage.
memory-barriers.txt
- info on Linux kernel memory barriers.
+memory-devices/
+ - directory with info on parts like the Texas Instruments EMIF driver
memory-hotplug.txt
- Hotpluggable memory support, how to use and current status.
memory.txt
- info on typical Linux memory problems.
+metag/
+ - directory with info about Linux on Meta architecture.
mips/
- directory with info about Linux on MIPS architecture.
+misc-devices/
+ - directory with info about devices using the misc dev subsystem
mmc/
- directory with info about the MMC subsystem
+mn10300/
+ - directory with info about the mn10300 architecture port
+mtd/
+ - directory with info about memory technology devices (flash)
mono.txt
- how to execute Mono-based .NET binaries with the help of BINFMT_MISC.
mutex-design.txt
@@ -240,6 +323,8 @@
- directory with information on the NetLabel subsystem.
networking/
- directory with info on various aspects of networking with Linux.
+nfc/
+ - directory relating info about Near Field Communications support.
nommu-mmap.txt
- documentation about no-mmu memory mapping support.
numastat.txt
@@ -256,26 +341,46 @@
- description and usage of the low level parallel port functions.
pcmcia/
- info on the Linux PCMCIA driver.
+percpu-rw-semaphore.txt
+ - RCU based read-write semaphore optimized for locking for reading
pi-futex.txt
- - documentation on lightweight PI-futexes.
+ - documentation on lightweight priority inheritance futexes.
+pinctrl.txt
+ - info on pinctrl subsystem and the PINMUX/PINCONF and drivers
pnp.txt
- Linux Plug and Play documentation.
power/
- directory with info on Linux PCI power management.
powerpc/
- directory with info on using Linux with the PowerPC.
+prctl/
+ - directory with info on the priveledge control subsystem
preempt-locking.txt
- info on locking under a preemptive kernel.
printk-formats.txt
- how to get printk format specifiers right
+pps/
+ - directory with information on the pulse-per-second support
+ptp/
+ - directory with info on support for IEEE 1588 PTP clocks in Linux.
+pwm.txt
+ - info on the pulse width modulation driver subsystem
ramoops.txt
- documentation of the ramoops oops/panic logging module.
+rapidio/
+ - directory with info on RapidIO packet-based fabric interconnect
rbtree.txt
- info on what red-black trees are and what they are for.
+remoteproc.txt
+ - info on how to handle remote processor (e.g. AMP) offloads/usage.
+rfkill.txt
+ - info on the radio frequency kill switch subsystem/support.
robust-futex-ABI.txt
- documentation of the robust futex ABI.
robust-futexes.txt
- a description of what robust futexes are.
+rpmsg.txt
+ - info on the Remote Processor Messaging (rpmsg) Framework
rt-mutex-design.txt
- description of the RealTime mutex implementation design.
rt-mutex.txt
@@ -300,10 +405,10 @@
- short blurb on the SGI Visual Workstations.
sh/
- directory with info on porting Linux to a new architecture.
+smsc_ece1099.txt
+ -info on the smsc Keyboard Scan Expansion/GPIO Expansion device.
sound/
- directory with info on sound card support.
-sparc/
- - directory with info on using Linux on Sparc architecture.
sparse.txt
- info on how to obtain and use the sparse tool for typechecking.
spi/
@@ -314,6 +419,8 @@
- info on why the kernel does not have a stable in-kernel api or abi.
stable_kernel_rules.txt
- rules and procedures for the -stable kernel releases.
+static-keys.txt
+ - info on how static keys allow debug code in hotpaths via patching
svga.txt
- short guide on selecting video modes at boot via VGA BIOS.
sysfs-rules.txt
@@ -322,27 +429,53 @@
- directory with info on the /proc/sys/* files.
sysrq.txt
- info on the magic SysRq key.
-telephony/
- - directory with info on telephony (e.g. voice over IP) support.
+target/
+ - directory with info on generating TCM v4 fabric .ko modules
+thermal/
+ - directory with information on managing thermal issues (CPU/temp)
+trace/
+ - directory with info on tracing technologies within linux
+unaligned-memory-access.txt
+ - info on how to avoid arch breaking unaligned memory access in code.
unicode.txt
- info on the Unicode character/font mapping used in Linux.
unshare.txt
- description of the Linux unshare system call.
usb/
- directory with info regarding the Universal Serial Bus.
+vDSO/
+ - directory with info regarding virtual dynamic shared objects
+vfio.txt
+ - info on Virtual Function I/O used in guest/hypervisor instances.
+vgaarbiter.txt
+ - info on enable/disable the legacy decoding on different VGA devices
video-output.txt
- sysfs class driver interface to enable/disable a video output device.
video4linux/
- directory with info regarding video/TV/radio cards and linux.
+virtual/
+ - directory with information on the various linux virtualizations.
vm/
- directory with info on the Linux vm code.
+vme_api.txt
+ - file relating info on the VME bus API in linux
volatile-considered-harmful.txt
- Why the "volatile" type class should not be used
w1/
- directory with documents regarding the 1-wire (w1) subsystem.
watchdog/
- how to auto-reboot Linux if it has "fallen and can't get up". ;-)
+wimax/
+ - directory with info about Intel Wireless Wimax Connections
+workqueue.txt
+ - information on the Concurrency Managed Workqueue implementation
x86/x86_64/
- directory with info on Linux support for AMD x86-64 (Hammer) machines.
+xtensa/
+ - directory with documents relating to arch/xtensa port/implementation
+xz.txt
+ - how to make use of the XZ data compression within linux kernel
+zh_CN/
+ - directory with Chinese translations of various documents
zorro.txt
- info on writing drivers for Zorro bus devices found on Amigas.
diff --git a/Documentation/ABI/stable/sysfs-class-tpm b/Documentation/ABI/stable/sysfs-class-tpm
new file mode 100644
index 0000000..a60b45e
--- /dev/null
+++ b/Documentation/ABI/stable/sysfs-class-tpm
@@ -0,0 +1,185 @@
+What: /sys/class/misc/tpmX/device/
+Date: April 2005
+KernelVersion: 2.6.12
+Contact: tpmdd-devel@lists.sf.net
+Description: The device/ directory under a specific TPM instance exposes
+ the properties of that TPM chip
+
+
+What: /sys/class/misc/tpmX/device/active
+Date: April 2006
+KernelVersion: 2.6.17
+Contact: tpmdd-devel@lists.sf.net
+Description: The "active" property prints a '1' if the TPM chip is accepting
+ commands. An inactive TPM chip still contains all the state of
+ an active chip (Storage Root Key, NVRAM, etc), and can be
+ visible to the OS, but will only accept a restricted set of
+ commands. See the TPM Main Specification part 2, Structures,
+ section 17 for more information on which commands are
+ available.
+
+What: /sys/class/misc/tpmX/device/cancel
+Date: June 2005
+KernelVersion: 2.6.13
+Contact: tpmdd-devel@lists.sf.net
+Description: The "cancel" property allows you to cancel the currently
+ pending TPM command. Writing any value to cancel will call the
+ TPM vendor specific cancel operation.
+
+What: /sys/class/misc/tpmX/device/caps
+Date: April 2005
+KernelVersion: 2.6.12
+Contact: tpmdd-devel@lists.sf.net
+Description: The "caps" property contains TPM manufacturer and version info.
+
+ Example output:
+
+ Manufacturer: 0x53544d20
+ TCG version: 1.2
+ Firmware version: 8.16
+
+ Manufacturer is a hex dump of the 4 byte manufacturer info
+ space in a TPM. TCG version shows the TCG TPM spec level that
+ the chip supports. Firmware version is that of the chip and
+ is manufacturer specific.
+
+What: /sys/class/misc/tpmX/device/durations
+Date: March 2011
+KernelVersion: 3.1
+Contact: tpmdd-devel@lists.sf.net
+Description: The "durations" property shows the 3 vendor-specific values
+ used to wait for a short, medium and long TPM command. All
+ TPM commands are categorized as short, medium or long in
+ execution time, so that the driver doesn't have to wait
+ any longer than necessary before starting to poll for a
+ result.
+
+ Example output:
+
+ 3015000 4508000 180995000 [original]
+
+ Here the short, medium and long durations are displayed in
+ usecs. "[original]" indicates that the values are displayed
+ unmodified from when they were queried from the chip.
+ Durations can be modified in the case where a buggy chip
+ reports them in msec instead of usec and they need to be
+ scaled to be displayed in usecs. In this case "[adjusted]"
+ will be displayed in place of "[original]".
+
+What: /sys/class/misc/tpmX/device/enabled
+Date: April 2006
+KernelVersion: 2.6.17
+Contact: tpmdd-devel@lists.sf.net
+Description: The "enabled" property prints a '1' if the TPM chip is enabled,
+ meaning that it should be visible to the OS. This property
+ may be visible but produce a '0' after some operation that
+ disables the TPM.
+
+What: /sys/class/misc/tpmX/device/owned
+Date: April 2006
+KernelVersion: 2.6.17
+Contact: tpmdd-devel@lists.sf.net
+Description: The "owned" property produces a '1' if the TPM_TakeOwnership
+ ordinal has been executed successfully in the chip. A '0'
+ indicates that ownership hasn't been taken.
+
+What: /sys/class/misc/tpmX/device/pcrs
+Date: April 2005
+KernelVersion: 2.6.12
+Contact: tpmdd-devel@lists.sf.net
+Description: The "pcrs" property will dump the current value of all Platform
+ Configuration Registers in the TPM. Note that since these
+ values may be constantly changing, the output is only valid
+ for a snapshot in time.
+
+ Example output:
+
+ PCR-00: 3A 3F 78 0F 11 A4 B4 99 69 FC AA 80 CD 6E 39 57 C3 3B 22 75
+ PCR-01: 3A 3F 78 0F 11 A4 B4 99 69 FC AA 80 CD 6E 39 57 C3 3B 22 75
+ PCR-02: 3A 3F 78 0F 11 A4 B4 99 69 FC AA 80 CD 6E 39 57 C3 3B 22 75
+ PCR-03: 3A 3F 78 0F 11 A4 B4 99 69 FC AA 80 CD 6E 39 57 C3 3B 22 75
+ PCR-04: 3A 3F 78 0F 11 A4 B4 99 69 FC AA 80 CD 6E 39 57 C3 3B 22 75
+ ...
+
+ The number of PCRs and hex bytes needed to represent a PCR
+ value will vary depending on TPM chip version. For TPM 1.1 and
+ 1.2 chips, PCRs represent SHA-1 hashes, which are 20 bytes
+ long. Use the "caps" property to determine TPM version.
+
+What: /sys/class/misc/tpmX/device/pubek
+Date: April 2005
+KernelVersion: 2.6.12
+Contact: tpmdd-devel@lists.sf.net
+Description: The "pubek" property will return the TPM's public endorsement
+ key if possible. If the TPM has had ownership established and
+ is version 1.2, the pubek will not be available without the
+ owner's authorization. Since the TPM driver doesn't store any
+ secrets, it can't authorize its own request for the pubek,
+ making it unaccessible. The public endorsement key is gener-
+ ated at TPM menufacture time and exists for the life of the
+ chip.
+
+ Example output:
+
+ Algorithm: 00 00 00 01
+ Encscheme: 00 03
+ Sigscheme: 00 01
+ Parameters: 00 00 08 00 00 00 00 02 00 00 00 00
+ Modulus length: 256
+ Modulus:
+ B4 76 41 82 C9 20 2C 10 18 40 BC 8B E5 44 4C 6C
+ 3A B2 92 0C A4 9B 2A 83 EB 5C 12 85 04 48 A0 B6
+ 1E E4 81 84 CE B2 F2 45 1C F0 85 99 61 02 4D EB
+ 86 C4 F7 F3 29 60 52 93 6B B2 E5 AB 8B A9 09 E3
+ D7 0E 7D CA 41 BF 43 07 65 86 3C 8C 13 7A D0 8B
+ 82 5E 96 0B F8 1F 5F 34 06 DA A2 52 C1 A9 D5 26
+ 0F F4 04 4B D9 3F 2D F2 AC 2F 74 64 1F 8B CD 3E
+ 1E 30 38 6C 70 63 69 AB E2 50 DF 49 05 2E E1 8D
+ 6F 78 44 DA 57 43 69 EE 76 6C 38 8A E9 8E A3 F0
+ A7 1F 3C A8 D0 12 15 3E CA 0E BD FA 24 CD 33 C6
+ 47 AE A4 18 83 8E 22 39 75 93 86 E6 FD 66 48 B6
+ 10 AD 94 14 65 F9 6A 17 78 BD 16 53 84 30 BF 70
+ E0 DC 65 FD 3C C6 B0 1E BF B9 C1 B5 6C EF B1 3A
+ F8 28 05 83 62 26 11 DC B4 6B 5A 97 FF 32 26 B6
+ F7 02 71 CF 15 AE 16 DD D1 C1 8E A8 CF 9B 50 7B
+ C3 91 FF 44 1E CF 7C 39 FE 17 77 21 20 BD CE 9B
+
+ Possible values:
+
+ Algorithm: TPM_ALG_RSA (1)
+ Encscheme: TPM_ES_RSAESPKCSv15 (2)
+ TPM_ES_RSAESOAEP_SHA1_MGF1 (3)
+ Sigscheme: TPM_SS_NONE (1)
+ Parameters, a byte string of 3 u32 values:
+ Key Length (bits): 00 00 08 00 (2048)
+ Num primes: 00 00 00 02 (2)
+ Exponent Size: 00 00 00 00 (0 means the
+ default exp)
+ Modulus Length: 256 (bytes)
+ Modulus: The 256 byte Endorsement Key modulus
+
+What: /sys/class/misc/tpmX/device/temp_deactivated
+Date: April 2006
+KernelVersion: 2.6.17
+Contact: tpmdd-devel@lists.sf.net
+Description: The "temp_deactivated" property returns a '1' if the chip has
+ been temporarily dectivated, usually until the next power
+ cycle. Whether a warm boot (reboot) will clear a TPM chip
+ from a temp_deactivated state is platform specific.
+
+What: /sys/class/misc/tpmX/device/timeouts
+Date: March 2011
+KernelVersion: 3.1
+Contact: tpmdd-devel@lists.sf.net
+Description: The "timeouts" property shows the 4 vendor-specific values
+ for the TPM's interface spec timeouts. The use of these
+ timeouts is defined by the TPM interface spec that the chip
+ conforms to.
+
+ Example output:
+
+ 750000 750000 750000 750000 [original]
+
+ The four timeout values are shown in usecs, with a trailing
+ "[original]" or "[adjusted]" depending on whether the values
+ were scaled by the driver to be reported in usec from msecs.
diff --git a/Documentation/ABI/stable/sysfs-driver-ib_srp b/Documentation/ABI/stable/sysfs-driver-ib_srp
index 481aae9..5c53d28 100644
--- a/Documentation/ABI/stable/sysfs-driver-ib_srp
+++ b/Documentation/ABI/stable/sysfs-driver-ib_srp
@@ -54,6 +54,13 @@
ib_srp. Specifying a value that exceeds cmd_sg_entries is
only safe with partial memory descriptor list support enabled
(allow_ext_sg=1).
+ * comp_vector, a number in the range 0..n-1 specifying the
+ MSI-X completion vector. Some HCA's allocate multiple (n)
+ MSI-X vectors per HCA port. If the IRQ affinity masks of
+ these interrupts have been configured such that each MSI-X
+ interrupt is handled by a different CPU then the comp_vector
+ parameter can be used to spread the SRP completion workload
+ over multiple CPU's.
What: /sys/class/infiniband_srp/srp-<hca>-<port_number>/ibdev
Date: January 2, 2006
diff --git a/Documentation/ABI/stable/sysfs-module b/Documentation/ABI/stable/sysfs-module
index a0dd21c..6272ae5 100644
--- a/Documentation/ABI/stable/sysfs-module
+++ b/Documentation/ABI/stable/sysfs-module
@@ -4,9 +4,13 @@
/sys/module/MODULENAME
The name of the module that is in the kernel. This
- module name will show up either if the module is built
- directly into the kernel, or if it is loaded as a
- dynamic module.
+ module name will always show up if the module is loaded as a
+ dynamic module. If it is built directly into the kernel, it
+ will only show up if it has a version or at least one
+ parameter.
+
+ Note: The conditions of creation in the built-in case are not
+ by design and may be removed in the future.
/sys/module/MODULENAME/parameters
This directory contains individual files that are each
diff --git a/Documentation/ABI/testing/configfs-usb-gadget b/Documentation/ABI/testing/configfs-usb-gadget
new file mode 100644
index 0000000..01e769d
--- /dev/null
+++ b/Documentation/ABI/testing/configfs-usb-gadget
@@ -0,0 +1,81 @@
+What: /config/usb-gadget
+Date: Jun 2013
+KenelVersion: 3.11
+Description:
+ This group contains sub-groups corresponding to created
+ USB gadgets.
+
+What: /config/usb-gadget/gadget
+Date: Jun 2013
+KenelVersion: 3.11
+Description:
+
+ The attributes of a gadget:
+
+ UDC - bind a gadget to UDC/unbind a gadget;
+ write UDC's name found in /sys/class/udc/*
+ to bind a gadget, empty string "" to unbind.
+
+ bDeviceClass - USB device class code
+ bDeviceSubClass - USB device subclass code
+ bDeviceProtocol - USB device protocol code
+ bMaxPacketSize0 - maximum endpoint 0 packet size
+ bcdDevice - bcd device release number
+ bcdUSB - bcd USB specification version number
+ idProduct - product ID
+ idVendor - vendor ID
+
+What: /config/usb-gadget/gadget/configs
+Date: Jun 2013
+KenelVersion: 3.11
+Description:
+ This group contains a USB gadget's configurations
+
+What: /config/usb-gadget/gadget/configs/config
+Date: Jun 2013
+KernelVersion: 3.11
+Description:
+ The attributes of a configuration:
+
+ bmAttributes - configuration characteristics
+ MaxPower - maximum power consumption from the bus
+
+What: /config/usb-gadget/gadget/configs/config/strings
+Date: Jun 2013
+KernelVersion: 3.11
+Description:
+ This group contains subdirectories for language-specific
+ strings for this configuration.
+
+What: /config/usb-gadget/gadget/configs/config/strings/language
+Date: Jun 2013
+KernelVersion: 3.11
+Description:
+ The attributes:
+
+ configuration - configuration description
+
+
+What: /config/usb-gadget/gadget/functions
+Date: Jun 2013
+KenelVersion: 3.11
+Description:
+ This group contains functions available to this USB gadget.
+
+What: /config/usb-gadget/gadget/strings
+Date: Jun 2013
+KenelVersion: 3.11
+Description:
+ This group contains subdirectories for language-specific
+ strings for this gadget.
+
+What: /config/usb-gadget/gadget/strings/language
+Date: Jun 2013
+KenelVersion: 3.11
+Description:
+ The attributes:
+
+ serialnumber - gadget's serial number (string)
+ product - gadget's product description
+ manufacturer - gadget's manufacturer description
+
diff --git a/Documentation/ABI/testing/configfs-usb-gadget-acm b/Documentation/ABI/testing/configfs-usb-gadget-acm
new file mode 100644
index 0000000..5708a56
--- /dev/null
+++ b/Documentation/ABI/testing/configfs-usb-gadget-acm
@@ -0,0 +1,8 @@
+What: /config/usb-gadget/gadget/functions/acm.name
+Date: Jun 2013
+KenelVersion: 3.11
+Description:
+
+ This item contains just one readonly attribute: port_num.
+ It contains the port number of the /dev/ttyGS<n> device
+ associated with acm function's instance "name".
diff --git a/Documentation/ABI/testing/configfs-usb-gadget-ecm b/Documentation/ABI/testing/configfs-usb-gadget-ecm
new file mode 100644
index 0000000..6b9a582
--- /dev/null
+++ b/Documentation/ABI/testing/configfs-usb-gadget-ecm
@@ -0,0 +1,16 @@
+What: /config/usb-gadget/gadget/functions/ecm.name
+Date: Jun 2013
+KenelVersion: 3.11
+Description:
+ The attributes:
+
+ ifname - network device interface name associated with
+ this function instance
+ qmult - queue length multiplier for high and
+ super speed
+ host_addr - MAC address of host's end of this
+ Ethernet over USB link
+ dev_addr - MAC address of device's end of this
+ Ethernet over USB link
+
+
diff --git a/Documentation/ABI/testing/configfs-usb-gadget-eem b/Documentation/ABI/testing/configfs-usb-gadget-eem
new file mode 100644
index 0000000..dbddf36
--- /dev/null
+++ b/Documentation/ABI/testing/configfs-usb-gadget-eem
@@ -0,0 +1,14 @@
+What: /config/usb-gadget/gadget/functions/eem.name
+Date: Jun 2013
+KenelVersion: 3.11
+Description:
+ The attributes:
+
+ ifname - network device interface name associated with
+ this function instance
+ qmult - queue length multiplier for high and
+ super speed
+ host_addr - MAC address of host's end of this
+ Ethernet over USB link
+ dev_addr - MAC address of device's end of this
+ Ethernet over USB link
diff --git a/Documentation/ABI/testing/configfs-usb-gadget-ncm b/Documentation/ABI/testing/configfs-usb-gadget-ncm
new file mode 100644
index 0000000..bc309f423
--- /dev/null
+++ b/Documentation/ABI/testing/configfs-usb-gadget-ncm
@@ -0,0 +1,15 @@
+What: /config/usb-gadget/gadget/functions/ncm.name
+Date: Jun 2013
+KenelVersion: 3.11
+Description:
+ The attributes:
+
+ ifname - network device interface name associated with
+ this function instance
+ qmult - queue length multiplier for high and
+ super speed
+ host_addr - MAC address of host's end of this
+ Ethernet over USB link
+ dev_addr - MAC address of device's end of this
+ Ethernet over USB link
+
diff --git a/Documentation/ABI/testing/configfs-usb-gadget-obex b/Documentation/ABI/testing/configfs-usb-gadget-obex
new file mode 100644
index 0000000..aaa5c96
--- /dev/null
+++ b/Documentation/ABI/testing/configfs-usb-gadget-obex
@@ -0,0 +1,9 @@
+What: /config/usb-gadget/gadget/functions/obex.name
+Date: Jun 2013
+KenelVersion: 3.11
+Description:
+
+ This item contains just one readonly attribute: port_num.
+ It contains the port number of the /dev/ttyGS<n> device
+ associated with obex function's instance "name".
+
diff --git a/Documentation/ABI/testing/configfs-usb-gadget-phonet b/Documentation/ABI/testing/configfs-usb-gadget-phonet
new file mode 100644
index 0000000..3e3b742
--- /dev/null
+++ b/Documentation/ABI/testing/configfs-usb-gadget-phonet
@@ -0,0 +1,8 @@
+What: /config/usb-gadget/gadget/functions/phonet.name
+Date: Jun 2013
+KenelVersion: 3.11
+Description:
+
+ This item contains just one readonly attribute: ifname.
+ It contains the network interface name assigned during
+ network device registration.
diff --git a/Documentation/ABI/testing/configfs-usb-gadget-rndis b/Documentation/ABI/testing/configfs-usb-gadget-rndis
new file mode 100644
index 0000000..822e6da
--- /dev/null
+++ b/Documentation/ABI/testing/configfs-usb-gadget-rndis
@@ -0,0 +1,14 @@
+What: /config/usb-gadget/gadget/functions/rndis.name
+Date: Jun 2013
+KenelVersion: 3.11
+Description:
+ The attributes:
+
+ ifname - network device interface name associated with
+ this function instance
+ qmult - queue length multiplier for high and
+ super speed
+ host_addr - MAC address of host's end of this
+ Ethernet over USB link
+ dev_addr - MAC address of device's end of this
+ Ethernet over USB link
diff --git a/Documentation/ABI/testing/configfs-usb-gadget-serial b/Documentation/ABI/testing/configfs-usb-gadget-serial
new file mode 100644
index 0000000..16f130c1
--- /dev/null
+++ b/Documentation/ABI/testing/configfs-usb-gadget-serial
@@ -0,0 +1,9 @@
+What: /config/usb-gadget/gadget/functions/gser.name
+Date: Jun 2013
+KenelVersion: 3.11
+Description:
+
+ This item contains just one readonly attribute: port_num.
+ It contains the port number of the /dev/ttyGS<n> device
+ associated with gser function's instance "name".
+
diff --git a/Documentation/ABI/testing/configfs-usb-gadget-subset b/Documentation/ABI/testing/configfs-usb-gadget-subset
new file mode 100644
index 0000000..154ae59
--- /dev/null
+++ b/Documentation/ABI/testing/configfs-usb-gadget-subset
@@ -0,0 +1,14 @@
+What: /config/usb-gadget/gadget/functions/geth.name
+Date: Jun 2013
+KenelVersion: 3.11
+Description:
+ The attributes:
+
+ ifname - network device interface name associated with
+ this function instance
+ qmult - queue length multiplier for high and
+ super speed
+ host_addr - MAC address of host's end of this
+ Ethernet over USB link
+ dev_addr - MAC address of device's end of this
+ Ethernet over USB link
diff --git a/Documentation/ABI/testing/ima_policy b/Documentation/ABI/testing/ima_policy
index ec0a38e..f1c5cc9 100644
--- a/Documentation/ABI/testing/ima_policy
+++ b/Documentation/ABI/testing/ima_policy
@@ -18,17 +18,21 @@
rule format: action [condition ...]
action: measure | dont_measure | appraise | dont_appraise | audit
- condition:= base | lsm
- base: [[func=] [mask=] [fsmagic=] [uid=] [fowner]]
+ condition:= base | lsm [option]
+ base: [[func=] [mask=] [fsmagic=] [fsuuid=] [uid=]
+ [fowner]]
lsm: [[subj_user=] [subj_role=] [subj_type=]
[obj_user=] [obj_role=] [obj_type=]]
+ option: [[appraise_type=]]
- base: func:= [BPRM_CHECK][FILE_MMAP][FILE_CHECK][MODULE_CHECK]
+ base: func:= [BPRM_CHECK][MMAP_CHECK][FILE_CHECK][MODULE_CHECK]
mask:= [MAY_READ] [MAY_WRITE] [MAY_APPEND] [MAY_EXEC]
fsmagic:= hex value
+ fsuuid:= file system UUID (e.g 8bcbe394-4f13-4144-be8e-5aa9ea2ce2f6)
uid:= decimal value
fowner:=decimal value
lsm: are LSM specific
+ option: appraise_type:= [imasig]
default policy:
# PROC_SUPER_MAGIC
diff --git a/Documentation/ABI/testing/pstore b/Documentation/ABI/testing/pstore
index ff1df4e..5fca9f5 100644
--- a/Documentation/ABI/testing/pstore
+++ b/Documentation/ABI/testing/pstore
@@ -1,4 +1,4 @@
-Where: /dev/pstore/...
+Where: /sys/fs/pstore/... (or /dev/pstore/...)
Date: March 2011
Kernel Version: 2.6.39
Contact: tony.luck@intel.com
@@ -11,9 +11,9 @@
of the console log is captured, but other interesting
data can also be saved.
- # mount -t pstore -o kmsg_bytes=8000 - /dev/pstore
+ # mount -t pstore -o kmsg_bytes=8000 - /sys/fs/pstore
- $ ls -l /dev/pstore
+ $ ls -l /sys/fs/pstore/
total 0
-r--r--r-- 1 root root 7896 Nov 30 15:38 dmesg-erst-1
@@ -27,9 +27,9 @@
the file will signal to the underlying persistent storage
device that it can reclaim the space for later re-use.
- $ rm /dev/pstore/dmesg-erst-1
+ $ rm /sys/fs/pstore/dmesg-erst-1
- The expectation is that all files in /dev/pstore
+ The expectation is that all files in /sys/fs/pstore/
will be saved elsewhere and erased from persistent store
soon after boot to free up space ready for the next
catastrophe.
diff --git a/Documentation/ABI/testing/sysfs-block-bcache b/Documentation/ABI/testing/sysfs-block-bcache
new file mode 100644
index 0000000..9e4bbc5
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-block-bcache
@@ -0,0 +1,156 @@
+What: /sys/block/<disk>/bcache/unregister
+Date: November 2010
+Contact: Kent Overstreet <kent.overstreet@gmail.com>
+Description:
+ A write to this file causes the backing device or cache to be
+ unregistered. If a backing device had dirty data in the cache,
+ writeback mode is automatically disabled and all dirty data is
+ flushed before the device is unregistered. Caches unregister
+ all associated backing devices before unregistering themselves.
+
+What: /sys/block/<disk>/bcache/clear_stats
+Date: November 2010
+Contact: Kent Overstreet <kent.overstreet@gmail.com>
+Description:
+ Writing to this file resets all the statistics for the device.
+
+What: /sys/block/<disk>/bcache/cache
+Date: November 2010
+Contact: Kent Overstreet <kent.overstreet@gmail.com>
+Description:
+ For a backing device that has cache, a symlink to
+ the bcache/ dir of that cache.
+
+What: /sys/block/<disk>/bcache/cache_hits
+Date: November 2010
+Contact: Kent Overstreet <kent.overstreet@gmail.com>
+Description:
+ For backing devices: integer number of full cache hits,
+ counted per bio. A partial cache hit counts as a miss.
+
+What: /sys/block/<disk>/bcache/cache_misses
+Date: November 2010
+Contact: Kent Overstreet <kent.overstreet@gmail.com>
+Description:
+ For backing devices: integer number of cache misses.
+
+What: /sys/block/<disk>/bcache/cache_hit_ratio
+Date: November 2010
+Contact: Kent Overstreet <kent.overstreet@gmail.com>
+Description:
+ For backing devices: cache hits as a percentage.
+
+What: /sys/block/<disk>/bcache/sequential_cutoff
+Date: November 2010
+Contact: Kent Overstreet <kent.overstreet@gmail.com>
+Description:
+ For backing devices: Threshold past which sequential IO will
+ skip the cache. Read and written as bytes in human readable
+ units (i.e. echo 10M > sequntial_cutoff).
+
+What: /sys/block/<disk>/bcache/bypassed
+Date: November 2010
+Contact: Kent Overstreet <kent.overstreet@gmail.com>
+Description:
+ Sum of all reads and writes that have bypassed the cache (due
+ to the sequential cutoff). Expressed as bytes in human
+ readable units.
+
+What: /sys/block/<disk>/bcache/writeback
+Date: November 2010
+Contact: Kent Overstreet <kent.overstreet@gmail.com>
+Description:
+ For backing devices: When on, writeback caching is enabled and
+ writes will be buffered in the cache. When off, caching is in
+ writethrough mode; reads and writes will be added to the
+ cache but no write buffering will take place.
+
+What: /sys/block/<disk>/bcache/writeback_running
+Date: November 2010
+Contact: Kent Overstreet <kent.overstreet@gmail.com>
+Description:
+ For backing devices: when off, dirty data will not be written
+ from the cache to the backing device. The cache will still be
+ used to buffer writes until it is mostly full, at which point
+ writes transparently revert to writethrough mode. Intended only
+ for benchmarking/testing.
+
+What: /sys/block/<disk>/bcache/writeback_delay
+Date: November 2010
+Contact: Kent Overstreet <kent.overstreet@gmail.com>
+Description:
+ For backing devices: In writeback mode, when dirty data is
+ written to the cache and the cache held no dirty data for that
+ backing device, writeback from cache to backing device starts
+ after this delay, expressed as an integer number of seconds.
+
+What: /sys/block/<disk>/bcache/writeback_percent
+Date: November 2010
+Contact: Kent Overstreet <kent.overstreet@gmail.com>
+Description:
+ For backing devices: If nonzero, writeback from cache to
+ backing device only takes place when more than this percentage
+ of the cache is used, allowing more write coalescing to take
+ place and reducing total number of writes sent to the backing
+ device. Integer between 0 and 40.
+
+What: /sys/block/<disk>/bcache/synchronous
+Date: November 2010
+Contact: Kent Overstreet <kent.overstreet@gmail.com>
+Description:
+ For a cache, a boolean that allows synchronous mode to be
+ switched on and off. In synchronous mode all writes are ordered
+ such that the cache can reliably recover from unclean shutdown;
+ if disabled bcache will not generally wait for writes to
+ complete but if the cache is not shut down cleanly all data
+ will be discarded from the cache. Should not be turned off with
+ writeback caching enabled.
+
+What: /sys/block/<disk>/bcache/discard
+Date: November 2010
+Contact: Kent Overstreet <kent.overstreet@gmail.com>
+Description:
+ For a cache, a boolean allowing discard/TRIM to be turned off
+ or back on if the device supports it.
+
+What: /sys/block/<disk>/bcache/bucket_size
+Date: November 2010
+Contact: Kent Overstreet <kent.overstreet@gmail.com>
+Description:
+ For a cache, bucket size in human readable units, as set at
+ cache creation time; should match the erase block size of the
+ SSD for optimal performance.
+
+What: /sys/block/<disk>/bcache/nbuckets
+Date: November 2010
+Contact: Kent Overstreet <kent.overstreet@gmail.com>
+Description:
+ For a cache, the number of usable buckets.
+
+What: /sys/block/<disk>/bcache/tree_depth
+Date: November 2010
+Contact: Kent Overstreet <kent.overstreet@gmail.com>
+Description:
+ For a cache, height of the btree excluding leaf nodes (i.e. a
+ one node tree will have a depth of 0).
+
+What: /sys/block/<disk>/bcache/btree_cache_size
+Date: November 2010
+Contact: Kent Overstreet <kent.overstreet@gmail.com>
+Description:
+ Number of btree buckets/nodes that are currently cached in
+ memory; cache dynamically grows and shrinks in response to
+ memory pressure from the rest of the system.
+
+What: /sys/block/<disk>/bcache/written
+Date: November 2010
+Contact: Kent Overstreet <kent.overstreet@gmail.com>
+Description:
+ For a cache, total amount of data in human readable units
+ written to the cache, excluding all metadata.
+
+What: /sys/block/<disk>/bcache/btree_written
+Date: November 2010
+Contact: Kent Overstreet <kent.overstreet@gmail.com>
+Description:
+ For a cache, sum of all btree writes in human readable units.
diff --git a/Documentation/ABI/testing/sysfs-bus-acpi b/Documentation/ABI/testing/sysfs-bus-acpi
new file mode 100644
index 0000000..7fa9cbc
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-acpi
@@ -0,0 +1,58 @@
+What: /sys/bus/acpi/devices/.../path
+Date: December 2006
+Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
+Description:
+ This attribute indicates the full path of ACPI namespace
+ object associated with the device object. For example,
+ \_SB_.PCI0.
+ This file is not present for device objects representing
+ fixed ACPI hardware features (like power and sleep
+ buttons).
+
+What: /sys/bus/acpi/devices/.../modalias
+Date: July 2007
+Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
+Description:
+ This attribute indicates the PNP IDs of the device object.
+ That is acpi:HHHHHHHH:[CCCCCCC:]. Where each HHHHHHHH or
+ CCCCCCCC contains device object's PNPID (_HID or _CID).
+
+What: /sys/bus/acpi/devices/.../hid
+Date: April 2005
+Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
+Description:
+ This attribute indicates the hardware ID (_HID) of the
+ device object. For example, PNP0103.
+ This file is present for device objects having the _HID
+ control method.
+
+What: /sys/bus/acpi/devices/.../description
+Date: October 2012
+Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
+Description:
+ This attribute contains the output of the device object's
+ _STR control method, if present.
+
+What: /sys/bus/acpi/devices/.../adr
+Date: October 2012
+Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
+Description:
+ This attribute contains the output of the device object's
+ _ADR control method, which is present for ACPI device
+ objects representing devices having standard enumeration
+ algorithms, such as PCI.
+
+What: /sys/bus/acpi/devices/.../uid
+Date: October 2012
+Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
+Description:
+ This attribute contains the output of the device object's
+ _UID control method, if present.
+
+What: /sys/bus/acpi/devices/.../eject
+Date: December 2006
+Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
+Description:
+ Writing 1 to this attribute will trigger hot removal of
+ this device object. This file exists for every device
+ object that has _EJ0 method.
diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices-events b/Documentation/ABI/testing/sysfs-bus-event_source-devices-events
new file mode 100644
index 0000000..3c1cc24
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-events
@@ -0,0 +1,84 @@
+What: /sys/devices/cpu/events/
+ /sys/devices/cpu/events/branch-misses
+ /sys/devices/cpu/events/cache-references
+ /sys/devices/cpu/events/cache-misses
+ /sys/devices/cpu/events/stalled-cycles-frontend
+ /sys/devices/cpu/events/branch-instructions
+ /sys/devices/cpu/events/stalled-cycles-backend
+ /sys/devices/cpu/events/instructions
+ /sys/devices/cpu/events/cpu-cycles
+
+Date: 2013/01/08
+
+Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
+
+Description: Generic performance monitoring events
+
+ A collection of performance monitoring events that may be
+ supported by many/most CPUs. These events can be monitored
+ using the 'perf(1)' tool.
+
+ The contents of each file would look like:
+
+ event=0xNNNN
+
+ where 'N' is a hex digit and the number '0xNNNN' shows the
+ "raw code" for the perf event identified by the file's
+ "basename".
+
+
+What: /sys/devices/cpu/events/PM_1PLUS_PPC_CMPL
+ /sys/devices/cpu/events/PM_BRU_FIN
+ /sys/devices/cpu/events/PM_BR_MPRED
+ /sys/devices/cpu/events/PM_CMPLU_STALL
+ /sys/devices/cpu/events/PM_CMPLU_STALL_BRU
+ /sys/devices/cpu/events/PM_CMPLU_STALL_DCACHE_MISS
+ /sys/devices/cpu/events/PM_CMPLU_STALL_DFU
+ /sys/devices/cpu/events/PM_CMPLU_STALL_DIV
+ /sys/devices/cpu/events/PM_CMPLU_STALL_ERAT_MISS
+ /sys/devices/cpu/events/PM_CMPLU_STALL_FXU
+ /sys/devices/cpu/events/PM_CMPLU_STALL_IFU
+ /sys/devices/cpu/events/PM_CMPLU_STALL_LSU
+ /sys/devices/cpu/events/PM_CMPLU_STALL_REJECT
+ /sys/devices/cpu/events/PM_CMPLU_STALL_SCALAR
+ /sys/devices/cpu/events/PM_CMPLU_STALL_SCALAR_LONG
+ /sys/devices/cpu/events/PM_CMPLU_STALL_STORE
+ /sys/devices/cpu/events/PM_CMPLU_STALL_THRD
+ /sys/devices/cpu/events/PM_CMPLU_STALL_VECTOR
+ /sys/devices/cpu/events/PM_CMPLU_STALL_VECTOR_LONG
+ /sys/devices/cpu/events/PM_CYC
+ /sys/devices/cpu/events/PM_GCT_NOSLOT_BR_MPRED
+ /sys/devices/cpu/events/PM_GCT_NOSLOT_BR_MPRED_IC_MISS
+ /sys/devices/cpu/events/PM_GCT_NOSLOT_CYC
+ /sys/devices/cpu/events/PM_GCT_NOSLOT_IC_MISS
+ /sys/devices/cpu/events/PM_GRP_CMPL
+ /sys/devices/cpu/events/PM_INST_CMPL
+ /sys/devices/cpu/events/PM_LD_MISS_L1
+ /sys/devices/cpu/events/PM_LD_REF_L1
+ /sys/devices/cpu/events/PM_RUN_CYC
+ /sys/devices/cpu/events/PM_RUN_INST_CMPL
+
+Date: 2013/01/08
+
+Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
+ Linux Powerpc mailing list <linuxppc-dev@ozlabs.org>
+
+Description: POWER-systems specific performance monitoring events
+
+ A collection of performance monitoring events that may be
+ supported by the POWER CPU. These events can be monitored
+ using the 'perf(1)' tool.
+
+ These events may not be supported by other CPUs.
+
+ The contents of each file would look like:
+
+ event=0xNNNN
+
+ where 'N' is a hex digit and the number '0xNNNN' shows the
+ "raw code" for the perf event identified by the file's
+ "basename".
+
+ Further, multiple terms like 'event=0xNNNN' can be specified
+ and separated with comma. All available terms are defined in
+ the /sys/bus/event_source/devices/<dev>/format file.
diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices-format b/Documentation/ABI/testing/sysfs-bus-event_source-devices-format
index 079afc7..77f47ff 100644
--- a/Documentation/ABI/testing/sysfs-bus-event_source-devices-format
+++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-format
@@ -9,6 +9,12 @@
we want to export, so that userspace can deal with sane
name/value pairs.
+ Userspace must be prepared for the possibility that attributes
+ define overlapping bit ranges. For example:
+ attr1 = 'config:0-23'
+ attr2 = 'config:0-7'
+ attr3 = 'config:12-35'
+
Example: 'config1:1,6-10,44'
Defines contents of attribute that occupies bits 1,6-10,44 of
perf_event_attr::config1.
diff --git a/Documentation/ABI/testing/sysfs-bus-fcoe b/Documentation/ABI/testing/sysfs-bus-fcoe
index 50e2a80..21640ea 100644
--- a/Documentation/ABI/testing/sysfs-bus-fcoe
+++ b/Documentation/ABI/testing/sysfs-bus-fcoe
@@ -1,14 +1,53 @@
-What: /sys/bus/fcoe/ctlr_X
+What: /sys/bus/fcoe/
+Date: August 2012
+KernelVersion: TBD
+Contact: Robert Love <robert.w.love@intel.com>, devel@open-fcoe.org
+Description: The FCoE bus. Attributes in this directory are control interfaces.
+Attributes:
+
+ ctlr_create: 'FCoE Controller' instance creation interface. Writing an
+ <ifname> to this file will allocate and populate sysfs with a
+ fcoe_ctlr_device (ctlr_X). The user can then configure any
+ per-port settings and finally write to the fcoe_ctlr_device's
+ 'start' attribute to begin the kernel's discovery and login
+ process.
+
+ ctlr_destroy: 'FCoE Controller' instance removal interface. Writing a
+ fcoe_ctlr_device's sysfs name to this file will log the
+ fcoe_ctlr_device out of the fabric or otherwise connected
+ FCoE devices. It will also free all kernel memory allocated
+ for this fcoe_ctlr_device and any structures associated
+ with it, this includes the scsi_host.
+
+What: /sys/bus/fcoe/devices/ctlr_X
Date: March 2012
KernelVersion: TBD
Contact: Robert Love <robert.w.love@intel.com>, devel@open-fcoe.org
-Description: 'FCoE Controller' instances on the fcoe bus
+Description: 'FCoE Controller' instances on the fcoe bus.
+ The FCoE Controller now has a three stage creation process.
+ 1) Write interface name to ctlr_create 2) Configure the FCoE
+ Controller (ctlr_X) 3) Enable the FCoE Controller to begin
+ discovery and login. The FCoE Controller is destroyed by
+ writing it's name, i.e. ctlr_X to the ctlr_delete file.
+
Attributes:
fcf_dev_loss_tmo: Device loss timeout peroid (see below). Changing
this value will change the dev_loss_tmo for all
FCFs discovered by this controller.
+ mode: Display or change the FCoE Controller's mode. Possible
+ modes are 'Fabric' and 'VN2VN'. If a FCoE Controller
+ is started in 'Fabric' mode then FIP FCF discovery is
+ initiated and ultimately a fabric login is attempted.
+ If a FCoE Controller is started in 'VN2VN' mode then
+ FIP VN2VN discovery and login is performed. A FCoE
+ Controller only supports one mode at a time.
+
+ enabled: Whether an FCoE controller is enabled or disabled.
+ 0 if disabled, 1 if enabled. Writing either 0 or 1
+ to this file will enable or disable the FCoE controller.
+
lesb/link_fail: Link Error Status Block (LESB) link failure count.
lesb/vlink_fail: Link Error Status Block (LESB) virtual link
@@ -26,7 +65,7 @@
Notes: ctlr_X (global increment starting at 0)
-What: /sys/bus/fcoe/fcf_X
+What: /sys/bus/fcoe/devices/fcf_X
Date: March 2012
KernelVersion: TBD
Contact: Robert Love <robert.w.love@intel.com>, devel@open-fcoe.org
diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio
index 2e33dc6..dda81ff 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio
+++ b/Documentation/ABI/testing/sysfs-bus-iio
@@ -690,45 +690,45 @@
Actually start the buffer capture up. Will start trigger
if first device and appropriate.
-What: /sys/bus/iio/devices/iio:deviceX/buffer/scan_elements
+What: /sys/bus/iio/devices/iio:deviceX/scan_elements
KernelVersion: 2.6.37
Contact: linux-iio@vger.kernel.org
Description:
Directory containing interfaces for elements that will be
captured for a single triggered sample set in the buffer.
-What: /sys/.../buffer/scan_elements/in_accel_x_en
-What: /sys/.../buffer/scan_elements/in_accel_y_en
-What: /sys/.../buffer/scan_elements/in_accel_z_en
-What: /sys/.../buffer/scan_elements/in_anglvel_x_en
-What: /sys/.../buffer/scan_elements/in_anglvel_y_en
-What: /sys/.../buffer/scan_elements/in_anglvel_z_en
-What: /sys/.../buffer/scan_elements/in_magn_x_en
-What: /sys/.../buffer/scan_elements/in_magn_y_en
-What: /sys/.../buffer/scan_elements/in_magn_z_en
-What: /sys/.../buffer/scan_elements/in_timestamp_en
-What: /sys/.../buffer/scan_elements/in_voltageY_supply_en
-What: /sys/.../buffer/scan_elements/in_voltageY_en
-What: /sys/.../buffer/scan_elements/in_voltageY-voltageZ_en
-What: /sys/.../buffer/scan_elements/in_incli_x_en
-What: /sys/.../buffer/scan_elements/in_incli_y_en
-What: /sys/.../buffer/scan_elements/in_pressureY_en
-What: /sys/.../buffer/scan_elements/in_pressure_en
+What: /sys/.../iio:deviceX/scan_elements/in_accel_x_en
+What: /sys/.../iio:deviceX/scan_elements/in_accel_y_en
+What: /sys/.../iio:deviceX/scan_elements/in_accel_z_en
+What: /sys/.../iio:deviceX/scan_elements/in_anglvel_x_en
+What: /sys/.../iio:deviceX/scan_elements/in_anglvel_y_en
+What: /sys/.../iio:deviceX/scan_elements/in_anglvel_z_en
+What: /sys/.../iio:deviceX/scan_elements/in_magn_x_en
+What: /sys/.../iio:deviceX/scan_elements/in_magn_y_en
+What: /sys/.../iio:deviceX/scan_elements/in_magn_z_en
+What: /sys/.../iio:deviceX/scan_elements/in_timestamp_en
+What: /sys/.../iio:deviceX/scan_elements/in_voltageY_supply_en
+What: /sys/.../iio:deviceX/scan_elements/in_voltageY_en
+What: /sys/.../iio:deviceX/scan_elements/in_voltageY-voltageZ_en
+What: /sys/.../iio:deviceX/scan_elements/in_incli_x_en
+What: /sys/.../iio:deviceX/scan_elements/in_incli_y_en
+What: /sys/.../iio:deviceX/scan_elements/in_pressureY_en
+What: /sys/.../iio:deviceX/scan_elements/in_pressure_en
KernelVersion: 2.6.37
Contact: linux-iio@vger.kernel.org
Description:
Scan element control for triggered data capture.
-What: /sys/.../buffer/scan_elements/in_accel_type
-What: /sys/.../buffer/scan_elements/in_anglvel_type
-What: /sys/.../buffer/scan_elements/in_magn_type
-What: /sys/.../buffer/scan_elements/in_incli_type
-What: /sys/.../buffer/scan_elements/in_voltageY_type
-What: /sys/.../buffer/scan_elements/in_voltage_type
-What: /sys/.../buffer/scan_elements/in_voltageY_supply_type
-What: /sys/.../buffer/scan_elements/in_timestamp_type
-What: /sys/.../buffer/scan_elements/in_pressureY_type
-What: /sys/.../buffer/scan_elements/in_pressure_type
+What: /sys/.../iio:deviceX/scan_elements/in_accel_type
+What: /sys/.../iio:deviceX/scan_elements/in_anglvel_type
+What: /sys/.../iio:deviceX/scan_elements/in_magn_type
+What: /sys/.../iio:deviceX/scan_elements/in_incli_type
+What: /sys/.../iio:deviceX/scan_elements/in_voltageY_type
+What: /sys/.../iio:deviceX/scan_elements/in_voltage_type
+What: /sys/.../iio:deviceX/scan_elements/in_voltageY_supply_type
+What: /sys/.../iio:deviceX/scan_elements/in_timestamp_type
+What: /sys/.../iio:deviceX/scan_elements/in_pressureY_type
+What: /sys/.../iio:deviceX/scan_elements/in_pressure_type
KernelVersion: 2.6.37
Contact: linux-iio@vger.kernel.org
Description:
@@ -752,29 +752,29 @@
For other storage combinations this attribute will be extended
appropriately.
-What: /sys/.../buffer/scan_elements/in_accel_type_available
+What: /sys/.../iio:deviceX/scan_elements/in_accel_type_available
KernelVersion: 2.6.37
Contact: linux-iio@vger.kernel.org
Description:
If the type parameter can take one of a small set of values,
this attribute lists them.
-What: /sys/.../buffer/scan_elements/in_voltageY_index
-What: /sys/.../buffer/scan_elements/in_voltageY_supply_index
-What: /sys/.../buffer/scan_elements/in_accel_x_index
-What: /sys/.../buffer/scan_elements/in_accel_y_index
-What: /sys/.../buffer/scan_elements/in_accel_z_index
-What: /sys/.../buffer/scan_elements/in_anglvel_x_index
-What: /sys/.../buffer/scan_elements/in_anglvel_y_index
-What: /sys/.../buffer/scan_elements/in_anglvel_z_index
-What: /sys/.../buffer/scan_elements/in_magn_x_index
-What: /sys/.../buffer/scan_elements/in_magn_y_index
-What: /sys/.../buffer/scan_elements/in_magn_z_index
-What: /sys/.../buffer/scan_elements/in_incli_x_index
-What: /sys/.../buffer/scan_elements/in_incli_y_index
-What: /sys/.../buffer/scan_elements/in_timestamp_index
-What: /sys/.../buffer/scan_elements/in_pressureY_index
-What: /sys/.../buffer/scan_elements/in_pressure_index
+What: /sys/.../iio:deviceX/scan_elements/in_voltageY_index
+What: /sys/.../iio:deviceX/scan_elements/in_voltageY_supply_index
+What: /sys/.../iio:deviceX/scan_elements/in_accel_x_index
+What: /sys/.../iio:deviceX/scan_elements/in_accel_y_index
+What: /sys/.../iio:deviceX/scan_elements/in_accel_z_index
+What: /sys/.../iio:deviceX/scan_elements/in_anglvel_x_index
+What: /sys/.../iio:deviceX/scan_elements/in_anglvel_y_index
+What: /sys/.../iio:deviceX/scan_elements/in_anglvel_z_index
+What: /sys/.../iio:deviceX/scan_elements/in_magn_x_index
+What: /sys/.../iio:deviceX/scan_elements/in_magn_y_index
+What: /sys/.../iio:deviceX/scan_elements/in_magn_z_index
+What: /sys/.../iio:deviceX/scan_elements/in_incli_x_index
+What: /sys/.../iio:deviceX/scan_elements/in_incli_y_index
+What: /sys/.../iio:deviceX/scan_elements/in_timestamp_index
+What: /sys/.../iio:deviceX/scan_elements/in_pressureY_index
+What: /sys/.../iio:deviceX/scan_elements/in_pressure_index
KernelVersion: 2.6.37
Contact: linux-iio@vger.kernel.org
Description:
diff --git a/Documentation/ABI/testing/sysfs-bus-iio-mpu6050 b/Documentation/ABI/testing/sysfs-bus-iio-mpu6050
new file mode 100644
index 0000000..cb53737
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-iio-mpu6050
@@ -0,0 +1,13 @@
+What: /sys/bus/iio/devices/iio:deviceX/in_gyro_matrix
+What: /sys/bus/iio/devices/iio:deviceX/in_accel_matrix
+What: /sys/bus/iio/devices/iio:deviceX/in_magn_matrix
+KernelVersion: 3.4.0
+Contact: linux-iio@vger.kernel.org
+Description:
+ This is mounting matrix for motion sensors. Mounting matrix
+ is a 3x3 unitary matrix. A typical mounting matrix would look like
+ [0, 1, 0; 1, 0, 0; 0, 0, -1]. Using this information, it would be
+ easy to tell the relative positions among sensors as well as their
+ positions relative to the board that holds these sensors. Identity matrix
+ [1, 0, 0; 0, 1, 0; 0, 0, 1] means sensor chip and device are perfectly
+ aligned with each other. All axes are exactly the same.
diff --git a/Documentation/ABI/testing/sysfs-bus-mei b/Documentation/ABI/testing/sysfs-bus-mei
new file mode 100644
index 0000000..2066f0b
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-mei
@@ -0,0 +1,7 @@
+What: /sys/bus/mei/devices/.../modalias
+Date: March 2013
+KernelVersion: 3.10
+Contact: Samuel Ortiz <sameo@linux.intel.com>
+ linux-mei@linux.intel.com
+Description: Stores the same MODALIAS value emitted by uevent
+ Format: mei:<mei device name>
diff --git a/Documentation/ABI/testing/sysfs-bus-pci b/Documentation/ABI/testing/sysfs-bus-pci
index 1ce5ae3..5210a51 100644
--- a/Documentation/ABI/testing/sysfs-bus-pci
+++ b/Documentation/ABI/testing/sysfs-bus-pci
@@ -64,7 +64,6 @@
Writing a non-zero value to this attribute will
force a rescan of all PCI buses in the system, and
re-discover previously removed devices.
- Depends on CONFIG_HOTPLUG.
What: /sys/bus/pci/devices/.../msi_irqs/
Date: September, 2011
@@ -90,7 +89,6 @@
Description:
Writing a non-zero value to this attribute will
hot-remove the PCI device and any of its children.
- Depends on CONFIG_HOTPLUG.
What: /sys/bus/pci/devices/.../pci_bus/.../rescan
Date: May 2011
@@ -99,7 +97,7 @@
Writing a non-zero value to this attribute will
force a rescan of the bus and all child buses,
and re-discover devices removed earlier from this
- part of the device tree. Depends on CONFIG_HOTPLUG.
+ part of the device tree.
What: /sys/bus/pci/devices/.../rescan
Date: January 2009
@@ -109,7 +107,6 @@
force a rescan of the device's parent bus and all
child buses, and re-discover devices removed earlier
from this part of the device tree.
- Depends on CONFIG_HOTPLUG.
What: /sys/bus/pci/devices/.../reset
Date: July 2009
diff --git a/Documentation/ABI/testing/sysfs-bus-rbd b/Documentation/ABI/testing/sysfs-bus-rbd
index cd9213c..0a30647 100644
--- a/Documentation/ABI/testing/sysfs-bus-rbd
+++ b/Documentation/ABI/testing/sysfs-bus-rbd
@@ -66,27 +66,7 @@
The current snapshot for which the device is mapped.
-snap_*
-
- A directory per each snapshot
-
parent
Information identifying the pool, image, and snapshot id for
the parent image in a layered rbd image (format 2 only).
-
-Entries under /sys/bus/rbd/devices/<dev-id>/snap_<snap-name>
--------------------------------------------------------------
-
-snap_id
-
- The rados internal snapshot id assigned for this snapshot
-
-snap_size
-
- The size of the image when this snapshot was taken.
-
-snap_features
-
- A hexadecimal encoding of the feature bits for this snapshot.
-
diff --git a/Documentation/ABI/testing/sysfs-bus-usb b/Documentation/ABI/testing/sysfs-bus-usb
index b6fbe51..9759b8c 100644
--- a/Documentation/ABI/testing/sysfs-bus-usb
+++ b/Documentation/ABI/testing/sysfs-bus-usb
@@ -32,7 +32,7 @@
KernelVersion: 2.6.25
Contact: Sarah Sharp <sarah.a.sharp@intel.com>
Description:
- If CONFIG_PM and CONFIG_USB_SUSPEND are enabled, then this file
+ If CONFIG_PM_RUNTIME is enabled then this file
is present. When read, it returns the total time (in msec)
that the USB device has been connected to the machine. This
file is read-only.
@@ -45,7 +45,7 @@
KernelVersion: 2.6.25
Contact: Sarah Sharp <sarah.a.sharp@intel.com>
Description:
- If CONFIG_PM and CONFIG_USB_SUSPEND are enabled, then this file
+ If CONFIG_PM_RUNTIME is enabled then this file
is present. When read, it returns the total time (in msec)
that the USB device has been active, i.e. not in a suspended
state. This file is read-only.
@@ -187,7 +187,7 @@
Date: September 2011
Contact: Andiry Xu <andiry.xu@amd.com>
Description:
- If CONFIG_USB_SUSPEND is set and a USB 2.0 lpm-capable device
+ If CONFIG_PM_RUNTIME is set and a USB 2.0 lpm-capable device
is plugged in to a xHCI host which support link PM, it will
perform a LPM test; if the test is passed and host supports
USB2 hardware LPM (xHCI 1.0 feature), USB2 hardware LPM will
@@ -227,3 +227,39 @@
Description:
The /sys/bus/usb/devices/.../(hub interface)/portX
is usb port device's sysfs directory.
+
+What: /sys/bus/usb/devices/.../(hub interface)/portX/connect_type
+Date: January 2013
+Contact: Lan Tianyu <tianyu.lan@intel.com>
+Description:
+ Some platforms provide usb port connect types through ACPI.
+ This attribute is to expose these information to user space.
+ The file will read "hotplug", "wired" and "not used" if the
+ information is available, and "unknown" otherwise.
+
+What: /sys/bus/usb/devices/.../power/usb2_lpm_l1_timeout
+Date: May 2013
+Contact: Mathias Nyman <mathias.nyman@linux.intel.com>
+Description:
+ USB 2.0 devices may support hardware link power management (LPM)
+ L1 sleep state. The usb2_lpm_l1_timeout attribute allows
+ tuning the timeout for L1 inactivity timer (LPM timer), e.g.
+ needed inactivity time before host requests the device to go to L1 sleep.
+ Useful for power management tuning.
+ Supported values are 0 - 65535 microseconds.
+
+What: /sys/bus/usb/devices/.../power/usb2_lpm_besl
+Date: May 2013
+Contact: Mathias Nyman <mathias.nyman@linux.intel.com>
+Description:
+ USB 2.0 devices that support hardware link power management (LPM)
+ L1 sleep state now use a best effort service latency value (BESL) to
+ indicate the best effort to resumption of service to the device after the
+ initiation of the resume event.
+ If the device does not have a preferred besl value then the host can select
+ one instead. This usb2_lpm_besl attribute allows to tune the host selected besl
+ value in order to tune power saving and service latency.
+
+ Supported values are 0 - 15.
+ More information on how besl values map to microseconds can be found in
+ USB 2.0 ECN Errata for Link Power Management, section 4.10)
diff --git a/Documentation/ABI/testing/sysfs-class-bdi b/Documentation/ABI/testing/sysfs-class-bdi
index 5f50097..d773d56 100644
--- a/Documentation/ABI/testing/sysfs-class-bdi
+++ b/Documentation/ABI/testing/sysfs-class-bdi
@@ -48,3 +48,8 @@
most of the write-back cache. For example in case of an NFS
mount that is prone to get stuck, or a FUSE mount which cannot
be trusted to play fair.
+
+stable_pages_required (read-only)
+
+ If set, the backing device requires that all pages comprising a write
+ request must not be changed until writeout is complete.
diff --git a/Documentation/ABI/testing/sysfs-class-devfreq b/Documentation/ABI/testing/sysfs-class-devfreq
index 0ba6ea2..ee39aca 100644
--- a/Documentation/ABI/testing/sysfs-class-devfreq
+++ b/Documentation/ABI/testing/sysfs-class-devfreq
@@ -78,3 +78,23 @@
Description:
The /sys/class/devfreq/.../available_governors shows
currently available governors in the system.
+
+What: /sys/class/devfreq/.../min_freq
+Date: January 2013
+Contact: MyungJoo Ham <myungjoo.ham@samsung.com>
+Description:
+ The /sys/class/devfreq/.../min_freq shows and stores
+ the minimum frequency requested by users. It is 0 if
+ the user does not care. min_freq overrides the
+ frequency requested by governors.
+
+What: /sys/class/devfreq/.../max_freq
+Date: January 2013
+Contact: MyungJoo Ham <myungjoo.ham@samsung.com>
+Description:
+ The /sys/class/devfreq/.../max_freq shows and stores
+ the maximum frequency requested by users. It is 0 if
+ the user does not care. max_freq overrides the
+ frequency requested by governors and min_freq.
+ The max_freq overrides min_freq because max_freq may be
+ used to throttle devices to avoid overheating.
diff --git a/Documentation/ABI/testing/sysfs-class-mtd b/Documentation/ABI/testing/sysfs-class-mtd
index 938ef71..3105644 100644
--- a/Documentation/ABI/testing/sysfs-class-mtd
+++ b/Documentation/ABI/testing/sysfs-class-mtd
@@ -14,8 +14,7 @@
The /sys/class/mtd/mtd{0,1,2,3,...} directories correspond
to each /dev/mtdX character device. These may represent
physical/simulated flash devices, partitions on a flash
- device, or concatenated flash devices. They exist regardless
- of whether CONFIG_MTD_CHAR is actually enabled.
+ device, or concatenated flash devices.
What: /sys/class/mtd/mtdXro/
Date: April 2009
@@ -23,8 +22,7 @@
Contact: linux-mtd@lists.infradead.org
Description:
These directories provide the corresponding read-only device
- nodes for /sys/class/mtd/mtdX/ . They are only created
- (for the benefit of udev) if CONFIG_MTD_CHAR is enabled.
+ nodes for /sys/class/mtd/mtdX/ .
What: /sys/class/mtd/mtdX/dev
Date: April 2009
diff --git a/Documentation/ABI/testing/sysfs-class-net-mesh b/Documentation/ABI/testing/sysfs-class-net-mesh
index bc41da6..bdcd8b4 100644
--- a/Documentation/ABI/testing/sysfs-class-net-mesh
+++ b/Documentation/ABI/testing/sysfs-class-net-mesh
@@ -67,6 +67,14 @@
Defines the penalty which will be applied to an
originator message's tq-field on every hop.
+What: /sys/class/net/<mesh_iface>/mesh/network_coding
+Date: Nov 2012
+Contact: Martin Hundeboll <martin@hundeboll.net>
+Description:
+ Controls whether Network Coding (using some magic
+ to send fewer wifi packets but still the same
+ content) is enabled or not.
+
What: /sys/class/net/<mesh_iface>/mesh/orig_interval
Date: May 2010
Contact: Marek Lindner <lindner_marek@yahoo.de>
diff --git a/Documentation/ABI/testing/sysfs-class-pwm b/Documentation/ABI/testing/sysfs-class-pwm
new file mode 100644
index 0000000..c479d77
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-pwm
@@ -0,0 +1,79 @@
+What: /sys/class/pwm/
+Date: May 2013
+KernelVersion: 3.11
+Contact: H Hartley Sweeten <hsweeten@visionengravers.com>
+Description:
+ The pwm/ class sub-directory belongs to the Generic PWM
+ Framework and provides a sysfs interface for using PWM
+ channels.
+
+What: /sys/class/pwm/pwmchipN/
+Date: May 2013
+KernelVersion: 3.11
+Contact: H Hartley Sweeten <hsweeten@visionengravers.com>
+Description:
+ A /sys/class/pwm/pwmchipN directory is created for each
+ probed PWM controller/chip where N is the base of the
+ PWM chip.
+
+What: /sys/class/pwm/pwmchipN/npwm
+Date: May 2013
+KernelVersion: 3.11
+Contact: H Hartley Sweeten <hsweeten@visionengravers.com>
+Description:
+ The number of PWM channels supported by the PWM chip.
+
+What: /sys/class/pwm/pwmchipN/export
+Date: May 2013
+KernelVersion: 3.11
+Contact: H Hartley Sweeten <hsweeten@visionengravers.com>
+Description:
+ Exports a PWM channel from the PWM chip for sysfs control.
+ Value is between 0 and /sys/class/pwm/pwmchipN/npwm - 1.
+
+What: /sys/class/pwm/pwmchipN/unexport
+Date: May 2013
+KernelVersion: 3.11
+Contact: H Hartley Sweeten <hsweeten@visionengravers.com>
+Description:
+ Unexports a PWM channel.
+
+What: /sys/class/pwm/pwmchipN/pwmX
+Date: May 2013
+KernelVersion: 3.11
+Contact: H Hartley Sweeten <hsweeten@visionengravers.com>
+Description:
+ A /sys/class/pwm/pwmchipN/pwmX directory is created for
+ each exported PWM channel where X is the exported PWM
+ channel number.
+
+What: /sys/class/pwm/pwmchipN/pwmX/period
+Date: May 2013
+KernelVersion: 3.11
+Contact: H Hartley Sweeten <hsweeten@visionengravers.com>
+Description:
+ Sets the PWM signal period in nanoseconds.
+
+What: /sys/class/pwm/pwmchipN/pwmX/duty_cycle
+Date: May 2013
+KernelVersion: 3.11
+Contact: H Hartley Sweeten <hsweeten@visionengravers.com>
+Description:
+ Sets the PWM signal duty cycle in nanoseconds.
+
+What: /sys/class/pwm/pwmchipN/pwmX/polarity
+Date: May 2013
+KernelVersion: 3.11
+Contact: H Hartley Sweeten <hsweeten@visionengravers.com>
+Description:
+ Sets the output polarity of the PWM signal to "normal" or
+ "inversed".
+
+What: /sys/class/pwm/pwmchipN/pwmX/enable
+Date: May 2013
+KernelVersion: 3.11
+Contact: H Hartley Sweeten <hsweeten@visionengravers.com>
+Description:
+ Enable/disable the PWM signal.
+ 0 is disabled
+ 1 is enabled
diff --git a/Documentation/ABI/testing/sysfs-class-uwb_rc-wusbhc b/Documentation/ABI/testing/sysfs-class-uwb_rc-wusbhc
index 25b1e75..5977e28 100644
--- a/Documentation/ABI/testing/sysfs-class-uwb_rc-wusbhc
+++ b/Documentation/ABI/testing/sysfs-class-uwb_rc-wusbhc
@@ -36,3 +36,22 @@
Refer to [ECMA-368] section 10.3.1.1 for the value to
use.
+
+What: /sys/class/uwb_rc/uwbN/wusbhc/wusb_dnts
+Date: June 2013
+KernelVersion: 3.11
+Contact: Thomas Pugliese <thomas.pugliese@gmail.com>
+Description:
+ The device notification time slot (DNTS) count and inverval in
+ milliseconds that the WUSB host should use. This controls how
+ often the devices will have the opportunity to send
+ notifications to the host.
+
+What: /sys/class/uwb_rc/uwbN/wusbhc/wusb_retry_count
+Date: June 2013
+KernelVersion: 3.11
+Contact: Thomas Pugliese <thomas.pugliese@gmail.com>
+Description:
+ The number of retries that the WUSB host should attempt
+ before reporting an error for a bus transaction. The range of
+ valid values is [0..15], where 0 indicates infinite retries.
diff --git a/Documentation/ABI/testing/sysfs-devices-edac b/Documentation/ABI/testing/sysfs-devices-edac
index 30ee78a..6568e00 100644
--- a/Documentation/ABI/testing/sysfs-devices-edac
+++ b/Documentation/ABI/testing/sysfs-devices-edac
@@ -77,7 +77,7 @@
What: /sys/devices/system/edac/mc/mc*/max_location
Date: April 2012
-Contact: Mauro Carvalho Chehab <mchehab@redhat.com>
+Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
linux-edac@vger.kernel.org
Description: This attribute file displays the information about the last
available memory slot in this memory controller. It is used by
@@ -85,7 +85,7 @@
What: /sys/devices/system/edac/mc/mc*/(dimm|rank)*/size
Date: April 2012
-Contact: Mauro Carvalho Chehab <mchehab@redhat.com>
+Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
linux-edac@vger.kernel.org
Description: This attribute file will display the size of dimm or rank.
For dimm*/size, this is the size, in MB of the DIMM memory
@@ -96,14 +96,14 @@
What: /sys/devices/system/edac/mc/mc*/(dimm|rank)*/dimm_dev_type
Date: April 2012
-Contact: Mauro Carvalho Chehab <mchehab@redhat.com>
+Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
linux-edac@vger.kernel.org
Description: This attribute file will display what type of DRAM device is
being utilized on this DIMM (x1, x2, x4, x8, ...).
What: /sys/devices/system/edac/mc/mc*/(dimm|rank)*/dimm_edac_mode
Date: April 2012
-Contact: Mauro Carvalho Chehab <mchehab@redhat.com>
+Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
linux-edac@vger.kernel.org
Description: This attribute file will display what type of Error detection
and correction is being utilized. For example: S4ECD4ED would
@@ -111,7 +111,7 @@
What: /sys/devices/system/edac/mc/mc*/(dimm|rank)*/dimm_label
Date: April 2012
-Contact: Mauro Carvalho Chehab <mchehab@redhat.com>
+Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
linux-edac@vger.kernel.org
Description: This control file allows this DIMM to have a label assigned
to it. With this label in the module, when errors occur
@@ -126,14 +126,14 @@
What: /sys/devices/system/edac/mc/mc*/(dimm|rank)*/dimm_location
Date: April 2012
-Contact: Mauro Carvalho Chehab <mchehab@redhat.com>
+Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
linux-edac@vger.kernel.org
Description: This attribute file will display the location (csrow/channel,
branch/channel/slot or channel/slot) of the dimm or rank.
What: /sys/devices/system/edac/mc/mc*/(dimm|rank)*/dimm_mem_type
Date: April 2012
-Contact: Mauro Carvalho Chehab <mchehab@redhat.com>
+Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
linux-edac@vger.kernel.org
Description: This attribute file will display what type of memory is
currently on this csrow. Normally, either buffered or
diff --git a/Documentation/ABI/testing/sysfs-devices-lpss_ltr b/Documentation/ABI/testing/sysfs-devices-lpss_ltr
new file mode 100644
index 0000000..ea9298d
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-devices-lpss_ltr
@@ -0,0 +1,44 @@
+What: /sys/devices/.../lpss_ltr/
+Date: March 2013
+Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Description:
+ The /sys/devices/.../lpss_ltr/ directory is only present for
+ devices included into the Intel Lynxpoint Low Power Subsystem
+ (LPSS). If present, it contains attributes containing the LTR
+ mode and the values of LTR registers of the device.
+
+What: /sys/devices/.../lpss_ltr/ltr_mode
+Date: March 2013
+Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Description:
+ The /sys/devices/.../lpss_ltr/ltr_mode attribute contains an
+ integer number (0 or 1) indicating whether or not the devices'
+ LTR functionality is working in the software mode (1).
+
+ This attribute is read-only. If the device's runtime PM status
+ is not "active", attempts to read from this attribute cause
+ -EAGAIN to be returned.
+
+What: /sys/devices/.../lpss_ltr/auto_ltr
+Date: March 2013
+Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Description:
+ The /sys/devices/.../lpss_ltr/auto_ltr attribute contains the
+ current value of the device's AUTO_LTR register (raw)
+ represented as an 8-digit hexadecimal number.
+
+ This attribute is read-only. If the device's runtime PM status
+ is not "active", attempts to read from this attribute cause
+ -EAGAIN to be returned.
+
+What: /sys/devices/.../lpss_ltr/sw_ltr
+Date: March 2013
+Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Description:
+ The /sys/devices/.../lpss_ltr/auto_ltr attribute contains the
+ current value of the device's SW_LTR register (raw) represented
+ as an 8-digit hexadecimal number.
+
+ This attribute is read-only. If the device's runtime PM status
+ is not "active", attempts to read from this attribute cause
+ -EAGAIN to be returned.
diff --git a/Documentation/ABI/testing/sysfs-devices-online b/Documentation/ABI/testing/sysfs-devices-online
new file mode 100644
index 0000000..f990026
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-devices-online
@@ -0,0 +1,20 @@
+What: /sys/devices/.../online
+Date: April 2013
+Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Description:
+ The /sys/devices/.../online attribute is only present for
+ devices whose bus types provide .online() and .offline()
+ callbacks. The number read from it (0 or 1) reflects the value
+ of the device's 'offline' field. If that number is 1 and '0'
+ (or 'n', or 'N') is written to this file, the device bus type's
+ .offline() callback is executed for the device and (if
+ successful) its 'offline' field is updated accordingly. In
+ turn, if that number is 0 and '1' (or 'y', or 'Y') is written to
+ this file, the device bus type's .online() callback is executed
+ for the device and (if successful) its 'offline' field is
+ updated as appropriate.
+
+ After a successful execution of the bus type's .offline()
+ callback the device cannot be used for any purpose until either
+ it is removed (i.e. device_del() is called for it), or its bus
+ type's .online() is exeucted successfully.
diff --git a/Documentation/ABI/testing/sysfs-devices-power_resources_D0 b/Documentation/ABI/testing/sysfs-devices-power_resources_D0
new file mode 100644
index 0000000..73b77a6
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-devices-power_resources_D0
@@ -0,0 +1,13 @@
+What: /sys/devices/.../power_resources_D0/
+Date: January 2013
+Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Description:
+ The /sys/devices/.../power_resources_D0/ directory is only
+ present for device objects representing ACPI device nodes that
+ use ACPI power resources for power management.
+
+ If present, it contains symbolic links to device directories
+ representing ACPI power resources that need to be turned on for
+ the given device node to be in ACPI power state D0. The names
+ of the links are the same as the names of the directories they
+ point to.
diff --git a/Documentation/ABI/testing/sysfs-devices-power_resources_D1 b/Documentation/ABI/testing/sysfs-devices-power_resources_D1
new file mode 100644
index 0000000..30c2070
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-devices-power_resources_D1
@@ -0,0 +1,14 @@
+What: /sys/devices/.../power_resources_D1/
+Date: January 2013
+Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Description:
+ The /sys/devices/.../power_resources_D1/ directory is only
+ present for device objects representing ACPI device nodes that
+ use ACPI power resources for power management and support ACPI
+ power state D1.
+
+ If present, it contains symbolic links to device directories
+ representing ACPI power resources that need to be turned on for
+ the given device node to be in ACPI power state D1. The names
+ of the links are the same as the names of the directories they
+ point to.
diff --git a/Documentation/ABI/testing/sysfs-devices-power_resources_D2 b/Documentation/ABI/testing/sysfs-devices-power_resources_D2
new file mode 100644
index 0000000..fd9d84b
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-devices-power_resources_D2
@@ -0,0 +1,14 @@
+What: /sys/devices/.../power_resources_D2/
+Date: January 2013
+Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Description:
+ The /sys/devices/.../power_resources_D2/ directory is only
+ present for device objects representing ACPI device nodes that
+ use ACPI power resources for power management and support ACPI
+ power state D2.
+
+ If present, it contains symbolic links to device directories
+ representing ACPI power resources that need to be turned on for
+ the given device node to be in ACPI power state D2. The names
+ of the links are the same as the names of the directories they
+ point to.
diff --git a/Documentation/ABI/testing/sysfs-devices-power_resources_D3hot b/Documentation/ABI/testing/sysfs-devices-power_resources_D3hot
new file mode 100644
index 0000000..3df32c2
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-devices-power_resources_D3hot
@@ -0,0 +1,14 @@
+What: /sys/devices/.../power_resources_D3hot/
+Date: January 2013
+Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Description:
+ The /sys/devices/.../power_resources_D3hot/ directory is only
+ present for device objects representing ACPI device nodes that
+ use ACPI power resources for power management and support ACPI
+ power state D3hot.
+
+ If present, it contains symbolic links to device directories
+ representing ACPI power resources that need to be turned on for
+ the given device node to be in ACPI power state D3hot. The
+ names of the links are the same as the names of the directories
+ they point to.
diff --git a/Documentation/ABI/testing/sysfs-devices-power_resources_wakeup b/Documentation/ABI/testing/sysfs-devices-power_resources_wakeup
new file mode 100644
index 0000000..e0588fe
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-devices-power_resources_wakeup
@@ -0,0 +1,13 @@
+What: /sys/devices/.../power_resources_wakeup/
+Date: April 2013
+Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Description:
+ The /sys/devices/.../power_resources_wakeup/ directory is only
+ present for device objects representing ACPI device nodes that
+ require ACPI power resources for wakeup signaling.
+
+ If present, it contains symbolic links to device directories
+ representing ACPI power resources that need to be turned on for
+ the given device node to be able to signal wakeup. The names of
+ the links are the same as the names of the directories they
+ point to.
diff --git a/Documentation/ABI/testing/sysfs-devices-power_state b/Documentation/ABI/testing/sysfs-devices-power_state
new file mode 100644
index 0000000..7ad9546
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-devices-power_state
@@ -0,0 +1,20 @@
+What: /sys/devices/.../power_state
+Date: January 2013
+Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Description:
+ The /sys/devices/.../power_state attribute is only present for
+ device objects representing ACPI device nodes that provide power
+ management methods.
+
+ If present, it contains a string representing the current ACPI
+ power state of the given device node. Its possible values,
+ "D0", "D1", "D2", "D3hot", and "D3cold", reflect the power state
+ names defined by the ACPI specification (ACPI 4 and above).
+
+ If the device node uses shared ACPI power resources, this state
+ determines a list of power resources required not to be turned
+ off. However, some power resources needed by the device node in
+ higher-power (lower-number) states may also be ON because of
+ some other devices using them at the moment.
+
+ This attribute is read-only.
diff --git a/Documentation/ABI/testing/sysfs-devices-real_power_state b/Documentation/ABI/testing/sysfs-devices-real_power_state
new file mode 100644
index 0000000..8b3527c
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-devices-real_power_state
@@ -0,0 +1,23 @@
+What: /sys/devices/.../real_power_state
+Date: January 2013
+Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Description:
+ The /sys/devices/.../real_power_state attribute is only present
+ for device objects representing ACPI device nodes that provide
+ power management methods and use ACPI power resources for power
+ management.
+
+ If present, it contains a string representing the real ACPI
+ power state of the given device node as returned by the _PSC
+ control method or inferred from the configuration of power
+ resources. Its possible values, "D0", "D1", "D2", "D3hot", and
+ "D3cold", reflect the power state names defined by the ACPI
+ specification (ACPI 4 and above).
+
+ In some situations the value of this attribute may be different
+ from the value of the /sys/devices/.../power_state attribute for
+ the same device object. If that happens, some shared power
+ resources used by the device node are only ON because of some
+ other devices using them at the moment.
+
+ This attribute is read-only.
diff --git a/Documentation/ABI/testing/sysfs-devices-resource_in_use b/Documentation/ABI/testing/sysfs-devices-resource_in_use
new file mode 100644
index 0000000..b4a3bc5
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-devices-resource_in_use
@@ -0,0 +1,12 @@
+What: /sys/devices/.../resource_in_use
+Date: January 2013
+Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Description:
+ The /sys/devices/.../resource_in_use attribute is only present
+ for device objects representing ACPI power resources.
+
+ If present, it contains a number (0 or 1) representing the
+ current status of the given power resource (0 means that the
+ resource is not in use and therefore it has been turned off).
+
+ This attribute is read-only.
diff --git a/Documentation/ABI/testing/sysfs-devices-sun b/Documentation/ABI/testing/sysfs-devices-sun
index 86be984..625ce4b 100644
--- a/Documentation/ABI/testing/sysfs-devices-sun
+++ b/Documentation/ABI/testing/sysfs-devices-sun
@@ -1,4 +1,4 @@
-Whatt: /sys/devices/.../sun
+What: /sys/devices/.../sun
Date: October 2012
Contact: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Description:
diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu
index 6943133..468e4d48 100644
--- a/Documentation/ABI/testing/sysfs-devices-system-cpu
+++ b/Documentation/ABI/testing/sysfs-devices-system-cpu
@@ -67,20 +67,6 @@
/sys/devices/system/cpu/cpu42/node2 -> ../../node/node2
-What: /sys/devices/system/cpu/cpu#/node
-Date: October 2009
-Contact: Linux memory management mailing list <linux-mm@kvack.org>
-Description: Discover NUMA node a CPU belongs to
-
- When CONFIG_NUMA is enabled, a symbolic link that points
- to the corresponding NUMA node directory.
-
- For example, the following symlink is created for cpu42
- in NUMA node 2:
-
- /sys/devices/system/cpu/cpu42/node2 -> ../../node/node2
-
-
What: /sys/devices/system/cpu/cpu#/topology/core_id
/sys/devices/system/cpu/cpu#/topology/core_siblings
/sys/devices/system/cpu/cpu#/topology/core_siblings_list
@@ -158,6 +144,21 @@
to learn how to control the knobs.
+What: /sys/devices/system/cpu/cpu#/cpufreq/freqdomain_cpus
+Date: June 2013
+Contact: cpufreq@vger.kernel.org
+Description: Discover CPUs in the same CPU frequency coordination domain
+
+ freqdomain_cpus is the list of CPUs (online+offline) that share
+ the same clock/freq domain (possibly at the hardware level).
+ That information may be hidden from the cpufreq core and the
+ value of related_cpus may be different from freqdomain_cpus. This
+ attribute is useful for user space DVFS controllers to get better
+ power/performance results for platforms using acpi-cpufreq.
+
+ This file is only present if the acpi-cpufreq driver is in use.
+
+
What: /sys/devices/system/cpu/cpu*/cache/index3/cache_disable_{0,1}
Date: August 2008
KernelVersion: 2.6.27
@@ -187,3 +188,15 @@
Boosting allows the CPU and the firmware to run at a frequency
beyound it's nominal limit.
More details can be found in Documentation/cpu-freq/boost.txt
+
+
+What: /sys/devices/system/cpu/cpu#/crash_notes
+ /sys/devices/system/cpu/cpu#/crash_notes_size
+Date: April 2013
+Contact: kexec@lists.infradead.org
+Description: address and size of the percpu note.
+
+ crash_notes: the physical address of the memory that holds the
+ note of cpu#.
+
+ crash_notes_size: size of the note of cpu#.
diff --git a/Documentation/ABI/testing/sysfs-driver-hid-roccat-isku b/Documentation/ABI/testing/sysfs-driver-hid-roccat-isku
index 9eca5a1..c601d0f 100644
--- a/Documentation/ABI/testing/sysfs-driver-hid-roccat-isku
+++ b/Documentation/ABI/testing/sysfs-driver-hid-roccat-isku
@@ -101,7 +101,8 @@
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When written, this file lets one set the backlight intensity for
a specific profile. Profile number is included in written data.
- The data has to be 10 bytes long.
+ The data has to be 10 bytes long for Isku, IskuFX needs 16 bytes
+ of data.
Before reading this file, control has to be written to select
which profile to read.
Users: http://roccat.sourceforge.net
@@ -141,3 +142,12 @@
The data has to be 16 bytes long.
This file is writeonly.
Users: http://roccat.sourceforge.net
+
+What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/talkfx
+Date: February 2013
+Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
+Description: When written, this file lets one trigger temporary color schemes
+ from the host.
+ The data has to be 16 bytes long.
+ This file is writeonly.
+Users: http://roccat.sourceforge.net
diff --git a/Documentation/ABI/testing/sysfs-driver-hid-roccat-konepure b/Documentation/ABI/testing/sysfs-driver-hid-roccat-konepure
new file mode 100644
index 0000000..41a9b7f
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-hid-roccat-konepure
@@ -0,0 +1,105 @@
+What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/konepure/roccatkonepure<minor>/actual_profile
+Date: December 2012
+Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
+Description: The mouse can store 5 profiles which can be switched by the
+ press of a button. actual_profile holds number of actual profile.
+ This value is persistent, so its value determines the profile
+ that's active when the mouse is powered on next time.
+ When written, the mouse activates the set profile immediately.
+ The data has to be 3 bytes long.
+ The mouse will reject invalid data.
+Users: http://roccat.sourceforge.net
+
+What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/konepure/roccatkonepure<minor>/control
+Date: December 2012
+Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
+Description: When written, this file lets one select which data from which
+ profile will be read next. The data has to be 3 bytes long.
+ This file is writeonly.
+Users: http://roccat.sourceforge.net
+
+What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/konepure/roccatkonepure<minor>/info
+Date: December 2012
+Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
+Description: When read, this file returns general data like firmware version.
+ When written, the device can be reset.
+ The data is 6 bytes long.
+Users: http://roccat.sourceforge.net
+
+What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/konepure/roccatkonepure<minor>/macro
+Date: December 2012
+Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
+Description: The mouse can store a macro with max 500 key/button strokes
+ internally.
+ When written, this file lets one set the sequence for a specific
+ button for a specific profile. Button and profile numbers are
+ included in written data. The data has to be 2082 bytes long.
+ This file is writeonly.
+Users: http://roccat.sourceforge.net
+
+What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/konepure/roccatkonepure<minor>/profile_buttons
+Date: December 2012
+Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
+Description: The mouse can store 5 profiles which can be switched by the
+ press of a button. A profile is split in settings and buttons.
+ profile_buttons holds information about button layout.
+ When written, this file lets one write the respective profile
+ buttons back to the mouse. The data has to be 59 bytes long.
+ The mouse will reject invalid data.
+ Which profile to write is determined by the profile number
+ contained in the data.
+ Before reading this file, control has to be written to select
+ which profile to read.
+Users: http://roccat.sourceforge.net
+
+What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/konepure/roccatkonepure<minor>/profile_settings
+Date: December 2012
+Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
+Description: The mouse can store 5 profiles which can be switched by the
+ press of a button. A profile is split in settings and buttons.
+ profile_settings holds information like resolution, sensitivity
+ and light effects.
+ When written, this file lets one write the respective profile
+ settings back to the mouse. The data has to be 31 bytes long.
+ The mouse will reject invalid data.
+ Which profile to write is determined by the profile number
+ contained in the data.
+ Before reading this file, control has to be written to select
+ which profile to read.
+Users: http://roccat.sourceforge.net
+
+What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/konepure/roccatkonepure<minor>/sensor
+Date: December 2012
+Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
+Description: The mouse has a tracking- and a distance-control-unit. These
+ can be activated/deactivated and the lift-off distance can be
+ set. The data has to be 6 bytes long.
+ This file is writeonly.
+Users: http://roccat.sourceforge.net
+
+What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/konepure/roccatkonepure<minor>/talk
+Date: December 2012
+Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
+Description: Used to active some easy* functions of the mouse from outside.
+ The data has to be 16 bytes long.
+ This file is writeonly.
+Users: http://roccat.sourceforge.net
+
+What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/konepure/roccatkonepure<minor>/tcu
+Date: December 2012
+Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
+Description: When written a calibration process for the tracking control unit
+ can be initiated/cancelled. Also lets one read/write sensor
+ registers.
+ The data has to be 4 bytes long.
+Users: http://roccat.sourceforge.net
+
+What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/konepure/roccatkonepure<minor>/tcu_image
+Date: December 2012
+Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
+Description: When read the mouse returns a 30x30 pixel image of the
+ sampled underground. This works only in the course of a
+ calibration process initiated with tcu.
+ The returned data is 1028 bytes in size.
+ This file is readonly.
+Users: http://roccat.sourceforge.net
diff --git a/Documentation/ABI/testing/sysfs-driver-hid-srws1 b/Documentation/ABI/testing/sysfs-driver-hid-srws1
new file mode 100644
index 0000000..d0eba70
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-hid-srws1
@@ -0,0 +1,21 @@
+What: /sys/class/leds/SRWS1::<serial>::RPM1
+What: /sys/class/leds/SRWS1::<serial>::RPM2
+What: /sys/class/leds/SRWS1::<serial>::RPM3
+What: /sys/class/leds/SRWS1::<serial>::RPM4
+What: /sys/class/leds/SRWS1::<serial>::RPM5
+What: /sys/class/leds/SRWS1::<serial>::RPM6
+What: /sys/class/leds/SRWS1::<serial>::RPM7
+What: /sys/class/leds/SRWS1::<serial>::RPM8
+What: /sys/class/leds/SRWS1::<serial>::RPM9
+What: /sys/class/leds/SRWS1::<serial>::RPM10
+What: /sys/class/leds/SRWS1::<serial>::RPM11
+What: /sys/class/leds/SRWS1::<serial>::RPM12
+What: /sys/class/leds/SRWS1::<serial>::RPM13
+What: /sys/class/leds/SRWS1::<serial>::RPM14
+What: /sys/class/leds/SRWS1::<serial>::RPM15
+What: /sys/class/leds/SRWS1::<serial>::RPMALL
+Date: Jan 2013
+KernelVersion: 3.9
+Contact: Simon Wood <simon@mungewell.org>
+Description: Provides a control for turning on/off the LEDs which form
+ an RPM meter on the front of the controller
diff --git a/Documentation/ABI/testing/sysfs-driver-hid-thingm b/Documentation/ABI/testing/sysfs-driver-hid-thingm
new file mode 100644
index 0000000..abcffee
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-hid-thingm
@@ -0,0 +1,23 @@
+What: /sys/class/leds/blink1::<serial>/rgb
+Date: January 2013
+Contact: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
+Description: The ThingM blink1 is an USB RGB LED. The color notation is
+ 3-byte hexadecimal. Read this attribute to get the last set
+ color. Write the 24-bit hexadecimal color to change the current
+ LED color. The default color is full white (0xFFFFFF).
+ For instance, set the color to green with: echo 00FF00 > rgb
+
+What: /sys/class/leds/blink1::<serial>/fade
+Date: January 2013
+Contact: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
+Description: This attribute allows to set a fade time in milliseconds for
+ the next color change. Read the attribute to know the current
+ fade time. The default value is set to 0 (no fade time). For
+ instance, set a fade time of 2 seconds with: echo 2000 > fade
+
+What: /sys/class/leds/blink1::<serial>/play
+Date: January 2013
+Contact: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
+Description: This attribute is used to play/pause the light patterns. Write 1
+ to start playing, 0 to stop. Reading this attribute returns the
+ current playing status.
diff --git a/Documentation/ABI/testing/sysfs-driver-hid-wiimote b/Documentation/ABI/testing/sysfs-driver-hid-wiimote
index 3d98009..ed5dd56 100644
--- a/Documentation/ABI/testing/sysfs-driver-hid-wiimote
+++ b/Documentation/ABI/testing/sysfs-driver-hid-wiimote
@@ -12,7 +12,7 @@
What: /sys/bus/hid/drivers/wiimote/<dev>/extension
Date: August 2011
KernelVersion: 3.2
-Contact: David Herrmann <dh.herrmann@googlemail.com>
+Contact: David Herrmann <dh.herrmann@gmail.com>
Description: This file contains the currently connected and initialized
extensions. It can be one of: none, motionp, nunchuck, classic,
motionp+nunchuck, motionp+classic
@@ -20,3 +20,40 @@
the official Nintendo Nunchuck extension and classic is the
Nintendo Classic Controller extension. The motionp extension can
be combined with the other two.
+ Starting with kernel-version 3.11 Motion Plus hotplugging is
+ supported and if detected, it's no longer reported as static
+ extension. You will get uevent notifications for the motion-plus
+ device then.
+
+What: /sys/bus/hid/drivers/wiimote/<dev>/devtype
+Date: May 2013
+KernelVersion: 3.11
+Contact: David Herrmann <dh.herrmann@gmail.com>
+Description: While a device is initialized by the wiimote driver, we perform
+ a device detection and signal a "change" uevent after it is
+ done. This file shows the detected device type. "pending" means
+ that the detection is still ongoing, "unknown" means, that the
+ device couldn't be detected or loaded. "generic" means, that the
+ device couldn't be detected but supports basic Wii Remote
+ features and can be used.
+ Other strings for each device-type are available and may be
+ added if new device-specific detections are added.
+ Currently supported are:
+ gen10: First Wii Remote generation
+ gen20: Second Wii Remote Plus generation (builtin MP)
+ balanceboard: Wii Balance Board
+
+What: /sys/bus/hid/drivers/wiimote/<dev>/bboard_calib
+Date: May 2013
+KernelVersion: 3.11
+Contact: David Herrmann <dh.herrmann@gmail.com>
+Description: This attribute is only provided if the device was detected as a
+ balance board. It provides a single line with 3 calibration
+ values for all 4 sensors. The values are separated by colons and
+ are each 2 bytes long (encoded as 4 digit hexadecimal value).
+ First, 0kg values for all 4 sensors are written, followed by the
+ 17kg values for all 4 sensors and last the 34kg values for all 4
+ sensors.
+ Calibration data is already applied by the kernel to all input
+ values but may be used by user-space to perform other
+ transformations.
diff --git a/Documentation/ABI/testing/sysfs-driver-intel-rapid-start b/Documentation/ABI/testing/sysfs-driver-intel-rapid-start
new file mode 100644
index 0000000..5a7d2e2
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-intel-rapid-start
@@ -0,0 +1,21 @@
+What: /sys/bus/acpi/intel-rapid-start/wakeup_events
+Date: July 2, 2013
+KernelVersion: 3.11
+Contact: Matthew Garrett <mjg59@srcf.ucam.org>
+Description: An integer representing a set of wakeup events as follows:
+ 1: Wake to enter hibernation when the wakeup timer expires
+ 2: Wake to enter hibernation when the battery reaches a
+ critical level
+
+ These values are ORed together. For example, a value of 3
+ indicates that the system will wake to enter hibernation when
+ either the wakeup timer expires or the battery reaches a
+ critical level.
+
+What: /sys/bus/acpi/intel-rapid-start/wakeup_time
+Date: July 2, 2013
+KernelVersion: 3.11
+Contact: Matthew Garrett <mjg59@srcf.ucam.org>
+Description: An integer representing the length of time the system will
+ remain asleep before waking up to enter hibernation.
+ This value is in minutes.
diff --git a/Documentation/ABI/testing/sysfs-firmware-acpi b/Documentation/ABI/testing/sysfs-firmware-acpi
index dd930c8..b4436cca 100644
--- a/Documentation/ABI/testing/sysfs-firmware-acpi
+++ b/Documentation/ABI/testing/sysfs-firmware-acpi
@@ -18,6 +18,42 @@
yoffset: The number of pixels between the top of the screen
and the top edge of the image.
+What: /sys/firmware/acpi/hotplug/
+Date: February 2013
+Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Description:
+ There are separate hotplug profiles for different classes of
+ devices supported by ACPI, such as containers, memory modules,
+ processors, PCI root bridges etc. A hotplug profile for a given
+ class of devices is a collection of settings defining the way
+ that class of devices will be handled by the ACPI core hotplug
+ code. Those profiles are represented in sysfs as subdirectories
+ of /sys/firmware/acpi/hotplug/.
+
+ The following setting is available to user space for each
+ hotplug profile:
+
+ enabled: If set, the ACPI core will handle notifications of
+ hotplug events associated with the given class of
+ devices and will allow those devices to be ejected with
+ the help of the _EJ0 control method. Unsetting it
+ effectively disables hotplug for the correspoinding
+ class of devices.
+
+ The value of the above attribute is an integer number: 1 (set)
+ or 0 (unset). Attempts to write any other values to it will
+ cause -EINVAL to be returned.
+
+What: /sys/firmware/acpi/hotplug/force_remove
+Date: May 2013
+Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Description:
+ The number in this file (0 or 1) determines whether (1) or not
+ (0) the ACPI subsystem will allow devices to be hot-removed even
+ if they cannot be put offline gracefully (from the kernel's
+ viewpoint). That number can be changed by writing a boolean
+ value to this file.
+
What: /sys/firmware/acpi/interrupts/
Date: February 2008
Contact: Len Brown <lenb@kernel.org>
diff --git a/Documentation/ABI/testing/sysfs-kernel-mm-ksm b/Documentation/ABI/testing/sysfs-kernel-mm-ksm
new file mode 100644
index 0000000..73e653e
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-kernel-mm-ksm
@@ -0,0 +1,52 @@
+What: /sys/kernel/mm/ksm
+Date: September 2009
+KernelVersion: 2.6.32
+Contact: Linux memory management mailing list <linux-mm@kvack.org>
+Description: Interface for Kernel Samepage Merging (KSM)
+
+What: /sys/kernel/mm/ksm/full_scans
+What: /sys/kernel/mm/ksm/pages_shared
+What: /sys/kernel/mm/ksm/pages_sharing
+What: /sys/kernel/mm/ksm/pages_to_scan
+What: /sys/kernel/mm/ksm/pages_unshared
+What: /sys/kernel/mm/ksm/pages_volatile
+What: /sys/kernel/mm/ksm/run
+What: /sys/kernel/mm/ksm/sleep_millisecs
+Date: September 2009
+Contact: Linux memory management mailing list <linux-mm@kvack.org>
+Description: Kernel Samepage Merging daemon sysfs interface
+
+ full_scans: how many times all mergeable areas have been
+ scanned.
+
+ pages_shared: how many shared pages are being used.
+
+ pages_sharing: how many more sites are sharing them i.e. how
+ much saved.
+
+ pages_to_scan: how many present pages to scan before ksmd goes
+ to sleep.
+
+ pages_unshared: how many pages unique but repeatedly checked
+ for merging.
+
+ pages_volatile: how many pages changing too fast to be placed
+ in a tree.
+
+ run: write 0 to disable ksm, read 0 while ksm is disabled.
+ write 1 to run ksm, read 1 while ksm is running.
+ write 2 to disable ksm and unmerge all its pages.
+
+ sleep_millisecs: how many milliseconds ksm should sleep between
+ scans.
+
+ See Documentation/vm/ksm.txt for more information.
+
+What: /sys/kernel/mm/ksm/merge_across_nodes
+Date: January 2013
+KernelVersion: 3.9
+Contact: Linux memory management mailing list <linux-mm@kvack.org>
+Description: Control merging pages across different NUMA nodes.
+
+ When it is set to 0 only pages from the same node are merged,
+ otherwise pages from all nodes can be merged together (default).
diff --git a/Documentation/ABI/testing/sysfs-platform-msi-laptop b/Documentation/ABI/testing/sysfs-platform-msi-laptop
new file mode 100644
index 0000000..307a247
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-platform-msi-laptop
@@ -0,0 +1,83 @@
+What: /sys/devices/platform/msi-laptop-pf/lcd_level
+Date: Oct 2006
+KernelVersion: 2.6.19
+Contact: "Lennart Poettering <mzxreary@0pointer.de>"
+Description:
+ Screen brightness: contains a single integer in the range 0..8.
+
+What: /sys/devices/platform/msi-laptop-pf/auto_brightness
+Date: Oct 2006
+KernelVersion: 2.6.19
+Contact: "Lennart Poettering <mzxreary@0pointer.de>"
+Description:
+ Enable automatic brightness control: contains either 0 or 1. If
+ set to 1 the hardware adjusts the screen brightness
+ automatically when the power cord is plugged/unplugged.
+
+What: /sys/devices/platform/msi-laptop-pf/wlan
+Date: Oct 2006
+KernelVersion: 2.6.19
+Contact: "Lennart Poettering <mzxreary@0pointer.de>"
+Description:
+ WLAN subsystem enabled: contains either 0 or 1.
+
+What: /sys/devices/platform/msi-laptop-pf/bluetooth
+Date: Oct 2006
+KernelVersion: 2.6.19
+Contact: "Lennart Poettering <mzxreary@0pointer.de>"
+Description:
+ Bluetooth subsystem enabled: contains either 0 or 1. Please
+ note that this file is constantly 0 if no Bluetooth hardware is
+ available.
+
+What: /sys/devices/platform/msi-laptop-pf/touchpad
+Date: Nov 2012
+KernelVersion: 3.8
+Contact: "Maxim Mikityanskiy <maxtram95@gmail.com>"
+Description:
+ Contains either 0 or 1 and indicates if touchpad is turned on.
+ Touchpad state can only be toggled by pressing Fn+F3.
+
+What: /sys/devices/platform/msi-laptop-pf/turbo_mode
+Date: Nov 2012
+KernelVersion: 3.8
+Contact: "Maxim Mikityanskiy <maxtram95@gmail.com>"
+Description:
+ Contains either 0 or 1 and indicates if turbo mode is turned
+ on. In turbo mode power LED is orange and processor is
+ overclocked. Turbo mode is available only if charging. It is
+ only possible to toggle turbo mode state by pressing Fn+F10,
+ and there is a few seconds cooldown between subsequent toggles.
+ If user presses Fn+F10 too frequent, turbo mode state is not
+ changed.
+
+What: /sys/devices/platform/msi-laptop-pf/eco_mode
+Date: Nov 2012
+KernelVersion: 3.8
+Contact: "Maxim Mikityanskiy <maxtram95@gmail.com>"
+Description:
+ Contains either 0 or 1 and indicates if ECO mode is turned on.
+ In ECO mode power LED is green and userspace should do some
+ powersaving actions. ECO mode is available only on battery
+ power. ECO mode can only be toggled by pressing Fn+F10.
+
+What: /sys/devices/platform/msi-laptop-pf/turbo_cooldown
+Date: Nov 2012
+KernelVersion: 3.8
+Contact: "Maxim Mikityanskiy <maxtram95@gmail.com>"
+Description:
+ Contains value in range 0..3:
+ * 0 -> Turbo mode is off
+ * 1 -> Turbo mode is on, cannot be turned off yet
+ * 2 -> Turbo mode is off, cannot be turned on yet
+ * 3 -> Turbo mode is on
+
+What: /sys/devices/platform/msi-laptop-pf/auto_fan
+Date: Nov 2012
+KernelVersion: 3.8
+Contact: "Maxim Mikityanskiy <maxtram95@gmail.com>"
+Description:
+ Contains either 0 or 1 and indicates if fan speed is controlled
+ automatically (1) or fan runs at maximal speed (0). Can be
+ toggled in software.
+
diff --git a/Documentation/ABI/testing/sysfs-platform-ts5500 b/Documentation/ABI/testing/sysfs-platform-ts5500
new file mode 100644
index 0000000..c88375a
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-platform-ts5500
@@ -0,0 +1,47 @@
+What: /sys/devices/platform/ts5500/adc
+Date: January 2013
+KernelVersion: 3.7
+Contact: "Savoir-faire Linux Inc." <kernel@savoirfairelinux.com>
+Description:
+ Indicates the presence of an A/D Converter. If it is present,
+ it will display "1", otherwise "0".
+
+What: /sys/devices/platform/ts5500/ereset
+Date: January 2013
+KernelVersion: 3.7
+Contact: "Savoir-faire Linux Inc." <kernel@savoirfairelinux.com>
+Description:
+ Indicates the presence of an external reset. If it is present,
+ it will display "1", otherwise "0".
+
+What: /sys/devices/platform/ts5500/id
+Date: January 2013
+KernelVersion: 3.7
+Contact: "Savoir-faire Linux Inc." <kernel@savoirfairelinux.com>
+Description:
+ Product ID of the TS board. TS-5500 ID is 0x60.
+
+What: /sys/devices/platform/ts5500/jumpers
+Date: January 2013
+KernelVersion: 3.7
+Contact: "Savoir-faire Linux Inc." <kernel@savoirfairelinux.com>
+Description:
+ Bitfield showing the jumpers' state. If a jumper is present,
+ the corresponding bit is set. For instance, 0x0e means jumpers
+ 2, 3 and 4 are set.
+
+What: /sys/devices/platform/ts5500/rs485
+Date: January 2013
+KernelVersion: 3.7
+Contact: "Savoir-faire Linux Inc." <kernel@savoirfairelinux.com>
+Description:
+ Indicates the presence of the RS485 option. If it is present,
+ it will display "1", otherwise "0".
+
+What: /sys/devices/platform/ts5500/sram
+Date: January 2013
+KernelVersion: 3.7
+Contact: "Savoir-faire Linux Inc." <kernel@savoirfairelinux.com>
+Description:
+ Indicates the presence of the SRAM option. If it is present,
+ it will display "1", otherwise "0".
diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle
index 495e5ba..7fe0546 100644
--- a/Documentation/CodingStyle
+++ b/Documentation/CodingStyle
@@ -389,7 +389,8 @@
used frequently by compilers in form of the unconditional jump instruction.
The goto statement comes in handy when a function exits from multiple
-locations and some common work such as cleanup has to be done.
+locations and some common work such as cleanup has to be done. If there is no
+cleanup needed then just return directly.
The rationale is:
@@ -546,15 +547,7 @@
logging of avc messages output). Does not do system-call
auditing without CONFIG_AUDITSYSCALL.
-Features that might still be considered unstable should be defined as
-dependent on "EXPERIMENTAL":
-
-config SLUB
- depends on EXPERIMENTAL && !ARCH_USES_SLAB_PAGE_STRUCT
- bool "SLUB (Unqueued Allocator)"
- ...
-
-while seriously dangerous features (such as write support for certain
+Seriously dangerous features (such as write support for certain
filesystems) should advertise this prominently in their prompt string:
config ADFS_FS_RW
diff --git a/Documentation/DMA-API-HOWTO.txt b/Documentation/DMA-API-HOWTO.txt
index 4a4fb295..14129f1 100644
--- a/Documentation/DMA-API-HOWTO.txt
+++ b/Documentation/DMA-API-HOWTO.txt
@@ -488,9 +488,10 @@
that the mapping code will work correctly on all dma implementations without
any dependency on the specifics of the underlying implementation. Using the
returned address without checking for errors could result in failures ranging
-from panics to silent data corruption. Couple of example of incorrect ways to
-check for errors that make assumptions about the underlying dma implementation
-are as follows and these are applicable to dma_map_page() as well.
+from panics to silent data corruption. A couple of examples of incorrect ways
+to check for errors that make assumptions about the underlying dma
+implementation are as follows and these are applicable to dma_map_page() as
+well.
Incorrect example 1:
dma_addr_t dma_handle;
@@ -751,7 +752,7 @@
dma_unmap_single(dma_handle1);
map_error_handling1:
-Example 2: (if buffers are allocated a loop, unmap all mapped buffers when
+Example 2: (if buffers are allocated in a loop, unmap all mapped buffers when
mapping error is detected in the middle)
dma_addr_t dma_addr;
diff --git a/Documentation/DocBook/80211.tmpl b/Documentation/DocBook/80211.tmpl
index 42e7f03..49267ea9 100644
--- a/Documentation/DocBook/80211.tmpl
+++ b/Documentation/DocBook/80211.tmpl
@@ -107,8 +107,8 @@
!Finclude/net/cfg80211.h key_params
!Finclude/net/cfg80211.h survey_info_flags
!Finclude/net/cfg80211.h survey_info
-!Finclude/net/cfg80211.h beacon_parameters
-!Finclude/net/cfg80211.h plink_actions
+!Finclude/net/cfg80211.h cfg80211_beacon_data
+!Finclude/net/cfg80211.h cfg80211_ap_settings
!Finclude/net/cfg80211.h station_parameters
!Finclude/net/cfg80211.h station_info_flags
!Finclude/net/cfg80211.h rate_info_flags
@@ -127,14 +127,11 @@
!Finclude/net/cfg80211.h cfg80211_ibss_params
!Finclude/net/cfg80211.h cfg80211_connect_params
!Finclude/net/cfg80211.h cfg80211_pmksa
-!Finclude/net/cfg80211.h cfg80211_send_rx_auth
-!Finclude/net/cfg80211.h cfg80211_send_auth_timeout
-!Finclude/net/cfg80211.h cfg80211_send_rx_assoc
-!Finclude/net/cfg80211.h cfg80211_send_assoc_timeout
-!Finclude/net/cfg80211.h cfg80211_send_deauth
-!Finclude/net/cfg80211.h __cfg80211_send_deauth
-!Finclude/net/cfg80211.h cfg80211_send_disassoc
-!Finclude/net/cfg80211.h __cfg80211_send_disassoc
+!Finclude/net/cfg80211.h cfg80211_rx_mlme_mgmt
+!Finclude/net/cfg80211.h cfg80211_auth_timeout
+!Finclude/net/cfg80211.h cfg80211_rx_assoc_resp
+!Finclude/net/cfg80211.h cfg80211_assoc_timeout
+!Finclude/net/cfg80211.h cfg80211_tx_mlme_mgmt
!Finclude/net/cfg80211.h cfg80211_ibss_joined
!Finclude/net/cfg80211.h cfg80211_connect_result
!Finclude/net/cfg80211.h cfg80211_roamed
@@ -437,7 +434,7 @@
</section>
!Finclude/net/mac80211.h ieee80211_get_buffered_bc
!Finclude/net/mac80211.h ieee80211_beacon_get
-!Finclude/net/mac80211.h ieee80211_sta_eosp_irqsafe
+!Finclude/net/mac80211.h ieee80211_sta_eosp
!Finclude/net/mac80211.h ieee80211_frame_release_type
!Finclude/net/mac80211.h ieee80211_sta_ps_transition
!Finclude/net/mac80211.h ieee80211_sta_ps_transition_ni
diff --git a/Documentation/DocBook/device-drivers.tmpl b/Documentation/DocBook/device-drivers.tmpl
index 7514dbf..cbfdf54 100644
--- a/Documentation/DocBook/device-drivers.tmpl
+++ b/Documentation/DocBook/device-drivers.tmpl
@@ -126,6 +126,8 @@
</sect1>
<sect1><title>Device Drivers DMA Management</title>
!Edrivers/base/dma-buf.c
+!Edrivers/base/reservation.c
+!Iinclude/linux/reservation.h
!Edrivers/base/dma-coherent.c
!Edrivers/base/dma-mapping.c
</sect1>
@@ -227,7 +229,7 @@
<chapter id="uart16x50">
<title>16x50 UART Driver</title>
!Edrivers/tty/serial/serial_core.c
-!Edrivers/tty/serial/8250/8250.c
+!Edrivers/tty/serial/8250/8250_core.c
</chapter>
<chapter id="fbdev">
@@ -297,10 +299,10 @@
</sect1>
<sect1><title>Frame Buffer Fonts</title>
<para>
- Refer to the file drivers/video/console/fonts.c for more information.
+ Refer to the file lib/fonts/fonts.c for more information.
</para>
<!-- FIXME: Removed for now since no structured comments in source
-X!Idrivers/video/console/fonts.c
+X!Ilib/fonts/fonts.c
-->
</sect1>
</chapter>
diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 4ee2304..7d1278e 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -186,11 +186,12 @@
<varlistentry>
<term>DRIVER_HAVE_IRQ</term><term>DRIVER_IRQ_SHARED</term>
<listitem><para>
- DRIVER_HAVE_IRQ indicates whether the driver has an IRQ handler. The
- DRM core will automatically register an interrupt handler when the
- flag is set. DRIVER_IRQ_SHARED indicates whether the device &
- handler support shared IRQs (note that this is required of PCI
- drivers).
+ DRIVER_HAVE_IRQ indicates whether the driver has an IRQ handler
+ managed by the DRM Core. The core will support simple IRQ handler
+ installation when the flag is set. The installation process is
+ described in <xref linkend="drm-irq-registration"/>.</para>
+ <para>DRIVER_IRQ_SHARED indicates whether the device & handler
+ support shared IRQs (note that this is required of PCI drivers).
</para></listitem>
</varlistentry>
<varlistentry>
@@ -344,50 +345,71 @@
The DRM core tries to facilitate IRQ handler registration and
unregistration by providing <function>drm_irq_install</function> and
<function>drm_irq_uninstall</function> functions. Those functions only
- support a single interrupt per device.
+ support a single interrupt per device, devices that use more than one
+ IRQs need to be handled manually.
</para>
- <!--!Fdrivers/char/drm/drm_irq.c drm_irq_install-->
- <para>
- Both functions get the device IRQ by calling
- <function>drm_dev_to_irq</function>. This inline function will call a
- bus-specific operation to retrieve the IRQ number. For platform devices,
- <function>platform_get_irq</function>(..., 0) is used to retrieve the
- IRQ number.
- </para>
- <para>
- <function>drm_irq_install</function> starts by calling the
- <methodname>irq_preinstall</methodname> driver operation. The operation
- is optional and must make sure that the interrupt will not get fired by
- clearing all pending interrupt flags or disabling the interrupt.
- </para>
- <para>
- The IRQ will then be requested by a call to
- <function>request_irq</function>. If the DRIVER_IRQ_SHARED driver
- feature flag is set, a shared (IRQF_SHARED) IRQ handler will be
- requested.
- </para>
- <para>
- The IRQ handler function must be provided as the mandatory irq_handler
- driver operation. It will get passed directly to
- <function>request_irq</function> and thus has the same prototype as all
- IRQ handlers. It will get called with a pointer to the DRM device as the
- second argument.
- </para>
- <para>
- Finally the function calls the optional
- <methodname>irq_postinstall</methodname> driver operation. The operation
- usually enables interrupts (excluding the vblank interrupt, which is
- enabled separately), but drivers may choose to enable/disable interrupts
- at a different time.
- </para>
- <para>
- <function>drm_irq_uninstall</function> is similarly used to uninstall an
- IRQ handler. It starts by waking up all processes waiting on a vblank
- interrupt to make sure they don't hang, and then calls the optional
- <methodname>irq_uninstall</methodname> driver operation. The operation
- must disable all hardware interrupts. Finally the function frees the IRQ
- by calling <function>free_irq</function>.
- </para>
+ <sect4>
+ <title>Managed IRQ Registration</title>
+ <para>
+ Both the <function>drm_irq_install</function> and
+ <function>drm_irq_uninstall</function> functions get the device IRQ by
+ calling <function>drm_dev_to_irq</function>. This inline function will
+ call a bus-specific operation to retrieve the IRQ number. For platform
+ devices, <function>platform_get_irq</function>(..., 0) is used to
+ retrieve the IRQ number.
+ </para>
+ <para>
+ <function>drm_irq_install</function> starts by calling the
+ <methodname>irq_preinstall</methodname> driver operation. The operation
+ is optional and must make sure that the interrupt will not get fired by
+ clearing all pending interrupt flags or disabling the interrupt.
+ </para>
+ <para>
+ The IRQ will then be requested by a call to
+ <function>request_irq</function>. If the DRIVER_IRQ_SHARED driver
+ feature flag is set, a shared (IRQF_SHARED) IRQ handler will be
+ requested.
+ </para>
+ <para>
+ The IRQ handler function must be provided as the mandatory irq_handler
+ driver operation. It will get passed directly to
+ <function>request_irq</function> and thus has the same prototype as all
+ IRQ handlers. It will get called with a pointer to the DRM device as the
+ second argument.
+ </para>
+ <para>
+ Finally the function calls the optional
+ <methodname>irq_postinstall</methodname> driver operation. The operation
+ usually enables interrupts (excluding the vblank interrupt, which is
+ enabled separately), but drivers may choose to enable/disable interrupts
+ at a different time.
+ </para>
+ <para>
+ <function>drm_irq_uninstall</function> is similarly used to uninstall an
+ IRQ handler. It starts by waking up all processes waiting on a vblank
+ interrupt to make sure they don't hang, and then calls the optional
+ <methodname>irq_uninstall</methodname> driver operation. The operation
+ must disable all hardware interrupts. Finally the function frees the IRQ
+ by calling <function>free_irq</function>.
+ </para>
+ </sect4>
+ <sect4>
+ <title>Manual IRQ Registration</title>
+ <para>
+ Drivers that require multiple interrupt handlers can't use the managed
+ IRQ registration functions. In that case IRQs must be registered and
+ unregistered manually (usually with the <function>request_irq</function>
+ and <function>free_irq</function> functions, or their devm_* equivalent).
+ </para>
+ <para>
+ When manually registering IRQs, drivers must not set the DRIVER_HAVE_IRQ
+ driver feature flag, and must not provide the
+ <methodname>irq_handler</methodname> driver operation. They must set the
+ <structname>drm_device</structname> <structfield>irq_enabled</structfield>
+ field to 1 upon registration of the IRQs, and clear it to 0 after
+ unregistering the IRQs.
+ </para>
+ </sect4>
</sect3>
<sect3>
<title>Memory Manager Initialization</title>
@@ -434,7 +456,7 @@
The DRM core includes two memory managers, namely Translation Table Maps
(TTM) and Graphics Execution Manager (GEM). TTM was the first DRM memory
manager to be developed and tried to be a one-size-fits-them all
- solution. It provides a single userspace API to accomodate the need of
+ solution. It provides a single userspace API to accommodate the need of
all hardware, supporting both Unified Memory Architecture (UMA) devices
and devices with dedicated video RAM (i.e. most discrete video cards).
This resulted in a large, complex piece of code that turned out to be
@@ -701,7 +723,7 @@
<para>
Similar to global names, GEM file descriptors are also used to share GEM
objects across processes. They offer additional security: as file
- descriptors must be explictly sent over UNIX domain sockets to be shared
+ descriptors must be explicitly sent over UNIX domain sockets to be shared
between applications, they can't be guessed like the globally unique GEM
names.
</para>
@@ -743,6 +765,10 @@
These two operations are mandatory for GEM drivers that support DRM
PRIME.
</para>
+ <sect4>
+ <title>DRM PRIME Helper Functions Reference</title>
+!Pdrivers/gpu/drm/drm_prime.c PRIME Helpers
+ </sect4>
</sect3>
<sect3 id="drm-gem-objects-mapping">
<title>GEM Objects Mapping</title>
@@ -978,10 +1004,25 @@
If the parameters are deemed valid, drivers then create, initialize and
return an instance of struct <structname>drm_framebuffer</structname>.
If desired the instance can be embedded in a larger driver-specific
- structure. The new instance is initialized with a call to
- <function>drm_framebuffer_init</function> which takes a pointer to DRM
- frame buffer operations (struct
- <structname>drm_framebuffer_funcs</structname>). Frame buffer operations are
+ structure. Drivers must fill its <structfield>width</structfield>,
+ <structfield>height</structfield>, <structfield>pitches</structfield>,
+ <structfield>offsets</structfield>, <structfield>depth</structfield>,
+ <structfield>bits_per_pixel</structfield> and
+ <structfield>pixel_format</structfield> fields from the values passed
+ through the <parameter>drm_mode_fb_cmd2</parameter> argument. They
+ should call the <function>drm_helper_mode_fill_fb_struct</function>
+ helper function to do so.
+ </para>
+
+ <para>
+ The initailization of the new framebuffer instance is finalized with a
+ call to <function>drm_framebuffer_init</function> which takes a pointer
+ to DRM frame buffer operations (struct
+ <structname>drm_framebuffer_funcs</structname>). Note that this function
+ publishes the framebuffer and so from this point on it can be accessed
+ concurrently from other threads. Hence it must be the last step in the
+ driver's framebuffer initialization sequence. Frame buffer operations
+ are
<itemizedlist>
<listitem>
<synopsis>int (*create_handle)(struct drm_framebuffer *fb,
@@ -1022,16 +1063,16 @@
</itemizedlist>
</para>
<para>
- After initializing the <structname>drm_framebuffer</structname>
- instance drivers must fill its <structfield>width</structfield>,
- <structfield>height</structfield>, <structfield>pitches</structfield>,
- <structfield>offsets</structfield>, <structfield>depth</structfield>,
- <structfield>bits_per_pixel</structfield> and
- <structfield>pixel_format</structfield> fields from the values passed
- through the <parameter>drm_mode_fb_cmd2</parameter> argument. They
- should call the <function>drm_helper_mode_fill_fb_struct</function>
- helper function to do so.
- </para>
+ The lifetime of a drm framebuffer is controlled with a reference count,
+ drivers can grab additional references with
+ <function>drm_framebuffer_reference</function> </para> and drop them
+ again with <function>drm_framebuffer_unreference</function>. For
+ driver-private framebuffers for which the last reference is never
+ dropped (e.g. for the fbdev framebuffer when the struct
+ <structname>drm_framebuffer</structname> is embedded into the fbdev
+ helper struct) drivers can manually clean up a framebuffer at module
+ unload time with
+ <function>drm_framebuffer_unregister_private</function>.
</sect2>
<sect2>
<title>Output Polling</title>
@@ -1043,6 +1084,22 @@
operation.
</para>
</sect2>
+ <sect2>
+ <title>Locking</title>
+ <para>
+ Beside some lookup structures with their own locking (which is hidden
+ behind the interface functions) most of the modeset state is protected
+ by the <code>dev-<mode_config.lock</code> mutex and additionally
+ per-crtc locks to allow cursor updates, pageflips and similar operations
+ to occur concurrently with background tasks like output detection.
+ Operations which cross domains like a full modeset always grab all
+ locks. Drivers there need to protect resources shared between crtcs with
+ additional locking. They also need to be careful to always grab the
+ relevant crtc locks if a modset functions touches crtc state, e.g. for
+ load detection (which does only grab the <code>mode_config.lock</code>
+ to allow concurrent screen updates on live crtcs).
+ </para>
+ </sect2>
</sect1>
<!-- Internals: kms initialization and cleanup -->
@@ -1119,13 +1176,19 @@
</para>
<para>
The <methodname>page_flip</methodname> operation schedules a page flip.
- Once any pending rendering targetting the new frame buffer has
+ Once any pending rendering targeting the new frame buffer has
completed, the CRTC will be reprogrammed to display that frame buffer
after the next vertical refresh. The operation must return immediately
without waiting for rendering or page flip to complete and must block
any new rendering to the frame buffer until the page flip completes.
</para>
<para>
+ If a page flip can be successfully scheduled the driver must set the
+ <code>drm_crtc-<fb</code> field to the new framebuffer pointed to
+ by <code>fb</code>. This is important so that the reference counting
+ on framebuffers stays balanced.
+ </para>
+ <para>
If a page flip is already pending, the
<methodname>page_flip</methodname> operation must return
-<errorname>EBUSY</errorname>.
@@ -1173,6 +1236,15 @@
<title>Miscellaneous</title>
<itemizedlist>
<listitem>
+ <synopsis>void (*set_property)(struct drm_crtc *crtc,
+ struct drm_property *property, uint64_t value);</synopsis>
+ <para>
+ Set the value of the given CRTC property to
+ <parameter>value</parameter>. See <xref linkend="drm-kms-properties"/>
+ for more information about properties.
+ </para>
+ </listitem>
+ <listitem>
<synopsis>void (*gamma_set)(struct drm_crtc *crtc, u16 *r, u16 *g, u16 *b,
uint32_t start, uint32_t size);</synopsis>
<para>
@@ -1322,6 +1394,15 @@
<xref linkend="drm-kms-init"/>.
</para>
</listitem>
+ <listitem>
+ <synopsis>void (*set_property)(struct drm_plane *plane,
+ struct drm_property *property, uint64_t value);</synopsis>
+ <para>
+ Set the value of the given plane property to
+ <parameter>value</parameter>. See <xref linkend="drm-kms-properties"/>
+ for more information about properties.
+ </para>
+ </listitem>
</itemizedlist>
</sect3>
</sect2>
@@ -1531,6 +1612,15 @@
<title>Miscellaneous</title>
<itemizedlist>
<listitem>
+ <synopsis>void (*set_property)(struct drm_connector *connector,
+ struct drm_property *property, uint64_t value);</synopsis>
+ <para>
+ Set the value of the given connector property to
+ <parameter>value</parameter>. See <xref linkend="drm-kms-properties"/>
+ for more information about properties.
+ </para>
+ </listitem>
+ <listitem>
<synopsis>void (*destroy)(struct drm_connector *connector);</synopsis>
<para>
Destroy the connector when not needed anymore. See
@@ -1609,6 +1699,10 @@
make its properties available to applications.
</para>
</sect2>
+ <sect2>
+ <title>KMS API Functions</title>
+!Edrivers/gpu/drm/drm_crtc.c
+ </sect2>
</sect1>
<!-- Internals: kms helper functions -->
@@ -1801,10 +1895,6 @@
<synopsis>bool (*mode_fixup)(struct drm_encoder *encoder,
const struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode);</synopsis>
- <note><para>
- FIXME: The mode argument be const, but the i915 driver modifies
- mode->clock in <function>intel_dp_mode_fixup</function>.
- </para></note>
<para>
Let encoders adjust the requested mode or reject it completely. This
operation returns true if the mode is accepted (possibly after being
@@ -2104,6 +2194,7 @@
<title>fbdev Helper Functions Reference</title>
!Pdrivers/gpu/drm/drm_fb_helper.c fbdev helpers
!Edrivers/gpu/drm/drm_fb_helper.c
+!Iinclude/drm/drm_fb_helper.h
</sect2>
<sect2>
<title>Display Port Helper Functions Reference</title>
@@ -2111,6 +2202,132 @@
!Iinclude/drm/drm_dp_helper.h
!Edrivers/gpu/drm/drm_dp_helper.c
</sect2>
+ <sect2>
+ <title>EDID Helper Functions Reference</title>
+!Edrivers/gpu/drm/drm_edid.c
+ </sect2>
+ <sect2>
+ <title>Rectangle Utilities Reference</title>
+!Pinclude/drm/drm_rect.h rect utils
+!Iinclude/drm/drm_rect.h
+!Edrivers/gpu/drm/drm_rect.c
+ </sect2>
+ </sect1>
+
+ <!-- Internals: kms properties -->
+
+ <sect1 id="drm-kms-properties">
+ <title>KMS Properties</title>
+ <para>
+ Drivers may need to expose additional parameters to applications than
+ those described in the previous sections. KMS supports attaching
+ properties to CRTCs, connectors and planes and offers a userspace API to
+ list, get and set the property values.
+ </para>
+ <para>
+ Properties are identified by a name that uniquely defines the property
+ purpose, and store an associated value. For all property types except blob
+ properties the value is a 64-bit unsigned integer.
+ </para>
+ <para>
+ KMS differentiates between properties and property instances. Drivers
+ first create properties and then create and associate individual instances
+ of those properties to objects. A property can be instantiated multiple
+ times and associated with different objects. Values are stored in property
+ instances, and all other property information are stored in the propery
+ and shared between all instances of the property.
+ </para>
+ <para>
+ Every property is created with a type that influences how the KMS core
+ handles the property. Supported property types are
+ <variablelist>
+ <varlistentry>
+ <term>DRM_MODE_PROP_RANGE</term>
+ <listitem><para>Range properties report their minimum and maximum
+ admissible values. The KMS core verifies that values set by
+ application fit in that range.</para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>DRM_MODE_PROP_ENUM</term>
+ <listitem><para>Enumerated properties take a numerical value that
+ ranges from 0 to the number of enumerated values defined by the
+ property minus one, and associate a free-formed string name to each
+ value. Applications can retrieve the list of defined value-name pairs
+ and use the numerical value to get and set property instance values.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>DRM_MODE_PROP_BITMASK</term>
+ <listitem><para>Bitmask properties are enumeration properties that
+ additionally restrict all enumerated values to the 0..63 range.
+ Bitmask property instance values combine one or more of the
+ enumerated bits defined by the property.</para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>DRM_MODE_PROP_BLOB</term>
+ <listitem><para>Blob properties store a binary blob without any format
+ restriction. The binary blobs are created as KMS standalone objects,
+ and blob property instance values store the ID of their associated
+ blob object.</para>
+ <para>Blob properties are only used for the connector EDID property
+ and cannot be created by drivers.</para></listitem>
+ </varlistentry>
+ </variablelist>
+ </para>
+ <para>
+ To create a property drivers call one of the following functions depending
+ on the property type. All property creation functions take property flags
+ and name, as well as type-specific arguments.
+ <itemizedlist>
+ <listitem>
+ <synopsis>struct drm_property *drm_property_create_range(struct drm_device *dev, int flags,
+ const char *name,
+ uint64_t min, uint64_t max);</synopsis>
+ <para>Create a range property with the given minimum and maximum
+ values.</para>
+ </listitem>
+ <listitem>
+ <synopsis>struct drm_property *drm_property_create_enum(struct drm_device *dev, int flags,
+ const char *name,
+ const struct drm_prop_enum_list *props,
+ int num_values);</synopsis>
+ <para>Create an enumerated property. The <parameter>props</parameter>
+ argument points to an array of <parameter>num_values</parameter>
+ value-name pairs.</para>
+ </listitem>
+ <listitem>
+ <synopsis>struct drm_property *drm_property_create_bitmask(struct drm_device *dev,
+ int flags, const char *name,
+ const struct drm_prop_enum_list *props,
+ int num_values);</synopsis>
+ <para>Create a bitmask property. The <parameter>props</parameter>
+ argument points to an array of <parameter>num_values</parameter>
+ value-name pairs.</para>
+ </listitem>
+ </itemizedlist>
+ </para>
+ <para>
+ Properties can additionally be created as immutable, in which case they
+ will be read-only for applications but can be modified by the driver. To
+ create an immutable property drivers must set the DRM_MODE_PROP_IMMUTABLE
+ flag at property creation time.
+ </para>
+ <para>
+ When no array of value-name pairs is readily available at property
+ creation time for enumerated or range properties, drivers can create
+ the property using the <function>drm_property_create</function> function
+ and manually add enumeration value-name pairs by calling the
+ <function>drm_property_add_enum</function> function. Care must be taken to
+ properly specify the property type through the <parameter>flags</parameter>
+ argument.
+ </para>
+ <para>
+ After creating properties drivers can attach property instances to CRTC,
+ connector and plane objects by calling the
+ <function>drm_object_attach_property</function>. The function takes a
+ pointer to the target object, a pointer to the previously created property
+ and an initial instance value.
+ </para>
</sect1>
<!-- Internals: vertical blanking -->
diff --git a/Documentation/DocBook/genericirq.tmpl b/Documentation/DocBook/genericirq.tmpl
index b342234..d16d21b 100644
--- a/Documentation/DocBook/genericirq.tmpl
+++ b/Documentation/DocBook/genericirq.tmpl
@@ -464,6 +464,19 @@
protected via desc->lock, by the generic layer.
</para>
</chapter>
+
+ <chapter id="genericchip">
+ <title>Generic interrupt chip</title>
+ <para>
+ To avoid copies of identical implementations of irq chips the
+ core provides a configurable generic interrupt chip
+ implementation. Developers should check carefuly whether the
+ generic chip fits their needs before implementing the same
+ functionality slightly different themself.
+ </para>
+!Ekernel/irq/generic-chip.c
+ </chapter>
+
<chapter id="structs">
<title>Structures</title>
<para>
diff --git a/Documentation/DocBook/kernel-hacking.tmpl b/Documentation/DocBook/kernel-hacking.tmpl
index eee7142..d0758b2 100644
--- a/Documentation/DocBook/kernel-hacking.tmpl
+++ b/Documentation/DocBook/kernel-hacking.tmpl
@@ -945,7 +945,7 @@
<sect1 id="sym-exportsymbols">
<title><function>EXPORT_SYMBOL()</function>
- <filename class="headerfile">include/linux/module.h</filename></title>
+ <filename class="headerfile">include/linux/export.h</filename></title>
<para>
This is the classic method of exporting a symbol: dynamically
@@ -955,7 +955,7 @@
<sect1 id="sym-exportsymbols-gpl">
<title><function>EXPORT_SYMBOL_GPL()</function>
- <filename class="headerfile">include/linux/module.h</filename></title>
+ <filename class="headerfile">include/linux/export.h</filename></title>
<para>
Similar to <function>EXPORT_SYMBOL()</function> except that the
@@ -1185,13 +1185,6 @@
</para>
<para>
- You may well want to make your CONFIG option only visible if
- <symbol>CONFIG_EXPERIMENTAL</symbol> is enabled: this serves as a
- warning to users. There many other fancy things you can do: see
- the various <filename>Kconfig</filename> files for ideas.
- </para>
-
- <para>
In your description of the option, make sure you address both the
expert user and the user who knows nothing about your feature. Mention
incompatibilities and issues here. <emphasis> Definitely
diff --git a/Documentation/DocBook/kernel-locking.tmpl b/Documentation/DocBook/kernel-locking.tmpl
index 67e7ab4..09e884e 100644
--- a/Documentation/DocBook/kernel-locking.tmpl
+++ b/Documentation/DocBook/kernel-locking.tmpl
@@ -1955,12 +1955,17 @@
</sect1>
</chapter>
- <chapter id="apiref">
+ <chapter id="apiref-mutex">
<title>Mutex API reference</title>
!Iinclude/linux/mutex.h
!Ekernel/mutex.c
</chapter>
+ <chapter id="apiref-futex">
+ <title>Futex API reference</title>
+!Ikernel/futex.c
+ </chapter>
+
<chapter id="references">
<title>Further reading</title>
diff --git a/Documentation/DocBook/kgdb.tmpl b/Documentation/DocBook/kgdb.tmpl
index 4ee4ba3..f77358f 100644
--- a/Documentation/DocBook/kgdb.tmpl
+++ b/Documentation/DocBook/kgdb.tmpl
@@ -94,10 +94,8 @@
<sect1 id="CompileKGDB">
<title>Kernel config options for kgdb</title>
<para>
- To enable <symbol>CONFIG_KGDB</symbol> you should first turn on
- "Prompt for development and/or incomplete code/drivers"
- (CONFIG_EXPERIMENTAL) in "General setup", then under the
- "Kernel debugging" select "KGDB: kernel debugger".
+ To enable <symbol>CONFIG_KGDB</symbol> you should look under
+ "Kernel debugging" and select "KGDB: kernel debugger".
</para>
<para>
While it is not a hard requirement that you have symbols in your
diff --git a/Documentation/DocBook/media/dvb/dvbapi.xml b/Documentation/DocBook/media/dvb/dvbapi.xml
index 757488b2..0197bcc 100644
--- a/Documentation/DocBook/media/dvb/dvbapi.xml
+++ b/Documentation/DocBook/media/dvb/dvbapi.xml
@@ -84,7 +84,7 @@
<title>LINUX DVB API</title>
-<subtitle>Version 5.8</subtitle>
+<subtitle>Version 5.10</subtitle>
<!-- ADD THE CHAPTERS HERE -->
<chapter id="dvb_introdution">
&sub-intro;
diff --git a/Documentation/DocBook/media/dvb/dvbproperty.xml b/Documentation/DocBook/media/dvb/dvbproperty.xml
index 957e3ac..a9b15e3 100644
--- a/Documentation/DocBook/media/dvb/dvbproperty.xml
+++ b/Documentation/DocBook/media/dvb/dvbproperty.xml
@@ -1,20 +1,47 @@
<section id="FE_GET_SET_PROPERTY">
<title><constant>FE_GET_PROPERTY/FE_SET_PROPERTY</constant></title>
-<para>This section describes the DVB version 5 extention of the DVB-API, also
+<para>This section describes the DVB version 5 extension of the DVB-API, also
called "S2API", as this API were added to provide support for DVB-S2. It was
designed to be able to replace the old frontend API. Yet, the DISEQC and
the capability ioctls weren't implemented yet via the new way.</para>
<para>The typical usage for the <constant>FE_GET_PROPERTY/FE_SET_PROPERTY</constant>
API is to replace the ioctl's were the <link linkend="dvb-frontend-parameters">
struct <constant>dvb_frontend_parameters</constant></link> were used.</para>
+<section id="dtv-stats">
+<title>DTV stats type</title>
+<programlisting>
+struct dtv_stats {
+ __u8 scale; /* enum fecap_scale_params type */
+ union {
+ __u64 uvalue; /* for counters and relative scales */
+ __s64 svalue; /* for 1/1000 dB measures */
+ };
+} __packed;
+</programlisting>
+</section>
+<section id="dtv-fe-stats">
+<title>DTV stats type</title>
+<programlisting>
+#define MAX_DTV_STATS 4
+
+struct dtv_fe_stats {
+ __u8 len;
+ struct dtv_stats stat[MAX_DTV_STATS];
+} __packed;
+</programlisting>
+</section>
+
<section id="dtv-property">
<title>DTV property type</title>
<programlisting>
/* Reserved fields should be set to 0 */
+
struct dtv_property {
__u32 cmd;
+ __u32 reserved[3];
union {
__u32 data;
+ struct dtv_fe_stats st;
struct {
__u8 data[32];
__u32 len;
@@ -440,7 +467,7 @@
<title><constant>DTV-ISDBT-LAYER*</constant> parameters</title>
<para>ISDB-T channels can be coded hierarchically. As opposed to DVB-T in
ISDB-T hierarchical layers can be decoded simultaneously. For that
- reason a ISDB-T demodulator has 3 viterbi and 3 reed-solomon-decoders.</para>
+ reason a ISDB-T demodulator has 3 Viterbi and 3 Reed-Solomon decoders.</para>
<para>ISDB-T has 3 hierarchical layers which each can use a part of the
available segments. The total number of segments over all layers has
to 13 in ISDB-T.</para>
@@ -850,6 +877,145 @@
<para>use the special macro LNA_AUTO to set LNA auto</para>
</section>
</section>
+
+ <section id="frontend-stat-properties">
+ <title>Frontend statistics indicators</title>
+ <para>The values are returned via <constant>dtv_property.stat</constant>.
+ If the property is supported, <constant>dtv_property.stat.len</constant> is bigger than zero.</para>
+ <para>For most delivery systems, <constant>dtv_property.stat.len</constant>
+ will be 1 if the stats is supported, and the properties will
+ return a single value for each parameter.</para>
+ <para>It should be noticed, however, that new OFDM delivery systems
+ like ISDB can use different modulation types for each group of
+ carriers. On such standards, up to 3 groups of statistics can be
+ provided, and <constant>dtv_property.stat.len</constant> is updated
+ to reflect the "global" metrics, plus one metric per each carrier
+ group (called "layer" on ISDB).</para>
+ <para>So, in order to be consistent with other delivery systems, the first
+ value at <link linkend="dtv-stats"><constant>dtv_property.stat.dtv_stats</constant></link>
+ array refers to the global metric. The other elements of the array
+ represent each layer, starting from layer A(index 1),
+ layer B (index 2) and so on.</para>
+ <para>The number of filled elements are stored at <constant>dtv_property.stat.len</constant>.</para>
+ <para>Each element of the <constant>dtv_property.stat.dtv_stats</constant> array consists on two elements:</para>
+ <itemizedlist mark='opencircle'>
+ <listitem><para><constant>svalue</constant> or <constant>uvalue</constant>, where
+ <constant>svalue</constant> is for signed values of the measure (dB measures)
+ and <constant>uvalue</constant> is for unsigned values (counters, relative scale)</para></listitem>
+ <listitem><para><constant>scale</constant> - Scale for the value. It can be:</para>
+ <itemizedlist mark='bullet' id="fecap-scale-params">
+ <listitem><para><constant>FE_SCALE_NOT_AVAILABLE</constant> - The parameter is supported by the frontend, but it was not possible to collect it (could be a transitory or permanent condition)</para></listitem>
+ <listitem><para><constant>FE_SCALE_DECIBEL</constant> - parameter is a signed value, measured in 1/1000 dB</para></listitem>
+ <listitem><para><constant>FE_SCALE_RELATIVE</constant> - parameter is a unsigned value, where 0 means 0% and 65535 means 100%.</para></listitem>
+ <listitem><para><constant>FE_SCALE_COUNTER</constant> - parameter is a unsigned value that counts the occurrence of an event, like bit error, block error, or lapsed time.</para></listitem>
+ </itemizedlist>
+ </listitem>
+ </itemizedlist>
+ <section id="DTV-STAT-SIGNAL-STRENGTH">
+ <title><constant>DTV_STAT_SIGNAL_STRENGTH</constant></title>
+ <para>Indicates the signal strength level at the analog part of the tuner or of the demod.</para>
+ <para>Possible scales for this metric are:</para>
+ <itemizedlist mark='bullet'>
+ <listitem><para><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</para></listitem>
+ <listitem><para><constant>FE_SCALE_DECIBEL</constant> - signal strength is in 0.0001 dBm units, power measured in miliwatts. This value is generally negative.</para></listitem>
+ <listitem><para><constant>FE_SCALE_RELATIVE</constant> - The frontend provides a 0% to 100% measurement for power (actually, 0 to 65535).</para></listitem>
+ </itemizedlist>
+ </section>
+ <section id="DTV-STAT-CNR">
+ <title><constant>DTV_STAT_CNR</constant></title>
+ <para>Indicates the Signal to Noise ratio for the main carrier.</para>
+ <para>Possible scales for this metric are:</para>
+ <itemizedlist mark='bullet'>
+ <listitem><para><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</para></listitem>
+ <listitem><para><constant>FE_SCALE_DECIBEL</constant> - Signal/Noise ratio is in 0.0001 dB units.</para></listitem>
+ <listitem><para><constant>FE_SCALE_RELATIVE</constant> - The frontend provides a 0% to 100% measurement for Signal/Noise (actually, 0 to 65535).</para></listitem>
+ </itemizedlist>
+ </section>
+ <section id="DTV-STAT-PRE-ERROR-BIT-COUNT">
+ <title><constant>DTV_STAT_PRE_ERROR_BIT_COUNT</constant></title>
+ <para>Measures the number of bit errors before the forward error correction (FEC) on the inner coding block (before Viterbi, LDPC or other inner code).</para>
+ <para>This measure is taken during the same interval as <constant>DTV_STAT_PRE_TOTAL_BIT_COUNT</constant>.</para>
+ <para>In order to get the BER (Bit Error Rate) measurement, it should be divided by
+ <link linkend="DTV-STAT-PRE-TOTAL-BIT-COUNT"><constant>DTV_STAT_PRE_TOTAL_BIT_COUNT</constant></link>.</para>
+ <para>This measurement is monotonically increased, as the frontend gets more bit count measurements.
+ The frontend may reset it when a channel/transponder is tuned.</para>
+ <para>Possible scales for this metric are:</para>
+ <itemizedlist mark='bullet'>
+ <listitem><para><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</para></listitem>
+ <listitem><para><constant>FE_SCALE_COUNTER</constant> - Number of error bits counted before the inner coding.</para></listitem>
+ </itemizedlist>
+ </section>
+ <section id="DTV-STAT-PRE-TOTAL-BIT-COUNT">
+ <title><constant>DTV_STAT_PRE_TOTAL_BIT_COUNT</constant></title>
+ <para>Measures the amount of bits received before the inner code block, during the same period as
+ <link linkend="DTV-STAT-PRE-ERROR-BIT-COUNT"><constant>DTV_STAT_PRE_ERROR_BIT_COUNT</constant></link> measurement was taken.</para>
+ <para>It should be noticed that this measurement can be smaller than the total amount of bits on the transport stream,
+ as the frontend may need to manually restart the measurement, losing some data between each measurement interval.</para>
+ <para>This measurement is monotonically increased, as the frontend gets more bit count measurements.
+ The frontend may reset it when a channel/transponder is tuned.</para>
+ <para>Possible scales for this metric are:</para>
+ <itemizedlist mark='bullet'>
+ <listitem><para><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</para></listitem>
+ <listitem><para><constant>FE_SCALE_COUNTER</constant> - Number of bits counted while measuring
+ <link linkend="DTV-STAT-PRE-ERROR-BIT-COUNT"><constant>DTV_STAT_PRE_ERROR_BIT_COUNT</constant></link>.</para></listitem>
+ </itemizedlist>
+ </section>
+ <section id="DTV-STAT-POST-ERROR-BIT-COUNT">
+ <title><constant>DTV_STAT_POST_ERROR_BIT_COUNT</constant></title>
+ <para>Measures the number of bit errors after the forward error correction (FEC) done by inner code block (after Viterbi, LDPC or other inner code).</para>
+ <para>This measure is taken during the same interval as <constant>DTV_STAT_POST_TOTAL_BIT_COUNT</constant>.</para>
+ <para>In order to get the BER (Bit Error Rate) measurement, it should be divided by
+ <link linkend="DTV-STAT-POST-TOTAL-BIT-COUNT"><constant>DTV_STAT_POST_TOTAL_BIT_COUNT</constant></link>.</para>
+ <para>This measurement is monotonically increased, as the frontend gets more bit count measurements.
+ The frontend may reset it when a channel/transponder is tuned.</para>
+ <para>Possible scales for this metric are:</para>
+ <itemizedlist mark='bullet'>
+ <listitem><para><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</para></listitem>
+ <listitem><para><constant>FE_SCALE_COUNTER</constant> - Number of error bits counted after the inner coding.</para></listitem>
+ </itemizedlist>
+ </section>
+ <section id="DTV-STAT-POST-TOTAL-BIT-COUNT">
+ <title><constant>DTV_STAT_POST_TOTAL_BIT_COUNT</constant></title>
+ <para>Measures the amount of bits received after the inner coding, during the same period as
+ <link linkend="DTV-STAT-POST-ERROR-BIT-COUNT"><constant>DTV_STAT_POST_ERROR_BIT_COUNT</constant></link> measurement was taken.</para>
+ <para>It should be noticed that this measurement can be smaller than the total amount of bits on the transport stream,
+ as the frontend may need to manually restart the measurement, losing some data between each measurement interval.</para>
+ <para>This measurement is monotonically increased, as the frontend gets more bit count measurements.
+ The frontend may reset it when a channel/transponder is tuned.</para>
+ <para>Possible scales for this metric are:</para>
+ <itemizedlist mark='bullet'>
+ <listitem><para><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</para></listitem>
+ <listitem><para><constant>FE_SCALE_COUNTER</constant> - Number of bits counted while measuring
+ <link linkend="DTV-STAT-POST-ERROR-BIT-COUNT"><constant>DTV_STAT_POST_ERROR_BIT_COUNT</constant></link>.</para></listitem>
+ </itemizedlist>
+ </section>
+ <section id="DTV-STAT-ERROR-BLOCK-COUNT">
+ <title><constant>DTV_STAT_ERROR_BLOCK_COUNT</constant></title>
+ <para>Measures the number of block errors after the outer forward error correction coding (after Reed-Solomon or other outer code).</para>
+ <para>This measurement is monotonically increased, as the frontend gets more bit count measurements.
+ The frontend may reset it when a channel/transponder is tuned.</para>
+ <para>Possible scales for this metric are:</para>
+ <itemizedlist mark='bullet'>
+ <listitem><para><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</para></listitem>
+ <listitem><para><constant>FE_SCALE_COUNTER</constant> - Number of error blocks counted after the outer coding.</para></listitem>
+ </itemizedlist>
+ </section>
+ <section id="DTV-STAT-TOTAL-BLOCK-COUNT">
+ <title><constant>DTV-STAT_TOTAL_BLOCK_COUNT</constant></title>
+ <para>Measures the total number of blocks received during the same period as
+ <link linkend="DTV-STAT-ERROR-BLOCK-COUNT"><constant>DTV_STAT_ERROR_BLOCK_COUNT</constant></link> measurement was taken.</para>
+ <para>It can be used to calculate the PER indicator, by dividing
+ <link linkend="DTV-STAT-ERROR-BLOCK-COUNT"><constant>DTV_STAT_ERROR_BLOCK_COUNT</constant></link>
+ by <link linkend="DTV-STAT-TOTAL-BLOCK-COUNT"><constant>DTV-STAT-TOTAL-BLOCK-COUNT</constant></link>.</para>
+ <para>Possible scales for this metric are:</para>
+ <itemizedlist mark='bullet'>
+ <listitem><para><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</para></listitem>
+ <listitem><para><constant>FE_SCALE_COUNTER</constant> - Number of blocks counted while measuring
+ <link linkend="DTV-STAT-ERROR-BLOCK-COUNT"><constant>DTV_STAT_ERROR_BLOCK_COUNT</constant></link>.</para></listitem>
+ </itemizedlist>
+ </section>
+ </section>
+
<section id="frontend-property-terrestrial-systems">
<title>Properties used on terrestrial delivery systems</title>
<section id="dvbt-params">
@@ -871,6 +1037,7 @@
<listitem><para><link linkend="DTV-HIERARCHY"><constant>DTV_HIERARCHY</constant></link></para></listitem>
<listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem>
</itemizedlist>
+ <para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
</section>
<section id="dvbt2-params">
<title>DVB-T2 delivery system</title>
@@ -895,6 +1062,7 @@
<listitem><para><link linkend="DTV-STREAM-ID"><constant>DTV_STREAM_ID</constant></link></para></listitem>
<listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem>
</itemizedlist>
+ <para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
</section>
<section id="isdbt">
<title>ISDB-T delivery system</title>
@@ -948,6 +1116,7 @@
<listitem><para><link linkend="DTV-ISDBT-LAYER-SEGMENT-COUNT"><constant>DTV_ISDBT_LAYERC_SEGMENT_COUNT</constant></link></para></listitem>
<listitem><para><link linkend="DTV-ISDBT-LAYER-TIME-INTERLEAVING"><constant>DTV_ISDBT_LAYERC_TIME_INTERLEAVING</constant></link></para></listitem>
</itemizedlist>
+ <para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
</section>
<section id="atsc-params">
<title>ATSC delivery system</title>
@@ -961,6 +1130,7 @@
<listitem><para><link linkend="DTV-MODULATION"><constant>DTV_MODULATION</constant></link></para></listitem>
<listitem><para><link linkend="DTV-BANDWIDTH-HZ"><constant>DTV_BANDWIDTH_HZ</constant></link></para></listitem>
</itemizedlist>
+ <para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
</section>
<section id="atscmh-params">
<title>ATSC-MH delivery system</title>
@@ -988,6 +1158,7 @@
<listitem><para><link linkend="DTV-ATSCMH-SCCC-CODE-MODE-C"><constant>DTV_ATSCMH_SCCC_CODE_MODE_C</constant></link></para></listitem>
<listitem><para><link linkend="DTV-ATSCMH-SCCC-CODE-MODE-D"><constant>DTV_ATSCMH_SCCC_CODE_MODE_D</constant></link></para></listitem>
</itemizedlist>
+ <para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
</section>
<section id="dtmb-params">
<title>DTMB delivery system</title>
@@ -1007,6 +1178,7 @@
<listitem><para><link linkend="DTV-INTERLEAVING"><constant>DTV_INTERLEAVING</constant></link></para></listitem>
<listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem>
</itemizedlist>
+ <para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
</section>
</section>
<section id="frontend-property-cable-systems">
@@ -1028,6 +1200,7 @@
<listitem><para><link linkend="DTV-INNER-FEC"><constant>DTV_INNER_FEC</constant></link></para></listitem>
<listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem>
</itemizedlist>
+ <para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
</section>
<section id="dvbc-annex-b-params">
<title>DVB-C Annex B delivery system</title>
@@ -1043,6 +1216,7 @@
<listitem><para><link linkend="DTV-INVERSION"><constant>DTV_INVERSION</constant></link></para></listitem>
<listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem>
</itemizedlist>
+ <para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
</section>
</section>
<section id="frontend-property-satellital-systems">
@@ -1062,6 +1236,7 @@
<listitem><para><link linkend="DTV-VOLTAGE"><constant>DTV_VOLTAGE</constant></link></para></listitem>
<listitem><para><link linkend="DTV-TONE"><constant>DTV_TONE</constant></link></para></listitem>
</itemizedlist>
+ <para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
<para>Future implementations might add those two missing parameters:</para>
<itemizedlist mark='opencircle'>
<listitem><para><link linkend="DTV-DISEQC-MASTER"><constant>DTV_DISEQC_MASTER</constant></link></para></listitem>
@@ -1077,6 +1252,7 @@
<listitem><para><link linkend="DTV-ROLLOFF"><constant>DTV_ROLLOFF</constant></link></para></listitem>
<listitem><para><link linkend="DTV-STREAM-ID"><constant>DTV_STREAM_ID</constant></link></para></listitem>
</itemizedlist>
+ <para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
</section>
<section id="turbo-params">
<title>Turbo code delivery system</title>
diff --git a/Documentation/DocBook/media/dvb/frontend.xml b/Documentation/DocBook/media/dvb/frontend.xml
index 426c252..0d6e81b 100644
--- a/Documentation/DocBook/media/dvb/frontend.xml
+++ b/Documentation/DocBook/media/dvb/frontend.xml
@@ -230,10 +230,10 @@
<entry align="char">The frontend has found a DVB signal</entry>
</row><row>
<entry align="char">FE_HAS_VITERBI</entry>
-<entry align="char">The frontend FEC code is stable</entry>
+<entry align="char">The frontend FEC inner coding (Viterbi, LDPC or other inner code) is stable</entry>
</row><row>
<entry align="char">FE_HAS_SYNC</entry>
-<entry align="char">Syncronization bytes was found</entry>
+<entry align="char">Synchronization bytes was found</entry>
</row><row>
<entry align="char">FE_HAS_LOCK</entry>
<entry align="char">The DVB were locked and everything is working</entry>
diff --git a/Documentation/DocBook/media/v4l/common.xml b/Documentation/DocBook/media/v4l/common.xml
index 73c6847..1ddf354 100644
--- a/Documentation/DocBook/media/v4l/common.xml
+++ b/Documentation/DocBook/media/v4l/common.xml
@@ -609,7 +609,7 @@
<para>Applications can make use of the <xref linkend="input-capabilities" /> and
<xref linkend="output-capabilities"/> flags to determine whether the video standard ioctls
are available for the device.</para>
-&ENOTTY;.
+
<para>See <xref linkend="buffer" /> for a rationale. Probably
even USB cameras follow some well known video standard. It might have
been better to explicitly indicate elsewhere if a device cannot live
@@ -750,15 +750,6 @@
<xref linkend="vesadmt" /> standards.
</para>
</listitem>
- <listitem>
- <para>DV Presets: Digital Video (DV) presets (<emphasis role="bold">deprecated</emphasis>).
- These are IDs representing a
-video timing at the input/output. Presets are pre-defined timings implemented
-by the hardware according to video standards. A __u32 data type is used to represent
-a preset unlike the bit mask that is used in &v4l2-std-id; allowing future extensions
-to support as many different presets as needed. This API is deprecated in favor of the DV Timings
-API.</para>
- </listitem>
</itemizedlist>
<para>To enumerate and query the attributes of the DV timings supported by a device,
applications use the &VIDIOC-ENUM-DV-TIMINGS; and &VIDIOC-DV-TIMINGS-CAP; ioctls.
@@ -766,11 +757,6 @@
&VIDIOC-S-DV-TIMINGS; ioctl and to get current DV timings they use the
&VIDIOC-G-DV-TIMINGS; ioctl. To detect the DV timings as seen by the video receiver applications
use the &VIDIOC-QUERY-DV-TIMINGS; ioctl.</para>
- <para>To enumerate and query the attributes of DV presets supported by a device,
-applications use the &VIDIOC-ENUM-DV-PRESETS; ioctl. To get the current DV preset,
-applications use the &VIDIOC-G-DV-PRESET; ioctl and to set a preset they use the
-&VIDIOC-S-DV-PRESET; ioctl. To detect the preset as seen by the video receiver applications
-use the &VIDIOC-QUERY-DV-PRESET; ioctl.</para>
<para>Applications can make use of the <xref linkend="input-capabilities" /> and
<xref linkend="output-capabilities"/> flags to decide what ioctls are available to set the
video timings for the device.</para>
diff --git a/Documentation/DocBook/media/v4l/compat.xml b/Documentation/DocBook/media/v4l/compat.xml
index 3dd9e78..0c7195e 100644
--- a/Documentation/DocBook/media/v4l/compat.xml
+++ b/Documentation/DocBook/media/v4l/compat.xml
@@ -2254,7 +2254,7 @@
<orderedlist>
<listitem>
<para>The <constant>VIDIOC_G_CHIP_IDENT</constant> ioctl was renamed
-to <constant>VIDIOC_G_CHIP_IDENT_OLD</constant> and &VIDIOC-DBG-G-CHIP-IDENT;
+to <constant>VIDIOC_G_CHIP_IDENT_OLD</constant> and <constant>VIDIOC_DBG_G_CHIP_IDENT</constant>
was introduced in its place. The old struct <structname>v4l2_chip_ident</structname>
was renamed to <structname id="v4l2-chip-ident-old">v4l2_chip_ident_old</structname>.</para>
</listitem>
@@ -2310,6 +2310,9 @@
<listitem>
<para>Added FM Modulator (FM TX) Extended Control Class: <constant>V4L2_CTRL_CLASS_FM_TX</constant> and their Control IDs.</para>
</listitem>
+<listitem>
+ <para>Added FM Receiver (FM RX) Extended Control Class: <constant>V4L2_CTRL_CLASS_FM_RX</constant> and their Control IDs.</para>
+ </listitem>
<listitem>
<para>Added Remote Controller chapter, describing the default Remote Controller mapping for media devices.</para>
</listitem>
@@ -2477,6 +2480,49 @@
</orderedlist>
</section>
+ <section>
+ <title>V4L2 in Linux 3.9</title>
+ <orderedlist>
+ <listitem>
+ <para>Added timestamp types to
+ <structfield>flags</structfield> field in
+ <structname>v4l2_buffer</structname>. See <xref
+ linkend="buffer-flags" />.</para>
+ </listitem>
+ <listitem>
+ <para>Added <constant>V4L2_EVENT_CTRL_CH_RANGE</constant> control event
+ changes flag. See <xref linkend="changes-flags"/>.</para>
+ </listitem>
+ </orderedlist>
+ </section>
+
+ <section>
+ <title>V4L2 in Linux 3.10</title>
+ <orderedlist>
+ <listitem>
+ <para>Removed obsolete and unused DV_PRESET ioctls
+ VIDIOC_G_DV_PRESET, VIDIOC_S_DV_PRESET, VIDIOC_QUERY_DV_PRESET and
+ VIDIOC_ENUM_DV_PRESET. Remove the related v4l2_input/output capability
+ flags V4L2_IN_CAP_PRESETS and V4L2_OUT_CAP_PRESETS.
+ </para>
+ </listitem>
+ <listitem>
+ <para>Added new debugging ioctl &VIDIOC-DBG-G-CHIP-INFO;.
+ </para>
+ </listitem>
+ </orderedlist>
+ </section>
+
+ <section>
+ <title>V4L2 in Linux 3.11</title>
+ <orderedlist>
+ <listitem>
+ <para>Remove obsolete <constant>VIDIOC_DBG_G_CHIP_IDENT</constant> ioctl.
+ </para>
+ </listitem>
+ </orderedlist>
+ </section>
+
<section id="other">
<title>Relation of V4L2 to other Linux multimedia APIs</title>
@@ -2560,7 +2606,7 @@
ioctls.</para>
</listitem>
<listitem>
- <para>&VIDIOC-DBG-G-CHIP-IDENT; ioctl.</para>
+ <para>&VIDIOC-DBG-G-CHIP-INFO; ioctl.</para>
</listitem>
<listitem>
<para>&VIDIOC-ENUM-DV-TIMINGS;, &VIDIOC-QUERY-DV-TIMINGS; and
@@ -2609,8 +2655,8 @@
<xref linkend="extended-controls" />.</para>
</listitem>
<listitem>
- <para>&VIDIOC-G-DV-PRESET;, &VIDIOC-S-DV-PRESET;, &VIDIOC-ENUM-DV-PRESETS; and
- &VIDIOC-QUERY-DV-PRESET; ioctls. Use the DV Timings API (<xref linkend="dv-timings" />).</para>
+ <para>VIDIOC_G_DV_PRESET, VIDIOC_S_DV_PRESET, VIDIOC_ENUM_DV_PRESETS and
+ VIDIOC_QUERY_DV_PRESET ioctls. Use the DV Timings API (<xref linkend="dv-timings" />).</para>
</listitem>
<listitem>
<para><constant>VIDIOC_SUBDEV_G_CROP</constant> and
diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml
index 7fe5be1..c2fc9ec 100644
--- a/Documentation/DocBook/media/v4l/controls.xml
+++ b/Documentation/DocBook/media/v4l/controls.xml
@@ -203,29 +203,6 @@
<entry>boolean</entry>
<entry>Mirror the picture vertically.</entry>
</row>
- <row>
- <entry><constant>V4L2_CID_HCENTER_DEPRECATED</constant> (formerly <constant>V4L2_CID_HCENTER</constant>)</entry>
- <entry>integer</entry>
- <entry>Horizontal image centering. This control is
-deprecated. New drivers and applications should use the <link
-linkend="camera-controls">Camera class controls</link>
-<constant>V4L2_CID_PAN_ABSOLUTE</constant>,
-<constant>V4L2_CID_PAN_RELATIVE</constant> and
-<constant>V4L2_CID_PAN_RESET</constant> instead.</entry>
- </row>
- <row>
- <entry><constant>V4L2_CID_VCENTER_DEPRECATED</constant>
- (formerly <constant>V4L2_CID_VCENTER</constant>)</entry>
- <entry>integer</entry>
- <entry>Vertical image centering. Centering is intended to
-<emphasis>physically</emphasis> adjust cameras. For image cropping see
-<xref linkend="crop" />, for clipping <xref linkend="overlay" />. This
-control is deprecated. New drivers and applications should use the
-<link linkend="camera-controls">Camera class controls</link>
-<constant>V4L2_CID_TILT_ABSOLUTE</constant>,
-<constant>V4L2_CID_TILT_RELATIVE</constant> and
-<constant>V4L2_CID_TILT_RESET</constant> instead.</entry>
- </row>
<row id="v4l2-power-line-frequency">
<entry><constant>V4L2_CID_POWER_LINE_FREQUENCY</constant></entry>
<entry>enum</entry>
@@ -2323,6 +2300,12 @@
</row>
<row><entry></entry></row>
<row>
+ <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_REPEAT_SEQ_HEADER</constant> </entry>
+ <entry>boolean</entry>
+ </row><row><entry spanname="descr">Repeat the video sequence headers. Repeating these
+headers makes random access to the video stream easier. Applicable to the MPEG1, 2 and 4 encoder.</entry>
+ </row>
+ <row>
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_DECODER_MPEG4_DEBLOCK_FILTER</constant> </entry>
<entry>boolean</entry>
</row><row><entry spanname="descr">Enabled the deblocking post processing filter for MPEG4 decoder.
@@ -3159,6 +3142,13 @@
<entry><constant>V4L2_EXPOSURE_METERING_SPOT</constant> </entry>
<entry>Measure only very small area at the center of the frame.</entry>
</row>
+ <row>
+ <entry><constant>V4L2_EXPOSURE_METERING_MATRIX</constant> </entry>
+ <entry>A multi-zone metering. The light intensity is measured
+in several points of the frame and the the results are combined. The
+algorithm of the zones selection and their significance in calculating the
+final value is device dependent.</entry>
+ </row>
</tbody>
</entrytbl>
</row>
@@ -3871,7 +3861,7 @@
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_TUNE_PREEMPHASIS</constant> </entry>
- <entry>integer</entry>
+ <entry>enum v4l2_preemphasis</entry>
</row>
<row id="v4l2-preemphasis"><entry spanname="descr">Configures the pre-emphasis value for broadcasting.
A pre-emphasis filter is applied to the broadcast to accentuate the high audio frequencies.
@@ -4710,4 +4700,76 @@
</table>
</section>
+
+ <section id="fm-rx-controls">
+ <title>FM Receiver Control Reference</title>
+
+ <para>The FM Receiver (FM_RX) class includes controls for common features of
+ FM Reception capable devices.</para>
+
+ <table pgwide="1" frame="none" id="fm-rx-control-id">
+ <title>FM_RX Control IDs</title>
+
+ <tgroup cols="4">
+ <colspec colname="c1" colwidth="1*" />
+ <colspec colname="c2" colwidth="6*" />
+ <colspec colname="c3" colwidth="2*" />
+ <colspec colname="c4" colwidth="6*" />
+ <spanspec namest="c1" nameend="c2" spanname="id" />
+ <spanspec namest="c2" nameend="c4" spanname="descr" />
+ <thead>
+ <row>
+ <entry spanname="id" align="left">ID</entry>
+ <entry align="left">Type</entry>
+ </row><row rowsep="1"><entry spanname="descr" align="left">Description</entry>
+ </row>
+ </thead>
+ <tbody valign="top">
+ <row><entry></entry></row>
+ <row>
+ <entry spanname="id"><constant>V4L2_CID_FM_RX_CLASS</constant> </entry>
+ <entry>class</entry>
+ </row><row><entry spanname="descr">The FM_RX class
+descriptor. Calling &VIDIOC-QUERYCTRL; for this control will return a
+description of this control class.</entry>
+ </row>
+ <row>
+ <entry spanname="id"><constant>V4L2_CID_RDS_RECEPTION</constant> </entry>
+ <entry>boolean</entry>
+ </row><row><entry spanname="descr">Enables/disables RDS
+ reception by the radio tuner</entry>
+ </row>
+ <row>
+ <entry spanname="id"><constant>V4L2_CID_TUNE_DEEMPHASIS</constant> </entry>
+ <entry>enum v4l2_deemphasis</entry>
+ </row>
+ <row id="v4l2-deemphasis"><entry spanname="descr">Configures the de-emphasis value for reception.
+A de-emphasis filter is applied to the broadcast to accentuate the high audio frequencies.
+Depending on the region, a time constant of either 50 or 75 useconds is used. The enum v4l2_deemphasis
+defines possible values for de-emphasis. Here they are:</entry>
+ </row><row>
+ <entrytbl spanname="descr" cols="2">
+ <tbody valign="top">
+ <row>
+ <entry><constant>V4L2_DEEMPHASIS_DISABLED</constant> </entry>
+ <entry>No de-emphasis is applied.</entry>
+ </row>
+ <row>
+ <entry><constant>V4L2_DEEMPHASIS_50_uS</constant> </entry>
+ <entry>A de-emphasis of 50 uS is used.</entry>
+ </row>
+ <row>
+ <entry><constant>V4L2_DEEMPHASIS_75_uS</constant> </entry>
+ <entry>A de-emphasis of 75 uS is used.</entry>
+ </row>
+ </tbody>
+ </entrytbl>
+
+ </row>
+ <row><entry></entry></row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ </section>
</section>
diff --git a/Documentation/DocBook/media/v4l/dev-codec.xml b/Documentation/DocBook/media/v4l/dev-codec.xml
index dca0ecd..ff44c16 100644
--- a/Documentation/DocBook/media/v4l/dev-codec.xml
+++ b/Documentation/DocBook/media/v4l/dev-codec.xml
@@ -1,18 +1,27 @@
<title>Codec Interface</title>
- <note>
- <title>Suspended</title>
-
- <para>This interface has been be suspended from the V4L2 API
-implemented in Linux 2.6 until we have more experience with codec
-device interfaces.</para>
- </note>
-
<para>A V4L2 codec can compress, decompress, transform, or otherwise
-convert video data from one format into another format, in memory.
-Applications send data to be converted to the driver through a
-&func-write; call, and receive the converted data through a
-&func-read; call. For efficiency a driver may also support streaming
-I/O.</para>
+convert video data from one format into another format, in memory. Typically
+such devices are memory-to-memory devices (i.e. devices with the
+<constant>V4L2_CAP_VIDEO_M2M</constant> or <constant>V4L2_CAP_VIDEO_M2M_MPLANE</constant>
+capability set).
+</para>
- <para>[to do]</para>
+ <para>A memory-to-memory video node acts just like a normal video node, but it
+supports both output (sending frames from memory to the codec hardware) and
+capture (receiving the processed frames from the codec hardware into memory)
+stream I/O. An application will have to setup the stream
+I/O for both sides and finally call &VIDIOC-STREAMON; for both capture and output
+to start the codec.</para>
+
+ <para>Video compression codecs use the MPEG controls to setup their codec parameters
+(note that the MPEG controls actually support many more codecs than just MPEG).
+See <xref linkend="mpeg-controls"></xref>.</para>
+
+ <para>Memory-to-memory devices can often be used as a shared resource: you can
+open the video node multiple times, each application setting up their own codec properties
+that are local to the file handle, and each can use it independently from the others.
+The driver will arbitrate access to the codec and reprogram it whenever another file
+handler gets access. This is different from the usual video node behavior where the video properties
+are global to the device (i.e. changing something through one file handle is visible
+through another file handle).</para>
diff --git a/Documentation/DocBook/media/v4l/driver.xml b/Documentation/DocBook/media/v4l/driver.xml
index eacafe3..7c6638b 100644
--- a/Documentation/DocBook/media/v4l/driver.xml
+++ b/Documentation/DocBook/media/v4l/driver.xml
@@ -116,7 +116,7 @@
return 0; /* a negative value on error, 0 on success. */
}
-static void __devexit
+static void
my_remove (struct pci_dev * pci_dev)
{
my_device *my = pci_get_drvdata (pci_dev);
@@ -124,7 +124,7 @@
/* Describe me. */
}
-static int __devinit
+static int
my_probe (struct pci_dev * pci_dev,
const struct pci_device_id * pci_id)
{
@@ -157,7 +157,7 @@
.id_table = my_pci_device_ids,
.probe = my_probe,
- .remove = __devexit_p (my_remove),
+ .remove = my_remove,
/* Power management functions. */
.suspend = my_suspend,
diff --git a/Documentation/DocBook/media/v4l/io.xml b/Documentation/DocBook/media/v4l/io.xml
index 388a340..2c4c068 100644
--- a/Documentation/DocBook/media/v4l/io.xml
+++ b/Documentation/DocBook/media/v4l/io.xml
@@ -477,7 +477,7 @@
<note>
<title>Experimental</title>
- <para>This is an <link linkend="experimental"> experimental </link>
+ <para>This is an <link linkend="experimental">experimental</link>
interface and may change in the future.</para>
</note>
@@ -488,7 +488,7 @@
different or the same device (known as the importer role), or both. This
section describes the DMABUF importer role API in V4L2.</para>
- <para>Refer to <link linked="vidioc-expbuf"> DMABUF exporting </link> for
+ <para>Refer to <link linkend="vidioc-expbuf">DMABUF exporting</link> for
details about exporting V4L2 buffers as DMABUF file descriptors.</para>
<para>Input and output devices support the streaming I/O method when the
@@ -741,17 +741,19 @@
<entry>struct timeval</entry>
<entry><structfield>timestamp</structfield></entry>
<entry></entry>
- <entry><para>For input streams this is the
-system time (as returned by the <function>gettimeofday()</function>
-function) when the first data byte was captured. For output streams
-the data will not be displayed before this time, secondary to the
-nominal frame rate determined by the current video standard in
-enqueued order. Applications can for example zero this field to
-display frames as soon as possible. The driver stores the time at
-which the first data byte was actually sent out in the
-<structfield>timestamp</structfield> field. This permits
-applications to monitor the drift between the video and system
-clock.</para></entry>
+ <entry><para>For input streams this is time when the first data
+ byte was captured, as returned by the
+ <function>clock_gettime()</function> function for the relevant
+ clock id; see <constant>V4L2_BUF_FLAG_TIMESTAMP_*</constant> in
+ <xref linkend="buffer-flags" />. For output streams the data
+ will not be displayed before this time, secondary to the nominal
+ frame rate determined by the current video standard in enqueued
+ order. Applications can for example zero this field to display
+ frames as soon as possible. The driver stores the time at which
+ the first data byte was actually sent out in the
+ <structfield>timestamp</structfield> field. This permits
+ applications to monitor the drift between the video and system
+ clock.</para></entry>
</row>
<row>
<entry>&v4l2-timecode;</entry>
@@ -903,7 +905,7 @@
</row>
<row>
<entry></entry>
- <entry>__unsigned long</entry>
+ <entry>unsigned long</entry>
<entry><structfield>userptr</structfield></entry>
<entry>When the memory type in the containing &v4l2-buffer; is
<constant>V4L2_MEMORY_USERPTR</constant>, this is a userspace
@@ -1114,6 +1116,41 @@
in this buffer has not been created by the CPU but by some DMA-capable unit,
in which case caches have not been used.</entry>
</row>
+ <row>
+ <entry><constant>V4L2_BUF_FLAG_TIMESTAMP_MASK</constant></entry>
+ <entry>0xe000</entry>
+ <entry>Mask for timestamp types below. To test the
+ timestamp type, mask out bits not belonging to timestamp
+ type by performing a logical and operation with buffer
+ flags and timestamp mask.</entry>
+ </row>
+ <row>
+ <entry><constant>V4L2_BUF_FLAG_TIMESTAMP_UNKNOWN</constant></entry>
+ <entry>0x0000</entry>
+ <entry>Unknown timestamp type. This type is used by
+ drivers before Linux 3.9 and may be either monotonic (see
+ below) or realtime (wall clock). Monotonic clock has been
+ favoured in embedded systems whereas most of the drivers
+ use the realtime clock. Either kinds of timestamps are
+ available in user space via
+ <function>clock_gettime(2)</function> using clock IDs
+ <constant>CLOCK_MONOTONIC</constant> and
+ <constant>CLOCK_REALTIME</constant>, respectively.</entry>
+ </row>
+ <row>
+ <entry><constant>V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC</constant></entry>
+ <entry>0x2000</entry>
+ <entry>The buffer timestamp has been taken from the
+ <constant>CLOCK_MONOTONIC</constant> clock. To access the
+ same clock outside V4L2, use
+ <function>clock_gettime(2)</function> .</entry>
+ </row>
+ <row>
+ <entry><constant>V4L2_BUF_FLAG_TIMESTAMP_COPY</constant></entry>
+ <entry>0x4000</entry>
+ <entry>The CAPTURE buffer timestamp has been taken from the
+ corresponding OUTPUT buffer. This flag applies only to mem2mem devices.</entry>
+ </row>
</tbody>
</tgroup>
</table>
diff --git a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
index 576b68b..116c301 100644
--- a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
+++ b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
@@ -272,6 +272,16 @@
<entry><constant>MEDIA_ENT_T_V4L2_SUBDEV_LENS</constant></entry>
<entry>Lens controller</entry>
</row>
+ <row>
+ <entry><constant>MEDIA_ENT_T_V4L2_SUBDEV_DECODER</constant></entry>
+ <entry>Video decoder, the basic function of the video decoder is to
+ accept analogue video from a wide variety of sources such as
+ broadcast, DVD players, cameras and video cassette recorders, in
+ either NTSC, PAL or HD format and still occasionally SECAM, separate
+ it into its component parts, luminance and chrominance, and output
+ it in some digital video standard, with appropriate embedded timing
+ signals.</entry>
+ </row>
</tbody>
</tgroup>
</table>
diff --git a/Documentation/DocBook/media/v4l/pixfmt-nv12m.xml b/Documentation/DocBook/media/v4l/pixfmt-nv12m.xml
index a990b34..f3a3d45 100644
--- a/Documentation/DocBook/media/v4l/pixfmt-nv12m.xml
+++ b/Documentation/DocBook/media/v4l/pixfmt-nv12m.xml
@@ -6,7 +6,7 @@
<refnamediv>
<refname id="V4L2-PIX-FMT-NV12M"><constant>V4L2_PIX_FMT_NV12M</constant></refname>
<refname id="V4L2-PIX-FMT-NV21M"><constant>V4L2_PIX_FMT_NV21M</constant></refname>
- <refname id="V4L2-PIX-FMT-NV12MT_16X16"><constant>V4L2_PIX_FMT_NV12MT_16X16</constant></refname>
+ <refname id="V4L2-PIX-FMT-NV12MT-16X16"><constant>V4L2_PIX_FMT_NV12MT_16X16</constant></refname>
<refpurpose>Variation of <constant>V4L2_PIX_FMT_NV12</constant> and <constant>V4L2_PIX_FMT_NV21</constant> with planes
non contiguous in memory. </refpurpose>
</refnamediv>
diff --git a/Documentation/DocBook/media/v4l/pixfmt-nv12mt.xml b/Documentation/DocBook/media/v4l/pixfmt-nv12mt.xml
index 2f82b1d..8a70a17 100644
--- a/Documentation/DocBook/media/v4l/pixfmt-nv12mt.xml
+++ b/Documentation/DocBook/media/v4l/pixfmt-nv12mt.xml
@@ -24,7 +24,7 @@
plane (and the image), but is half as tall in pixels. The chroma plane is also
grouped into 64x32 macroblocks.</para>
<para>Width of the buffer has to be aligned to the multiple of 128, and
-height alignment is 32. Every four adjactent buffers - two horizontally and two
+height alignment is 32. Every four adjacent buffers - two horizontally and two
vertically are grouped together and are located in memory in Z or flipped Z
order. </para>
<para>Layout of macroblocks in memory is presented in the following
diff --git a/Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml b/Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml
new file mode 100644
index 0000000..29acc20
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml
@@ -0,0 +1,34 @@
+ <refentry>
+ <refmeta>
+ <refentrytitle>
+ V4L2_PIX_FMT_SBGGR10ALAW8 ('aBA8'),
+ V4L2_PIX_FMT_SGBRG10ALAW8 ('aGA8'),
+ V4L2_PIX_FMT_SGRBG10ALAW8 ('agA8'),
+ V4L2_PIX_FMT_SRGGB10ALAW8 ('aRA8'),
+ </refentrytitle>
+ &manvol;
+ </refmeta>
+ <refnamediv>
+ <refname id="V4L2-PIX-FMT-SBGGR10ALAW8">
+ <constant>V4L2_PIX_FMT_SBGGR10ALAW8</constant>
+ </refname>
+ <refname id="V4L2-PIX-FMT-SGBRG10ALAW8">
+ <constant>V4L2_PIX_FMT_SGBRG10ALAW8</constant>
+ </refname>
+ <refname id="V4L2-PIX-FMT-SGRBG10ALAW8">
+ <constant>V4L2_PIX_FMT_SGRBG10ALAW8</constant>
+ </refname>
+ <refname id="V4L2-PIX-FMT-SRGGB10ALAW8">
+ <constant>V4L2_PIX_FMT_SRGGB10ALAW8</constant>
+ </refname>
+ <refpurpose>10-bit Bayer formats compressed to 8 bits</refpurpose>
+ </refnamediv>
+ <refsect1>
+ <title>Description</title>
+ <para>The following four pixel formats are raw sRGB / Bayer
+ formats with 10 bits per color compressed to 8 bits each,
+ using the A-LAW algorithm. Each color component consumes 8
+ bits of memory. In other respects this format is similar to
+ <xref linkend="V4L2-PIX-FMT-SRGGB8"></xref>.</para>
+ </refsect1>
+ </refentry>
diff --git a/Documentation/DocBook/media/v4l/pixfmt-uv8.xml b/Documentation/DocBook/media/v4l/pixfmt-uv8.xml
new file mode 100644
index 0000000..c507c1f
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/pixfmt-uv8.xml
@@ -0,0 +1,62 @@
+ <refentry id="V4L2-PIX-FMT-UV8">
+ <refmeta>
+ <refentrytitle>V4L2_PIX_FMT_UV8 ('UV8')</refentrytitle>
+ &manvol;
+ </refmeta>
+ <refnamediv>
+ <refname><constant>V4L2_PIX_FMT_UV8</constant></refname>
+ <refpurpose>UV plane interleaved</refpurpose>
+ </refnamediv>
+ <refsect1>
+ <title>Description</title>
+ <para>In this format there is no Y plane, Only CbCr plane. ie
+ (UV interleaved)</para>
+ <example>
+ <title>
+ <constant>V4L2_PIX_FMT_UV8</constant>
+ pixel image
+ </title>
+
+ <formalpara>
+ <title>Byte Order.</title>
+ <para>Each cell is one byte.
+ <informaltable frame="none">
+ <tgroup cols="5" align="center">
+ <colspec align="left" colwidth="2*" />
+ <tbody valign="top">
+ <row>
+ <entry>start + 0:</entry>
+ <entry>Cb<subscript>00</subscript></entry>
+ <entry>Cr<subscript>00</subscript></entry>
+ <entry>Cb<subscript>01</subscript></entry>
+ <entry>Cr<subscript>01</subscript></entry>
+ </row>
+ <row>
+ <entry>start + 4:</entry>
+ <entry>Cb<subscript>10</subscript></entry>
+ <entry>Cr<subscript>10</subscript></entry>
+ <entry>Cb<subscript>11</subscript></entry>
+ <entry>Cr<subscript>11</subscript></entry>
+ </row>
+ <row>
+ <entry>start + 8:</entry>
+ <entry>Cb<subscript>20</subscript></entry>
+ <entry>Cr<subscript>20</subscript></entry>
+ <entry>Cb<subscript>21</subscript></entry>
+ <entry>Cr<subscript>21</subscript></entry>
+ </row>
+ <row>
+ <entry>start + 12:</entry>
+ <entry>Cb<subscript>30</subscript></entry>
+ <entry>Cr<subscript>30</subscript></entry>
+ <entry>Cb<subscript>31</subscript></entry>
+ <entry>Cr<subscript>31</subscript></entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </informaltable>
+ </para>
+ </formalpara>
+ </example>
+ </refsect1>
+ </refentry>
diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml b/Documentation/DocBook/media/v4l/pixfmt.xml
index bf94f41..99b8d2a 100644
--- a/Documentation/DocBook/media/v4l/pixfmt.xml
+++ b/Documentation/DocBook/media/v4l/pixfmt.xml
@@ -673,6 +673,7 @@
&sub-srggb8;
&sub-sbggr16;
&sub-srggb10;
+ &sub-srggb10alaw8;
&sub-srggb10dpcm8;
&sub-srggb12;
</section>
@@ -701,6 +702,7 @@
&sub-y12;
&sub-y10b;
&sub-y16;
+ &sub-uv8;
&sub-yuyv;
&sub-uyvy;
&sub-yvyu;
diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml b/Documentation/DocBook/media/v4l/subdev-formats.xml
index a0a9364..adc6198 100644
--- a/Documentation/DocBook/media/v4l/subdev-formats.xml
+++ b/Documentation/DocBook/media/v4l/subdev-formats.xml
@@ -93,19 +93,35 @@
<table pgwide="0" frame="none" id="v4l2-mbus-pixelcode-rgb">
<title>RGB formats</title>
- <tgroup cols="11">
+ <tgroup cols="27">
<colspec colname="id" align="left" />
<colspec colname="code" align="center"/>
<colspec colname="bit" />
- <colspec colnum="4" colname="b07" align="center" />
- <colspec colnum="5" colname="b06" align="center" />
- <colspec colnum="6" colname="b05" align="center" />
- <colspec colnum="7" colname="b04" align="center" />
- <colspec colnum="8" colname="b03" align="center" />
- <colspec colnum="9" colname="b02" align="center" />
- <colspec colnum="10" colname="b01" align="center" />
- <colspec colnum="11" colname="b00" align="center" />
- <spanspec namest="b07" nameend="b00" spanname="b0" />
+ <colspec colnum="4" colname="b23" align="center" />
+ <colspec colnum="5" colname="b22" align="center" />
+ <colspec colnum="6" colname="b21" align="center" />
+ <colspec colnum="7" colname="b20" align="center" />
+ <colspec colnum="8" colname="b19" align="center" />
+ <colspec colnum="9" colname="b18" align="center" />
+ <colspec colnum="10" colname="b17" align="center" />
+ <colspec colnum="11" colname="b16" align="center" />
+ <colspec colnum="12" colname="b15" align="center" />
+ <colspec colnum="13" colname="b14" align="center" />
+ <colspec colnum="14" colname="b13" align="center" />
+ <colspec colnum="15" colname="b12" align="center" />
+ <colspec colnum="16" colname="b11" align="center" />
+ <colspec colnum="17" colname="b10" align="center" />
+ <colspec colnum="18" colname="b09" align="center" />
+ <colspec colnum="19" colname="b08" align="center" />
+ <colspec colnum="20" colname="b07" align="center" />
+ <colspec colnum="21" colname="b06" align="center" />
+ <colspec colnum="22" colname="b05" align="center" />
+ <colspec colnum="23" colname="b04" align="center" />
+ <colspec colnum="24" colname="b03" align="center" />
+ <colspec colnum="25" colname="b02" align="center" />
+ <colspec colnum="26" colname="b01" align="center" />
+ <colspec colnum="27" colname="b00" align="center" />
+ <spanspec namest="b23" nameend="b00" spanname="b0" />
<thead>
<row>
<entry>Identifier</entry>
@@ -117,6 +133,22 @@
<entry></entry>
<entry></entry>
<entry>Bit</entry>
+ <entry>23</entry>
+ <entry>22</entry>
+ <entry>21</entry>
+ <entry>20</entry>
+ <entry>19</entry>
+ <entry>18</entry>
+ <entry>17</entry>
+ <entry>16</entry>
+ <entry>15</entry>
+ <entry>14</entry>
+ <entry>13</entry>
+ <entry>12</entry>
+ <entry>11</entry>
+ <entry>10</entry>
+ <entry>9</entry>
+ <entry>8</entry>
<entry>7</entry>
<entry>6</entry>
<entry>5</entry>
@@ -132,6 +164,7 @@
<entry>V4L2_MBUS_FMT_RGB444_2X8_PADHI_BE</entry>
<entry>0x1001</entry>
<entry></entry>
+ &dash-ent-16;
<entry>0</entry>
<entry>0</entry>
<entry>0</entry>
@@ -145,6 +178,7 @@
<entry></entry>
<entry></entry>
<entry></entry>
+ &dash-ent-16;
<entry>g<subscript>3</subscript></entry>
<entry>g<subscript>2</subscript></entry>
<entry>g<subscript>1</subscript></entry>
@@ -158,6 +192,7 @@
<entry>V4L2_MBUS_FMT_RGB444_2X8_PADHI_LE</entry>
<entry>0x1002</entry>
<entry></entry>
+ &dash-ent-16;
<entry>g<subscript>3</subscript></entry>
<entry>g<subscript>2</subscript></entry>
<entry>g<subscript>1</subscript></entry>
@@ -171,6 +206,7 @@
<entry></entry>
<entry></entry>
<entry></entry>
+ &dash-ent-16;
<entry>0</entry>
<entry>0</entry>
<entry>0</entry>
@@ -184,6 +220,7 @@
<entry>V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE</entry>
<entry>0x1003</entry>
<entry></entry>
+ &dash-ent-16;
<entry>0</entry>
<entry>r<subscript>4</subscript></entry>
<entry>r<subscript>3</subscript></entry>
@@ -197,6 +234,7 @@
<entry></entry>
<entry></entry>
<entry></entry>
+ &dash-ent-16;
<entry>g<subscript>2</subscript></entry>
<entry>g<subscript>1</subscript></entry>
<entry>g<subscript>0</subscript></entry>
@@ -210,6 +248,7 @@
<entry>V4L2_MBUS_FMT_RGB555_2X8_PADHI_LE</entry>
<entry>0x1004</entry>
<entry></entry>
+ &dash-ent-16;
<entry>g<subscript>2</subscript></entry>
<entry>g<subscript>1</subscript></entry>
<entry>g<subscript>0</subscript></entry>
@@ -223,6 +262,7 @@
<entry></entry>
<entry></entry>
<entry></entry>
+ &dash-ent-16;
<entry>0</entry>
<entry>r<subscript>4</subscript></entry>
<entry>r<subscript>3</subscript></entry>
@@ -236,6 +276,7 @@
<entry>V4L2_MBUS_FMT_BGR565_2X8_BE</entry>
<entry>0x1005</entry>
<entry></entry>
+ &dash-ent-16;
<entry>b<subscript>4</subscript></entry>
<entry>b<subscript>3</subscript></entry>
<entry>b<subscript>2</subscript></entry>
@@ -249,6 +290,7 @@
<entry></entry>
<entry></entry>
<entry></entry>
+ &dash-ent-16;
<entry>g<subscript>2</subscript></entry>
<entry>g<subscript>1</subscript></entry>
<entry>g<subscript>0</subscript></entry>
@@ -262,6 +304,7 @@
<entry>V4L2_MBUS_FMT_BGR565_2X8_LE</entry>
<entry>0x1006</entry>
<entry></entry>
+ &dash-ent-16;
<entry>g<subscript>2</subscript></entry>
<entry>g<subscript>1</subscript></entry>
<entry>g<subscript>0</subscript></entry>
@@ -275,6 +318,7 @@
<entry></entry>
<entry></entry>
<entry></entry>
+ &dash-ent-16;
<entry>b<subscript>4</subscript></entry>
<entry>b<subscript>3</subscript></entry>
<entry>b<subscript>2</subscript></entry>
@@ -288,6 +332,7 @@
<entry>V4L2_MBUS_FMT_RGB565_2X8_BE</entry>
<entry>0x1007</entry>
<entry></entry>
+ &dash-ent-16;
<entry>r<subscript>4</subscript></entry>
<entry>r<subscript>3</subscript></entry>
<entry>r<subscript>2</subscript></entry>
@@ -301,6 +346,7 @@
<entry></entry>
<entry></entry>
<entry></entry>
+ &dash-ent-16;
<entry>g<subscript>2</subscript></entry>
<entry>g<subscript>1</subscript></entry>
<entry>g<subscript>0</subscript></entry>
@@ -314,6 +360,7 @@
<entry>V4L2_MBUS_FMT_RGB565_2X8_LE</entry>
<entry>0x1008</entry>
<entry></entry>
+ &dash-ent-16;
<entry>g<subscript>2</subscript></entry>
<entry>g<subscript>1</subscript></entry>
<entry>g<subscript>0</subscript></entry>
@@ -327,6 +374,7 @@
<entry></entry>
<entry></entry>
<entry></entry>
+ &dash-ent-16;
<entry>r<subscript>4</subscript></entry>
<entry>r<subscript>3</subscript></entry>
<entry>r<subscript>2</subscript></entry>
@@ -336,6 +384,144 @@
<entry>g<subscript>4</subscript></entry>
<entry>g<subscript>3</subscript></entry>
</row>
+ <row id="V4L2-MBUS-FMT-RGB666-1X18">
+ <entry>V4L2_MBUS_FMT_RGB666_1X18</entry>
+ <entry>0x1009</entry>
+ <entry></entry>
+ <entry>-</entry>
+ <entry>-</entry>
+ <entry>-</entry>
+ <entry>-</entry>
+ <entry>-</entry>
+ <entry>-</entry>
+ <entry>r<subscript>5</subscript></entry>
+ <entry>r<subscript>4</subscript></entry>
+ <entry>r<subscript>3</subscript></entry>
+ <entry>r<subscript>2</subscript></entry>
+ <entry>r<subscript>1</subscript></entry>
+ <entry>r<subscript>0</subscript></entry>
+ <entry>g<subscript>5</subscript></entry>
+ <entry>g<subscript>4</subscript></entry>
+ <entry>g<subscript>3</subscript></entry>
+ <entry>g<subscript>2</subscript></entry>
+ <entry>g<subscript>1</subscript></entry>
+ <entry>g<subscript>0</subscript></entry>
+ <entry>b<subscript>5</subscript></entry>
+ <entry>b<subscript>4</subscript></entry>
+ <entry>b<subscript>3</subscript></entry>
+ <entry>b<subscript>2</subscript></entry>
+ <entry>b<subscript>1</subscript></entry>
+ <entry>b<subscript>0</subscript></entry>
+ </row>
+ <row id="V4L2-MBUS-FMT-RGB888-1X24">
+ <entry>V4L2_MBUS_FMT_RGB888_1X24</entry>
+ <entry>0x100a</entry>
+ <entry></entry>
+ <entry>r<subscript>7</subscript></entry>
+ <entry>r<subscript>6</subscript></entry>
+ <entry>r<subscript>5</subscript></entry>
+ <entry>r<subscript>4</subscript></entry>
+ <entry>r<subscript>3</subscript></entry>
+ <entry>r<subscript>2</subscript></entry>
+ <entry>r<subscript>1</subscript></entry>
+ <entry>r<subscript>0</subscript></entry>
+ <entry>g<subscript>7</subscript></entry>
+ <entry>g<subscript>6</subscript></entry>
+ <entry>g<subscript>5</subscript></entry>
+ <entry>g<subscript>4</subscript></entry>
+ <entry>g<subscript>3</subscript></entry>
+ <entry>g<subscript>2</subscript></entry>
+ <entry>g<subscript>1</subscript></entry>
+ <entry>g<subscript>0</subscript></entry>
+ <entry>b<subscript>7</subscript></entry>
+ <entry>b<subscript>6</subscript></entry>
+ <entry>b<subscript>5</subscript></entry>
+ <entry>b<subscript>4</subscript></entry>
+ <entry>b<subscript>3</subscript></entry>
+ <entry>b<subscript>2</subscript></entry>
+ <entry>b<subscript>1</subscript></entry>
+ <entry>b<subscript>0</subscript></entry>
+ </row>
+ <row id="V4L2-MBUS-FMT-RGB888-2X12-BE">
+ <entry>V4L2_MBUS_FMT_RGB888_2X12_BE</entry>
+ <entry>0x100b</entry>
+ <entry></entry>
+ &dash-ent-10;
+ <entry>-</entry>
+ <entry>-</entry>
+ <entry>r<subscript>7</subscript></entry>
+ <entry>r<subscript>6</subscript></entry>
+ <entry>r<subscript>5</subscript></entry>
+ <entry>r<subscript>4</subscript></entry>
+ <entry>r<subscript>3</subscript></entry>
+ <entry>r<subscript>2</subscript></entry>
+ <entry>r<subscript>1</subscript></entry>
+ <entry>r<subscript>0</subscript></entry>
+ <entry>g<subscript>7</subscript></entry>
+ <entry>g<subscript>6</subscript></entry>
+ <entry>g<subscript>5</subscript></entry>
+ <entry>g<subscript>4</subscript></entry>
+ </row>
+ <row>
+ <entry></entry>
+ <entry></entry>
+ <entry></entry>
+ &dash-ent-10;
+ <entry>-</entry>
+ <entry>-</entry>
+ <entry>g<subscript>3</subscript></entry>
+ <entry>g<subscript>2</subscript></entry>
+ <entry>g<subscript>1</subscript></entry>
+ <entry>g<subscript>0</subscript></entry>
+ <entry>b<subscript>7</subscript></entry>
+ <entry>b<subscript>6</subscript></entry>
+ <entry>b<subscript>5</subscript></entry>
+ <entry>b<subscript>4</subscript></entry>
+ <entry>b<subscript>3</subscript></entry>
+ <entry>b<subscript>2</subscript></entry>
+ <entry>b<subscript>1</subscript></entry>
+ <entry>b<subscript>0</subscript></entry>
+ </row>
+ <row id="V4L2-MBUS-FMT-RGB888-2X12-LE">
+ <entry>V4L2_MBUS_FMT_RGB888_2X12_LE</entry>
+ <entry>0x100c</entry>
+ <entry></entry>
+ &dash-ent-10;
+ <entry>-</entry>
+ <entry>-</entry>
+ <entry>g<subscript>3</subscript></entry>
+ <entry>g<subscript>2</subscript></entry>
+ <entry>g<subscript>1</subscript></entry>
+ <entry>g<subscript>0</subscript></entry>
+ <entry>b<subscript>7</subscript></entry>
+ <entry>b<subscript>6</subscript></entry>
+ <entry>b<subscript>5</subscript></entry>
+ <entry>b<subscript>4</subscript></entry>
+ <entry>b<subscript>3</subscript></entry>
+ <entry>b<subscript>2</subscript></entry>
+ <entry>b<subscript>1</subscript></entry>
+ <entry>b<subscript>0</subscript></entry>
+ </row>
+ <row>
+ <entry></entry>
+ <entry></entry>
+ <entry></entry>
+ &dash-ent-10;
+ <entry>-</entry>
+ <entry>-</entry>
+ <entry>r<subscript>7</subscript></entry>
+ <entry>r<subscript>6</subscript></entry>
+ <entry>r<subscript>5</subscript></entry>
+ <entry>r<subscript>4</subscript></entry>
+ <entry>r<subscript>3</subscript></entry>
+ <entry>r<subscript>2</subscript></entry>
+ <entry>r<subscript>1</subscript></entry>
+ <entry>r<subscript>0</subscript></entry>
+ <entry>g<subscript>7</subscript></entry>
+ <entry>g<subscript>6</subscript></entry>
+ <entry>g<subscript>5</subscript></entry>
+ <entry>g<subscript>4</subscript></entry>
+ </row>
</tbody>
</tgroup>
</table>
@@ -353,9 +539,9 @@
<listitem><para>The number of bits per pixel component. All components are
transferred on the same number of bits. Common values are 8, 10 and 12.</para>
</listitem>
- <listitem><para>If the pixel components are DPCM-compressed, a mention of the
- DPCM compression and the number of bits per compressed pixel component.</para>
- </listitem>
+ <listitem><para>The compression (optional). If the pixel components are
+ ALAW- or DPCM-compressed, a mention of the compression scheme and the
+ number of bits per compressed pixel component.</para></listitem>
<listitem><para>The number of bus samples per pixel. Pixels that are wider than
the bus width must be transferred in multiple samples. Common values are
1 and 2.</para></listitem>
@@ -504,6 +690,74 @@
<entry>r<subscript>1</subscript></entry>
<entry>r<subscript>0</subscript></entry>
</row>
+ <row id="V4L2-MBUS-FMT-SBGGR10-ALAW8-1X8">
+ <entry>V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8</entry>
+ <entry>0x3015</entry>
+ <entry></entry>
+ <entry>-</entry>
+ <entry>-</entry>
+ <entry>-</entry>
+ <entry>-</entry>
+ <entry>b<subscript>7</subscript></entry>
+ <entry>b<subscript>6</subscript></entry>
+ <entry>b<subscript>5</subscript></entry>
+ <entry>b<subscript>4</subscript></entry>
+ <entry>b<subscript>3</subscript></entry>
+ <entry>b<subscript>2</subscript></entry>
+ <entry>b<subscript>1</subscript></entry>
+ <entry>b<subscript>0</subscript></entry>
+ </row>
+ <row id="V4L2-MBUS-FMT-SGBRG10-ALAW8-1X8">
+ <entry>V4L2_MBUS_FMT_SGBRG10_ALAW8_1X8</entry>
+ <entry>0x3016</entry>
+ <entry></entry>
+ <entry>-</entry>
+ <entry>-</entry>
+ <entry>-</entry>
+ <entry>-</entry>
+ <entry>g<subscript>7</subscript></entry>
+ <entry>g<subscript>6</subscript></entry>
+ <entry>g<subscript>5</subscript></entry>
+ <entry>g<subscript>4</subscript></entry>
+ <entry>g<subscript>3</subscript></entry>
+ <entry>g<subscript>2</subscript></entry>
+ <entry>g<subscript>1</subscript></entry>
+ <entry>g<subscript>0</subscript></entry>
+ </row>
+ <row id="V4L2-MBUS-FMT-SGRBG10-ALAW8-1X8">
+ <entry>V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8</entry>
+ <entry>0x3017</entry>
+ <entry></entry>
+ <entry>-</entry>
+ <entry>-</entry>
+ <entry>-</entry>
+ <entry>-</entry>
+ <entry>g<subscript>7</subscript></entry>
+ <entry>g<subscript>6</subscript></entry>
+ <entry>g<subscript>5</subscript></entry>
+ <entry>g<subscript>4</subscript></entry>
+ <entry>g<subscript>3</subscript></entry>
+ <entry>g<subscript>2</subscript></entry>
+ <entry>g<subscript>1</subscript></entry>
+ <entry>g<subscript>0</subscript></entry>
+ </row>
+ <row id="V4L2-MBUS-FMT-SRGGB10-ALAW8-1X8">
+ <entry>V4L2_MBUS_FMT_SRGGB10_ALAW8_1X8</entry>
+ <entry>0x3018</entry>
+ <entry></entry>
+ <entry>-</entry>
+ <entry>-</entry>
+ <entry>-</entry>
+ <entry>-</entry>
+ <entry>r<subscript>7</subscript></entry>
+ <entry>r<subscript>6</subscript></entry>
+ <entry>r<subscript>5</subscript></entry>
+ <entry>r<subscript>4</subscript></entry>
+ <entry>r<subscript>3</subscript></entry>
+ <entry>r<subscript>2</subscript></entry>
+ <entry>r<subscript>1</subscript></entry>
+ <entry>r<subscript>0</subscript></entry>
+ </row>
<row id="V4L2-MBUS-FMT-SBGGR10-DPCM8-1X8">
<entry>V4L2_MBUS_FMT_SBGGR10_DPCM8_1X8</entry>
<entry>0x300b</entry>
@@ -853,10 +1107,16 @@
<title>Packed YUV Formats</title>
<para>Those data formats transfer pixel data as (possibly downsampled) Y, U
- and V components. The format code is made of the following information.
+ and V components. Some formats include dummy bits in some of their samples
+ and are collectively referred to as "YDYC" (Y-Dummy-Y-Chroma) formats.
+ One cannot rely on the values of these dummy bits as those are undefined.
+ </para>
+ <para>The format code is made of the following information.
<itemizedlist>
<listitem><para>The Y, U and V components order code, as transferred on the
- bus. Possible values are YUYV, UYVY, YVYU and VYUY.</para></listitem>
+ bus. Possible values are YUYV, UYVY, YVYU and VYUY for formats with no
+ dummy bit, and YDYUYDYV, YDYVYDYU, YUYDYVYD and YVYDYUYD for YDYC formats.
+ </para></listitem>
<listitem><para>The number of bits per pixel component. All components are
transferred on the same number of bits. Common values are 8, 10 and 12.</para>
</listitem>
@@ -877,7 +1137,21 @@
U, Y, V, Y order will be named <constant>V4L2_MBUS_FMT_UYVY8_2X8</constant>.
</para>
- <para>The following table lisst existing packet YUV formats.</para>
+ <para><xref linkend="v4l2-mbus-pixelcode-yuv8"/> list existing packet YUV
+ formats and describes the organization of each pixel data in each sample.
+ When a format pattern is split across multiple samples each of the samples
+ in the pattern is described.</para>
+
+ <para>The role of each bit transferred over the bus is identified by one
+ of the following codes.</para>
+
+ <itemizedlist>
+ <listitem><para>y<subscript>x</subscript> for luma component bit number x</para></listitem>
+ <listitem><para>u<subscript>x</subscript> for blue chroma component bit number x</para></listitem>
+ <listitem><para>v<subscript>x</subscript> for red chroma component bit number x</para></listitem>
+ <listitem><para>- for non-available bits (for positions higher than the bus width)</para></listitem>
+ <listitem><para>d for dummy bits</para></listitem>
+ </itemizedlist>
<table pgwide="0" frame="none" id="v4l2-mbus-pixelcode-yuv8">
<title>YUV Formats</title>
@@ -885,27 +1159,37 @@
<colspec colname="id" align="left" />
<colspec colname="code" align="center"/>
<colspec colname="bit" />
- <colspec colnum="4" colname="b19" align="center" />
- <colspec colnum="5" colname="b18" align="center" />
- <colspec colnum="6" colname="b17" align="center" />
- <colspec colnum="7" colname="b16" align="center" />
- <colspec colnum="8" colname="b15" align="center" />
- <colspec colnum="9" colname="b14" align="center" />
- <colspec colnum="10" colname="b13" align="center" />
- <colspec colnum="11" colname="b12" align="center" />
- <colspec colnum="12" colname="b11" align="center" />
- <colspec colnum="13" colname="b10" align="center" />
- <colspec colnum="14" colname="b09" align="center" />
- <colspec colnum="15" colname="b08" align="center" />
- <colspec colnum="16" colname="b07" align="center" />
- <colspec colnum="17" colname="b06" align="center" />
- <colspec colnum="18" colname="b05" align="center" />
- <colspec colnum="19" colname="b04" align="center" />
- <colspec colnum="20" colname="b03" align="center" />
- <colspec colnum="21" colname="b02" align="center" />
- <colspec colnum="22" colname="b01" align="center" />
- <colspec colnum="23" colname="b00" align="center" />
- <spanspec namest="b19" nameend="b00" spanname="b0" />
+ <colspec colnum="4" colname="b29" align="center" />
+ <colspec colnum="5" colname="b28" align="center" />
+ <colspec colnum="6" colname="b27" align="center" />
+ <colspec colnum="7" colname="b26" align="center" />
+ <colspec colnum="8" colname="b25" align="center" />
+ <colspec colnum="9" colname="b24" align="center" />
+ <colspec colnum="10" colname="b23" align="center" />
+ <colspec colnum="11" colname="b22" align="center" />
+ <colspec colnum="12" colname="b21" align="center" />
+ <colspec colnum="13" colname="b20" align="center" />
+ <colspec colnum="14" colname="b19" align="center" />
+ <colspec colnum="15" colname="b18" align="center" />
+ <colspec colnum="16" colname="b17" align="center" />
+ <colspec colnum="17" colname="b16" align="center" />
+ <colspec colnum="18" colname="b15" align="center" />
+ <colspec colnum="19" colname="b14" align="center" />
+ <colspec colnum="20" colname="b13" align="center" />
+ <colspec colnum="21" colname="b12" align="center" />
+ <colspec colnum="22" colname="b11" align="center" />
+ <colspec colnum="23" colname="b10" align="center" />
+ <colspec colnum="24" colname="b09" align="center" />
+ <colspec colnum="25" colname="b08" align="center" />
+ <colspec colnum="26" colname="b07" align="center" />
+ <colspec colnum="27" colname="b06" align="center" />
+ <colspec colnum="28" colname="b05" align="center" />
+ <colspec colnum="29" colname="b04" align="center" />
+ <colspec colnum="30" colname="b03" align="center" />
+ <colspec colnum="31" colname="b02" align="center" />
+ <colspec colnum="32" colname="b01" align="center" />
+ <colspec colnum="33" colname="b00" align="center" />
+ <spanspec namest="b29" nameend="b00" spanname="b0" />
<thead>
<row>
<entry>Identifier</entry>
@@ -917,6 +1201,16 @@
<entry></entry>
<entry></entry>
<entry>Bit</entry>
+ <entry>29</entry>
+ <entry>28</entry>
+ <entry>27</entry>
+ <entry>26</entry>
+ <entry>25</entry>
+ <entry>24</entry>
+ <entry>23</entry>
+ <entry>22</entry>
+ <entry>21</entry>
+ <entry>10</entry>
<entry>19</entry>
<entry>18</entry>
<entry>17</entry>
@@ -944,16 +1238,8 @@
<entry>V4L2_MBUS_FMT_Y8_1X8</entry>
<entry>0x2001</entry>
<entry></entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
+ &dash-ent-10;
+ &dash-ent-10;
<entry>-</entry>
<entry>-</entry>
<entry>y<subscript>7</subscript></entry>
@@ -965,9 +1251,9 @@
<entry>y<subscript>1</subscript></entry>
<entry>y<subscript>0</subscript></entry>
</row>
- <row id="V4L2-MBUS-FMT-UYVY8-1_5X8">
- <entry>V4L2_MBUS_FMT_UYVY8_1_5X8</entry>
- <entry>0x2002</entry>
+ <row id="V4L2-MBUS-FMT-UV8-1X8">
+ <entry>V4L2_MBUS_FMT_UV8_1X8</entry>
+ <entry>0x2015</entry>
<entry></entry>
<entry>-</entry>
<entry>-</entry>
@@ -1006,29 +1292,38 @@
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
- <entry>y<subscript>7</subscript></entry>
- <entry>y<subscript>6</subscript></entry>
- <entry>y<subscript>5</subscript></entry>
- <entry>y<subscript>4</subscript></entry>
- <entry>y<subscript>3</subscript></entry>
- <entry>y<subscript>2</subscript></entry>
- <entry>y<subscript>1</subscript></entry>
- <entry>y<subscript>0</subscript></entry>
+ <entry>v<subscript>7</subscript></entry>
+ <entry>v<subscript>6</subscript></entry>
+ <entry>v<subscript>5</subscript></entry>
+ <entry>v<subscript>4</subscript></entry>
+ <entry>v<subscript>3</subscript></entry>
+ <entry>v<subscript>2</subscript></entry>
+ <entry>v<subscript>1</subscript></entry>
+ <entry>v<subscript>0</subscript></entry>
+ </row>
+ <row id="V4L2-MBUS-FMT-UYVY8-1_5X8">
+ <entry>V4L2_MBUS_FMT_UYVY8_1_5X8</entry>
+ <entry>0x2002</entry>
+ <entry></entry>
+ &dash-ent-10;
+ &dash-ent-10;
+ <entry>-</entry>
+ <entry>-</entry>
+ <entry>u<subscript>7</subscript></entry>
+ <entry>u<subscript>6</subscript></entry>
+ <entry>u<subscript>5</subscript></entry>
+ <entry>u<subscript>4</subscript></entry>
+ <entry>u<subscript>3</subscript></entry>
+ <entry>u<subscript>2</subscript></entry>
+ <entry>u<subscript>1</subscript></entry>
+ <entry>u<subscript>0</subscript></entry>
</row>
<row>
<entry></entry>
<entry></entry>
<entry></entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
+ &dash-ent-10;
+ &dash-ent-10;
<entry>-</entry>
<entry>-</entry>
<entry>y<subscript>7</subscript></entry>
@@ -1044,16 +1339,25 @@
<entry></entry>
<entry></entry>
<entry></entry>
+ &dash-ent-10;
+ &dash-ent-10;
<entry>-</entry>
<entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
+ <entry>y<subscript>7</subscript></entry>
+ <entry>y<subscript>6</subscript></entry>
+ <entry>y<subscript>5</subscript></entry>
+ <entry>y<subscript>4</subscript></entry>
+ <entry>y<subscript>3</subscript></entry>
+ <entry>y<subscript>2</subscript></entry>
+ <entry>y<subscript>1</subscript></entry>
+ <entry>y<subscript>0</subscript></entry>
+ </row>
+ <row>
+ <entry></entry>
+ <entry></entry>
+ <entry></entry>
+ &dash-ent-10;
+ &dash-ent-10;
<entry>-</entry>
<entry>-</entry>
<entry>v<subscript>7</subscript></entry>
@@ -1069,16 +1373,8 @@
<entry></entry>
<entry></entry>
<entry></entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
+ &dash-ent-10;
+ &dash-ent-10;
<entry>-</entry>
<entry>-</entry>
<entry>y<subscript>7</subscript></entry>
@@ -1094,16 +1390,8 @@
<entry></entry>
<entry></entry>
<entry></entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
+ &dash-ent-10;
+ &dash-ent-10;
<entry>-</entry>
<entry>-</entry>
<entry>y<subscript>7</subscript></entry>
@@ -1119,16 +1407,8 @@
<entry>V4L2_MBUS_FMT_VYUY8_1_5X8</entry>
<entry>0x2003</entry>
<entry></entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
+ &dash-ent-10;
+ &dash-ent-10;
<entry>-</entry>
<entry>-</entry>
<entry>v<subscript>7</subscript></entry>
@@ -1144,16 +1424,8 @@
<entry></entry>
<entry></entry>
<entry></entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
+ &dash-ent-10;
+ &dash-ent-10;
<entry>-</entry>
<entry>-</entry>
<entry>y<subscript>7</subscript></entry>
@@ -1169,16 +1441,8 @@
<entry></entry>
<entry></entry>
<entry></entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
+ &dash-ent-10;
+ &dash-ent-10;
<entry>-</entry>
<entry>-</entry>
<entry>y<subscript>7</subscript></entry>
@@ -1194,16 +1458,8 @@
<entry></entry>
<entry></entry>
<entry></entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
+ &dash-ent-10;
+ &dash-ent-10;
<entry>-</entry>
<entry>-</entry>
<entry>u<subscript>7</subscript></entry>
@@ -1219,16 +1475,8 @@
<entry></entry>
<entry></entry>
<entry></entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
+ &dash-ent-10;
+ &dash-ent-10;
<entry>-</entry>
<entry>-</entry>
<entry>y<subscript>7</subscript></entry>
@@ -1244,16 +1492,8 @@
<entry></entry>
<entry></entry>
<entry></entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
+ &dash-ent-10;
+ &dash-ent-10;
<entry>-</entry>
<entry>-</entry>
<entry>y<subscript>7</subscript></entry>
@@ -1269,16 +1509,8 @@
<entry>V4L2_MBUS_FMT_YUYV8_1_5X8</entry>
<entry>0x2004</entry>
<entry></entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
+ &dash-ent-10;
+ &dash-ent-10;
<entry>-</entry>
<entry>-</entry>
<entry>y<subscript>7</subscript></entry>
@@ -1294,16 +1526,8 @@
<entry></entry>
<entry></entry>
<entry></entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
+ &dash-ent-10;
+ &dash-ent-10;
<entry>-</entry>
<entry>-</entry>
<entry>y<subscript>7</subscript></entry>
@@ -1319,16 +1543,8 @@
<entry></entry>
<entry></entry>
<entry></entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
+ &dash-ent-10;
+ &dash-ent-10;
<entry>-</entry>
<entry>-</entry>
<entry>u<subscript>7</subscript></entry>
@@ -1344,16 +1560,8 @@
<entry></entry>
<entry></entry>
<entry></entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
+ &dash-ent-10;
+ &dash-ent-10;
<entry>-</entry>
<entry>-</entry>
<entry>y<subscript>7</subscript></entry>
@@ -1369,16 +1577,8 @@
<entry></entry>
<entry></entry>
<entry></entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
+ &dash-ent-10;
+ &dash-ent-10;
<entry>-</entry>
<entry>-</entry>
<entry>y<subscript>7</subscript></entry>
@@ -1394,16 +1594,8 @@
<entry></entry>
<entry></entry>
<entry></entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
+ &dash-ent-10;
+ &dash-ent-10;
<entry>-</entry>
<entry>-</entry>
<entry>v<subscript>7</subscript></entry>
@@ -1419,16 +1611,8 @@
<entry>V4L2_MBUS_FMT_YVYU8_1_5X8</entry>
<entry>0x2005</entry>
<entry></entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
+ &dash-ent-10;
+ &dash-ent-10;
<entry>-</entry>
<entry>-</entry>
<entry>y<subscript>7</subscript></entry>
@@ -1444,16 +1628,8 @@
<entry></entry>
<entry></entry>
<entry></entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
+ &dash-ent-10;
+ &dash-ent-10;
<entry>-</entry>
<entry>-</entry>
<entry>y<subscript>7</subscript></entry>
@@ -1469,16 +1645,8 @@
<entry></entry>
<entry></entry>
<entry></entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
+ &dash-ent-10;
+ &dash-ent-10;
<entry>-</entry>
<entry>-</entry>
<entry>v<subscript>7</subscript></entry>
@@ -1494,16 +1662,8 @@
<entry></entry>
<entry></entry>
<entry></entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
+ &dash-ent-10;
+ &dash-ent-10;
<entry>-</entry>
<entry>-</entry>
<entry>y<subscript>7</subscript></entry>
@@ -1519,16 +1679,8 @@
<entry></entry>
<entry></entry>
<entry></entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
+ &dash-ent-10;
+ &dash-ent-10;
<entry>-</entry>
<entry>-</entry>
<entry>y<subscript>7</subscript></entry>
@@ -1544,16 +1696,8 @@
<entry></entry>
<entry></entry>
<entry></entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
+ &dash-ent-10;
+ &dash-ent-10;
<entry>-</entry>
<entry>-</entry>
<entry>u<subscript>7</subscript></entry>
@@ -1569,16 +1713,8 @@
<entry>V4L2_MBUS_FMT_UYVY8_2X8</entry>
<entry>0x2006</entry>
<entry></entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
+ &dash-ent-10;
+ &dash-ent-10;
<entry>-</entry>
<entry>-</entry>
<entry>u<subscript>7</subscript></entry>
@@ -1594,16 +1730,8 @@
<entry></entry>
<entry></entry>
<entry></entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
+ &dash-ent-10;
+ &dash-ent-10;
<entry>-</entry>
<entry>-</entry>
<entry>y<subscript>7</subscript></entry>
@@ -1619,16 +1747,8 @@
<entry></entry>
<entry></entry>
<entry></entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
+ &dash-ent-10;
+ &dash-ent-10;
<entry>-</entry>
<entry>-</entry>
<entry>v<subscript>7</subscript></entry>
@@ -1644,16 +1764,8 @@
<entry></entry>
<entry></entry>
<entry></entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
+ &dash-ent-10;
+ &dash-ent-10;
<entry>-</entry>
<entry>-</entry>
<entry>y<subscript>7</subscript></entry>
@@ -1669,16 +1781,8 @@
<entry>V4L2_MBUS_FMT_VYUY8_2X8</entry>
<entry>0x2007</entry>
<entry></entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
+ &dash-ent-10;
+ &dash-ent-10;
<entry>-</entry>
<entry>-</entry>
<entry>v<subscript>7</subscript></entry>
@@ -1694,16 +1798,8 @@
<entry></entry>
<entry></entry>
<entry></entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
+ &dash-ent-10;
+ &dash-ent-10;
<entry>-</entry>
<entry>-</entry>
<entry>y<subscript>7</subscript></entry>
@@ -1719,16 +1815,8 @@
<entry></entry>
<entry></entry>
<entry></entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
+ &dash-ent-10;
+ &dash-ent-10;
<entry>-</entry>
<entry>-</entry>
<entry>u<subscript>7</subscript></entry>
@@ -1744,16 +1832,8 @@
<entry></entry>
<entry></entry>
<entry></entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
+ &dash-ent-10;
+ &dash-ent-10;
<entry>-</entry>
<entry>-</entry>
<entry>y<subscript>7</subscript></entry>
@@ -1769,16 +1849,8 @@
<entry>V4L2_MBUS_FMT_YUYV8_2X8</entry>
<entry>0x2008</entry>
<entry></entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
+ &dash-ent-10;
+ &dash-ent-10;
<entry>-</entry>
<entry>-</entry>
<entry>y<subscript>7</subscript></entry>
@@ -1794,16 +1866,8 @@
<entry></entry>
<entry></entry>
<entry></entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
+ &dash-ent-10;
+ &dash-ent-10;
<entry>-</entry>
<entry>-</entry>
<entry>u<subscript>7</subscript></entry>
@@ -1819,16 +1883,8 @@
<entry></entry>
<entry></entry>
<entry></entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
+ &dash-ent-10;
+ &dash-ent-10;
<entry>-</entry>
<entry>-</entry>
<entry>y<subscript>7</subscript></entry>
@@ -1844,16 +1900,8 @@
<entry></entry>
<entry></entry>
<entry></entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
+ &dash-ent-10;
+ &dash-ent-10;
<entry>-</entry>
<entry>-</entry>
<entry>v<subscript>7</subscript></entry>
@@ -1869,16 +1917,8 @@
<entry>V4L2_MBUS_FMT_YVYU8_2X8</entry>
<entry>0x2009</entry>
<entry></entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
+ &dash-ent-10;
+ &dash-ent-10;
<entry>-</entry>
<entry>-</entry>
<entry>y<subscript>7</subscript></entry>
@@ -1894,16 +1934,8 @@
<entry></entry>
<entry></entry>
<entry></entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
+ &dash-ent-10;
+ &dash-ent-10;
<entry>-</entry>
<entry>-</entry>
<entry>v<subscript>7</subscript></entry>
@@ -1919,16 +1951,8 @@
<entry></entry>
<entry></entry>
<entry></entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
+ &dash-ent-10;
+ &dash-ent-10;
<entry>-</entry>
<entry>-</entry>
<entry>y<subscript>7</subscript></entry>
@@ -1944,16 +1968,8 @@
<entry></entry>
<entry></entry>
<entry></entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
+ &dash-ent-10;
+ &dash-ent-10;
<entry>-</entry>
<entry>-</entry>
<entry>u<subscript>7</subscript></entry>
@@ -1969,16 +1985,8 @@
<entry>V4L2_MBUS_FMT_Y10_1X10</entry>
<entry>0x200a</entry>
<entry></entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
+ &dash-ent-10;
+ &dash-ent-10;
<entry>y<subscript>9</subscript></entry>
<entry>y<subscript>8</subscript></entry>
<entry>y<subscript>7</subscript></entry>
@@ -1994,16 +2002,8 @@
<entry>V4L2_MBUS_FMT_YUYV10_2X10</entry>
<entry>0x200b</entry>
<entry></entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
+ &dash-ent-10;
+ &dash-ent-10;
<entry>y<subscript>9</subscript></entry>
<entry>y<subscript>8</subscript></entry>
<entry>y<subscript>7</subscript></entry>
@@ -2019,16 +2019,8 @@
<entry></entry>
<entry></entry>
<entry></entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
+ &dash-ent-10;
+ &dash-ent-10;
<entry>u<subscript>9</subscript></entry>
<entry>u<subscript>8</subscript></entry>
<entry>u<subscript>7</subscript></entry>
@@ -2044,16 +2036,8 @@
<entry></entry>
<entry></entry>
<entry></entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
+ &dash-ent-10;
+ &dash-ent-10;
<entry>y<subscript>9</subscript></entry>
<entry>y<subscript>8</subscript></entry>
<entry>y<subscript>7</subscript></entry>
@@ -2069,16 +2053,8 @@
<entry></entry>
<entry></entry>
<entry></entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
+ &dash-ent-10;
+ &dash-ent-10;
<entry>v<subscript>9</subscript></entry>
<entry>v<subscript>8</subscript></entry>
<entry>v<subscript>7</subscript></entry>
@@ -2094,16 +2070,8 @@
<entry>V4L2_MBUS_FMT_YVYU10_2X10</entry>
<entry>0x200c</entry>
<entry></entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
+ &dash-ent-10;
+ &dash-ent-10;
<entry>y<subscript>9</subscript></entry>
<entry>y<subscript>8</subscript></entry>
<entry>y<subscript>7</subscript></entry>
@@ -2119,16 +2087,8 @@
<entry></entry>
<entry></entry>
<entry></entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
+ &dash-ent-10;
+ &dash-ent-10;
<entry>v<subscript>9</subscript></entry>
<entry>v<subscript>8</subscript></entry>
<entry>v<subscript>7</subscript></entry>
@@ -2144,16 +2104,8 @@
<entry></entry>
<entry></entry>
<entry></entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
+ &dash-ent-10;
+ &dash-ent-10;
<entry>y<subscript>9</subscript></entry>
<entry>y<subscript>8</subscript></entry>
<entry>y<subscript>7</subscript></entry>
@@ -2169,16 +2121,8 @@
<entry></entry>
<entry></entry>
<entry></entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
- <entry>-</entry>
+ &dash-ent-10;
+ &dash-ent-10;
<entry>u<subscript>9</subscript></entry>
<entry>u<subscript>8</subscript></entry>
<entry>u<subscript>7</subscript></entry>
@@ -2194,6 +2138,7 @@
<entry>V4L2_MBUS_FMT_Y12_1X12</entry>
<entry>0x2013</entry>
<entry></entry>
+ &dash-ent-10;
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
@@ -2219,6 +2164,7 @@
<entry>V4L2_MBUS_FMT_UYVY8_1X16</entry>
<entry>0x200f</entry>
<entry></entry>
+ &dash-ent-10;
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
@@ -2244,6 +2190,7 @@
<entry></entry>
<entry></entry>
<entry></entry>
+ &dash-ent-10;
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
@@ -2269,6 +2216,7 @@
<entry>V4L2_MBUS_FMT_VYUY8_1X16</entry>
<entry>0x2010</entry>
<entry></entry>
+ &dash-ent-10;
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
@@ -2294,6 +2242,7 @@
<entry></entry>
<entry></entry>
<entry></entry>
+ &dash-ent-10;
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
@@ -2319,6 +2268,7 @@
<entry>V4L2_MBUS_FMT_YUYV8_1X16</entry>
<entry>0x2011</entry>
<entry></entry>
+ &dash-ent-10;
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
@@ -2344,6 +2294,7 @@
<entry></entry>
<entry></entry>
<entry></entry>
+ &dash-ent-10;
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
@@ -2369,6 +2320,7 @@
<entry>V4L2_MBUS_FMT_YVYU8_1X16</entry>
<entry>0x2012</entry>
<entry></entry>
+ &dash-ent-10;
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
@@ -2394,6 +2346,7 @@
<entry></entry>
<entry></entry>
<entry></entry>
+ &dash-ent-10;
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
@@ -2415,10 +2368,111 @@
<entry>u<subscript>1</subscript></entry>
<entry>u<subscript>0</subscript></entry>
</row>
+ <row id="V4L2-MBUS-FMT-YDYUYDYV8-1X16">
+ <entry>V4L2_MBUS_FMT_YDYUYDYV8_1X16</entry>
+ <entry>0x2014</entry>
+ <entry></entry>
+ <entry>-</entry>
+ <entry>-</entry>
+ <entry>-</entry>
+ <entry>-</entry>
+ <entry>y<subscript>7</subscript></entry>
+ <entry>y<subscript>6</subscript></entry>
+ <entry>y<subscript>5</subscript></entry>
+ <entry>y<subscript>4</subscript></entry>
+ <entry>y<subscript>3</subscript></entry>
+ <entry>y<subscript>2</subscript></entry>
+ <entry>y<subscript>1</subscript></entry>
+ <entry>y<subscript>0</subscript></entry>
+ <entry>d</entry>
+ <entry>d</entry>
+ <entry>d</entry>
+ <entry>d</entry>
+ <entry>d</entry>
+ <entry>d</entry>
+ <entry>d</entry>
+ <entry>d</entry>
+ </row>
+ <row>
+ <entry></entry>
+ <entry></entry>
+ <entry></entry>
+ <entry>-</entry>
+ <entry>-</entry>
+ <entry>-</entry>
+ <entry>-</entry>
+ <entry>y<subscript>7</subscript></entry>
+ <entry>y<subscript>6</subscript></entry>
+ <entry>y<subscript>5</subscript></entry>
+ <entry>y<subscript>4</subscript></entry>
+ <entry>y<subscript>3</subscript></entry>
+ <entry>y<subscript>2</subscript></entry>
+ <entry>y<subscript>1</subscript></entry>
+ <entry>y<subscript>0</subscript></entry>
+ <entry>u<subscript>7</subscript></entry>
+ <entry>u<subscript>6</subscript></entry>
+ <entry>u<subscript>5</subscript></entry>
+ <entry>u<subscript>4</subscript></entry>
+ <entry>u<subscript>3</subscript></entry>
+ <entry>u<subscript>2</subscript></entry>
+ <entry>u<subscript>1</subscript></entry>
+ <entry>u<subscript>0</subscript></entry>
+ </row>
+ <row>
+ <entry></entry>
+ <entry></entry>
+ <entry></entry>
+ <entry>-</entry>
+ <entry>-</entry>
+ <entry>-</entry>
+ <entry>-</entry>
+ <entry>y<subscript>7</subscript></entry>
+ <entry>y<subscript>6</subscript></entry>
+ <entry>y<subscript>5</subscript></entry>
+ <entry>y<subscript>4</subscript></entry>
+ <entry>y<subscript>3</subscript></entry>
+ <entry>y<subscript>2</subscript></entry>
+ <entry>y<subscript>1</subscript></entry>
+ <entry>y<subscript>0</subscript></entry>
+ <entry>d</entry>
+ <entry>d</entry>
+ <entry>d</entry>
+ <entry>d</entry>
+ <entry>d</entry>
+ <entry>d</entry>
+ <entry>d</entry>
+ <entry>d</entry>
+ </row>
+ <row>
+ <entry></entry>
+ <entry></entry>
+ <entry></entry>
+ <entry>-</entry>
+ <entry>-</entry>
+ <entry>-</entry>
+ <entry>-</entry>
+ <entry>y<subscript>7</subscript></entry>
+ <entry>y<subscript>6</subscript></entry>
+ <entry>y<subscript>5</subscript></entry>
+ <entry>y<subscript>4</subscript></entry>
+ <entry>y<subscript>3</subscript></entry>
+ <entry>y<subscript>2</subscript></entry>
+ <entry>y<subscript>1</subscript></entry>
+ <entry>y<subscript>0</subscript></entry>
+ <entry>v<subscript>7</subscript></entry>
+ <entry>v<subscript>6</subscript></entry>
+ <entry>v<subscript>5</subscript></entry>
+ <entry>v<subscript>4</subscript></entry>
+ <entry>v<subscript>3</subscript></entry>
+ <entry>v<subscript>2</subscript></entry>
+ <entry>v<subscript>1</subscript></entry>
+ <entry>v<subscript>0</subscript></entry>
+ </row>
<row id="V4L2-MBUS-FMT-YUYV10-1X20">
<entry>V4L2_MBUS_FMT_YUYV10_1X20</entry>
<entry>0x200d</entry>
<entry></entry>
+ &dash-ent-10;
<entry>y<subscript>9</subscript></entry>
<entry>y<subscript>8</subscript></entry>
<entry>y<subscript>7</subscript></entry>
@@ -2444,6 +2498,7 @@
<entry></entry>
<entry></entry>
<entry></entry>
+ &dash-ent-10;
<entry>y<subscript>9</subscript></entry>
<entry>y<subscript>8</subscript></entry>
<entry>y<subscript>7</subscript></entry>
@@ -2469,6 +2524,7 @@
<entry>V4L2_MBUS_FMT_YVYU10_1X20</entry>
<entry>0x200e</entry>
<entry></entry>
+ &dash-ent-10;
<entry>y<subscript>9</subscript></entry>
<entry>y<subscript>8</subscript></entry>
<entry>y<subscript>7</subscript></entry>
@@ -2494,6 +2550,7 @@
<entry></entry>
<entry></entry>
<entry></entry>
+ &dash-ent-10;
<entry>y<subscript>9</subscript></entry>
<entry>y<subscript>8</subscript></entry>
<entry>y<subscript>7</subscript></entry>
@@ -2515,6 +2572,41 @@
<entry>u<subscript>1</subscript></entry>
<entry>u<subscript>0</subscript></entry>
</row>
+ <row id="V4L2-MBUS-FMT-YUV10-1X30">
+ <entry>V4L2_MBUS_FMT_YUV10_1X30</entry>
+ <entry>0x2014</entry>
+ <entry></entry>
+ <entry>y<subscript>9</subscript></entry>
+ <entry>y<subscript>8</subscript></entry>
+ <entry>y<subscript>7</subscript></entry>
+ <entry>y<subscript>6</subscript></entry>
+ <entry>y<subscript>5</subscript></entry>
+ <entry>y<subscript>4</subscript></entry>
+ <entry>y<subscript>3</subscript></entry>
+ <entry>y<subscript>2</subscript></entry>
+ <entry>y<subscript>1</subscript></entry>
+ <entry>y<subscript>0</subscript></entry>
+ <entry>u<subscript>9</subscript></entry>
+ <entry>u<subscript>8</subscript></entry>
+ <entry>u<subscript>7</subscript></entry>
+ <entry>u<subscript>6</subscript></entry>
+ <entry>u<subscript>5</subscript></entry>
+ <entry>u<subscript>4</subscript></entry>
+ <entry>u<subscript>3</subscript></entry>
+ <entry>u<subscript>2</subscript></entry>
+ <entry>u<subscript>1</subscript></entry>
+ <entry>u<subscript>0</subscript></entry>
+ <entry>v<subscript>9</subscript></entry>
+ <entry>v<subscript>8</subscript></entry>
+ <entry>v<subscript>7</subscript></entry>
+ <entry>v<subscript>6</subscript></entry>
+ <entry>v<subscript>5</subscript></entry>
+ <entry>v<subscript>4</subscript></entry>
+ <entry>v<subscript>3</subscript></entry>
+ <entry>v<subscript>2</subscript></entry>
+ <entry>v<subscript>1</subscript></entry>
+ <entry>v<subscript>0</subscript></entry>
+ </row>
</tbody>
</tgroup>
</table>
diff --git a/Documentation/DocBook/media/v4l/v4l2.xml b/Documentation/DocBook/media/v4l/v4l2.xml
index 4d110b1..8469fe1 100644
--- a/Documentation/DocBook/media/v4l/v4l2.xml
+++ b/Documentation/DocBook/media/v4l/v4l2.xml
@@ -124,6 +124,7 @@
<year>2010</year>
<year>2011</year>
<year>2012</year>
+ <year>2013</year>
<holder>Bill Dirks, Michael H. Schimek, Hans Verkuil, Martin
Rubli, Andy Walls, Muralidharan Karicheri, Mauro Carvalho Chehab,
Pawel Osciak</holder>
@@ -140,6 +141,34 @@
applications. -->
<revision>
+ <revnumber>3.11</revnumber>
+ <date>2013-05-26</date>
+ <authorinitials>hv</authorinitials>
+ <revremark>Remove obsolete VIDIOC_DBG_G_CHIP_IDENT ioctl.
+ </revremark>
+ </revision>
+
+ <revision>
+ <revnumber>3.10</revnumber>
+ <date>2013-03-25</date>
+ <authorinitials>hv</authorinitials>
+ <revremark>Remove obsolete and unused DV_PRESET ioctls:
+ VIDIOC_G_DV_PRESET, VIDIOC_S_DV_PRESET, VIDIOC_QUERY_DV_PRESET and
+ VIDIOC_ENUM_DV_PRESET. Remove the related v4l2_input/output capability
+ flags V4L2_IN_CAP_PRESETS and V4L2_OUT_CAP_PRESETS. Added VIDIOC_DBG_G_CHIP_INFO.
+ </revremark>
+ </revision>
+
+ <revision>
+ <revnumber>3.9</revnumber>
+ <date>2012-12-03</date>
+ <authorinitials>sa, sn</authorinitials>
+ <revremark>Added timestamp types to v4l2_buffer.
+ Added V4L2_EVENT_CTRL_CH_RANGE control event changes flag.
+ </revremark>
+ </revision>
+
+ <revision>
<revnumber>3.6</revnumber>
<date>2012-07-02</date>
<authorinitials>hv</authorinitials>
@@ -472,7 +501,7 @@
</partinfo>
<title>Video for Linux Two API Specification</title>
- <subtitle>Revision 3.6</subtitle>
+ <subtitle>Revision 3.11</subtitle>
<chapter id="common">
&sub-common;
@@ -526,7 +555,7 @@
<!-- All ioctls go here. -->
&sub-create-bufs;
&sub-cropcap;
- &sub-dbg-g-chip-ident;
+ &sub-dbg-g-chip-info;
&sub-dbg-g-register;
&sub-decoder-cmd;
&sub-dqevent;
@@ -534,7 +563,6 @@
&sub-encoder-cmd;
&sub-enumaudio;
&sub-enumaudioout;
- &sub-enum-dv-presets;
&sub-enum-dv-timings;
&sub-enum-fmt;
&sub-enum-framesizes;
@@ -548,7 +576,6 @@
&sub-g-audioout;
&sub-g-crop;
&sub-g-ctrl;
- &sub-g-dv-preset;
&sub-g-dv-timings;
&sub-g-enc-index;
&sub-g-ext-ctrls;
@@ -572,7 +599,6 @@
&sub-querybuf;
&sub-querycap;
&sub-queryctrl;
- &sub-query-dv-preset;
&sub-query-dv-timings;
&sub-querystd;
&sub-reqbufs;
diff --git a/Documentation/DocBook/media/v4l/vidioc-dbg-g-chip-ident.xml b/Documentation/DocBook/media/v4l/vidioc-dbg-g-chip-ident.xml
deleted file mode 100644
index 4ecd966..0000000
--- a/Documentation/DocBook/media/v4l/vidioc-dbg-g-chip-ident.xml
+++ /dev/null
@@ -1,266 +0,0 @@
-<refentry id="vidioc-dbg-g-chip-ident">
- <refmeta>
- <refentrytitle>ioctl VIDIOC_DBG_G_CHIP_IDENT</refentrytitle>
- &manvol;
- </refmeta>
-
- <refnamediv>
- <refname>VIDIOC_DBG_G_CHIP_IDENT</refname>
- <refpurpose>Identify the chips on a TV card</refpurpose>
- </refnamediv>
-
- <refsynopsisdiv>
- <funcsynopsis>
- <funcprototype>
- <funcdef>int <function>ioctl</function></funcdef>
- <paramdef>int <parameter>fd</parameter></paramdef>
- <paramdef>int <parameter>request</parameter></paramdef>
- <paramdef>struct v4l2_dbg_chip_ident
-*<parameter>argp</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
- </refsynopsisdiv>
-
- <refsect1>
- <title>Arguments</title>
-
- <variablelist>
- <varlistentry>
- <term><parameter>fd</parameter></term>
- <listitem>
- <para>&fd;</para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term><parameter>request</parameter></term>
- <listitem>
- <para>VIDIOC_DBG_G_CHIP_IDENT</para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term><parameter>argp</parameter></term>
- <listitem>
- <para></para>
- </listitem>
- </varlistentry>
- </variablelist>
- </refsect1>
-
- <refsect1>
- <title>Description</title>
-
- <note>
- <title>Experimental</title>
-
- <para>This is an <link
-linkend="experimental">experimental</link> interface and may change in
-the future.</para>
- </note>
-
- <para>For driver debugging purposes this ioctl allows test
-applications to query the driver about the chips present on the TV
-card. Regular applications must not use it. When you found a chip
-specific bug, please contact the linux-media mailing list (&v4l-ml;)
-so it can be fixed.</para>
-
- <para>To query the driver applications must initialize the
-<structfield>match.type</structfield> and
-<structfield>match.addr</structfield> or <structfield>match.name</structfield>
-fields of a &v4l2-dbg-chip-ident;
-and call <constant>VIDIOC_DBG_G_CHIP_IDENT</constant> with a pointer to
-this structure. On success the driver stores information about the
-selected chip in the <structfield>ident</structfield> and
-<structfield>revision</structfield> fields. On failure the structure
-remains unchanged.</para>
-
- <para>When <structfield>match.type</structfield> is
-<constant>V4L2_CHIP_MATCH_HOST</constant>,
-<structfield>match.addr</structfield> selects the nth non-&i2c; chip
-on the TV card. You can enumerate all chips by starting at zero and
-incrementing <structfield>match.addr</structfield> by one until
-<constant>VIDIOC_DBG_G_CHIP_IDENT</constant> fails with an &EINVAL;.
-The number zero always selects the host chip, ⪚ the chip connected
-to the PCI or USB bus.</para>
-
- <para>When <structfield>match.type</structfield> is
-<constant>V4L2_CHIP_MATCH_I2C_DRIVER</constant>,
-<structfield>match.name</structfield> contains the I2C driver name.
-For instance
-<constant>"saa7127"</constant> will match any chip
-supported by the saa7127 driver, regardless of its &i2c; bus address.
-When multiple chips supported by the same driver are present, the
-ioctl will return <constant>V4L2_IDENT_AMBIGUOUS</constant> in the
-<structfield>ident</structfield> field.</para>
-
- <para>When <structfield>match.type</structfield> is
-<constant>V4L2_CHIP_MATCH_I2C_ADDR</constant>,
-<structfield>match.addr</structfield> selects a chip by its 7 bit
-&i2c; bus address.</para>
-
- <para>When <structfield>match.type</structfield> is
-<constant>V4L2_CHIP_MATCH_AC97</constant>,
-<structfield>match.addr</structfield> selects the nth AC97 chip
-on the TV card. You can enumerate all chips by starting at zero and
-incrementing <structfield>match.addr</structfield> by one until
-<constant>VIDIOC_DBG_G_CHIP_IDENT</constant> fails with an &EINVAL;.</para>
-
- <para>On success, the <structfield>ident</structfield> field will
-contain a chip ID from the Linux
-<filename>media/v4l2-chip-ident.h</filename> header file, and the
-<structfield>revision</structfield> field will contain a driver
-specific value, or zero if no particular revision is associated with
-this chip.</para>
-
- <para>When the driver could not identify the selected chip,
-<structfield>ident</structfield> will contain
-<constant>V4L2_IDENT_UNKNOWN</constant>. When no chip matched
-the ioctl will succeed but the
-<structfield>ident</structfield> field will contain
-<constant>V4L2_IDENT_NONE</constant>. If multiple chips matched,
-<structfield>ident</structfield> will contain
-<constant>V4L2_IDENT_AMBIGUOUS</constant>. In all these cases the
-<structfield>revision</structfield> field remains unchanged.</para>
-
- <para>This ioctl is optional, not all drivers may support it. It
-was introduced in Linux 2.6.21, but the API was changed to the
-one described here in 2.6.29.</para>
-
- <para>We recommended the <application>v4l2-dbg</application>
-utility over calling this ioctl directly. It is available from the
-LinuxTV v4l-dvb repository; see <ulink
-url="http://linuxtv.org/repo/">http://linuxtv.org/repo/</ulink> for
-access instructions.</para>
-
- <!-- Note for convenience vidioc-dbg-g-register.sgml
- contains a duplicate of this table. -->
- <table pgwide="1" frame="none" id="ident-v4l2-dbg-match">
- <title>struct <structname>v4l2_dbg_match</structname></title>
- <tgroup cols="4">
- &cs-ustr;
- <tbody valign="top">
- <row>
- <entry>__u32</entry>
- <entry><structfield>type</structfield></entry>
- <entry>See <xref linkend="ident-chip-match-types" /> for a list of
-possible types.</entry>
- </row>
- <row>
- <entry>union</entry>
- <entry>(anonymous)</entry>
- </row>
- <row>
- <entry></entry>
- <entry>__u32</entry>
- <entry><structfield>addr</structfield></entry>
- <entry>Match a chip by this number, interpreted according
-to the <structfield>type</structfield> field.</entry>
- </row>
- <row>
- <entry></entry>
- <entry>char</entry>
- <entry><structfield>name[32]</structfield></entry>
- <entry>Match a chip by this name, interpreted according
-to the <structfield>type</structfield> field.</entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- <table pgwide="1" frame="none" id="v4l2-dbg-chip-ident">
- <title>struct <structname>v4l2_dbg_chip_ident</structname></title>
- <tgroup cols="3">
- &cs-str;
- <tbody valign="top">
- <row>
- <entry>struct v4l2_dbg_match</entry>
- <entry><structfield>match</structfield></entry>
- <entry>How to match the chip, see <xref linkend="ident-v4l2-dbg-match" />.</entry>
- </row>
- <row>
- <entry>__u32</entry>
- <entry><structfield>ident</structfield></entry>
- <entry>A chip identifier as defined in the Linux
-<filename>media/v4l2-chip-ident.h</filename> header file, or one of
-the values from <xref linkend="chip-ids" />.</entry>
- </row>
- <row>
- <entry>__u32</entry>
- <entry><structfield>revision</structfield></entry>
- <entry>A chip revision, chip and driver specific.</entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- <!-- Note for convenience vidioc-dbg-g-register.sgml
- contains a duplicate of this table. -->
- <table pgwide="1" frame="none" id="ident-chip-match-types">
- <title>Chip Match Types</title>
- <tgroup cols="3">
- &cs-def;
- <tbody valign="top">
- <row>
- <entry><constant>V4L2_CHIP_MATCH_HOST</constant></entry>
- <entry>0</entry>
- <entry>Match the nth chip on the card, zero for the
- host chip. Does not match &i2c; chips.</entry>
- </row>
- <row>
- <entry><constant>V4L2_CHIP_MATCH_I2C_DRIVER</constant></entry>
- <entry>1</entry>
- <entry>Match an &i2c; chip by its driver name.</entry>
- </row>
- <row>
- <entry><constant>V4L2_CHIP_MATCH_I2C_ADDR</constant></entry>
- <entry>2</entry>
- <entry>Match a chip by its 7 bit &i2c; bus address.</entry>
- </row>
- <row>
- <entry><constant>V4L2_CHIP_MATCH_AC97</constant></entry>
- <entry>3</entry>
- <entry>Match the nth anciliary AC97 chip.</entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- <!-- This is an anonymous enum in media/v4l2-chip-ident.h. -->
- <table pgwide="1" frame="none" id="chip-ids">
- <title>Chip Identifiers</title>
- <tgroup cols="3">
- &cs-def;
- <tbody valign="top">
- <row>
- <entry><constant>V4L2_IDENT_NONE</constant></entry>
- <entry>0</entry>
- <entry>No chip matched.</entry>
- </row>
- <row>
- <entry><constant>V4L2_IDENT_AMBIGUOUS</constant></entry>
- <entry>1</entry>
- <entry>Multiple chips matched.</entry>
- </row>
- <row>
- <entry><constant>V4L2_IDENT_UNKNOWN</constant></entry>
- <entry>2</entry>
- <entry>A chip is present at this address, but the driver
-could not identify it.</entry>
- </row>
- </tbody>
- </tgroup>
- </table>
- </refsect1>
-
- <refsect1>
- &return-value;
-
- <variablelist>
- <varlistentry>
- <term><errorcode>EINVAL</errorcode></term>
- <listitem>
- <para>The <structfield>match_type</structfield> is invalid.</para>
- </listitem>
- </varlistentry>
- </variablelist>
- </refsect1>
-</refentry>
diff --git a/Documentation/DocBook/media/v4l/vidioc-dbg-g-chip-info.xml b/Documentation/DocBook/media/v4l/vidioc-dbg-g-chip-info.xml
new file mode 100644
index 0000000..4c4603c
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/vidioc-dbg-g-chip-info.xml
@@ -0,0 +1,207 @@
+<refentry id="vidioc-dbg-g-chip-info">
+ <refmeta>
+ <refentrytitle>ioctl VIDIOC_DBG_G_CHIP_INFO</refentrytitle>
+ &manvol;
+ </refmeta>
+
+ <refnamediv>
+ <refname>VIDIOC_DBG_G_CHIP_INFO</refname>
+ <refpurpose>Identify the chips on a TV card</refpurpose>
+ </refnamediv>
+
+ <refsynopsisdiv>
+ <funcsynopsis>
+ <funcprototype>
+ <funcdef>int <function>ioctl</function></funcdef>
+ <paramdef>int <parameter>fd</parameter></paramdef>
+ <paramdef>int <parameter>request</parameter></paramdef>
+ <paramdef>struct v4l2_dbg_chip_info
+*<parameter>argp</parameter></paramdef>
+ </funcprototype>
+ </funcsynopsis>
+ </refsynopsisdiv>
+
+ <refsect1>
+ <title>Arguments</title>
+
+ <variablelist>
+ <varlistentry>
+ <term><parameter>fd</parameter></term>
+ <listitem>
+ <para>&fd;</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><parameter>request</parameter></term>
+ <listitem>
+ <para>VIDIOC_DBG_G_CHIP_INFO</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><parameter>argp</parameter></term>
+ <listitem>
+ <para></para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ </refsect1>
+
+ <refsect1>
+ <title>Description</title>
+
+ <note>
+ <title>Experimental</title>
+
+ <para>This is an <link
+linkend="experimental">experimental</link> interface and may change in
+the future.</para>
+ </note>
+
+ <para>For driver debugging purposes this ioctl allows test
+applications to query the driver about the chips present on the TV
+card. Regular applications must not use it. When you found a chip
+specific bug, please contact the linux-media mailing list (&v4l-ml;)
+so it can be fixed.</para>
+
+ <para>Additionally the Linux kernel must be compiled with the
+<constant>CONFIG_VIDEO_ADV_DEBUG</constant> option to enable this ioctl.</para>
+
+ <para>To query the driver applications must initialize the
+<structfield>match.type</structfield> and
+<structfield>match.addr</structfield> or <structfield>match.name</structfield>
+fields of a &v4l2-dbg-chip-info;
+and call <constant>VIDIOC_DBG_G_CHIP_INFO</constant> with a pointer to
+this structure. On success the driver stores information about the
+selected chip in the <structfield>name</structfield> and
+<structfield>flags</structfield> fields.</para>
+
+ <para>When <structfield>match.type</structfield> is
+<constant>V4L2_CHIP_MATCH_BRIDGE</constant>,
+<structfield>match.addr</structfield> selects the nth bridge 'chip'
+on the TV card. You can enumerate all chips by starting at zero and
+incrementing <structfield>match.addr</structfield> by one until
+<constant>VIDIOC_DBG_G_CHIP_INFO</constant> fails with an &EINVAL;.
+The number zero always selects the bridge chip itself, ⪚ the chip
+connected to the PCI or USB bus. Non-zero numbers identify specific
+parts of the bridge chip such as an AC97 register block.</para>
+
+ <para>When <structfield>match.type</structfield> is
+<constant>V4L2_CHIP_MATCH_SUBDEV</constant>,
+<structfield>match.addr</structfield> selects the nth sub-device. This
+allows you to enumerate over all sub-devices.</para>
+
+ <para>On success, the <structfield>name</structfield> field will
+contain a chip name and the <structfield>flags</structfield> field will
+contain <constant>V4L2_CHIP_FL_READABLE</constant> if the driver supports
+reading registers from the device or <constant>V4L2_CHIP_FL_WRITABLE</constant>
+if the driver supports writing registers to the device.</para>
+
+ <para>We recommended the <application>v4l2-dbg</application>
+utility over calling this ioctl directly. It is available from the
+LinuxTV v4l-dvb repository; see <ulink
+url="http://linuxtv.org/repo/">http://linuxtv.org/repo/</ulink> for
+access instructions.</para>
+
+ <!-- Note for convenience vidioc-dbg-g-register.sgml
+ contains a duplicate of this table. -->
+ <table pgwide="1" frame="none" id="name-v4l2-dbg-match">
+ <title>struct <structname>v4l2_dbg_match</structname></title>
+ <tgroup cols="4">
+ &cs-ustr;
+ <tbody valign="top">
+ <row>
+ <entry>__u32</entry>
+ <entry><structfield>type</structfield></entry>
+ <entry>See <xref linkend="name-chip-match-types" /> for a list of
+possible types.</entry>
+ </row>
+ <row>
+ <entry>union</entry>
+ <entry>(anonymous)</entry>
+ </row>
+ <row>
+ <entry></entry>
+ <entry>__u32</entry>
+ <entry><structfield>addr</structfield></entry>
+ <entry>Match a chip by this number, interpreted according
+to the <structfield>type</structfield> field.</entry>
+ </row>
+ <row>
+ <entry></entry>
+ <entry>char</entry>
+ <entry><structfield>name[32]</structfield></entry>
+ <entry>Match a chip by this name, interpreted according
+to the <structfield>type</structfield> field. Currently unused.</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <table pgwide="1" frame="none" id="v4l2-dbg-chip-info">
+ <title>struct <structname>v4l2_dbg_chip_info</structname></title>
+ <tgroup cols="3">
+ &cs-str;
+ <tbody valign="top">
+ <row>
+ <entry>struct v4l2_dbg_match</entry>
+ <entry><structfield>match</structfield></entry>
+ <entry>How to match the chip, see <xref linkend="name-v4l2-dbg-match" />.</entry>
+ </row>
+ <row>
+ <entry>char</entry>
+ <entry><structfield>name[32]</structfield></entry>
+ <entry>The name of the chip.</entry>
+ </row>
+ <row>
+ <entry>__u32</entry>
+ <entry><structfield>flags</structfield></entry>
+ <entry>Set by the driver. If <constant>V4L2_CHIP_FL_READABLE</constant>
+is set, then the driver supports reading registers from the device. If
+<constant>V4L2_CHIP_FL_WRITABLE</constant> is set, then it supports writing registers.</entry>
+ </row>
+ <row>
+ <entry>__u32</entry>
+ <entry><structfield>reserved[8]</structfield></entry>
+ <entry>Reserved fields, both application and driver must set these to 0.</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <!-- Note for convenience vidioc-dbg-g-register.sgml
+ contains a duplicate of this table. -->
+ <table pgwide="1" frame="none" id="name-chip-match-types">
+ <title>Chip Match Types</title>
+ <tgroup cols="3">
+ &cs-def;
+ <tbody valign="top">
+ <row>
+ <entry><constant>V4L2_CHIP_MATCH_BRIDGE</constant></entry>
+ <entry>0</entry>
+ <entry>Match the nth chip on the card, zero for the
+ bridge chip. Does not match sub-devices.</entry>
+ </row>
+ <row>
+ <entry><constant>V4L2_CHIP_MATCH_SUBDEV</constant></entry>
+ <entry>4</entry>
+ <entry>Match the nth sub-device.</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+ </refsect1>
+
+ <refsect1>
+ &return-value;
+
+ <variablelist>
+ <varlistentry>
+ <term><errorcode>EINVAL</errorcode></term>
+ <listitem>
+ <para>The <structfield>match_type</structfield> is invalid or
+no device could be matched.</para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ </refsect1>
+</refentry>
diff --git a/Documentation/DocBook/media/v4l/vidioc-dbg-g-register.xml b/Documentation/DocBook/media/v4l/vidioc-dbg-g-register.xml
index a44aebc..3d038e7 100644
--- a/Documentation/DocBook/media/v4l/vidioc-dbg-g-register.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-dbg-g-register.xml
@@ -76,7 +76,7 @@
to enable these ioctls.</para>
<para>To write a register applications must initialize all fields
-of a &v4l2-dbg-register; and call
+of a &v4l2-dbg-register; except for <structfield>size</structfield> and call
<constant>VIDIOC_DBG_S_REGISTER</constant> with a pointer to this
structure. The <structfield>match.type</structfield> and
<structfield>match.addr</structfield> or <structfield>match.name</structfield>
@@ -87,54 +87,28 @@
<para>To read a register applications must initialize the
<structfield>match.type</structfield>,
-<structfield>match.chip</structfield> or <structfield>match.name</structfield> and
+<structfield>match.addr</structfield> or <structfield>match.name</structfield> and
<structfield>reg</structfield> fields, and call
<constant>VIDIOC_DBG_G_REGISTER</constant> with a pointer to this
structure. On success the driver stores the register value in the
-<structfield>val</structfield> field. On failure the structure remains
-unchanged.</para>
+<structfield>val</structfield> field and the size (in bytes) of the
+value in <structfield>size</structfield>.</para>
<para>When <structfield>match.type</structfield> is
-<constant>V4L2_CHIP_MATCH_HOST</constant>,
-<structfield>match.addr</structfield> selects the nth non-&i2c; chip
+<constant>V4L2_CHIP_MATCH_BRIDGE</constant>,
+<structfield>match.addr</structfield> selects the nth non-sub-device chip
on the TV card. The number zero always selects the host chip, ⪚ the
chip connected to the PCI or USB bus. You can find out which chips are
-present with the &VIDIOC-DBG-G-CHIP-IDENT; ioctl.</para>
+present with the &VIDIOC-DBG-G-CHIP-INFO; ioctl.</para>
<para>When <structfield>match.type</structfield> is
-<constant>V4L2_CHIP_MATCH_I2C_DRIVER</constant>,
-<structfield>match.name</structfield> contains the I2C driver name.
-For instance
-<constant>"saa7127"</constant> will match any chip
-supported by the saa7127 driver, regardless of its &i2c; bus address.
-When multiple chips supported by the same driver are present, the
-effect of these ioctls is undefined. Again with the
-&VIDIOC-DBG-G-CHIP-IDENT; ioctl you can find out which &i2c; chips are
-present.</para>
-
- <para>When <structfield>match.type</structfield> is
-<constant>V4L2_CHIP_MATCH_I2C_ADDR</constant>,
-<structfield>match.addr</structfield> selects a chip by its 7 bit &i2c;
-bus address.</para>
-
- <para>When <structfield>match.type</structfield> is
-<constant>V4L2_CHIP_MATCH_AC97</constant>,
-<structfield>match.addr</structfield> selects the nth AC97 chip
-on the TV card.</para>
-
- <note>
- <title>Success not guaranteed</title>
-
- <para>Due to a flaw in the Linux &i2c; bus driver these ioctls may
-return successfully without actually reading or writing a register. To
-catch the most likely failure we recommend a &VIDIOC-DBG-G-CHIP-IDENT;
-call confirming the presence of the selected &i2c; chip.</para>
- </note>
+<constant>V4L2_CHIP_MATCH_SUBDEV</constant>,
+<structfield>match.addr</structfield> selects the nth sub-device.</para>
<para>These ioctls are optional, not all drivers may support them.
However when a driver supports these ioctls it must also support
-&VIDIOC-DBG-G-CHIP-IDENT;. Conversely it may support
-<constant>VIDIOC_DBG_G_CHIP_IDENT</constant> but not these ioctls.</para>
+&VIDIOC-DBG-G-CHIP-INFO;. Conversely it may support
+<constant>VIDIOC_DBG_G_CHIP_INFO</constant> but not these ioctls.</para>
<para><constant>VIDIOC_DBG_G_REGISTER</constant> and
<constant>VIDIOC_DBG_S_REGISTER</constant> were introduced in Linux
@@ -146,7 +120,7 @@
url="http://linuxtv.org/repo/">http://linuxtv.org/repo/</ulink> for
access instructions.</para>
- <!-- Note for convenience vidioc-dbg-g-chip-ident.sgml
+ <!-- Note for convenience vidioc-dbg-g-chip-info.sgml
contains a duplicate of this table. -->
<table pgwide="1" frame="none" id="v4l2-dbg-match">
<title>struct <structname>v4l2_dbg_match</structname></title>
@@ -156,7 +130,7 @@
<row>
<entry>__u32</entry>
<entry><structfield>type</structfield></entry>
- <entry>See <xref linkend="ident-chip-match-types" /> for a list of
+ <entry>See <xref linkend="chip-match-types" /> for a list of
possible types.</entry>
</row>
<row>
@@ -175,7 +149,7 @@
<entry>char</entry>
<entry><structfield>name[32]</structfield></entry>
<entry>Match a chip by this name, interpreted according
-to the <structfield>type</structfield> field.</entry>
+to the <structfield>type</structfield> field. Currently unused.</entry>
</row>
</tbody>
</tgroup>
@@ -195,6 +169,11 @@
<entry>How to match the chip, see <xref linkend="v4l2-dbg-match" />.</entry>
</row>
<row>
+ <entry>__u32</entry>
+ <entry><structfield>size</structfield></entry>
+ <entry>The register size in bytes.</entry>
+ </row>
+ <row>
<entry>__u64</entry>
<entry><structfield>reg</structfield></entry>
<entry>A register number.</entry>
@@ -209,7 +188,7 @@
</tgroup>
</table>
- <!-- Note for convenience vidioc-dbg-g-chip-ident.sgml
+ <!-- Note for convenience vidioc-dbg-g-chip-info.sgml
contains a duplicate of this table. -->
<table pgwide="1" frame="none" id="chip-match-types">
<title>Chip Match Types</title>
@@ -217,25 +196,15 @@
&cs-def;
<tbody valign="top">
<row>
- <entry><constant>V4L2_CHIP_MATCH_HOST</constant></entry>
+ <entry><constant>V4L2_CHIP_MATCH_BRIDGE</constant></entry>
<entry>0</entry>
<entry>Match the nth chip on the card, zero for the
- host chip. Does not match &i2c; chips.</entry>
+ bridge chip. Does not match sub-devices.</entry>
</row>
<row>
- <entry><constant>V4L2_CHIP_MATCH_I2C_DRIVER</constant></entry>
- <entry>1</entry>
- <entry>Match an &i2c; chip by its driver name.</entry>
- </row>
- <row>
- <entry><constant>V4L2_CHIP_MATCH_I2C_ADDR</constant></entry>
- <entry>2</entry>
- <entry>Match a chip by its 7 bit &i2c; bus address.</entry>
- </row>
- <row>
- <entry><constant>V4L2_CHIP_MATCH_AC97</constant></entry>
- <entry>3</entry>
- <entry>Match the nth anciliary AC97 chip.</entry>
+ <entry><constant>V4L2_CHIP_MATCH_SUBDEV</constant></entry>
+ <entry>4</entry>
+ <entry>Match the nth sub-device.</entry>
</row>
</tbody>
</tgroup>
diff --git a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
index 98a856f..89891ad 100644
--- a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
@@ -261,6 +261,12 @@
<entry>This control event was triggered because the control flags
changed.</entry>
</row>
+ <row>
+ <entry><constant>V4L2_EVENT_CTRL_CH_RANGE</constant></entry>
+ <entry>0x0004</entry>
+ <entry>This control event was triggered because the minimum,
+ maximum, step or the default value of the control changed.</entry>
+ </row>
</tbody>
</tgroup>
</table>
diff --git a/Documentation/DocBook/media/v4l/vidioc-enum-dv-presets.xml b/Documentation/DocBook/media/v4l/vidioc-enum-dv-presets.xml
deleted file mode 100644
index fced5fb..0000000
--- a/Documentation/DocBook/media/v4l/vidioc-enum-dv-presets.xml
+++ /dev/null
@@ -1,240 +0,0 @@
-<refentry id="vidioc-enum-dv-presets">
- <refmeta>
- <refentrytitle>ioctl VIDIOC_ENUM_DV_PRESETS</refentrytitle>
- &manvol;
- </refmeta>
-
- <refnamediv>
- <refname>VIDIOC_ENUM_DV_PRESETS</refname>
- <refpurpose>Enumerate supported Digital Video presets</refpurpose>
- </refnamediv>
-
- <refsynopsisdiv>
- <funcsynopsis>
- <funcprototype>
- <funcdef>int <function>ioctl</function></funcdef>
- <paramdef>int <parameter>fd</parameter></paramdef>
- <paramdef>int <parameter>request</parameter></paramdef>
- <paramdef>struct v4l2_dv_enum_preset *<parameter>argp</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
- </refsynopsisdiv>
-
- <refsect1>
- <title>Arguments</title>
-
- <variablelist>
- <varlistentry>
- <term><parameter>fd</parameter></term>
- <listitem>
- <para>&fd;</para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term><parameter>request</parameter></term>
- <listitem>
- <para>VIDIOC_ENUM_DV_PRESETS</para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term><parameter>argp</parameter></term>
- <listitem>
- <para></para>
- </listitem>
- </varlistentry>
- </variablelist>
- </refsect1>
-
- <refsect1>
- <title>Description</title>
-
- <para>This ioctl is <emphasis role="bold">deprecated</emphasis>.
- New drivers and applications should use &VIDIOC-ENUM-DV-TIMINGS; instead.
- </para>
-
- <para>To query the attributes of a DV preset, applications initialize the
-<structfield>index</structfield> field and zero the reserved array of &v4l2-dv-enum-preset;
-and call the <constant>VIDIOC_ENUM_DV_PRESETS</constant> ioctl with a pointer to this
-structure. Drivers fill the rest of the structure or return an
-&EINVAL; when the index is out of bounds. To enumerate all DV Presets supported,
-applications shall begin at index zero, incrementing by one until the
-driver returns <errorcode>EINVAL</errorcode>. Drivers may enumerate a
-different set of DV presets after switching the video input or
-output.</para>
-
- <table pgwide="1" frame="none" id="v4l2-dv-enum-preset">
- <title>struct <structname>v4l2_dv_enum_presets</structname></title>
- <tgroup cols="3">
- &cs-str;
- <tbody valign="top">
- <row>
- <entry>__u32</entry>
- <entry><structfield>index</structfield></entry>
- <entry>Number of the DV preset, set by the
-application.</entry>
- </row>
- <row>
- <entry>__u32</entry>
- <entry><structfield>preset</structfield></entry>
- <entry>This field identifies one of the DV preset values listed in <xref linkend="v4l2-dv-presets-vals"/>.</entry>
- </row>
- <row>
- <entry>__u8</entry>
- <entry><structfield>name</structfield>[24]</entry>
- <entry>Name of the preset, a NUL-terminated ASCII string, for example: "720P-60", "1080I-60". This information is
-intended for the user.</entry>
- </row>
- <row>
- <entry>__u32</entry>
- <entry><structfield>width</structfield></entry>
- <entry>Width of the active video in pixels for the DV preset.</entry>
- </row>
- <row>
- <entry>__u32</entry>
- <entry><structfield>height</structfield></entry>
- <entry>Height of the active video in lines for the DV preset.</entry>
- </row>
- <row>
- <entry>__u32</entry>
- <entry><structfield>reserved</structfield>[4]</entry>
- <entry>Reserved for future extensions. Drivers must set the array to zero.</entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- <table pgwide="1" frame="none" id="v4l2-dv-presets-vals">
- <title>struct <structname>DV Presets</structname></title>
- <tgroup cols="3">
- &cs-str;
- <tbody valign="top">
- <row>
- <entry>Preset</entry>
- <entry>Preset value</entry>
- <entry>Description</entry>
- </row>
- <row>
- <entry></entry>
- <entry></entry>
- <entry></entry>
- </row>
- <row>
- <entry>V4L2_DV_INVALID</entry>
- <entry>0</entry>
- <entry>Invalid preset value.</entry>
- </row>
- <row>
- <entry>V4L2_DV_480P59_94</entry>
- <entry>1</entry>
- <entry>720x480 progressive video at 59.94 fps as per BT.1362.</entry>
- </row>
- <row>
- <entry>V4L2_DV_576P50</entry>
- <entry>2</entry>
- <entry>720x576 progressive video at 50 fps as per BT.1362.</entry>
- </row>
- <row>
- <entry>V4L2_DV_720P24</entry>
- <entry>3</entry>
- <entry>1280x720 progressive video at 24 fps as per SMPTE 296M.</entry>
- </row>
- <row>
- <entry>V4L2_DV_720P25</entry>
- <entry>4</entry>
- <entry>1280x720 progressive video at 25 fps as per SMPTE 296M.</entry>
- </row>
- <row>
- <entry>V4L2_DV_720P30</entry>
- <entry>5</entry>
- <entry>1280x720 progressive video at 30 fps as per SMPTE 296M.</entry>
- </row>
- <row>
- <entry>V4L2_DV_720P50</entry>
- <entry>6</entry>
- <entry>1280x720 progressive video at 50 fps as per SMPTE 296M.</entry>
- </row>
- <row>
- <entry>V4L2_DV_720P59_94</entry>
- <entry>7</entry>
- <entry>1280x720 progressive video at 59.94 fps as per SMPTE 274M.</entry>
- </row>
- <row>
- <entry>V4L2_DV_720P60</entry>
- <entry>8</entry>
- <entry>1280x720 progressive video at 60 fps as per SMPTE 274M/296M.</entry>
- </row>
- <row>
- <entry>V4L2_DV_1080I29_97</entry>
- <entry>9</entry>
- <entry>1920x1080 interlaced video at 29.97 fps as per BT.1120/SMPTE 274M.</entry>
- </row>
- <row>
- <entry>V4L2_DV_1080I30</entry>
- <entry>10</entry>
- <entry>1920x1080 interlaced video at 30 fps as per BT.1120/SMPTE 274M.</entry>
- </row>
- <row>
- <entry>V4L2_DV_1080I25</entry>
- <entry>11</entry>
- <entry>1920x1080 interlaced video at 25 fps as per BT.1120.</entry>
- </row>
- <row>
- <entry>V4L2_DV_1080I50</entry>
- <entry>12</entry>
- <entry>1920x1080 interlaced video at 50 fps as per SMPTE 296M.</entry>
- </row>
- <row>
- <entry>V4L2_DV_1080I60</entry>
- <entry>13</entry>
- <entry>1920x1080 interlaced video at 60 fps as per SMPTE 296M.</entry>
- </row>
- <row>
- <entry>V4L2_DV_1080P24</entry>
- <entry>14</entry>
- <entry>1920x1080 progressive video at 24 fps as per SMPTE 296M.</entry>
- </row>
- <row>
- <entry>V4L2_DV_1080P25</entry>
- <entry>15</entry>
- <entry>1920x1080 progressive video at 25 fps as per SMPTE 296M.</entry>
- </row>
- <row>
- <entry>V4L2_DV_1080P30</entry>
- <entry>16</entry>
- <entry>1920x1080 progressive video at 30 fps as per SMPTE 296M.</entry>
- </row>
- <row>
- <entry>V4L2_DV_1080P50</entry>
- <entry>17</entry>
- <entry>1920x1080 progressive video at 50 fps as per BT.1120.</entry>
- </row>
- <row>
- <entry>V4L2_DV_1080P60</entry>
- <entry>18</entry>
- <entry>1920x1080 progressive video at 60 fps as per BT.1120.</entry>
- </row>
- </tbody>
- </tgroup>
- </table>
- </refsect1>
-
- <refsect1>
- &return-value;
-
- <variablelist>
- <varlistentry>
- <term><errorcode>EINVAL</errorcode></term>
- <listitem>
- <para>The &v4l2-dv-enum-preset; <structfield>index</structfield>
-is out of bounds.</para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term><errorcode>ENODATA</errorcode></term>
- <listitem>
- <para>Digital video presets are not supported for this input or output.</para>
- </listitem>
- </varlistentry>
- </variablelist>
- </refsect1>
-</refentry>
diff --git a/Documentation/DocBook/media/v4l/vidioc-enuminput.xml b/Documentation/DocBook/media/v4l/vidioc-enuminput.xml
index 3c9a813..493a39a 100644
--- a/Documentation/DocBook/media/v4l/vidioc-enuminput.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-enuminput.xml
@@ -278,11 +278,6 @@
&cs-def;
<tbody valign="top">
<row>
- <entry><constant>V4L2_IN_CAP_PRESETS</constant></entry>
- <entry>0x00000001</entry>
- <entry>This input supports setting DV presets by using VIDIOC_S_DV_PRESET.</entry>
- </row>
- <row>
<entry><constant>V4L2_IN_CAP_DV_TIMINGS</constant></entry>
<entry>0x00000002</entry>
<entry>This input supports setting video timings by using VIDIOC_S_DV_TIMINGS.</entry>
diff --git a/Documentation/DocBook/media/v4l/vidioc-enumoutput.xml b/Documentation/DocBook/media/v4l/vidioc-enumoutput.xml
index f4ab079..2654e09 100644
--- a/Documentation/DocBook/media/v4l/vidioc-enumoutput.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-enumoutput.xml
@@ -163,11 +163,6 @@
&cs-def;
<tbody valign="top">
<row>
- <entry><constant>V4L2_OUT_CAP_PRESETS</constant></entry>
- <entry>0x00000001</entry>
- <entry>This output supports setting DV presets by using VIDIOC_S_DV_PRESET.</entry>
- </row>
- <row>
<entry><constant>V4L2_OUT_CAP_DV_TIMINGS</constant></entry>
<entry>0x00000002</entry>
<entry>This output supports setting video timings by using VIDIOC_S_DV_TIMINGS.</entry>
diff --git a/Documentation/DocBook/media/v4l/vidioc-expbuf.xml b/Documentation/DocBook/media/v4l/vidioc-expbuf.xml
index 72dfbd2..e287c8f 100644
--- a/Documentation/DocBook/media/v4l/vidioc-expbuf.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-expbuf.xml
@@ -83,15 +83,14 @@
<link linkend="dmabuf">DMABUF importing</link> for details about importing
DMABUF files into V4L2 nodes. It is recommended to close a DMABUF file when it
is no longer used to allow the associated memory to be reclaimed. </para>
-
</refsect1>
- <refsect1>
- <section>
- <title>Examples</title>
- <example>
- <title>Exporting a buffer.</title>
- <programlisting>
+ <refsect1>
+ <title>Examples</title>
+
+ <example>
+ <title>Exporting a buffer.</title>
+ <programlisting>
int buffer_export(int v4lfd, &v4l2-buf-type; bt, int index, int *dmafd)
{
&v4l2-exportbuffer; expbuf;
@@ -108,12 +107,12 @@
return 0;
}
- </programlisting>
- </example>
+ </programlisting>
+ </example>
- <example>
- <title>Exporting a buffer using the multi-planar API.</title>
- <programlisting>
+ <example>
+ <title>Exporting a buffer using the multi-planar API.</title>
+ <programlisting>
int buffer_export_mp(int v4lfd, &v4l2-buf-type; bt, int index,
int dmafd[], int n_planes)
{
@@ -137,12 +136,9 @@
return 0;
}
- </programlisting>
- </example>
- </section>
- </refsect1>
+ </programlisting>
+ </example>
- <refsect1>
<table pgwide="1" frame="none" id="v4l2-exportbuffer">
<title>struct <structname>v4l2_exportbuffer</structname></title>
<tgroup cols="3">
diff --git a/Documentation/DocBook/media/v4l/vidioc-g-ctrl.xml b/Documentation/DocBook/media/v4l/vidioc-g-ctrl.xml
index 12b1d05..ee2820d 100644
--- a/Documentation/DocBook/media/v4l/vidioc-g-ctrl.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-g-ctrl.xml
@@ -64,7 +64,9 @@
of bounds drivers can choose to take the closest valid value or return
an &ERANGE;, whatever seems more appropriate. However,
<constant>VIDIOC_S_CTRL</constant> is a write-only ioctl, it does not
-return the actual new value.</para>
+return the actual new value. If the <structfield>value</structfield>
+is inappropriate for the control (e.g. if it refers to an unsupported
+menu index of a menu control), then &EINVAL; is returned as well.</para>
<para>These ioctls work only with user controls. For other
control classes the &VIDIOC-G-EXT-CTRLS;, &VIDIOC-S-EXT-CTRLS; or
@@ -99,7 +101,9 @@
<term><errorcode>EINVAL</errorcode></term>
<listitem>
<para>The &v4l2-control; <structfield>id</structfield> is
-invalid.</para>
+invalid or the <structfield>value</structfield> is inappropriate for
+the given control (i.e. if a menu item is selected that is not supported
+by the driver according to &VIDIOC-QUERYMENU;).</para>
</listitem>
</varlistentry>
<varlistentry>
diff --git a/Documentation/DocBook/media/v4l/vidioc-g-dv-preset.xml b/Documentation/DocBook/media/v4l/vidioc-g-dv-preset.xml
deleted file mode 100644
index b9ea376..0000000
--- a/Documentation/DocBook/media/v4l/vidioc-g-dv-preset.xml
+++ /dev/null
@@ -1,113 +0,0 @@
-<refentry id="vidioc-g-dv-preset">
- <refmeta>
- <refentrytitle>ioctl VIDIOC_G_DV_PRESET, VIDIOC_S_DV_PRESET</refentrytitle>
- &manvol;
- </refmeta>
-
- <refnamediv>
- <refname>VIDIOC_G_DV_PRESET</refname>
- <refname>VIDIOC_S_DV_PRESET</refname>
- <refpurpose>Query or select the DV preset of the current input or output</refpurpose>
- </refnamediv>
-
- <refsynopsisdiv>
- <funcsynopsis>
- <funcprototype>
- <funcdef>int <function>ioctl</function></funcdef>
- <paramdef>int <parameter>fd</parameter></paramdef>
- <paramdef>int <parameter>request</parameter></paramdef>
- <paramdef>struct v4l2_dv_preset *<parameter>argp</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
- </refsynopsisdiv>
-
- <refsect1>
- <title>Arguments</title>
-
- <variablelist>
- <varlistentry>
- <term><parameter>fd</parameter></term>
- <listitem>
- <para>&fd;</para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term><parameter>request</parameter></term>
- <listitem>
- <para>VIDIOC_G_DV_PRESET, VIDIOC_S_DV_PRESET</para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term><parameter>argp</parameter></term>
- <listitem>
- <para></para>
- </listitem>
- </varlistentry>
- </variablelist>
- </refsect1>
-
- <refsect1>
- <title>Description</title>
-
- <para>These ioctls are <emphasis role="bold">deprecated</emphasis>.
- New drivers and applications should use &VIDIOC-G-DV-TIMINGS; and &VIDIOC-S-DV-TIMINGS;
- instead.
- </para>
-
- <para>To query and select the current DV preset, applications
-use the <constant>VIDIOC_G_DV_PRESET</constant> and <constant>VIDIOC_S_DV_PRESET</constant>
-ioctls which take a pointer to a &v4l2-dv-preset; type as argument.
-Applications must zero the reserved array in &v4l2-dv-preset;.
-<constant>VIDIOC_G_DV_PRESET</constant> returns a dv preset in the field
-<structfield>preset</structfield> of &v4l2-dv-preset;.</para>
-
- <para><constant>VIDIOC_S_DV_PRESET</constant> accepts a pointer to a &v4l2-dv-preset;
-that has the preset value to be set. Applications must zero the reserved array in &v4l2-dv-preset;.
-If the preset is not supported, it returns an &EINVAL; </para>
- </refsect1>
-
- <refsect1>
- &return-value;
-
- <variablelist>
- <varlistentry>
- <term><errorcode>EINVAL</errorcode></term>
- <listitem>
- <para>This ioctl is not supported, or the
-<constant>VIDIOC_S_DV_PRESET</constant>,<constant>VIDIOC_S_DV_PRESET</constant> parameter was unsuitable.</para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term><errorcode>ENODATA</errorcode></term>
- <listitem>
- <para>Digital video presets are not supported for this input or output.</para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term><errorcode>EBUSY</errorcode></term>
- <listitem>
- <para>The device is busy and therefore can not change the preset.</para>
- </listitem>
- </varlistentry>
- </variablelist>
-
- <table pgwide="1" frame="none" id="v4l2-dv-preset">
- <title>struct <structname>v4l2_dv_preset</structname></title>
- <tgroup cols="3">
- &cs-str;
- <tbody valign="top">
- <row>
- <entry>__u32</entry>
- <entry><structfield>preset</structfield></entry>
- <entry>Preset value to represent the digital video timings</entry>
- </row>
- <row>
- <entry>__u32</entry>
- <entry><structfield>reserved[4]</structfield></entry>
- <entry>Reserved fields for future use</entry>
- </row>
- </tbody>
- </tgroup>
- </table>
- </refsect1>
-</refentry>
diff --git a/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml b/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml
index 0a4b90f..b3bb957 100644
--- a/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml
@@ -106,7 +106,9 @@
&EINVAL;. When the value is out of bounds drivers can choose to take
the closest valid value or return an &ERANGE;, whatever seems more
appropriate. In the first case the new value is set in
-&v4l2-ext-control;.</para>
+&v4l2-ext-control;. If the new control value is inappropriate (e.g. the
+given menu index is not supported by the menu control), then this will
+also result in an &EINVAL; error.</para>
<para>The driver will only set/get these controls if all control
values are correct. This prevents the situation where only some of the
@@ -199,13 +201,46 @@
<row>
<entry>__u32</entry>
<entry><structfield>error_idx</structfield></entry>
- <entry>Set by the driver in case of an error. If it is equal
-to <structfield>count</structfield>, then no actual changes were made to
-controls. In other words, the error was not associated with setting a particular
-control. If it is another value, then only the controls up to <structfield>error_idx-1</structfield>
-were modified and control <structfield>error_idx</structfield> is the one that
-caused the error. The <structfield>error_idx</structfield> value is undefined
-if the ioctl returned 0 (success).</entry>
+ <entry><para>Set by the driver in case of an error. If the error is
+associated with a particular control, then <structfield>error_idx</structfield>
+is set to the index of that control. If the error is not related to a specific
+control, or the validation step failed (see below), then
+<structfield>error_idx</structfield> is set to <structfield>count</structfield>.
+The value is undefined if the ioctl returned 0 (success).</para>
+
+<para>Before controls are read from/written to hardware a validation step
+takes place: this checks if all controls in the list are valid controls,
+if no attempt is made to write to a read-only control or read from a write-only
+control, and any other up-front checks that can be done without accessing the
+hardware. The exact validations done during this step are driver dependent
+since some checks might require hardware access for some devices, thus making
+it impossible to do those checks up-front. However, drivers should make a
+best-effort to do as many up-front checks as possible.</para>
+
+<para>This check is done to avoid leaving the hardware in an inconsistent state due
+to easy-to-avoid problems. But it leads to another problem: the application needs to
+know whether an error came from the validation step (meaning that the hardware
+was not touched) or from an error during the actual reading from/writing to hardware.</para>
+
+<para>The, in hindsight quite poor, solution for that is to set <structfield>error_idx</structfield>
+to <structfield>count</structfield> if the validation failed. This has the
+unfortunate side-effect that it is not possible to see which control failed the
+validation. If the validation was successful and the error happened while
+accessing the hardware, then <structfield>error_idx</structfield> is less than
+<structfield>count</structfield> and only the controls up to
+<structfield>error_idx-1</structfield> were read or written correctly, and the
+state of the remaining controls is undefined.</para>
+
+<para>Since <constant>VIDIOC_TRY_EXT_CTRLS</constant> does not access hardware
+there is also no need to handle the validation step in this special way,
+so <structfield>error_idx</structfield> will just be set to the control that
+failed the validation step instead of to <structfield>count</structfield>.
+This means that if <constant>VIDIOC_S_EXT_CTRLS</constant> fails with
+<structfield>error_idx</structfield> set to <structfield>count</structfield>,
+then you can call <constant>VIDIOC_TRY_EXT_CTRLS</constant> to try to discover
+the actual control that failed the validation step. Unfortunately, there
+is no <constant>TRY</constant> equivalent for <constant>VIDIOC_G_EXT_CTRLS</constant>.
+</para></entry>
</row>
<row>
<entry>__u32</entry>
@@ -284,6 +319,15 @@
processing controls. These controls are described in <xref
linkend="image-process-controls" />.</entry>
</row>
+
+ <row>
+ <entry><constant>V4L2_CTRL_CLASS_FM_RX</constant></entry>
+ <entry>0xa10000</entry>
+ <entry>The class containing FM Receiver (FM RX) controls.
+These controls are described in <xref
+ linkend="fm-rx-controls" />.</entry>
+ </row>
+
</tbody>
</tgroup>
</table>
@@ -298,8 +342,10 @@
<term><errorcode>EINVAL</errorcode></term>
<listitem>
<para>The &v4l2-ext-control; <structfield>id</structfield>
-is invalid or the &v4l2-ext-controls;
-<structfield>ctrl_class</structfield> is invalid. This error code is
+is invalid, the &v4l2-ext-controls;
+<structfield>ctrl_class</structfield> is invalid, or the &v4l2-ext-control;
+<structfield>value</structfield> was inappropriate (e.g. the given menu
+index is not supported by the driver). This error code is
also returned by the <constant>VIDIOC_S_EXT_CTRLS</constant> and
<constant>VIDIOC_TRY_EXT_CTRLS</constant> ioctls if two or more
control values are in conflict.</para>
diff --git a/Documentation/DocBook/media/v4l/vidioc-query-dv-preset.xml b/Documentation/DocBook/media/v4l/vidioc-query-dv-preset.xml
deleted file mode 100644
index 68b49d0..0000000
--- a/Documentation/DocBook/media/v4l/vidioc-query-dv-preset.xml
+++ /dev/null
@@ -1,78 +0,0 @@
-<refentry id="vidioc-query-dv-preset">
- <refmeta>
- <refentrytitle>ioctl VIDIOC_QUERY_DV_PRESET</refentrytitle>
- &manvol;
- </refmeta>
-
- <refnamediv>
- <refname>VIDIOC_QUERY_DV_PRESET</refname>
- <refpurpose>Sense the DV preset received by the current
-input</refpurpose>
- </refnamediv>
-
- <refsynopsisdiv>
- <funcsynopsis>
- <funcprototype>
- <funcdef>int <function>ioctl</function></funcdef>
- <paramdef>int <parameter>fd</parameter></paramdef>
- <paramdef>int <parameter>request</parameter></paramdef>
- <paramdef>struct v4l2_dv_preset *<parameter>argp</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
- </refsynopsisdiv>
-
- <refsect1>
- <title>Arguments</title>
-
- <variablelist>
- <varlistentry>
- <term><parameter>fd</parameter></term>
- <listitem>
- <para>&fd;</para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term><parameter>request</parameter></term>
- <listitem>
- <para>VIDIOC_QUERY_DV_PRESET</para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term><parameter>argp</parameter></term>
- <listitem>
- <para></para>
- </listitem>
- </varlistentry>
- </variablelist>
- </refsect1>
-
- <refsect1>
- <title>Description</title>
-
- <para>This ioctl is <emphasis role="bold">deprecated</emphasis>.
- New drivers and applications should use &VIDIOC-QUERY-DV-TIMINGS; instead.
- </para>
-
- <para>The hardware may be able to detect the current DV preset
-automatically, similar to sensing the video standard. To do so, applications
-call <constant> VIDIOC_QUERY_DV_PRESET</constant> with a pointer to a
-&v4l2-dv-preset; type. Once the hardware detects a preset, that preset is
-returned in the preset field of &v4l2-dv-preset;. If the preset could not be
-detected because there was no signal, or the signal was unreliable, or the
-signal did not map to a supported preset, then the value V4L2_DV_INVALID is
-returned.</para>
- </refsect1>
-
- <refsect1>
- &return-value;
-
- <variablelist>
- <varlistentry>
- <term><errorcode>ENODATA</errorcode></term>
- <listitem>
- <para>Digital video presets are not supported for this input or output.</para>
- </listitem>
- </varlistentry>
- </variablelist>
- </refsect1>
-</refentry>
diff --git a/Documentation/DocBook/media/v4l/vidioc-querycap.xml b/Documentation/DocBook/media/v4l/vidioc-querycap.xml
index 4c70215..d5a3c97 100644
--- a/Documentation/DocBook/media/v4l/vidioc-querycap.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-querycap.xml
@@ -76,7 +76,7 @@
<row>
<entry>__u8</entry>
<entry><structfield>card</structfield>[32]</entry>
- <entry>Name of the device, a NUL-terminated ASCII string.
+ <entry>Name of the device, a NUL-terminated UTF-8 string.
For example: "Yoyodyne TV/FM". One driver may support different brands
or models of video hardware. This information is intended for users,
for example in a menu of available devices. Since multiple TV cards of
diff --git a/Documentation/DocBook/media/v4l/vidioc-querystd.xml b/Documentation/DocBook/media/v4l/vidioc-querystd.xml
index fe80a18..2223485 100644
--- a/Documentation/DocBook/media/v4l/vidioc-querystd.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-querystd.xml
@@ -54,7 +54,8 @@
VIDIOC_QUERYSTD</constant> with a pointer to a &v4l2-std-id; type. The
driver stores here a set of candidates, this can be a single flag or a
set of supported standards if for example the hardware can only
-distinguish between 50 and 60 Hz systems. When detection is not
+distinguish between 50 and 60 Hz systems. If no signal was detected,
+then the driver will return V4L2_STD_UNKNOWN. When detection is not
possible or fails, the set must contain all standards supported by the
current video input or output.</para>
diff --git a/Documentation/DocBook/media_api.tmpl b/Documentation/DocBook/media_api.tmpl
index f2413ac..6a8b715 100644
--- a/Documentation/DocBook/media_api.tmpl
+++ b/Documentation/DocBook/media_api.tmpl
@@ -22,6 +22,8 @@
<!-- LinuxTV v4l-dvb repository. -->
<!ENTITY v4l-dvb "<ulink url='http://linuxtv.org/repo/'>http://linuxtv.org/repo/</ulink>">
+<!ENTITY dash-ent-10 "<entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry>">
+<!ENTITY dash-ent-16 "<entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry>">
]>
<book id="media_api">
diff --git a/Documentation/DocBook/uio-howto.tmpl b/Documentation/DocBook/uio-howto.tmpl
index ddb05e9..9561815 100644
--- a/Documentation/DocBook/uio-howto.tmpl
+++ b/Documentation/DocBook/uio-howto.tmpl
@@ -984,7 +984,7 @@
return errno;
}
configfd = open("/sys/class/uio/uio0/device/config", O_RDWR);
- if (uiofd < 0) {
+ if (configfd < 0) {
perror("config open:");
return errno;
}
diff --git a/Documentation/DocBook/writing-an-alsa-driver.tmpl b/Documentation/DocBook/writing-an-alsa-driver.tmpl
index fb32aea..06741e9 100644
--- a/Documentation/DocBook/writing-an-alsa-driver.tmpl
+++ b/Documentation/DocBook/writing-an-alsa-driver.tmpl
@@ -871,9 +871,8 @@
<para>
This function itself doesn't allocate the data space. The data
must be allocated manually beforehand, and its pointer is passed
- as the argument. This pointer is used as the
- (<parameter>chip</parameter> identifier in the above example)
- for the instance.
+ as the argument. This pointer (<parameter>chip</parameter> in the
+ above example) is used as the identifier for the instance.
</para>
<para>
@@ -2304,7 +2303,7 @@
<constant>SNDRV_PCM_INFO_XXX</constant>. Here, at least, you
have to specify whether the mmap is supported and which
interleaved format is supported.
- When the is supported, add the
+ When the hardware supports mmap, add the
<constant>SNDRV_PCM_INFO_MMAP</constant> flag here. When the
hardware supports the interleaved or the non-interleaved
formats, <constant>SNDRV_PCM_INFO_INTERLEAVED</constant> or
@@ -2898,7 +2897,7 @@
<para>
When the pcm supports the pause operation (given in the info
- field of the hardware table), the <constant>PAUSE_PUSE</constant>
+ field of the hardware table), the <constant>PAUSE_PUSH</constant>
and <constant>PAUSE_RELEASE</constant> commands must be
handled here, too. The former is the command to pause the pcm,
and the latter to restart the pcm again.
@@ -3085,7 +3084,7 @@
<section id="pcm-interface-interrupt-handler-timer">
<title>High frequency timer interrupts</title>
<para>
- This happense when the hardware doesn't generate interrupts
+ This happens when the hardware doesn't generate interrupts
at the period boundary but issues timer interrupts at a fixed
timer rate (e.g. es1968 or ymfpci drivers).
In this case, you need to check the current hardware
@@ -3251,49 +3250,6 @@
<title>Example of Hardware Constraints for Channels</title>
<programlisting>
<![CDATA[
- static int hw_rule_format_by_channels(struct snd_pcm_hw_params *params,
- struct snd_pcm_hw_rule *rule)
- {
- struct snd_interval *c = hw_param_interval(params,
- SNDRV_PCM_HW_PARAM_CHANNELS);
- struct snd_mask *f = hw_param_mask(params, SNDRV_PCM_HW_PARAM_FORMAT);
- struct snd_mask fmt;
-
- snd_mask_any(&fmt); /* Init the struct */
- if (c->min < 2) {
- fmt.bits[0] &= SNDRV_PCM_FMTBIT_S16_LE;
- return snd_mask_refine(f, &fmt);
- }
- return 0;
- }
-]]>
- </programlisting>
- </example>
- </para>
-
- <para>
- Then you need to call this function to add your rule:
-
- <informalexample>
- <programlisting>
-<![CDATA[
- snd_pcm_hw_rule_add(substream->runtime, 0, SNDRV_PCM_HW_PARAM_CHANNELS,
- hw_rule_channels_by_format, 0, SNDRV_PCM_HW_PARAM_FORMAT,
- -1);
-]]>
- </programlisting>
- </informalexample>
- </para>
-
- <para>
- The rule function is called when an application sets the number of
- channels. But an application can set the format before the number of
- channels. Thus you also need to define the inverse rule:
-
- <example>
- <title>Example of Hardware Constraints for Channels</title>
- <programlisting>
-<![CDATA[
static int hw_rule_channels_by_format(struct snd_pcm_hw_params *params,
struct snd_pcm_hw_rule *rule)
{
@@ -3314,6 +3270,50 @@
</programlisting>
</example>
</para>
+
+ <para>
+ Then you need to call this function to add your rule:
+
+ <informalexample>
+ <programlisting>
+<![CDATA[
+ snd_pcm_hw_rule_add(substream->runtime, 0, SNDRV_PCM_HW_PARAM_CHANNELS,
+ hw_rule_channels_by_format, NULL,
+ SNDRV_PCM_HW_PARAM_FORMAT, -1);
+]]>
+ </programlisting>
+ </informalexample>
+ </para>
+
+ <para>
+ The rule function is called when an application sets the PCM
+ format, and it refines the number of channels accordingly.
+ But an application may set the number of channels before
+ setting the format. Thus you also need to define the inverse rule:
+
+ <example>
+ <title>Example of Hardware Constraints for Formats</title>
+ <programlisting>
+<![CDATA[
+ static int hw_rule_format_by_channels(struct snd_pcm_hw_params *params,
+ struct snd_pcm_hw_rule *rule)
+ {
+ struct snd_interval *c = hw_param_interval(params,
+ SNDRV_PCM_HW_PARAM_CHANNELS);
+ struct snd_mask *f = hw_param_mask(params, SNDRV_PCM_HW_PARAM_FORMAT);
+ struct snd_mask fmt;
+
+ snd_mask_any(&fmt); /* Init the struct */
+ if (c->min < 2) {
+ fmt.bits[0] &= SNDRV_PCM_FMTBIT_S16_LE;
+ return snd_mask_refine(f, &fmt);
+ }
+ return 0;
+ }
+]]>
+ </programlisting>
+ </example>
+ </para>
<para>
...and in the open callback:
@@ -3321,8 +3321,8 @@
<programlisting>
<![CDATA[
snd_pcm_hw_rule_add(substream->runtime, 0, SNDRV_PCM_HW_PARAM_FORMAT,
- hw_rule_format_by_channels, 0, SNDRV_PCM_HW_PARAM_CHANNELS,
- -1);
+ hw_rule_format_by_channels, NULL,
+ SNDRV_PCM_HW_PARAM_CHANNELS, -1);
]]>
</programlisting>
</informalexample>
@@ -6164,14 +6164,12 @@
<para>
The macro takes an conditional expression to evaluate.
- When <constant>CONFIG_SND_DEBUG</constant>, is set, the
- expression is actually evaluated. If it's non-zero, it shows
- the warning message such as
+ When <constant>CONFIG_SND_DEBUG</constant>, is set, if the
+ expression is non-zero, it shows the warning message such as
<computeroutput>BUG? (xxx)</computeroutput>
- normally followed by stack trace. It returns the evaluated
- value.
- When no <constant>CONFIG_SND_DEBUG</constant> is set, this
- macro always returns zero.
+ normally followed by stack trace.
+
+ In both cases it returns the evaluated value.
</para>
</section>
diff --git a/Documentation/DocBook/writing_usb_driver.tmpl b/Documentation/DocBook/writing_usb_driver.tmpl
index bd97a13..3210dcf 100644
--- a/Documentation/DocBook/writing_usb_driver.tmpl
+++ b/Documentation/DocBook/writing_usb_driver.tmpl
@@ -83,7 +83,7 @@
</para>
<para>
Because each different protocol causes a new driver to be created, I have
- written a generic USB driver skeleton, modeled after the pci-skeleton.c
+ written a generic USB driver skeleton, modelled after the pci-skeleton.c
file in the kernel source tree upon which many PCI network drivers have
been based. This USB skeleton can be found at drivers/usb/usb-skeleton.c
in the kernel source tree. In this article I will walk through the basics
diff --git a/Documentation/EDID/1600x1200.S b/Documentation/EDID/1600x1200.S
new file mode 100644
index 0000000..0ded64c
--- /dev/null
+++ b/Documentation/EDID/1600x1200.S
@@ -0,0 +1,44 @@
+/*
+ 1600x1200.S: EDID data set for standard 1600x1200 60 Hz monitor
+
+ Copyright (C) 2013 Carsten Emde <C.Emde@osadl.org>
+
+ This program is free software; you can redistribute it and/or
+ modify it under the terms of the GNU General Public License
+ as published by the Free Software Foundation; either version 2
+ of the License, or (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program; if not, write to the Free Software
+ Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
+*/
+
+/* EDID */
+#define VERSION 1
+#define REVISION 3
+
+/* Display */
+#define CLOCK 162000 /* kHz */
+#define XPIX 1600
+#define YPIX 1200
+#define XY_RATIO XY_RATIO_4_3
+#define XBLANK 560
+#define YBLANK 50
+#define XOFFSET 64
+#define XPULSE 192
+#define YOFFSET (63+1)
+#define YPULSE (63+3)
+#define DPI 72
+#define VFREQ 60 /* Hz */
+#define TIMING_NAME "Linux UXGA"
+#define ESTABLISHED_TIMINGS_BITS 0x00 /* none */
+#define HSYNC_POL 1
+#define VSYNC_POL 1
+#define CRC 0x9d
+
+#include "edid.S"
diff --git a/Documentation/EDID/HOWTO.txt b/Documentation/EDID/HOWTO.txt
index 75a9f2a..7146db1 100644
--- a/Documentation/EDID/HOWTO.txt
+++ b/Documentation/EDID/HOWTO.txt
@@ -18,21 +18,40 @@
individually prepared or corrected EDID data set in the /lib/firmware
directory from where it is loaded via the firmware interface. The code
(see drivers/gpu/drm/drm_edid_load.c) contains built-in data sets for
-commonly used screen resolutions (1024x768, 1280x1024, 1680x1050,
-1920x1080) as binary blobs, but the kernel source tree does not contain
-code to create these data. In order to elucidate the origin of the
-built-in binary EDID blobs and to facilitate the creation of individual
-data for a specific misbehaving monitor, commented sources and a
-Makefile environment are given here.
+commonly used screen resolutions (1024x768, 1280x1024, 1600x1200,
+1680x1050, 1920x1080) as binary blobs, but the kernel source tree does
+not contain code to create these data. In order to elucidate the origin
+of the built-in binary EDID blobs and to facilitate the creation of
+individual data for a specific misbehaving monitor, commented sources
+and a Makefile environment are given here.
To create binary EDID and C source code files from the existing data
material, simply type "make".
-If you want to create your own EDID file, copy the file 1024x768.S and
-replace the settings with your own data. The CRC value in the last line
+If you want to create your own EDID file, copy the file 1024x768.S,
+replace the settings with your own data and add a new target to the
+Makefile. Please note that the EDID data structure expects the timing
+values in a different way as compared to the standard X11 format.
+
+X11:
+HTimings: hdisp hsyncstart hsyncend htotal
+VTimings: vdisp vsyncstart vsyncend vtotal
+
+EDID:
+#define XPIX hdisp
+#define XBLANK htotal-hdisp
+#define XOFFSET hsyncstart-hdisp
+#define XPULSE hsyncend-hsyncstart
+
+#define YPIX vdisp
+#define YBLANK vtotal-vdisp
+#define YOFFSET (63+(vsyncstart-vdisp))
+#define YPULSE (63+(vsyncend-vsyncstart))
+
+The CRC value in the last line
#define CRC 0x55
-is a bit tricky. After a first version of the binary data set is
-created, it must be be checked with the "edid-decode" utility which will
+also is a bit tricky. After a first version of the binary data set is
+created, it must be checked with the "edid-decode" utility which will
most probably complain about a wrong CRC. Fortunately, the utility also
displays the correct CRC which must then be inserted into the source
file. After the make procedure is repeated, the EDID data set is ready
diff --git a/Documentation/HOWTO b/Documentation/HOWTO
index a9f288f..27faae3 100644
--- a/Documentation/HOWTO
+++ b/Documentation/HOWTO
@@ -112,7 +112,7 @@
Other excellent descriptions of how to create patches properly are:
"The Perfect Patch"
- http://userweb.kernel.org/~akpm/stuff/tpp.txt
+ http://kerneltrap.org/node/3737
"Linux kernel patch submission format"
http://linux.yyz.us/patch-format.html
diff --git a/Documentation/IPMI.txt b/Documentation/IPMI.txt
index 16eb4c9..f13c913 100644
--- a/Documentation/IPMI.txt
+++ b/Documentation/IPMI.txt
@@ -348,34 +348,40 @@
modprobe ipmi_si.o type=<type1>,<type2>....
ports=<port1>,<port2>... addrs=<addr1>,<addr2>...
- irqs=<irq1>,<irq2>... trydefaults=[0|1]
+ irqs=<irq1>,<irq2>...
regspacings=<sp1>,<sp2>,... regsizes=<size1>,<size2>,...
regshifts=<shift1>,<shift2>,...
slave_addrs=<addr1>,<addr2>,...
force_kipmid=<enable1>,<enable2>,...
kipmid_max_busy_us=<ustime1>,<ustime2>,...
unload_when_empty=[0|1]
+ trydefaults=[0|1] trydmi=[0|1] tryacpi=[0|1]
+ tryplatform=[0|1] trypci=[0|1]
-Each of these except si_trydefaults is a list, the first item for the
+Each of these except try... items is a list, the first item for the
first interface, second item for the second interface, etc.
The si_type may be either "kcs", "smic", or "bt". If you leave it blank, it
defaults to "kcs".
-If you specify si_addrs as non-zero for an interface, the driver will
+If you specify addrs as non-zero for an interface, the driver will
use the memory address given as the address of the device. This
overrides si_ports.
-If you specify si_ports as non-zero for an interface, the driver will
+If you specify ports as non-zero for an interface, the driver will
use the I/O port given as the device address.
-If you specify si_irqs as non-zero for an interface, the driver will
+If you specify irqs as non-zero for an interface, the driver will
attempt to use the given interrupt for the device.
-si_trydefaults sets whether the standard IPMI interface at 0xca2 and
+trydefaults sets whether the standard IPMI interface at 0xca2 and
any interfaces specified by ACPE are tried. By default, the driver
tries it, set this value to zero to turn this off.
+The other try... items disable discovery by their corresponding
+names. These are all enabled by default, set them to zero to disable
+them. The tryplatform disables openfirmware.
+
The next three parameters have to do with register layout. The
registers used by the interfaces may not appear at successive
locations and they may not be in 8-bit registers. These parameters
diff --git a/Documentation/PCI/MSI-HOWTO.txt b/Documentation/PCI/MSI-HOWTO.txt
index 53e6fca..a091780 100644
--- a/Documentation/PCI/MSI-HOWTO.txt
+++ b/Documentation/PCI/MSI-HOWTO.txt
@@ -127,15 +127,42 @@
returns as soon as it finds any constraint that doesn't allow the
call to succeed.
-4.2.3 pci_disable_msi
+4.2.3 pci_enable_msi_block_auto
+
+int pci_enable_msi_block_auto(struct pci_dev *dev, unsigned int *count)
+
+This variation on pci_enable_msi() call allows a device driver to request
+the maximum possible number of MSIs. The MSI specification only allows
+interrupts to be allocated in powers of two, up to a maximum of 2^5 (32).
+
+If this function returns a positive number, it indicates that it has
+succeeded and the returned value is the number of allocated interrupts. In
+this case, the function enables MSI on this device and updates dev->irq to
+be the lowest of the new interrupts assigned to it. The other interrupts
+assigned to the device are in the range dev->irq to dev->irq + returned
+value - 1.
+
+If this function returns a negative number, it indicates an error and
+the driver should not attempt to request any more MSI interrupts for
+this device.
+
+If the device driver needs to know the number of interrupts the device
+supports it can pass the pointer count where that number is stored. The
+device driver must decide what action to take if pci_enable_msi_block_auto()
+succeeds, but returns a value less than the number of interrupts supported.
+If the device driver does not need to know the number of interrupts
+supported, it can set the pointer count to NULL.
+
+4.2.4 pci_disable_msi
void pci_disable_msi(struct pci_dev *dev)
This function should be used to undo the effect of pci_enable_msi() or
-pci_enable_msi_block(). Calling it restores dev->irq to the pin-based
-interrupt number and frees the previously allocated message signaled
-interrupt(s). The interrupt may subsequently be assigned to another
-device, so drivers should not cache the value of dev->irq.
+pci_enable_msi_block() or pci_enable_msi_block_auto(). Calling it restores
+dev->irq to the pin-based interrupt number and frees the previously
+allocated message signaled interrupt(s). The interrupt may subsequently be
+assigned to another device, so drivers should not cache the value of
+dev->irq.
Before calling this function, a device driver must always call free_irq()
on any interrupt for which it previously called request_irq().
diff --git a/Documentation/PCI/pci-iov-howto.txt b/Documentation/PCI/pci-iov-howto.txt
index cfaca7e..86551cc 100644
--- a/Documentation/PCI/pci-iov-howto.txt
+++ b/Documentation/PCI/pci-iov-howto.txt
@@ -76,7 +76,7 @@
Following piece of code illustrates the usage of the SR-IOV API.
-static int __devinit dev_probe(struct pci_dev *dev, const struct pci_device_id *id)
+static int dev_probe(struct pci_dev *dev, const struct pci_device_id *id)
{
pci_enable_sriov(dev, NR_VIRTFN);
@@ -85,7 +85,7 @@
return 0;
}
-static void __devexit dev_remove(struct pci_dev *dev)
+static void dev_remove(struct pci_dev *dev)
{
pci_disable_sriov(dev);
@@ -131,7 +131,7 @@
.name = "SR-IOV Physical Function driver",
.id_table = dev_id_table,
.probe = dev_probe,
- .remove = __devexit_p(dev_remove),
+ .remove = dev_remove,
.suspend = dev_suspend,
.resume = dev_resume,
.shutdown = dev_shutdown,
diff --git a/Documentation/PCI/pci.txt b/Documentation/PCI/pci.txt
index aa09e54..bccf602 100644
--- a/Documentation/PCI/pci.txt
+++ b/Documentation/PCI/pci.txt
@@ -183,12 +183,6 @@
initializes.
__exit Exit code. Ignored for non-modular drivers.
-
- __devinit Device initialization code.
- Identical to __init if the kernel is not compiled
- with CONFIG_HOTPLUG, normal function otherwise.
- __devexit The same for __exit.
-
Tips on when/where to use the above attributes:
o The module_init()/module_exit() functions (and all
initialization functions called _only_ from these)
@@ -196,20 +190,6 @@
o Do not mark the struct pci_driver.
- o The ID table array should be marked __devinitconst; this is done
- automatically if the table is declared with DEFINE_PCI_DEVICE_TABLE().
-
- o The probe() and remove() functions should be marked __devinit
- and __devexit respectively. All initialization functions
- exclusively called by the probe() routine, can be marked __devinit.
- Ditto for remove() and __devexit.
-
- o If mydriver_remove() is marked with __devexit(), then all address
- references to mydriver_remove must use __devexit_p(mydriver_remove)
- (in the struct pci_driver declaration for example).
- __devexit_p() will generate the function name _or_ NULL if the
- function will be discarded. For an example, see drivers/net/tg3.c.
-
o Do NOT mark a function if you are not sure which mark to use.
Better to not mark the function than mark the function wrong.
diff --git a/Documentation/RCU/checklist.txt b/Documentation/RCU/checklist.txt
index 31ef8fe..7703ec7 100644
--- a/Documentation/RCU/checklist.txt
+++ b/Documentation/RCU/checklist.txt
@@ -217,9 +217,14 @@
whether the increased speed is worth it.
8. Although synchronize_rcu() is slower than is call_rcu(), it
- usually results in simpler code. So, unless update performance
- is critically important or the updaters cannot block,
- synchronize_rcu() should be used in preference to call_rcu().
+ usually results in simpler code. So, unless update performance is
+ critically important, the updaters cannot block, or the latency of
+ synchronize_rcu() is visible from userspace, synchronize_rcu()
+ should be used in preference to call_rcu(). Furthermore,
+ kfree_rcu() usually results in even simpler code than does
+ synchronize_rcu() without synchronize_rcu()'s multi-millisecond
+ latency. So please take advantage of kfree_rcu()'s "fire and
+ forget" memory-freeing capabilities where it applies.
An especially important property of the synchronize_rcu()
primitive is that it automatically self-limits: if grace periods
@@ -268,7 +273,8 @@
e. Periodically invoke synchronize_rcu(), permitting a limited
number of updates per grace period.
- The same cautions apply to call_rcu_bh() and call_rcu_sched().
+ The same cautions apply to call_rcu_bh(), call_rcu_sched(),
+ call_srcu(), and kfree_rcu().
9. All RCU list-traversal primitives, which include
rcu_dereference(), list_for_each_entry_rcu(), and
@@ -296,9 +302,9 @@
all currently executing rcu_read_lock()-protected RCU read-side
critical sections complete. It does -not- necessarily guarantee
that all currently running interrupts, NMIs, preempt_disable()
- code, or idle loops will complete. Therefore, if you do not have
- rcu_read_lock()-protected read-side critical sections, do -not-
- use synchronize_rcu().
+ code, or idle loops will complete. Therefore, if your
+ read-side critical sections are protected by something other
+ than rcu_read_lock(), do -not- use synchronize_rcu().
Similarly, disabling preemption is not an acceptable substitute
for rcu_read_lock(). Code that attempts to use preemption
@@ -348,12 +354,6 @@
using RCU rather than SRCU, because RCU is almost always faster
and easier to use than is SRCU.
- If you need to enter your read-side critical section in a
- hardirq or exception handler, and then exit that same read-side
- critical section in the task that was interrupted, then you need
- to srcu_read_lock_raw() and srcu_read_unlock_raw(), which avoid
- the lockdep checking that would otherwise this practice illegal.
-
Also unlike other forms of RCU, explicit initialization
and cleanup is required via init_srcu_struct() and
cleanup_srcu_struct(). These are passed a "struct srcu_struct"
@@ -401,9 +401,9 @@
read-side critical sections. It is the responsibility of the
RCU update-side primitives to deal with this.
-17. Use CONFIG_PROVE_RCU, CONFIG_DEBUG_OBJECTS_RCU_HEAD, and
- the __rcu sparse checks to validate your RCU code. These
- can help find problems as follows:
+17. Use CONFIG_PROVE_RCU, CONFIG_DEBUG_OBJECTS_RCU_HEAD, and the
+ __rcu sparse checks (enabled by CONFIG_SPARSE_RCU_POINTER) to
+ validate your RCU code. These can help find problems as follows:
CONFIG_PROVE_RCU: check that accesses to RCU-protected data
structures are carried out under the proper RCU
diff --git a/Documentation/RCU/lockdep.txt b/Documentation/RCU/lockdep.txt
index a102d4b..cd83d23 100644
--- a/Documentation/RCU/lockdep.txt
+++ b/Documentation/RCU/lockdep.txt
@@ -64,6 +64,11 @@
but retain the compiler constraints that prevent duplicating
or coalescsing. This is useful when when testing the
value of the pointer itself, for example, against NULL.
+ rcu_access_index(idx):
+ Return the value of the index and omit all barriers, but
+ retain the compiler constraints that prevent duplicating
+ or coalescsing. This is useful when when testing the
+ value of the index itself, for example, against -1.
The rcu_dereference_check() check expression can be any boolean
expression, but would normally include a lockdep expression. However,
diff --git a/Documentation/RCU/rcubarrier.txt b/Documentation/RCU/rcubarrier.txt
index 38428c1..2e319d1 100644
--- a/Documentation/RCU/rcubarrier.txt
+++ b/Documentation/RCU/rcubarrier.txt
@@ -79,7 +79,20 @@
2. Execute rcu_barrier().
3. Allow the module to be unloaded.
-The rcutorture module makes use of rcu_barrier in its exit function
+There are also rcu_barrier_bh(), rcu_barrier_sched(), and srcu_barrier()
+functions for the other flavors of RCU, and you of course must match
+the flavor of rcu_barrier() with that of call_rcu(). If your module
+uses multiple flavors of call_rcu(), then it must also use multiple
+flavors of rcu_barrier() when unloading that module. For example, if
+it uses call_rcu_bh(), call_srcu() on srcu_struct_1, and call_srcu() on
+srcu_struct_2(), then the following three lines of code will be required
+when unloading:
+
+ 1 rcu_barrier_bh();
+ 2 srcu_barrier(&srcu_struct_1);
+ 3 srcu_barrier(&srcu_struct_2);
+
+The rcutorture module makes use of rcu_barrier() in its exit function
as follows:
1 static void
diff --git a/Documentation/RCU/stallwarn.txt b/Documentation/RCU/stallwarn.txt
index 1927151..8e9359d 100644
--- a/Documentation/RCU/stallwarn.txt
+++ b/Documentation/RCU/stallwarn.txt
@@ -92,14 +92,14 @@
more information is printed with the stall-warning message, for example:
INFO: rcu_preempt detected stall on CPU
- 0: (63959 ticks this GP) idle=241/3fffffffffffffff/0
+ 0: (63959 ticks this GP) idle=241/3fffffffffffffff/0 softirq=82/543
(t=65000 jiffies)
In kernels with CONFIG_RCU_FAST_NO_HZ, even more information is
printed:
INFO: rcu_preempt detected stall on CPU
- 0: (64628 ticks this GP) idle=dd5/3fffffffffffffff/0 drain=0 . timer not pending
+ 0: (64628 ticks this GP) idle=dd5/3fffffffffffffff/0 softirq=82/543 last_accelerate: a345/d342 nonlazy_posted: 25 .D
(t=65000 jiffies)
The "(64628 ticks this GP)" indicates that this CPU has taken more
@@ -116,13 +116,28 @@
be a small positive number if in the idle loop and a very large positive
number (as shown above) otherwise.
-For CONFIG_RCU_FAST_NO_HZ kernels, the "drain=0" indicates that the CPU is
-not in the process of trying to force itself into dyntick-idle state, the
-"." indicates that the CPU has not given up forcing RCU into dyntick-idle
-mode (it would be "H" otherwise), and the "timer not pending" indicates
-that the CPU has not recently forced RCU into dyntick-idle mode (it
-would otherwise indicate the number of microseconds remaining in this
-forced state).
+The "softirq=" portion of the message tracks the number of RCU softirq
+handlers that the stalled CPU has executed. The number before the "/"
+is the number that had executed since boot at the time that this CPU
+last noted the beginning of a grace period, which might be the current
+(stalled) grace period, or it might be some earlier grace period (for
+example, if the CPU might have been in dyntick-idle mode for an extended
+time period. The number after the "/" is the number that have executed
+since boot until the current time. If this latter number stays constant
+across repeated stall-warning messages, it is possible that RCU's softirq
+handlers are no longer able to execute on this CPU. This can happen if
+the stalled CPU is spinning with interrupts are disabled, or, in -rt
+kernels, if a high-priority process is starving RCU's softirq handler.
+
+For CONFIG_RCU_FAST_NO_HZ kernels, the "last_accelerate:" prints the
+low-order 16 bits (in hex) of the jiffies counter when this CPU last
+invoked rcu_try_advance_all_cbs() from rcu_needs_cpu() or last invoked
+rcu_accelerate_cbs() from rcu_prepare_for_idle(). The "nonlazy_posted:"
+prints the number of non-lazy callbacks posted since the last call to
+rcu_needs_cpu(). Finally, an "L" indicates that there are currently
+no non-lazy callbacks ("." is printed otherwise, as shown above) and
+"D" indicates that dyntick-idle processing is enabled ("." is printed
+otherwise, for example, if disabled via the "nohz=" kernel boot parameter).
Multiple Warnings From One Stall
@@ -176,7 +191,7 @@
o A hardware or software issue shuts off the scheduler-clock
interrupt on a CPU that is not in dyntick-idle mode. This
problem really has happened, and seems to be most likely to
- result in RCU CPU stall warnings for CONFIG_NO_HZ=n kernels.
+ result in RCU CPU stall warnings for CONFIG_NO_HZ_COMMON=n kernels.
o A bug in the RCU implementation.
diff --git a/Documentation/RCU/torture.txt b/Documentation/RCU/torture.txt
index 7dce8a1..d8a5023 100644
--- a/Documentation/RCU/torture.txt
+++ b/Documentation/RCU/torture.txt
@@ -182,12 +182,6 @@
"srcu_expedited": srcu_read_lock(), srcu_read_unlock() and
synchronize_srcu_expedited().
- "srcu_raw": srcu_read_lock_raw(), srcu_read_unlock_raw(),
- and call_srcu().
-
- "srcu_raw_sync": srcu_read_lock_raw(), srcu_read_unlock_raw(),
- and synchronize_srcu().
-
"sched": preempt_disable(), preempt_enable(), and
call_rcu_sched().
diff --git a/Documentation/RCU/trace.txt b/Documentation/RCU/trace.txt
index c776968..f3778f8 100644
--- a/Documentation/RCU/trace.txt
+++ b/Documentation/RCU/trace.txt
@@ -530,113 +530,21 @@
reasons, e.g., the grace period ended first.
-CONFIG_TINY_RCU and CONFIG_TINY_PREEMPT_RCU debugfs Files and Formats
+CONFIG_TINY_RCU debugfs Files and Formats
These implementations of RCU provides a single debugfs file under the
top-level directory RCU, namely rcu/rcudata, which displays fields in
-rcu_bh_ctrlblk, rcu_sched_ctrlblk and, for CONFIG_TINY_PREEMPT_RCU,
-rcu_preempt_ctrlblk.
+rcu_bh_ctrlblk and rcu_sched_ctrlblk.
The output of "cat rcu/rcudata" is as follows:
-rcu_preempt: qlen=24 gp=1097669 g197/p197/c197 tasks=...
- ttb=. btg=no ntb=184 neb=0 nnb=183 j=01f7 bt=0274
- normal balk: nt=1097669 gt=0 bt=371 b=0 ny=25073378 nos=0
- exp balk: bt=0 nos=0
rcu_sched: qlen: 0
rcu_bh: qlen: 0
-This is split into rcu_preempt, rcu_sched, and rcu_bh sections, with the
-rcu_preempt section appearing only in CONFIG_TINY_PREEMPT_RCU builds.
-The last three lines of the rcu_preempt section appear only in
-CONFIG_RCU_BOOST kernel builds. The fields are as follows:
+This is split into rcu_sched and rcu_bh sections. The field is as
+follows:
o "qlen" is the number of RCU callbacks currently waiting either
for an RCU grace period or waiting to be invoked. This is the
only field present for rcu_sched and rcu_bh, due to the
short-circuiting of grace period in those two cases.
-
-o "gp" is the number of grace periods that have completed.
-
-o "g197/p197/c197" displays the grace-period state, with the
- "g" number being the number of grace periods that have started
- (mod 256), the "p" number being the number of grace periods
- that the CPU has responded to (also mod 256), and the "c"
- number being the number of grace periods that have completed
- (once again mode 256).
-
- Why have both "gp" and "g"? Because the data flowing into
- "gp" is only present in a CONFIG_RCU_TRACE kernel.
-
-o "tasks" is a set of bits. The first bit is "T" if there are
- currently tasks that have recently blocked within an RCU
- read-side critical section, the second bit is "N" if any of the
- aforementioned tasks are blocking the current RCU grace period,
- and the third bit is "E" if any of the aforementioned tasks are
- blocking the current expedited grace period. Each bit is "."
- if the corresponding condition does not hold.
-
-o "ttb" is a single bit. It is "B" if any of the blocked tasks
- need to be priority boosted and "." otherwise.
-
-o "btg" indicates whether boosting has been carried out during
- the current grace period, with "exp" indicating that boosting
- is in progress for an expedited grace period, "no" indicating
- that boosting has not yet started for a normal grace period,
- "begun" indicating that boosting has bebug for a normal grace
- period, and "done" indicating that boosting has completed for
- a normal grace period.
-
-o "ntb" is the total number of tasks subjected to RCU priority boosting
- periods since boot.
-
-o "neb" is the number of expedited grace periods that have had
- to resort to RCU priority boosting since boot.
-
-o "nnb" is the number of normal grace periods that have had
- to resort to RCU priority boosting since boot.
-
-o "j" is the low-order 16 bits of the jiffies counter in hexadecimal.
-
-o "bt" is the low-order 16 bits of the value that the jiffies counter
- will have at the next time that boosting is scheduled to begin.
-
-o In the line beginning with "normal balk", the fields are as follows:
-
- o "nt" is the number of times that the system balked from
- boosting because there were no blocked tasks to boost.
- Note that the system will balk from boosting even if the
- grace period is overdue when the currently running task
- is looping within an RCU read-side critical section.
- There is no point in boosting in this case, because
- boosting a running task won't make it run any faster.
-
- o "gt" is the number of times that the system balked
- from boosting because, although there were blocked tasks,
- none of them were preventing the current grace period
- from completing.
-
- o "bt" is the number of times that the system balked
- from boosting because boosting was already in progress.
-
- o "b" is the number of times that the system balked from
- boosting because boosting had already completed for
- the grace period in question.
-
- o "ny" is the number of times that the system balked from
- boosting because it was not yet time to start boosting
- the grace period in question.
-
- o "nos" is the number of times that the system balked from
- boosting for inexplicable ("not otherwise specified")
- reasons. This can actually happen due to races involving
- increments of the jiffies counter.
-
-o In the line beginning with "exp balk", the fields are as follows:
-
- o "bt" is the number of times that the system balked from
- boosting because there were no blocked tasks to boost.
-
- o "nos" is the number of times that the system balked from
- boosting for inexplicable ("not otherwise specified")
- reasons.
diff --git a/Documentation/RCU/whatisRCU.txt b/Documentation/RCU/whatisRCU.txt
index 0cc7820..0f0fb7c 100644
--- a/Documentation/RCU/whatisRCU.txt
+++ b/Documentation/RCU/whatisRCU.txt
@@ -265,9 +265,9 @@
rcu_read_lock();
p = rcu_dereference(head.next);
rcu_read_unlock();
- x = p->address;
+ x = p->address; /* BUG!!! */
rcu_read_lock();
- y = p->data;
+ y = p->data; /* BUG!!! */
rcu_read_unlock();
Holding a reference from one RCU read-side critical section
@@ -842,9 +842,7 @@
srcu_read_lock synchronize_srcu srcu_barrier
srcu_read_unlock call_srcu
- srcu_read_lock_raw synchronize_srcu_expedited
- srcu_read_unlock_raw
- srcu_dereference
+ srcu_dereference synchronize_srcu_expedited
SRCU: Initialization/cleanup
init_srcu_struct
@@ -865,38 +863,32 @@
a. Will readers need to block? If so, you need SRCU.
-b. Is it necessary to start a read-side critical section in a
- hardirq handler or exception handler, and then to complete
- this read-side critical section in the task that was
- interrupted? If so, you need SRCU's srcu_read_lock_raw() and
- srcu_read_unlock_raw() primitives.
-
-c. What about the -rt patchset? If readers would need to block
+b. What about the -rt patchset? If readers would need to block
in an non-rt kernel, you need SRCU. If readers would block
in a -rt kernel, but not in a non-rt kernel, SRCU is not
necessary.
-d. Do you need to treat NMI handlers, hardirq handlers,
+c. Do you need to treat NMI handlers, hardirq handlers,
and code segments with preemption disabled (whether
via preempt_disable(), local_irq_save(), local_bh_disable(),
or some other mechanism) as if they were explicit RCU readers?
If so, RCU-sched is the only choice that will work for you.
-e. Do you need RCU grace periods to complete even in the face
+d. Do you need RCU grace periods to complete even in the face
of softirq monopolization of one or more of the CPUs? For
example, is your code subject to network-based denial-of-service
attacks? If so, you need RCU-bh.
-f. Is your workload too update-intensive for normal use of
+e. Is your workload too update-intensive for normal use of
RCU, but inappropriate for other synchronization mechanisms?
If so, consider SLAB_DESTROY_BY_RCU. But please be careful!
-g. Do you need read-side critical sections that are respected
+f. Do you need read-side critical sections that are respected
even though they are in the middle of the idle loop, during
user-mode execution, or on an offlined CPU? If so, SRCU is the
only choice that will work for you.
-h. Otherwise, use RCU.
+g. Otherwise, use RCU.
Of course, this all assumes that you have determined that RCU is in fact
the right tool for your job.
diff --git a/Documentation/SubmitChecklist b/Documentation/SubmitChecklist
index dc0e332..2b7e32d 100644
--- a/Documentation/SubmitChecklist
+++ b/Documentation/SubmitChecklist
@@ -105,5 +105,5 @@
same time, just various/random combinations of them]:
CONFIG_SMP, CONFIG_SYSFS, CONFIG_PROC_FS, CONFIG_INPUT, CONFIG_PCI,
- CONFIG_BLOCK, CONFIG_PM, CONFIG_HOTPLUG, CONFIG_MAGIC_SYSRQ,
+ CONFIG_BLOCK, CONFIG_PM, CONFIG_MAGIC_SYSRQ,
CONFIG_NET, CONFIG_INET=n (but latter with CONFIG_NET=y)
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index c379a2a..6e97e73 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -60,8 +60,7 @@
"dontdiff" is a list of files which are generated by the kernel during
the build process, and should be ignored in any diff(1)-generated
patch. The "dontdiff" file is included in the kernel tree in
-2.6.12 and later. For earlier kernel versions, you can get it
-from <http://www.xenotime.net/linux/doc/dontdiff>.
+2.6.12 and later.
Make sure your patch does not include any extra files which do not
belong in a patch submission. Make sure to review your patch -after-
@@ -421,7 +420,7 @@
have been included in the discussion
-14) Using Reported-by:, Tested-by: and Reviewed-by:
+14) Using Reported-by:, Tested-by:, Reviewed-by: and Suggested-by:
If this patch fixes a problem reported by somebody else, consider adding a
Reported-by: tag to credit the reporter for their contribution. Please
@@ -469,6 +468,13 @@
understand the subject area and to perform thorough reviews, will normally
increase the likelihood of your patch getting into the kernel.
+A Suggested-by: tag indicates that the patch idea is suggested by the person
+named and ensures credit to the person for the idea. Please note that this
+tag should not be added without the reporter's permission, especially if the
+idea was not posted in a public forum. That said, if we diligently credit our
+idea reporters, they will, hopefully, be inspired to help us again in the
+future.
+
15) The canonical patch format
diff --git a/Documentation/accounting/getdelays.c b/Documentation/accounting/getdelays.c
index f8ebcde..c6a06b7 100644
--- a/Documentation/accounting/getdelays.c
+++ b/Documentation/accounting/getdelays.c
@@ -272,7 +272,7 @@
char *logfile = NULL;
int loop = 0;
int containerset = 0;
- char containerpath[1024];
+ char *containerpath = NULL;
int cfd = 0;
int forking = 0;
sigset_t sigset;
@@ -299,7 +299,7 @@
break;
case 'C':
containerset = 1;
- strncpy(containerpath, optarg, strlen(optarg) + 1);
+ containerpath = optarg;
break;
case 'w':
logfile = strdup(optarg);
diff --git a/Documentation/acpi/apei/einj.txt b/Documentation/acpi/apei/einj.txt
index e20b6da..a58b63d 100644
--- a/Documentation/acpi/apei/einj.txt
+++ b/Documentation/acpi/apei/einj.txt
@@ -47,11 +47,16 @@
- param1
This file is used to set the first error parameter value. Effect of
- parameter depends on error_type specified.
+ parameter depends on error_type specified. For example, if error
+ type is memory related type, the param1 should be a valid physical
+ memory address.
- param2
This file is used to set the second error parameter value. Effect of
- parameter depends on error_type specified.
+ parameter depends on error_type specified. For example, if error
+ type is memory related type, the param2 should be a physical memory
+ address mask. Linux requires page or narrower granularity, say,
+ 0xfffffffffffff000.
- notrigger
The EINJ mechanism is a two step process. First inject the error, then
diff --git a/Documentation/acpi/enumeration.txt b/Documentation/acpi/enumeration.txt
index 4f27785..d9be7a9 100644
--- a/Documentation/acpi/enumeration.txt
+++ b/Documentation/acpi/enumeration.txt
@@ -63,8 +63,85 @@
Currently the kernel is not able to automatically determine from which ACPI
device it should make the corresponding platform device so we need to add
the ACPI device explicitly to acpi_platform_device_ids list defined in
-drivers/acpi/scan.c. This limitation is only for the platform devices, SPI
-and I2C devices are created automatically as described below.
+drivers/acpi/acpi_platform.c. This limitation is only for the platform
+devices, SPI and I2C devices are created automatically as described below.
+
+DMA support
+~~~~~~~~~~~
+DMA controllers enumerated via ACPI should be registered in the system to
+provide generic access to their resources. For example, a driver that would
+like to be accessible to slave devices via generic API call
+dma_request_slave_channel() must register itself at the end of the probe
+function like this:
+
+ err = devm_acpi_dma_controller_register(dev, xlate_func, dw);
+ /* Handle the error if it's not a case of !CONFIG_ACPI */
+
+and implement custom xlate function if needed (usually acpi_dma_simple_xlate()
+is enough) which converts the FixedDMA resource provided by struct
+acpi_dma_spec into the corresponding DMA channel. A piece of code for that case
+could look like:
+
+ #ifdef CONFIG_ACPI
+ struct filter_args {
+ /* Provide necessary information for the filter_func */
+ ...
+ };
+
+ static bool filter_func(struct dma_chan *chan, void *param)
+ {
+ /* Choose the proper channel */
+ ...
+ }
+
+ static struct dma_chan *xlate_func(struct acpi_dma_spec *dma_spec,
+ struct acpi_dma *adma)
+ {
+ dma_cap_mask_t cap;
+ struct filter_args args;
+
+ /* Prepare arguments for filter_func */
+ ...
+ return dma_request_channel(cap, filter_func, &args);
+ }
+ #else
+ static struct dma_chan *xlate_func(struct acpi_dma_spec *dma_spec,
+ struct acpi_dma *adma)
+ {
+ return NULL;
+ }
+ #endif
+
+dma_request_slave_channel() will call xlate_func() for each registered DMA
+controller. In the xlate function the proper channel must be chosen based on
+information in struct acpi_dma_spec and the properties of the controller
+provided by struct acpi_dma.
+
+Clients must call dma_request_slave_channel() with the string parameter that
+corresponds to a specific FixedDMA resource. By default "tx" means the first
+entry of the FixedDMA resource array, "rx" means the second entry. The table
+below shows a layout:
+
+ Device (I2C0)
+ {
+ ...
+ Method (_CRS, 0, NotSerialized)
+ {
+ Name (DBUF, ResourceTemplate ()
+ {
+ FixedDMA (0x0018, 0x0004, Width32bit, _Y48)
+ FixedDMA (0x0019, 0x0005, Width32bit, )
+ })
+ ...
+ }
+ }
+
+So, the FixedDMA with request line 0x0018 is "tx" and next one is "rx" in
+this example.
+
+In robust cases the client unfortunately needs to call
+acpi_dma_request_slave_chan_by_index() directly and therefore choose the
+specific FixedDMA resource by its index.
SPI serial bus support
~~~~~~~~~~~~~~~~~~~~~~
@@ -185,7 +262,7 @@
.acpi_match_table ACPI_PTR(mpu3050_acpi_match),
},
.probe = mpu3050_probe,
- .remove = __devexit_p(mpu3050_remove),
+ .remove = mpu3050_remove,
.id_table = mpu3050_ids,
};
@@ -199,6 +276,8 @@
{
Name (SBUF, ResourceTemplate()
{
+ ...
+ // Used to power on/off the device
GpioIo (Exclusive, PullDefault, 0x0000, 0x0000,
IoRestrictionOutputOnly, "\\_SB.PCI0.GPI0",
0x00, ResourceConsumer,,)
@@ -206,10 +285,20 @@
// Pin List
0x0055
}
+
+ // Interrupt for the device
+ GpioInt (Edge, ActiveHigh, ExclusiveAndWake, PullNone,
+ 0x0000, "\\_SB.PCI0.GPI0", 0x00, ResourceConsumer,,)
+ {
+ // Pin list
+ 0x0058
+ }
+
...
- Return (SBUF)
}
+
+ Return (SBUF)
}
These GPIO numbers are controller relative and path "\\_SB.PCI0.GPI0"
@@ -220,6 +309,24 @@
acpi_get_gpio(path, gpio). This will return the Linux GPIO number or
negative errno if there was no translation found.
+In a simple case of just getting the Linux GPIO number from device
+resources one can use acpi_get_gpio_by_index() helper function. It takes
+pointer to the device and index of the GpioIo/GpioInt descriptor in the
+device resources list. For example:
+
+ int gpio_irq, gpio_power;
+ int ret;
+
+ gpio_irq = acpi_get_gpio_by_index(dev, 1, NULL);
+ if (gpio_irq < 0)
+ /* handle error */
+
+ gpio_power = acpi_get_gpio_by_index(dev, 0, NULL);
+ if (gpio_power < 0)
+ /* handle error */
+
+ /* Now we can use the GPIO numbers */
+
Other GpioIo parameters must be converted first by the driver to be
suitable to the gpiolib before passing them.
diff --git a/Documentation/acpi/namespace.txt b/Documentation/acpi/namespace.txt
new file mode 100644
index 0000000..260f6a36
--- /dev/null
+++ b/Documentation/acpi/namespace.txt
@@ -0,0 +1,395 @@
+ACPI Device Tree - Representation of ACPI Namespace
+
+Copyright (C) 2013, Intel Corporation
+Author: Lv Zheng <lv.zheng@intel.com>
+
+
+Abstract:
+
+The Linux ACPI subsystem converts ACPI namespace objects into a Linux
+device tree under the /sys/devices/LNXSYSTEM:00 and updates it upon
+receiving ACPI hotplug notification events. For each device object in this
+hierarchy there is a corresponding symbolic link in the
+/sys/bus/acpi/devices.
+This document illustrates the structure of the ACPI device tree.
+
+
+Credit:
+
+Thanks for the help from Zhang Rui <rui.zhang@intel.com> and Rafael J.
+Wysocki <rafael.j.wysocki@intel.com>.
+
+
+1. ACPI Definition Blocks
+
+ The ACPI firmware sets up RSDP (Root System Description Pointer) in the
+ system memory address space pointing to the XSDT (Extended System
+ Description Table). The XSDT always points to the FADT (Fixed ACPI
+ Description Table) using its first entry, the data within the FADT
+ includes various fixed-length entries that describe fixed ACPI features
+ of the hardware. The FADT contains a pointer to the DSDT
+ (Differentiated System Descripition Table). The XSDT also contains
+ entries pointing to possibly multiple SSDTs (Secondary System
+ Description Table).
+
+ The DSDT and SSDT data is organized in data structures called definition
+ blocks that contain definitions of various objects, including ACPI
+ control methods, encoded in AML (ACPI Machine Language). The data block
+ of the DSDT along with the contents of SSDTs represents a hierarchical
+ data structure called the ACPI namespace whose topology reflects the
+ structure of the underlying hardware platform.
+
+ The relationships between ACPI System Definition Tables described above
+ are illustrated in the following diagram.
+
+ +---------+ +-------+ +--------+ +------------------------+
+ | RSDP | +->| XSDT | +->| FADT | | +-------------------+ |
+ +---------+ | +-------+ | +--------+ +-|->| DSDT | |
+ | Pointer | | | Entry |-+ | ...... | | | +-------------------+ |
+ +---------+ | +-------+ | X_DSDT |--+ | | Definition Blocks | |
+ | Pointer |-+ | ..... | | ...... | | +-------------------+ |
+ +---------+ +-------+ +--------+ | +-------------------+ |
+ | Entry |------------------|->| SSDT | |
+ +- - - -+ | +-------------------| |
+ | Entry | - - - - - - - -+ | | Definition Blocks | |
+ +- - - -+ | | +-------------------+ |
+ | | +- - - - - - - - - -+ |
+ +-|->| SSDT | |
+ | +-------------------+ |
+ | | Definition Blocks | |
+ | +- - - - - - - - - -+ |
+ +------------------------+
+ |
+ OSPM Loading |
+ \|/
+ +----------------+
+ | ACPI Namespace |
+ +----------------+
+
+ Figure 1. ACPI Definition Blocks
+
+ NOTE: RSDP can also contain a pointer to the RSDT (Root System
+ Description Table). Platforms provide RSDT to enable
+ compatibility with ACPI 1.0 operating systems. The OS is expected
+ to use XSDT, if present.
+
+
+2. Example ACPI Namespace
+
+ All definition blocks are loaded into a single namespace. The namespace
+ is a hierarchy of objects identified by names and paths.
+ The following naming conventions apply to object names in the ACPI
+ namespace:
+ 1. All names are 32 bits long.
+ 2. The first byte of a name must be one of 'A' - 'Z', '_'.
+ 3. Each of the remaining bytes of a name must be one of 'A' - 'Z', '0'
+ - '9', '_'.
+ 4. Names starting with '_' are reserved by the ACPI specification.
+ 5. The '\' symbol represents the root of the namespace (i.e. names
+ prepended with '\' are relative to the namespace root).
+ 6. The '^' symbol represents the parent of the current namespace node
+ (i.e. names prepended with '^' are relative to the parent of the
+ current namespace node).
+
+ The figure below shows an example ACPI namespace.
+
+ +------+
+ | \ | Root
+ +------+
+ |
+ | +------+
+ +-| _PR | Scope(_PR): the processor namespace
+ | +------+
+ | |
+ | | +------+
+ | +-| CPU0 | Processor(CPU0): the first processor
+ | +------+
+ |
+ | +------+
+ +-| _SB | Scope(_SB): the system bus namespace
+ | +------+
+ | |
+ | | +------+
+ | +-| LID0 | Device(LID0); the lid device
+ | | +------+
+ | | |
+ | | | +------+
+ | | +-| _HID | Name(_HID, "PNP0C0D"): the hardware ID
+ | | | +------+
+ | | |
+ | | | +------+
+ | | +-| _STA | Method(_STA): the status control method
+ | | +------+
+ | |
+ | | +------+
+ | +-| PCI0 | Device(PCI0); the PCI root bridge
+ | +------+
+ | |
+ | | +------+
+ | +-| _HID | Name(_HID, "PNP0A08"): the hardware ID
+ | | +------+
+ | |
+ | | +------+
+ | +-| _CID | Name(_CID, "PNP0A03"): the compatible ID
+ | | +------+
+ | |
+ | | +------+
+ | +-| RP03 | Scope(RP03): the PCI0 power scope
+ | | +------+
+ | | |
+ | | | +------+
+ | | +-| PXP3 | PowerResource(PXP3): the PCI0 power resource
+ | | +------+
+ | |
+ | | +------+
+ | +-| GFX0 | Device(GFX0): the graphics adapter
+ | +------+
+ | |
+ | | +------+
+ | +-| _ADR | Name(_ADR, 0x00020000): the PCI bus address
+ | | +------+
+ | |
+ | | +------+
+ | +-| DD01 | Device(DD01): the LCD output device
+ | +------+
+ | |
+ | | +------+
+ | +-| _BCL | Method(_BCL): the backlight control method
+ | +------+
+ |
+ | +------+
+ +-| _TZ | Scope(_TZ): the thermal zone namespace
+ | +------+
+ | |
+ | | +------+
+ | +-| FN00 | PowerResource(FN00): the FAN0 power resource
+ | | +------+
+ | |
+ | | +------+
+ | +-| FAN0 | Device(FAN0): the FAN0 cooling device
+ | | +------+
+ | | |
+ | | | +------+
+ | | +-| _HID | Name(_HID, "PNP0A0B"): the hardware ID
+ | | +------+
+ | |
+ | | +------+
+ | +-| TZ00 | ThermalZone(TZ00); the FAN thermal zone
+ | +------+
+ |
+ | +------+
+ +-| _GPE | Scope(_GPE): the GPE namespace
+ +------+
+
+ Figure 2. Example ACPI Namespace
+
+
+3. Linux ACPI Device Objects
+
+ The Linux kernel's core ACPI subsystem creates struct acpi_device
+ objects for ACPI namespace objects representing devices, power resources
+ processors, thermal zones. Those objects are exported to user space via
+ sysfs as directories in the subtree under /sys/devices/LNXSYSTM:00. The
+ format of their names is <bus_id:instance>, where 'bus_id' refers to the
+ ACPI namespace representation of the given object and 'instance' is used
+ for distinguishing different object of the same 'bus_id' (it is
+ two-digit decimal representation of an unsigned integer).
+
+ The value of 'bus_id' depends on the type of the object whose name it is
+ part of as listed in the table below.
+
+ +---+-----------------+-------+----------+
+ | | Object/Feature | Table | bus_id |
+ +---+-----------------+-------+----------+
+ | N | Root | xSDT | LNXSYSTM |
+ +---+-----------------+-------+----------+
+ | N | Device | xSDT | _HID |
+ +---+-----------------+-------+----------+
+ | N | Processor | xSDT | LNXCPU |
+ +---+-----------------+-------+----------+
+ | N | ThermalZone | xSDT | LNXTHERM |
+ +---+-----------------+-------+----------+
+ | N | PowerResource | xSDT | LNXPOWER |
+ +---+-----------------+-------+----------+
+ | N | Other Devices | xSDT | device |
+ +---+-----------------+-------+----------+
+ | F | PWR_BUTTON | FADT | LNXPWRBN |
+ +---+-----------------+-------+----------+
+ | F | SLP_BUTTON | FADT | LNXSLPBN |
+ +---+-----------------+-------+----------+
+ | M | Video Extension | xSDT | LNXVIDEO |
+ +---+-----------------+-------+----------+
+ | M | ATA Controller | xSDT | LNXIOBAY |
+ +---+-----------------+-------+----------+
+ | M | Docking Station | xSDT | LNXDOCK |
+ +---+-----------------+-------+----------+
+
+ Table 1. ACPI Namespace Objects Mapping
+
+ The following rules apply when creating struct acpi_device objects on
+ the basis of the contents of ACPI System Description Tables (as
+ indicated by the letter in the first column and the notation in the
+ second column of the table above):
+ N:
+ The object's source is an ACPI namespace node (as indicated by the
+ named object's type in the second column). In that case the object's
+ directory in sysfs will contain the 'path' attribute whose value is
+ the full path to the node from the namespace root.
+ struct acpi_device objects are created for the ACPI namespace nodes
+ whose _STA control methods return PRESENT or FUNCTIONING. The power
+ resource nodes or nodes without _STA are assumed to be both PRESENT
+ and FUNCTIONING.
+ F:
+ The struct acpi_device object is created for a fixed hardware
+ feature (as indicated by the fixed feature flag's name in the second
+ column), so its sysfs directory will not contain the 'path'
+ attribute.
+ M:
+ The struct acpi_device object is created for an ACPI namespace node
+ with specific control methods (as indicated by the ACPI defined
+ device's type in the second column). The 'path' attribute containing
+ its namespace path will be present in its sysfs directory. For
+ example, if the _BCL method is present for an ACPI namespace node, a
+ struct acpi_device object with LNXVIDEO 'bus_id' will be created for
+ it.
+
+ The third column of the above table indicates which ACPI System
+ Description Tables contain information used for the creation of the
+ struct acpi_device objects represented by the given row (xSDT means DSDT
+ or SSDT).
+
+ The forth column of the above table indicates the 'bus_id' generation
+ rule of the struct acpi_device object:
+ _HID:
+ _HID in the last column of the table means that the object's bus_id
+ is derived from the _HID/_CID identification objects present under
+ the corresponding ACPI namespace node. The object's sysfs directory
+ will then contain the 'hid' and 'modalias' attributes that can be
+ used to retrieve the _HID and _CIDs of that object.
+ LNXxxxxx:
+ The 'modalias' attribute is also present for struct acpi_device
+ objects having bus_id of the "LNXxxxxx" form (pseudo devices), in
+ which cases it contains the bus_id string itself.
+ device:
+ 'device' in the last column of the table indicates that the object's
+ bus_id cannot be determined from _HID/_CID of the corresponding
+ ACPI namespace node, although that object represents a device (for
+ example, it may be a PCI device with _ADR defined and without _HID
+ or _CID). In that case the string 'device' will be used as the
+ object's bus_id.
+
+
+4. Linux ACPI Physical Device Glue
+
+ ACPI device (i.e. struct acpi_device) objects may be linked to other
+ objects in the Linux' device hierarchy that represent "physical" devices
+ (for example, devices on the PCI bus). If that happens, it means that
+ the ACPI device object is a "companion" of a device otherwise
+ represented in a different way and is used (1) to provide configuration
+ information on that device which cannot be obtained by other means and
+ (2) to do specific things to the device with the help of its ACPI
+ control methods. One ACPI device object may be linked this way to
+ multiple "physical" devices.
+
+ If an ACPI device object is linked to a "physical" device, its sysfs
+ directory contains the "physical_node" symbolic link to the sysfs
+ directory of the target device object. In turn, the target device's
+ sysfs directory will then contain the "firmware_node" symbolic link to
+ the sysfs directory of the companion ACPI device object.
+ The linking mechanism relies on device identification provided by the
+ ACPI namespace. For example, if there's an ACPI namespace object
+ representing a PCI device (i.e. a device object under an ACPI namespace
+ object representing a PCI bridge) whose _ADR returns 0x00020000 and the
+ bus number of the parent PCI bridge is 0, the sysfs directory
+ representing the struct acpi_device object created for that ACPI
+ namespace object will contain the 'physical_node' symbolic link to the
+ /sys/devices/pci0000:00/0000:00:02:0/ sysfs directory of the
+ corresponding PCI device.
+
+ The linking mechanism is generally bus-specific. The core of its
+ implementation is located in the drivers/acpi/glue.c file, but there are
+ complementary parts depending on the bus types in question located
+ elsewhere. For example, the PCI-specific part of it is located in
+ drivers/pci/pci-acpi.c.
+
+
+5. Example Linux ACPI Device Tree
+
+ The sysfs hierarchy of struct acpi_device objects corresponding to the
+ example ACPI namespace illustrated in Figure 2 with the addition of
+ fixed PWR_BUTTON/SLP_BUTTON devices is shown below.
+
+ +--------------+---+-----------------+
+ | LNXSYSTEM:00 | \ | acpi:LNXSYSTEM: |
+ +--------------+---+-----------------+
+ |
+ | +-------------+-----+----------------+
+ +-| LNXPWRBN:00 | N/A | acpi:LNXPWRBN: |
+ | +-------------+-----+----------------+
+ |
+ | +-------------+-----+----------------+
+ +-| LNXSLPBN:00 | N/A | acpi:LNXSLPBN: |
+ | +-------------+-----+----------------+
+ |
+ | +-----------+------------+--------------+
+ +-| LNXCPU:00 | \_PR_.CPU0 | acpi:LNXCPU: |
+ | +-----------+------------+--------------+
+ |
+ | +-------------+-------+----------------+
+ +-| LNXSYBUS:00 | \_SB_ | acpi:LNXSYBUS: |
+ | +-------------+-------+----------------+
+ | |
+ | | +- - - - - - - +- - - - - - +- - - - - - - -+
+ | +-| * PNP0C0D:00 | \_SB_.LID0 | acpi:PNP0C0D: |
+ | | +- - - - - - - +- - - - - - +- - - - - - - -+
+ | |
+ | | +------------+------------+-----------------------+
+ | +-| PNP0A08:00 | \_SB_.PCI0 | acpi:PNP0A08:PNP0A03: |
+ | +------------+------------+-----------------------+
+ | |
+ | | +-----------+-----------------+-----+
+ | +-| device:00 | \_SB_.PCI0.RP03 | N/A |
+ | | +-----------+-----------------+-----+
+ | | |
+ | | | +-------------+----------------------+----------------+
+ | | +-| LNXPOWER:00 | \_SB_.PCI0.RP03.PXP3 | acpi:LNXPOWER: |
+ | | +-------------+----------------------+----------------+
+ | |
+ | | +-------------+-----------------+----------------+
+ | +-| LNXVIDEO:00 | \_SB_.PCI0.GFX0 | acpi:LNXVIDEO: |
+ | +-------------+-----------------+----------------+
+ | |
+ | | +-----------+-----------------+-----+
+ | +-| device:01 | \_SB_.PCI0.DD01 | N/A |
+ | +-----------+-----------------+-----+
+ |
+ | +-------------+-------+----------------+
+ +-| LNXSYBUS:01 | \_TZ_ | acpi:LNXSYBUS: |
+ +-------------+-------+----------------+
+ |
+ | +-------------+------------+----------------+
+ +-| LNXPOWER:0a | \_TZ_.FN00 | acpi:LNXPOWER: |
+ | +-------------+------------+----------------+
+ |
+ | +------------+------------+---------------+
+ +-| PNP0C0B:00 | \_TZ_.FAN0 | acpi:PNP0C0B: |
+ | +------------+------------+---------------+
+ |
+ | +-------------+------------+----------------+
+ +-| LNXTHERM:00 | \_TZ_.TZ00 | acpi:LNXTHERM: |
+ +-------------+------------+----------------+
+
+ Figure 3. Example Linux ACPI Device Tree
+
+ NOTE: Each node is represented as "object/path/modalias", where:
+ 1. 'object' is the name of the object's directory in sysfs.
+ 2. 'path' is the ACPI namespace path of the corresponding
+ ACPI namespace object, as returned by the object's 'path'
+ sysfs attribute.
+ 3. 'modalias' is the value of the object's 'modalias' sysfs
+ attribute (as described earlier in this document).
+ NOTE: N/A indicates the device object does not have the 'path' or the
+ 'modalias' attribute.
+ NOTE: The PNP0C0D device listed above is highlighted (marked by "*")
+ to indicate it will be created only when its _STA methods return
+ PRESENT or FUNCTIONING.
diff --git a/Documentation/acpi/scan_handlers.txt b/Documentation/acpi/scan_handlers.txt
new file mode 100644
index 0000000..3246ccf
--- /dev/null
+++ b/Documentation/acpi/scan_handlers.txt
@@ -0,0 +1,77 @@
+ACPI Scan Handlers
+
+Copyright (C) 2012, Intel Corporation
+Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+
+During system initialization and ACPI-based device hot-add, the ACPI namespace
+is scanned in search of device objects that generally represent various pieces
+of hardware. This causes a struct acpi_device object to be created and
+registered with the driver core for every device object in the ACPI namespace
+and the hierarchy of those struct acpi_device objects reflects the namespace
+layout (i.e. parent device objects in the namespace are represented by parent
+struct acpi_device objects and analogously for their children). Those struct
+acpi_device objects are referred to as "device nodes" in what follows, but they
+should not be confused with struct device_node objects used by the Device Trees
+parsing code (although their role is analogous to the role of those objects).
+
+During ACPI-based device hot-remove device nodes representing pieces of hardware
+being removed are unregistered and deleted.
+
+The core ACPI namespace scanning code in drivers/acpi/scan.c carries out basic
+initialization of device nodes, such as retrieving common configuration
+information from the device objects represented by them and populating them with
+appropriate data, but some of them require additional handling after they have
+been registered. For example, if the given device node represents a PCI host
+bridge, its registration should cause the PCI bus under that bridge to be
+enumerated and PCI devices on that bus to be registered with the driver core.
+Similarly, if the device node represents a PCI interrupt link, it is necessary
+to configure that link so that the kernel can use it.
+
+Those additional configuration tasks usually depend on the type of the hardware
+component represented by the given device node which can be determined on the
+basis of the device node's hardware ID (HID). They are performed by objects
+called ACPI scan handlers represented by the following structure:
+
+struct acpi_scan_handler {
+ const struct acpi_device_id *ids;
+ struct list_head list_node;
+ int (*attach)(struct acpi_device *dev, const struct acpi_device_id *id);
+ void (*detach)(struct acpi_device *dev);
+};
+
+where ids is the list of IDs of device nodes the given handler is supposed to
+take care of, list_node is the hook to the global list of ACPI scan handlers
+maintained by the ACPI core and the .attach() and .detach() callbacks are
+executed, respectively, after registration of new device nodes and before
+unregistration of device nodes the handler attached to previously.
+
+The namespace scanning function, acpi_bus_scan(), first registers all of the
+device nodes in the given namespace scope with the driver core. Then, it tries
+to match a scan handler against each of them using the ids arrays of the
+available scan handlers. If a matching scan handler is found, its .attach()
+callback is executed for the given device node. If that callback returns 1,
+that means that the handler has claimed the device node and is now responsible
+for carrying out any additional configuration tasks related to it. It also will
+be responsible for preparing the device node for unregistration in that case.
+The device node's handler field is then populated with the address of the scan
+handler that has claimed it.
+
+If the .attach() callback returns 0, it means that the device node is not
+interesting to the given scan handler and may be matched against the next scan
+handler in the list. If it returns a (negative) error code, that means that
+the namespace scan should be terminated due to a serious error. The error code
+returned should then reflect the type of the error.
+
+The namespace trimming function, acpi_bus_trim(), first executes .detach()
+callbacks from the scan handlers of all device nodes in the given namespace
+scope (if they have scan handlers). Next, it unregisters all of the device
+nodes in that scope.
+
+ACPI scan handlers can be added to the list maintained by the ACPI core with the
+help of the acpi_scan_add_handler() function taking a pointer to the new scan
+handler as an argument. The order in which scan handlers are added to the list
+is the order in which they are matched against device nodes during namespace
+scans.
+
+All scan handles must be added to the list before acpi_bus_scan() is run for the
+first time and they cannot be removed from it.
diff --git a/Documentation/acpi/video_extension.txt b/Documentation/acpi/video_extension.txt
new file mode 100644
index 0000000..78b32ac
--- /dev/null
+++ b/Documentation/acpi/video_extension.txt
@@ -0,0 +1,106 @@
+ACPI video extensions
+~~~~~~~~~~~~~~~~~~~~~
+
+This driver implement the ACPI Extensions For Display Adapters for
+integrated graphics devices on motherboard, as specified in ACPI 2.0
+Specification, Appendix B, allowing to perform some basic control like
+defining the video POST device, retrieving EDID information or to
+setup a video output, etc. Note that this is an ref. implementation
+only. It may or may not work for your integrated video device.
+
+The ACPI video driver does 3 things regarding backlight control:
+
+1 Export a sysfs interface for user space to control backlight level
+
+If the ACPI table has a video device, and acpi_backlight=vendor kernel
+command line is not present, the driver will register a backlight device
+and set the required backlight operation structure for it for the sysfs
+interface control. For every registered class device, there will be a
+directory named acpi_videoX under /sys/class/backlight.
+
+The backlight sysfs interface has a standard definition here:
+Documentation/ABI/stable/sysfs-class-backlight.
+
+And what ACPI video driver does is:
+actual_brightness: on read, control method _BQC will be evaluated to
+get the brightness level the firmware thinks it is at;
+bl_power: not implemented, will set the current brightness instead;
+brightness: on write, control method _BCM will run to set the requested
+brightness level;
+max_brightness: Derived from the _BCL package(see below);
+type: firmware
+
+Note that ACPI video backlight driver will always use index for
+brightness, actual_brightness and max_brightness. So if we have
+the following _BCL package:
+
+Method (_BCL, 0, NotSerialized)
+{
+ Return (Package (0x0C)
+ {
+ 0x64,
+ 0x32,
+ 0x0A,
+ 0x14,
+ 0x1E,
+ 0x28,
+ 0x32,
+ 0x3C,
+ 0x46,
+ 0x50,
+ 0x5A,
+ 0x64
+ })
+}
+
+The first two levels are for when laptop are on AC or on battery and are
+not used by Linux currently. The remaining 10 levels are supported levels
+that we can choose from. The applicable index values are from 0 (that
+corresponds to the 0x0A brightness value) to 9 (that corresponds to the
+0x64 brightness value) inclusive. Each of those index values is regarded
+as a "brightness level" indicator. Thus from the user space perspective
+the range of available brightness levels is from 0 to 9 (max_brightness)
+inclusive.
+
+2 Notify user space about hotkey event
+
+There are generally two cases for hotkey event reporting:
+i) For some laptops, when user presses the hotkey, a scancode will be
+ generated and sent to user space through the input device created by
+ the keyboard driver as a key type input event, with proper remap, the
+ following key code will appear to user space:
+
+ EV_KEY, KEY_BRIGHTNESSUP
+ EV_KEY, KEY_BRIGHTNESSDOWN
+ etc.
+
+For this case, ACPI video driver does not need to do anything(actually,
+it doesn't even know this happened).
+
+ii) For some laptops, the press of the hotkey will not generate the
+ scancode, instead, firmware will notify the video device ACPI node
+ about the event. The event value is defined in the ACPI spec. ACPI
+ video driver will generate an key type input event according to the
+ notify value it received and send the event to user space through the
+ input device it created:
+
+ event keycode
+ 0x86 KEY_BRIGHTNESSUP
+ 0x87 KEY_BRIGHTNESSDOWN
+ etc.
+
+so this would lead to the same effect as case i) now.
+
+Once user space tool receives this event, it can modify the backlight
+level through the sysfs interface.
+
+3 Change backlight level in the kernel
+
+This works for machines covered by case ii) in Section 2. Once the driver
+received a notification, it will set the backlight level accordingly. This does
+not affect the sending of event to user space, they are always sent to user
+space regardless of whether or not the video module controls the backlight level
+directly. This behaviour can be controlled through the brightness_switch_enabled
+module parameter as documented in kernel-parameters.txt. It is recommended to
+disable this behaviour once a GUI environment starts up and wants to have full
+control of the backlight level.
diff --git a/Documentation/arm/IXP4xx b/Documentation/arm/IXP4xx
index 7b9351f..e48b74d 100644
--- a/Documentation/arm/IXP4xx
+++ b/Documentation/arm/IXP4xx
@@ -36,7 +36,7 @@
- Timers (watchdog, OS)
The following components of the chips are not supported by Linux and
-require the use of Intel's proprietary CSR softare:
+require the use of Intel's proprietary CSR software:
- USB device interface
- Network interfaces (HSS, Utopia, NPEs, etc)
diff --git a/Documentation/arm/cluster-pm-race-avoidance.txt b/Documentation/arm/cluster-pm-race-avoidance.txt
new file mode 100644
index 0000000..750b6fc
--- /dev/null
+++ b/Documentation/arm/cluster-pm-race-avoidance.txt
@@ -0,0 +1,498 @@
+Cluster-wide Power-up/power-down race avoidance algorithm
+=========================================================
+
+This file documents the algorithm which is used to coordinate CPU and
+cluster setup and teardown operations and to manage hardware coherency
+controls safely.
+
+The section "Rationale" explains what the algorithm is for and why it is
+needed. "Basic model" explains general concepts using a simplified view
+of the system. The other sections explain the actual details of the
+algorithm in use.
+
+
+Rationale
+---------
+
+In a system containing multiple CPUs, it is desirable to have the
+ability to turn off individual CPUs when the system is idle, reducing
+power consumption and thermal dissipation.
+
+In a system containing multiple clusters of CPUs, it is also desirable
+to have the ability to turn off entire clusters.
+
+Turning entire clusters off and on is a risky business, because it
+involves performing potentially destructive operations affecting a group
+of independently running CPUs, while the OS continues to run. This
+means that we need some coordination in order to ensure that critical
+cluster-level operations are only performed when it is truly safe to do
+so.
+
+Simple locking may not be sufficient to solve this problem, because
+mechanisms like Linux spinlocks may rely on coherency mechanisms which
+are not immediately enabled when a cluster powers up. Since enabling or
+disabling those mechanisms may itself be a non-atomic operation (such as
+writing some hardware registers and invalidating large caches), other
+methods of coordination are required in order to guarantee safe
+power-down and power-up at the cluster level.
+
+The mechanism presented in this document describes a coherent memory
+based protocol for performing the needed coordination. It aims to be as
+lightweight as possible, while providing the required safety properties.
+
+
+Basic model
+-----------
+
+Each cluster and CPU is assigned a state, as follows:
+
+ DOWN
+ COMING_UP
+ UP
+ GOING_DOWN
+
+ +---------> UP ----------+
+ | v
+
+ COMING_UP GOING_DOWN
+
+ ^ |
+ +--------- DOWN <--------+
+
+
+DOWN: The CPU or cluster is not coherent, and is either powered off or
+ suspended, or is ready to be powered off or suspended.
+
+COMING_UP: The CPU or cluster has committed to moving to the UP state.
+ It may be part way through the process of initialisation and
+ enabling coherency.
+
+UP: The CPU or cluster is active and coherent at the hardware
+ level. A CPU in this state is not necessarily being used
+ actively by the kernel.
+
+GOING_DOWN: The CPU or cluster has committed to moving to the DOWN
+ state. It may be part way through the process of teardown and
+ coherency exit.
+
+
+Each CPU has one of these states assigned to it at any point in time.
+The CPU states are described in the "CPU state" section, below.
+
+Each cluster is also assigned a state, but it is necessary to split the
+state value into two parts (the "cluster" state and "inbound" state) and
+to introduce additional states in order to avoid races between different
+CPUs in the cluster simultaneously modifying the state. The cluster-
+level states are described in the "Cluster state" section.
+
+To help distinguish the CPU states from cluster states in this
+discussion, the state names are given a CPU_ prefix for the CPU states,
+and a CLUSTER_ or INBOUND_ prefix for the cluster states.
+
+
+CPU state
+---------
+
+In this algorithm, each individual core in a multi-core processor is
+referred to as a "CPU". CPUs are assumed to be single-threaded:
+therefore, a CPU can only be doing one thing at a single point in time.
+
+This means that CPUs fit the basic model closely.
+
+The algorithm defines the following states for each CPU in the system:
+
+ CPU_DOWN
+ CPU_COMING_UP
+ CPU_UP
+ CPU_GOING_DOWN
+
+ cluster setup and
+ CPU setup complete policy decision
+ +-----------> CPU_UP ------------+
+ | v
+
+ CPU_COMING_UP CPU_GOING_DOWN
+
+ ^ |
+ +----------- CPU_DOWN <----------+
+ policy decision CPU teardown complete
+ or hardware event
+
+
+The definitions of the four states correspond closely to the states of
+the basic model.
+
+Transitions between states occur as follows.
+
+A trigger event (spontaneous) means that the CPU can transition to the
+next state as a result of making local progress only, with no
+requirement for any external event to happen.
+
+
+CPU_DOWN:
+
+ A CPU reaches the CPU_DOWN state when it is ready for
+ power-down. On reaching this state, the CPU will typically
+ power itself down or suspend itself, via a WFI instruction or a
+ firmware call.
+
+ Next state: CPU_COMING_UP
+ Conditions: none
+
+ Trigger events:
+
+ a) an explicit hardware power-up operation, resulting
+ from a policy decision on another CPU;
+
+ b) a hardware event, such as an interrupt.
+
+
+CPU_COMING_UP:
+
+ A CPU cannot start participating in hardware coherency until the
+ cluster is set up and coherent. If the cluster is not ready,
+ then the CPU will wait in the CPU_COMING_UP state until the
+ cluster has been set up.
+
+ Next state: CPU_UP
+ Conditions: The CPU's parent cluster must be in CLUSTER_UP.
+ Trigger events: Transition of the parent cluster to CLUSTER_UP.
+
+ Refer to the "Cluster state" section for a description of the
+ CLUSTER_UP state.
+
+
+CPU_UP:
+ When a CPU reaches the CPU_UP state, it is safe for the CPU to
+ start participating in local coherency.
+
+ This is done by jumping to the kernel's CPU resume code.
+
+ Note that the definition of this state is slightly different
+ from the basic model definition: CPU_UP does not mean that the
+ CPU is coherent yet, but it does mean that it is safe to resume
+ the kernel. The kernel handles the rest of the resume
+ procedure, so the remaining steps are not visible as part of the
+ race avoidance algorithm.
+
+ The CPU remains in this state until an explicit policy decision
+ is made to shut down or suspend the CPU.
+
+ Next state: CPU_GOING_DOWN
+ Conditions: none
+ Trigger events: explicit policy decision
+
+
+CPU_GOING_DOWN:
+
+ While in this state, the CPU exits coherency, including any
+ operations required to achieve this (such as cleaning data
+ caches).
+
+ Next state: CPU_DOWN
+ Conditions: local CPU teardown complete
+ Trigger events: (spontaneous)
+
+
+Cluster state
+-------------
+
+A cluster is a group of connected CPUs with some common resources.
+Because a cluster contains multiple CPUs, it can be doing multiple
+things at the same time. This has some implications. In particular, a
+CPU can start up while another CPU is tearing the cluster down.
+
+In this discussion, the "outbound side" is the view of the cluster state
+as seen by a CPU tearing the cluster down. The "inbound side" is the
+view of the cluster state as seen by a CPU setting the CPU up.
+
+In order to enable safe coordination in such situations, it is important
+that a CPU which is setting up the cluster can advertise its state
+independently of the CPU which is tearing down the cluster. For this
+reason, the cluster state is split into two parts:
+
+ "cluster" state: The global state of the cluster; or the state
+ on the outbound side:
+
+ CLUSTER_DOWN
+ CLUSTER_UP
+ CLUSTER_GOING_DOWN
+
+ "inbound" state: The state of the cluster on the inbound side.
+
+ INBOUND_NOT_COMING_UP
+ INBOUND_COMING_UP
+
+
+ The different pairings of these states results in six possible
+ states for the cluster as a whole:
+
+ CLUSTER_UP
+ +==========> INBOUND_NOT_COMING_UP -------------+
+ # |
+ |
+ CLUSTER_UP <----+ |
+ INBOUND_COMING_UP | v
+
+ ^ CLUSTER_GOING_DOWN CLUSTER_GOING_DOWN
+ # INBOUND_COMING_UP <=== INBOUND_NOT_COMING_UP
+
+ CLUSTER_DOWN | |
+ INBOUND_COMING_UP <----+ |
+ |
+ ^ |
+ +=========== CLUSTER_DOWN <------------+
+ INBOUND_NOT_COMING_UP
+
+ Transitions -----> can only be made by the outbound CPU, and
+ only involve changes to the "cluster" state.
+
+ Transitions ===##> can only be made by the inbound CPU, and only
+ involve changes to the "inbound" state, except where there is no
+ further transition possible on the outbound side (i.e., the
+ outbound CPU has put the cluster into the CLUSTER_DOWN state).
+
+ The race avoidance algorithm does not provide a way to determine
+ which exact CPUs within the cluster play these roles. This must
+ be decided in advance by some other means. Refer to the section
+ "Last man and first man selection" for more explanation.
+
+
+ CLUSTER_DOWN/INBOUND_NOT_COMING_UP is the only state where the
+ cluster can actually be powered down.
+
+ The parallelism of the inbound and outbound CPUs is observed by
+ the existence of two different paths from CLUSTER_GOING_DOWN/
+ INBOUND_NOT_COMING_UP (corresponding to GOING_DOWN in the basic
+ model) to CLUSTER_DOWN/INBOUND_COMING_UP (corresponding to
+ COMING_UP in the basic model). The second path avoids cluster
+ teardown completely.
+
+ CLUSTER_UP/INBOUND_COMING_UP is equivalent to UP in the basic
+ model. The final transition to CLUSTER_UP/INBOUND_NOT_COMING_UP
+ is trivial and merely resets the state machine ready for the
+ next cycle.
+
+ Details of the allowable transitions follow.
+
+ The next state in each case is notated
+
+ <cluster state>/<inbound state> (<transitioner>)
+
+ where the <transitioner> is the side on which the transition
+ can occur; either the inbound or the outbound side.
+
+
+CLUSTER_DOWN/INBOUND_NOT_COMING_UP:
+
+ Next state: CLUSTER_DOWN/INBOUND_COMING_UP (inbound)
+ Conditions: none
+ Trigger events:
+
+ a) an explicit hardware power-up operation, resulting
+ from a policy decision on another CPU;
+
+ b) a hardware event, such as an interrupt.
+
+
+CLUSTER_DOWN/INBOUND_COMING_UP:
+
+ In this state, an inbound CPU sets up the cluster, including
+ enabling of hardware coherency at the cluster level and any
+ other operations (such as cache invalidation) which are required
+ in order to achieve this.
+
+ The purpose of this state is to do sufficient cluster-level
+ setup to enable other CPUs in the cluster to enter coherency
+ safely.
+
+ Next state: CLUSTER_UP/INBOUND_COMING_UP (inbound)
+ Conditions: cluster-level setup and hardware coherency complete
+ Trigger events: (spontaneous)
+
+
+CLUSTER_UP/INBOUND_COMING_UP:
+
+ Cluster-level setup is complete and hardware coherency is
+ enabled for the cluster. Other CPUs in the cluster can safely
+ enter coherency.
+
+ This is a transient state, leading immediately to
+ CLUSTER_UP/INBOUND_NOT_COMING_UP. All other CPUs on the cluster
+ should consider treat these two states as equivalent.
+
+ Next state: CLUSTER_UP/INBOUND_NOT_COMING_UP (inbound)
+ Conditions: none
+ Trigger events: (spontaneous)
+
+
+CLUSTER_UP/INBOUND_NOT_COMING_UP:
+
+ Cluster-level setup is complete and hardware coherency is
+ enabled for the cluster. Other CPUs in the cluster can safely
+ enter coherency.
+
+ The cluster will remain in this state until a policy decision is
+ made to power the cluster down.
+
+ Next state: CLUSTER_GOING_DOWN/INBOUND_NOT_COMING_UP (outbound)
+ Conditions: none
+ Trigger events: policy decision to power down the cluster
+
+
+CLUSTER_GOING_DOWN/INBOUND_NOT_COMING_UP:
+
+ An outbound CPU is tearing the cluster down. The selected CPU
+ must wait in this state until all CPUs in the cluster are in the
+ CPU_DOWN state.
+
+ When all CPUs are in the CPU_DOWN state, the cluster can be torn
+ down, for example by cleaning data caches and exiting
+ cluster-level coherency.
+
+ To avoid wasteful unnecessary teardown operations, the outbound
+ should check the inbound cluster state for asynchronous
+ transitions to INBOUND_COMING_UP. Alternatively, individual
+ CPUs can be checked for entry into CPU_COMING_UP or CPU_UP.
+
+
+ Next states:
+
+ CLUSTER_DOWN/INBOUND_NOT_COMING_UP (outbound)
+ Conditions: cluster torn down and ready to power off
+ Trigger events: (spontaneous)
+
+ CLUSTER_GOING_DOWN/INBOUND_COMING_UP (inbound)
+ Conditions: none
+ Trigger events:
+
+ a) an explicit hardware power-up operation,
+ resulting from a policy decision on another
+ CPU;
+
+ b) a hardware event, such as an interrupt.
+
+
+CLUSTER_GOING_DOWN/INBOUND_COMING_UP:
+
+ The cluster is (or was) being torn down, but another CPU has
+ come online in the meantime and is trying to set up the cluster
+ again.
+
+ If the outbound CPU observes this state, it has two choices:
+
+ a) back out of teardown, restoring the cluster to the
+ CLUSTER_UP state;
+
+ b) finish tearing the cluster down and put the cluster
+ in the CLUSTER_DOWN state; the inbound CPU will
+ set up the cluster again from there.
+
+ Choice (a) permits the removal of some latency by avoiding
+ unnecessary teardown and setup operations in situations where
+ the cluster is not really going to be powered down.
+
+
+ Next states:
+
+ CLUSTER_UP/INBOUND_COMING_UP (outbound)
+ Conditions: cluster-level setup and hardware
+ coherency complete
+ Trigger events: (spontaneous)
+
+ CLUSTER_DOWN/INBOUND_COMING_UP (outbound)
+ Conditions: cluster torn down and ready to power off
+ Trigger events: (spontaneous)
+
+
+Last man and First man selection
+--------------------------------
+
+The CPU which performs cluster tear-down operations on the outbound side
+is commonly referred to as the "last man".
+
+The CPU which performs cluster setup on the inbound side is commonly
+referred to as the "first man".
+
+The race avoidance algorithm documented above does not provide a
+mechanism to choose which CPUs should play these roles.
+
+
+Last man:
+
+When shutting down the cluster, all the CPUs involved are initially
+executing Linux and hence coherent. Therefore, ordinary spinlocks can
+be used to select a last man safely, before the CPUs become
+non-coherent.
+
+
+First man:
+
+Because CPUs may power up asynchronously in response to external wake-up
+events, a dynamic mechanism is needed to make sure that only one CPU
+attempts to play the first man role and do the cluster-level
+initialisation: any other CPUs must wait for this to complete before
+proceeding.
+
+Cluster-level initialisation may involve actions such as configuring
+coherency controls in the bus fabric.
+
+The current implementation in mcpm_head.S uses a separate mutual exclusion
+mechanism to do this arbitration. This mechanism is documented in
+detail in vlocks.txt.
+
+
+Features and Limitations
+------------------------
+
+Implementation:
+
+ The current ARM-based implementation is split between
+ arch/arm/common/mcpm_head.S (low-level inbound CPU operations) and
+ arch/arm/common/mcpm_entry.c (everything else):
+
+ __mcpm_cpu_going_down() signals the transition of a CPU to the
+ CPU_GOING_DOWN state.
+
+ __mcpm_cpu_down() signals the transition of a CPU to the CPU_DOWN
+ state.
+
+ A CPU transitions to CPU_COMING_UP and then to CPU_UP via the
+ low-level power-up code in mcpm_head.S. This could
+ involve CPU-specific setup code, but in the current
+ implementation it does not.
+
+ __mcpm_outbound_enter_critical() and __mcpm_outbound_leave_critical()
+ handle transitions from CLUSTER_UP to CLUSTER_GOING_DOWN
+ and from there to CLUSTER_DOWN or back to CLUSTER_UP (in
+ the case of an aborted cluster power-down).
+
+ These functions are more complex than the __mcpm_cpu_*()
+ functions due to the extra inter-CPU coordination which
+ is needed for safe transitions at the cluster level.
+
+ A cluster transitions from CLUSTER_DOWN back to CLUSTER_UP via
+ the low-level power-up code in mcpm_head.S. This
+ typically involves platform-specific setup code,
+ provided by the platform-specific power_up_setup
+ function registered via mcpm_sync_init.
+
+Deep topologies:
+
+ As currently described and implemented, the algorithm does not
+ support CPU topologies involving more than two levels (i.e.,
+ clusters of clusters are not supported). The algorithm could be
+ extended by replicating the cluster-level states for the
+ additional topological levels, and modifying the transition
+ rules for the intermediate (non-outermost) cluster levels.
+
+
+Colophon
+--------
+
+Originally created and documented by Dave Martin for Linaro Limited, in
+collaboration with Nicolas Pitre and Achin Gupta.
+
+Copyright (C) 2012-2013 Linaro Limited
+Distributed under the terms of Version 2 of the GNU General Public
+License, as defined in linux/COPYING.
diff --git a/Documentation/arm/firmware.txt b/Documentation/arm/firmware.txt
new file mode 100644
index 0000000..c2e468f
--- /dev/null
+++ b/Documentation/arm/firmware.txt
@@ -0,0 +1,88 @@
+Interface for registering and calling firmware-specific operations for ARM.
+----
+Written by Tomasz Figa <t.figa@samsung.com>
+
+Some boards are running with secure firmware running in TrustZone secure
+world, which changes the way some things have to be initialized. This makes
+a need to provide an interface for such platforms to specify available firmware
+operations and call them when needed.
+
+Firmware operations can be specified using struct firmware_ops
+
+ struct firmware_ops {
+ /*
+ * Enters CPU idle mode
+ */
+ int (*do_idle)(void);
+ /*
+ * Sets boot address of specified physical CPU
+ */
+ int (*set_cpu_boot_addr)(int cpu, unsigned long boot_addr);
+ /*
+ * Boots specified physical CPU
+ */
+ int (*cpu_boot)(int cpu);
+ /*
+ * Initializes L2 cache
+ */
+ int (*l2x0_init)(void);
+ };
+
+and then registered with register_firmware_ops function
+
+ void register_firmware_ops(const struct firmware_ops *ops)
+
+the ops pointer must be non-NULL.
+
+There is a default, empty set of operations provided, so there is no need to
+set anything if platform does not require firmware operations.
+
+To call a firmware operation, a helper macro is provided
+
+ #define call_firmware_op(op, ...) \
+ ((firmware_ops->op) ? firmware_ops->op(__VA_ARGS__) : (-ENOSYS))
+
+the macro checks if the operation is provided and calls it or otherwise returns
+-ENOSYS to signal that given operation is not available (for example, to allow
+fallback to legacy operation).
+
+Example of registering firmware operations:
+
+ /* board file */
+
+ static int platformX_do_idle(void)
+ {
+ /* tell platformX firmware to enter idle */
+ return 0;
+ }
+
+ static int platformX_cpu_boot(int i)
+ {
+ /* tell platformX firmware to boot CPU i */
+ return 0;
+ }
+
+ static const struct firmware_ops platformX_firmware_ops = {
+ .do_idle = exynos_do_idle,
+ .cpu_boot = exynos_cpu_boot,
+ /* other operations not available on platformX */
+ };
+
+ /* init_early callback of machine descriptor */
+ static void __init board_init_early(void)
+ {
+ register_firmware_ops(&platformX_firmware_ops);
+ }
+
+Example of using a firmware operation:
+
+ /* some platform code, e.g. SMP initialization */
+
+ __raw_writel(virt_to_phys(exynos4_secondary_startup),
+ CPU1_BOOT_REG);
+
+ /* Call Exynos specific smc call */
+ if (call_firmware_op(cpu_boot, cpu) == -ENOSYS)
+ cpu_boot_legacy(...); /* Try legacy way */
+
+ gic_raise_softirq(cpumask_of(cpu), 1);
diff --git a/Documentation/arm/sti/overview.txt b/Documentation/arm/sti/overview.txt
new file mode 100644
index 0000000..1a4e93d
--- /dev/null
+++ b/Documentation/arm/sti/overview.txt
@@ -0,0 +1,33 @@
+ STi ARM Linux Overview
+ ==========================
+
+Introduction
+------------
+
+ The ST Microelectronics Multimedia and Application Processors range of
+ CortexA9 System-on-Chip are supported by the 'STi' platform of
+ ARM Linux. Currently STiH415, STiH416 SOCs are supported with both
+ B2000 and B2020 Reference boards.
+
+
+ configuration
+ -------------
+
+ A generic configuration is provided for both STiH415/416, and can be used as the
+ default by
+ make stih41x_defconfig
+
+ Layout
+ ------
+ All the files for multiple machine families (STiH415, STiH416, and STiG125)
+ are located in the platform code contained in arch/arm/mach-sti
+
+ There is a generic board board-dt.c in the mach folder which support
+ Flattened Device Tree, which means, It works with any compatible board with
+ Device Trees.
+
+
+ Document Author
+ ---------------
+
+ Srinivas Kandagatla <srinivas.kandagatla@st.com>, (c) 2013 ST Microelectronics
diff --git a/Documentation/arm/sti/stih415-overview.txt b/Documentation/arm/sti/stih415-overview.txt
new file mode 100644
index 0000000..1383e33
--- /dev/null
+++ b/Documentation/arm/sti/stih415-overview.txt
@@ -0,0 +1,12 @@
+ STiH415 Overview
+ ================
+
+Introduction
+------------
+
+ The STiH415 is the next generation of HD, AVC set-top box processors
+ for satellite, cable, terrestrial and IP-STB markets.
+
+ Features
+ - ARM Cortex-A9 1.0 GHz, dual-core CPU
+ - SATA2x2,USB 2.0x3, PCIe, Gbit Ethernet MACx2
diff --git a/Documentation/arm/sti/stih416-overview.txt b/Documentation/arm/sti/stih416-overview.txt
new file mode 100644
index 0000000..558444c
--- /dev/null
+++ b/Documentation/arm/sti/stih416-overview.txt
@@ -0,0 +1,12 @@
+ STiH416 Overview
+ ================
+
+Introduction
+------------
+
+ The STiH416 is the next generation of HD, AVC set-top box processors
+ for satellite, cable, terrestrial and IP-STB markets.
+
+ Features
+ - ARM Cortex-A9 1.2 GHz dual core CPU
+ - SATA2x2,USB 2.0x3, PCIe, Gbit Ethernet MACx2
diff --git a/Documentation/arm/sunxi/README b/Documentation/arm/sunxi/README
index 87a1e8f..e3f93fb 100644
--- a/Documentation/arm/sunxi/README
+++ b/Documentation/arm/sunxi/README
@@ -3,17 +3,26 @@
This document lists all the ARM Allwinner SoCs that are currently
supported in mainline by the Linux kernel. This document will also
-provide links to documentation and or datasheet for these SoCs.
+provide links to documentation and/or datasheet for these SoCs.
SunXi family
------------
+ Linux kernel mach directory: arch/arm/mach-sunxi
Flavors:
- Allwinner A10 (sun4i)
- Datasheet : http://dl.linux-sunxi.org/A10/A10%20Datasheet%20-%20v1.21%20%282012-04-06%29.pdf
+ * ARM Cortex-A8 based SoCs
+ - Allwinner A10 (sun4i)
+ + Datasheet
+ http://dl.linux-sunxi.org/A10/A10%20Datasheet%20-%20v1.21%20%282012-04-06%29.pdf
+ + User Manual
+ http://dl.linux-sunxi.org/A10/A10%20User%20Manual%20-%20v1.20%20%282012-04-09%2c%20DECRYPTED%29.pdf
- Allwinner A13 (sun5i)
- Datasheet : http://dl.linux-sunxi.org/A13/A13%20Datasheet%20-%20v1.12%20%282012-03-29%29.pdf
+ - Allwinner A10s (sun5i)
+ + Datasheet
+ http://dl.linux-sunxi.org/A10s/A10s%20Datasheet%20-%20v1.20%20%282012-03-27%29.pdf
- Core: Cortex A8
- Linux kernel mach directory: arch/arm/mach-sunxi
\ No newline at end of file
+ - Allwinner A13 (sun5i)
+ + Datasheet
+ http://dl.linux-sunxi.org/A13/A13%20Datasheet%20-%20v1.12%20%282012-03-29%29.pdf
+ + User Manual
+ http://dl.linux-sunxi.org/A13/A13%20User%20Manual%20-%20v1.2%20%282013-08-08%29.pdf
diff --git a/Documentation/arm/sunxi/clocks.txt b/Documentation/arm/sunxi/clocks.txt
new file mode 100644
index 0000000..e09a88a
--- /dev/null
+++ b/Documentation/arm/sunxi/clocks.txt
@@ -0,0 +1,56 @@
+Frequently asked questions about the sunxi clock system
+=======================================================
+
+This document contains useful bits of information that people tend to ask
+about the sunxi clock system, as well as accompanying ASCII art when adequate.
+
+Q: Why is the main 24MHz oscillator gatable? Wouldn't that break the
+ system?
+
+A: The 24MHz oscillator allows gating to save power. Indeed, if gated
+ carelessly the system would stop functioning, but with the right
+ steps, one can gate it and keep the system running. Consider this
+ simplified suspend example:
+
+ While the system is operational, you would see something like
+
+ 24MHz 32kHz
+ |
+ PLL1
+ \
+ \_ CPU Mux
+ |
+ [CPU]
+
+ When you are about to suspend, you switch the CPU Mux to the 32kHz
+ oscillator:
+
+ 24Mhz 32kHz
+ | |
+ PLL1 |
+ /
+ CPU Mux _/
+ |
+ [CPU]
+
+ Finally you can gate the main oscillator
+
+ 32kHz
+ |
+ |
+ /
+ CPU Mux _/
+ |
+ [CPU]
+
+Q: Were can I learn more about the sunxi clocks?
+
+A: The linux-sunxi wiki contains a page documenting the clock registers,
+ you can find it at
+
+ http://linux-sunxi.org/A10/CCM
+
+ The authoritative source for information at this time is the ccmu driver
+ released by Allwinner, you can find it at
+
+ https://github.com/linux-sunxi/linux-sunxi/tree/sunxi-3.0/arch/arm/mach-sun4i/clock/ccmu
diff --git a/Documentation/arm/vlocks.txt b/Documentation/arm/vlocks.txt
new file mode 100644
index 0000000..415960a
--- /dev/null
+++ b/Documentation/arm/vlocks.txt
@@ -0,0 +1,211 @@
+vlocks for Bare-Metal Mutual Exclusion
+======================================
+
+Voting Locks, or "vlocks" provide a simple low-level mutual exclusion
+mechanism, with reasonable but minimal requirements on the memory
+system.
+
+These are intended to be used to coordinate critical activity among CPUs
+which are otherwise non-coherent, in situations where the hardware
+provides no other mechanism to support this and ordinary spinlocks
+cannot be used.
+
+
+vlocks make use of the atomicity provided by the memory system for
+writes to a single memory location. To arbitrate, every CPU "votes for
+itself", by storing a unique number to a common memory location. The
+final value seen in that memory location when all the votes have been
+cast identifies the winner.
+
+In order to make sure that the election produces an unambiguous result
+in finite time, a CPU will only enter the election in the first place if
+no winner has been chosen and the election does not appear to have
+started yet.
+
+
+Algorithm
+---------
+
+The easiest way to explain the vlocks algorithm is with some pseudo-code:
+
+
+ int currently_voting[NR_CPUS] = { 0, };
+ int last_vote = -1; /* no votes yet */
+
+ bool vlock_trylock(int this_cpu)
+ {
+ /* signal our desire to vote */
+ currently_voting[this_cpu] = 1;
+ if (last_vote != -1) {
+ /* someone already volunteered himself */
+ currently_voting[this_cpu] = 0;
+ return false; /* not ourself */
+ }
+
+ /* let's suggest ourself */
+ last_vote = this_cpu;
+ currently_voting[this_cpu] = 0;
+
+ /* then wait until everyone else is done voting */
+ for_each_cpu(i) {
+ while (currently_voting[i] != 0)
+ /* wait */;
+ }
+
+ /* result */
+ if (last_vote == this_cpu)
+ return true; /* we won */
+ return false;
+ }
+
+ bool vlock_unlock(void)
+ {
+ last_vote = -1;
+ }
+
+
+The currently_voting[] array provides a way for the CPUs to determine
+whether an election is in progress, and plays a role analogous to the
+"entering" array in Lamport's bakery algorithm [1].
+
+However, once the election has started, the underlying memory system
+atomicity is used to pick the winner. This avoids the need for a static
+priority rule to act as a tie-breaker, or any counters which could
+overflow.
+
+As long as the last_vote variable is globally visible to all CPUs, it
+will contain only one value that won't change once every CPU has cleared
+its currently_voting flag.
+
+
+Features and limitations
+------------------------
+
+ * vlocks are not intended to be fair. In the contended case, it is the
+ _last_ CPU which attempts to get the lock which will be most likely
+ to win.
+
+ vlocks are therefore best suited to situations where it is necessary
+ to pick a unique winner, but it does not matter which CPU actually
+ wins.
+
+ * Like other similar mechanisms, vlocks will not scale well to a large
+ number of CPUs.
+
+ vlocks can be cascaded in a voting hierarchy to permit better scaling
+ if necessary, as in the following hypothetical example for 4096 CPUs:
+
+ /* first level: local election */
+ my_town = towns[(this_cpu >> 4) & 0xf];
+ I_won = vlock_trylock(my_town, this_cpu & 0xf);
+ if (I_won) {
+ /* we won the town election, let's go for the state */
+ my_state = states[(this_cpu >> 8) & 0xf];
+ I_won = vlock_lock(my_state, this_cpu & 0xf));
+ if (I_won) {
+ /* and so on */
+ I_won = vlock_lock(the_whole_country, this_cpu & 0xf];
+ if (I_won) {
+ /* ... */
+ }
+ vlock_unlock(the_whole_country);
+ }
+ vlock_unlock(my_state);
+ }
+ vlock_unlock(my_town);
+
+
+ARM implementation
+------------------
+
+The current ARM implementation [2] contains some optimisations beyond
+the basic algorithm:
+
+ * By packing the members of the currently_voting array close together,
+ we can read the whole array in one transaction (providing the number
+ of CPUs potentially contending the lock is small enough). This
+ reduces the number of round-trips required to external memory.
+
+ In the ARM implementation, this means that we can use a single load
+ and comparison:
+
+ LDR Rt, [Rn]
+ CMP Rt, #0
+
+ ...in place of code equivalent to:
+
+ LDRB Rt, [Rn]
+ CMP Rt, #0
+ LDRBEQ Rt, [Rn, #1]
+ CMPEQ Rt, #0
+ LDRBEQ Rt, [Rn, #2]
+ CMPEQ Rt, #0
+ LDRBEQ Rt, [Rn, #3]
+ CMPEQ Rt, #0
+
+ This cuts down on the fast-path latency, as well as potentially
+ reducing bus contention in contended cases.
+
+ The optimisation relies on the fact that the ARM memory system
+ guarantees coherency between overlapping memory accesses of
+ different sizes, similarly to many other architectures. Note that
+ we do not care which element of currently_voting appears in which
+ bits of Rt, so there is no need to worry about endianness in this
+ optimisation.
+
+ If there are too many CPUs to read the currently_voting array in
+ one transaction then multiple transations are still required. The
+ implementation uses a simple loop of word-sized loads for this
+ case. The number of transactions is still fewer than would be
+ required if bytes were loaded individually.
+
+
+ In principle, we could aggregate further by using LDRD or LDM, but
+ to keep the code simple this was not attempted in the initial
+ implementation.
+
+
+ * vlocks are currently only used to coordinate between CPUs which are
+ unable to enable their caches yet. This means that the
+ implementation removes many of the barriers which would be required
+ when executing the algorithm in cached memory.
+
+ packing of the currently_voting array does not work with cached
+ memory unless all CPUs contending the lock are cache-coherent, due
+ to cache writebacks from one CPU clobbering values written by other
+ CPUs. (Though if all the CPUs are cache-coherent, you should be
+ probably be using proper spinlocks instead anyway).
+
+
+ * The "no votes yet" value used for the last_vote variable is 0 (not
+ -1 as in the pseudocode). This allows statically-allocated vlocks
+ to be implicitly initialised to an unlocked state simply by putting
+ them in .bss.
+
+ An offset is added to each CPU's ID for the purpose of setting this
+ variable, so that no CPU uses the value 0 for its ID.
+
+
+Colophon
+--------
+
+Originally created and documented by Dave Martin for Linaro Limited, for
+use in ARM-based big.LITTLE platforms, with review and input gratefully
+received from Nicolas Pitre and Achin Gupta. Thanks to Nicolas for
+grabbing most of this text out of the relevant mail thread and writing
+up the pseudocode.
+
+Copyright (C) 2012-2013 Linaro Limited
+Distributed under the terms of Version 2 of the GNU General Public
+License, as defined in linux/COPYING.
+
+
+References
+----------
+
+[1] Lamport, L. "A New Solution of Dijkstra's Concurrent Programming
+ Problem", Communications of the ACM 17, 8 (August 1974), 453-455.
+
+ http://en.wikipedia.org/wiki/Lamport%27s_bakery_algorithm
+
+[2] linux/arch/arm/common/vlock.S, www.kernel.org.
diff --git a/Documentation/arm64/memory.txt b/Documentation/arm64/memory.txt
index d758702..78a37712 100644
--- a/Documentation/arm64/memory.txt
+++ b/Documentation/arm64/memory.txt
@@ -35,6 +35,8 @@
ffffffbe00000000 ffffffbffbbfffff ~8GB [guard, future vmmemap]
+ffffffbffbc00000 ffffffbffbdfffff 2MB earlyprintk device
+
ffffffbffbe00000 ffffffbffbe0ffff 64KB PCI I/O space
ffffffbbffff0000 ffffffbcffffffff ~2MB [guard]
@@ -71,3 +73,10 @@
| | +--------------------------> [41:29] L2 index (only 38:29 used)
| +-------------------------------> [47:42] L1 index (not used)
+-------------------------------------------------> [63] TTBR0/1
+
+When using KVM, the hypervisor maps kernel pages in EL2, at a fixed
+offset from the kernel VA (top 24bits of the kernel VA set to zero):
+
+Start End Size Use
+-----------------------------------------------------------------------
+0000004000000000 0000007fffffffff 256GB kernel objects mapped in HYP
diff --git a/Documentation/atomic_ops.txt b/Documentation/atomic_ops.txt
index 27f2b21..d9ca5be 100644
--- a/Documentation/atomic_ops.txt
+++ b/Documentation/atomic_ops.txt
@@ -253,6 +253,8 @@
the given new value. It returns the old value that the atomic variable v had
just before the operation.
+atomic_xchg requires explicit memory barriers around the operation.
+
int atomic_cmpxchg(atomic_t *v, int old, int new);
This performs an atomic compare exchange operation on the atomic value v,
diff --git a/Documentation/backlight/lp855x-driver.txt b/Documentation/backlight/lp855x-driver.txt
index 1529394..1c732f0 100644
--- a/Documentation/backlight/lp855x-driver.txt
+++ b/Documentation/backlight/lp855x-driver.txt
@@ -4,7 +4,7 @@
Backlight driver for LP855x ICs
Supported chips:
- Texas Instruments LP8550, LP8551, LP8552, LP8553 and LP8556
+ Texas Instruments LP8550, LP8551, LP8552, LP8553, LP8556 and LP8557
Author: Milo(Woogyom) Kim <milo.kim@ti.com>
@@ -24,7 +24,7 @@
2) chip_id
The lp855x chip id.
-Value : lp8550/lp8551/lp8552/lp8553/lp8556
+Value : lp8550/lp8551/lp8552/lp8553/lp8556/lp8557
Platform data for lp855x
------------------------
@@ -32,14 +32,10 @@
For supporting platform specific data, the lp855x platform data can be used.
* name : Backlight driver name. If it is not defined, default name is set.
-* mode : Brightness control mode. PWM or register based.
* device_control : Value of DEVICE CONTROL register.
* initial_brightness : Initial value of backlight brightness.
* period_ns : Platform specific PWM period value. unit is nano.
Only valid when brightness is pwm input mode.
-* load_new_rom_data :
- 0 : use default configuration data
- 1 : update values of eeprom or eprom registers on loading driver
* size_program : Total size of lp855x_rom_data.
* rom_data : List of new eeprom/eprom registers.
@@ -54,10 +50,8 @@
static struct lp855x_platform_data lp8552_pdata = {
.name = "lcd-bl",
- .mode = REGISTER_BASED,
.device_control = I2C_CONFIG(LP8552),
.initial_brightness = INITIAL_BRT,
- .load_new_rom_data = 1,
.size_program = ARRAY_SIZE(lp8552_eeprom_arr),
.rom_data = lp8552_eeprom_arr,
};
@@ -65,7 +59,6 @@
example 2) lp8556 platform data : pwm input mode with default rom data
static struct lp855x_platform_data lp8556_pdata = {
- .mode = PWM_BASED,
.device_control = PWM_CONFIG(LP8556),
.initial_brightness = INITIAL_BRT,
.period_ns = 1000000,
diff --git a/Documentation/bcache.txt b/Documentation/bcache.txt
new file mode 100644
index 0000000..c3365f2
--- /dev/null
+++ b/Documentation/bcache.txt
@@ -0,0 +1,437 @@
+Say you've got a big slow raid 6, and an X-25E or three. Wouldn't it be
+nice if you could use them as cache... Hence bcache.
+
+Wiki and git repositories are at:
+ http://bcache.evilpiepirate.org
+ http://evilpiepirate.org/git/linux-bcache.git
+ http://evilpiepirate.org/git/bcache-tools.git
+
+It's designed around the performance characteristics of SSDs - it only allocates
+in erase block sized buckets, and it uses a hybrid btree/log to track cached
+extants (which can be anywhere from a single sector to the bucket size). It's
+designed to avoid random writes at all costs; it fills up an erase block
+sequentially, then issues a discard before reusing it.
+
+Both writethrough and writeback caching are supported. Writeback defaults to
+off, but can be switched on and off arbitrarily at runtime. Bcache goes to
+great lengths to protect your data - it reliably handles unclean shutdown. (It
+doesn't even have a notion of a clean shutdown; bcache simply doesn't return
+writes as completed until they're on stable storage).
+
+Writeback caching can use most of the cache for buffering writes - writing
+dirty data to the backing device is always done sequentially, scanning from the
+start to the end of the index.
+
+Since random IO is what SSDs excel at, there generally won't be much benefit
+to caching large sequential IO. Bcache detects sequential IO and skips it;
+it also keeps a rolling average of the IO sizes per task, and as long as the
+average is above the cutoff it will skip all IO from that task - instead of
+caching the first 512k after every seek. Backups and large file copies should
+thus entirely bypass the cache.
+
+In the event of a data IO error on the flash it will try to recover by reading
+from disk or invalidating cache entries. For unrecoverable errors (meta data
+or dirty data), caching is automatically disabled; if dirty data was present
+in the cache it first disables writeback caching and waits for all dirty data
+to be flushed.
+
+Getting started:
+You'll need make-bcache from the bcache-tools repository. Both the cache device
+and backing device must be formatted before use.
+ make-bcache -B /dev/sdb
+ make-bcache -C /dev/sdc
+
+make-bcache has the ability to format multiple devices at the same time - if
+you format your backing devices and cache device at the same time, you won't
+have to manually attach:
+ make-bcache -B /dev/sda /dev/sdb -C /dev/sdc
+
+To make bcache devices known to the kernel, echo them to /sys/fs/bcache/register:
+
+ echo /dev/sdb > /sys/fs/bcache/register
+ echo /dev/sdc > /sys/fs/bcache/register
+
+To register your bcache devices automatically, you could add something like
+this to an init script:
+
+ echo /dev/sd* > /sys/fs/bcache/register_quiet
+
+It'll look for bcache superblocks and ignore everything that doesn't have one.
+
+Registering the backing device makes the bcache show up in /dev; you can now
+format it and use it as normal. But the first time using a new bcache device,
+it'll be running in passthrough mode until you attach it to a cache. See the
+section on attaching.
+
+The devices show up at /dev/bcacheN, and can be controlled via sysfs from
+/sys/block/bcacheN/bcache:
+
+ mkfs.ext4 /dev/bcache0
+ mount /dev/bcache0 /mnt
+
+Cache devices are managed as sets; multiple caches per set isn't supported yet
+but will allow for mirroring of metadata and dirty data in the future. Your new
+cache set shows up as /sys/fs/bcache/<UUID>
+
+ATTACHING:
+
+After your cache device and backing device are registered, the backing device
+must be attached to your cache set to enable caching. Attaching a backing
+device to a cache set is done thusly, with the UUID of the cache set in
+/sys/fs/bcache:
+
+ echo <UUID> > /sys/block/bcache0/bcache/attach
+
+This only has to be done once. The next time you reboot, just reregister all
+your bcache devices. If a backing device has data in a cache somewhere, the
+/dev/bcache# device won't be created until the cache shows up - particularly
+important if you have writeback caching turned on.
+
+If you're booting up and your cache device is gone and never coming back, you
+can force run the backing device:
+
+ echo 1 > /sys/block/sdb/bcache/running
+
+(You need to use /sys/block/sdb (or whatever your backing device is called), not
+/sys/block/bcache0, because bcache0 doesn't exist yet. If you're using a
+partition, the bcache directory would be at /sys/block/sdb/sdb2/bcache)
+
+The backing device will still use that cache set if it shows up in the future,
+but all the cached data will be invalidated. If there was dirty data in the
+cache, don't expect the filesystem to be recoverable - you will have massive
+filesystem corruption, though ext4's fsck does work miracles.
+
+ERROR HANDLING:
+
+Bcache tries to transparently handle IO errors to/from the cache device without
+affecting normal operation; if it sees too many errors (the threshold is
+configurable, and defaults to 0) it shuts down the cache device and switches all
+the backing devices to passthrough mode.
+
+ - For reads from the cache, if they error we just retry the read from the
+ backing device.
+
+ - For writethrough writes, if the write to the cache errors we just switch to
+ invalidating the data at that lba in the cache (i.e. the same thing we do for
+ a write that bypasses the cache)
+
+ - For writeback writes, we currently pass that error back up to the
+ filesystem/userspace. This could be improved - we could retry it as a write
+ that skips the cache so we don't have to error the write.
+
+ - When we detach, we first try to flush any dirty data (if we were running in
+ writeback mode). It currently doesn't do anything intelligent if it fails to
+ read some of the dirty data, though.
+
+TROUBLESHOOTING PERFORMANCE:
+
+Bcache has a bunch of config options and tunables. The defaults are intended to
+be reasonable for typical desktop and server workloads, but they're not what you
+want for getting the best possible numbers when benchmarking.
+
+ - Bad write performance
+
+ If write performance is not what you expected, you probably wanted to be
+ running in writeback mode, which isn't the default (not due to a lack of
+ maturity, but simply because in writeback mode you'll lose data if something
+ happens to your SSD)
+
+ # echo writeback > /sys/block/bcache0/cache_mode
+
+ - Bad performance, or traffic not going to the SSD that you'd expect
+
+ By default, bcache doesn't cache everything. It tries to skip sequential IO -
+ because you really want to be caching the random IO, and if you copy a 10
+ gigabyte file you probably don't want that pushing 10 gigabytes of randomly
+ accessed data out of your cache.
+
+ But if you want to benchmark reads from cache, and you start out with fio
+ writing an 8 gigabyte test file - so you want to disable that.
+
+ # echo 0 > /sys/block/bcache0/bcache/sequential_cutoff
+
+ To set it back to the default (4 mb), do
+
+ # echo 4M > /sys/block/bcache0/bcache/sequential_cutoff
+
+ - Traffic's still going to the spindle/still getting cache misses
+
+ In the real world, SSDs don't always keep up with disks - particularly with
+ slower SSDs, many disks being cached by one SSD, or mostly sequential IO. So
+ you want to avoid being bottlenecked by the SSD and having it slow everything
+ down.
+
+ To avoid that bcache tracks latency to the cache device, and gradually
+ throttles traffic if the latency exceeds a threshold (it does this by
+ cranking down the sequential bypass).
+
+ You can disable this if you need to by setting the thresholds to 0:
+
+ # echo 0 > /sys/fs/bcache/<cache set>/congested_read_threshold_us
+ # echo 0 > /sys/fs/bcache/<cache set>/congested_write_threshold_us
+
+ The default is 2000 us (2 milliseconds) for reads, and 20000 for writes.
+
+ - Still getting cache misses, of the same data
+
+ One last issue that sometimes trips people up is actually an old bug, due to
+ the way cache coherency is handled for cache misses. If a btree node is full,
+ a cache miss won't be able to insert a key for the new data and the data
+ won't be written to the cache.
+
+ In practice this isn't an issue because as soon as a write comes along it'll
+ cause the btree node to be split, and you need almost no write traffic for
+ this to not show up enough to be noticeable (especially since bcache's btree
+ nodes are huge and index large regions of the device). But when you're
+ benchmarking, if you're trying to warm the cache by reading a bunch of data
+ and there's no other traffic - that can be a problem.
+
+ Solution: warm the cache by doing writes, or use the testing branch (there's
+ a fix for the issue there).
+
+SYSFS - BACKING DEVICE:
+
+attach
+ Echo the UUID of a cache set to this file to enable caching.
+
+cache_mode
+ Can be one of either writethrough, writeback, writearound or none.
+
+clear_stats
+ Writing to this file resets the running total stats (not the day/hour/5 minute
+ decaying versions).
+
+detach
+ Write to this file to detach from a cache set. If there is dirty data in the
+ cache, it will be flushed first.
+
+dirty_data
+ Amount of dirty data for this backing device in the cache. Continuously
+ updated unlike the cache set's version, but may be slightly off.
+
+label
+ Name of underlying device.
+
+readahead
+ Size of readahead that should be performed. Defaults to 0. If set to e.g.
+ 1M, it will round cache miss reads up to that size, but without overlapping
+ existing cache entries.
+
+running
+ 1 if bcache is running (i.e. whether the /dev/bcache device exists, whether
+ it's in passthrough mode or caching).
+
+sequential_cutoff
+ A sequential IO will bypass the cache once it passes this threshold; the
+ most recent 128 IOs are tracked so sequential IO can be detected even when
+ it isn't all done at once.
+
+sequential_merge
+ If non zero, bcache keeps a list of the last 128 requests submitted to compare
+ against all new requests to determine which new requests are sequential
+ continuations of previous requests for the purpose of determining sequential
+ cutoff. This is necessary if the sequential cutoff value is greater than the
+ maximum acceptable sequential size for any single request.
+
+state
+ The backing device can be in one of four different states:
+
+ no cache: Has never been attached to a cache set.
+
+ clean: Part of a cache set, and there is no cached dirty data.
+
+ dirty: Part of a cache set, and there is cached dirty data.
+
+ inconsistent: The backing device was forcibly run by the user when there was
+ dirty data cached but the cache set was unavailable; whatever data was on the
+ backing device has likely been corrupted.
+
+stop
+ Write to this file to shut down the bcache device and close the backing
+ device.
+
+writeback_delay
+ When dirty data is written to the cache and it previously did not contain
+ any, waits some number of seconds before initiating writeback. Defaults to
+ 30.
+
+writeback_percent
+ If nonzero, bcache tries to keep around this percentage of the cache dirty by
+ throttling background writeback and using a PD controller to smoothly adjust
+ the rate.
+
+writeback_rate
+ Rate in sectors per second - if writeback_percent is nonzero, background
+ writeback is throttled to this rate. Continuously adjusted by bcache but may
+ also be set by the user.
+
+writeback_running
+ If off, writeback of dirty data will not take place at all. Dirty data will
+ still be added to the cache until it is mostly full; only meant for
+ benchmarking. Defaults to on.
+
+SYSFS - BACKING DEVICE STATS:
+
+There are directories with these numbers for a running total, as well as
+versions that decay over the past day, hour and 5 minutes; they're also
+aggregated in the cache set directory as well.
+
+bypassed
+ Amount of IO (both reads and writes) that has bypassed the cache
+
+cache_hits
+cache_misses
+cache_hit_ratio
+ Hits and misses are counted per individual IO as bcache sees them; a
+ partial hit is counted as a miss.
+
+cache_bypass_hits
+cache_bypass_misses
+ Hits and misses for IO that is intended to skip the cache are still counted,
+ but broken out here.
+
+cache_miss_collisions
+ Counts instances where data was going to be inserted into the cache from a
+ cache miss, but raced with a write and data was already present (usually 0
+ since the synchronization for cache misses was rewritten)
+
+cache_readaheads
+ Count of times readahead occurred.
+
+SYSFS - CACHE SET:
+
+average_key_size
+ Average data per key in the btree.
+
+bdev<0..n>
+ Symlink to each of the attached backing devices.
+
+block_size
+ Block size of the cache devices.
+
+btree_cache_size
+ Amount of memory currently used by the btree cache
+
+bucket_size
+ Size of buckets
+
+cache<0..n>
+ Symlink to each of the cache devices comprising this cache set.
+
+cache_available_percent
+ Percentage of cache device which doesn't contain dirty data, and could
+ potentially be used for writeback. This doesn't mean this space isn't used
+ for clean cached data; the unused statistic (in priority_stats) is typically
+ much lower.
+
+clear_stats
+ Clears the statistics associated with this cache
+
+dirty_data
+ Amount of dirty data is in the cache (updated when garbage collection runs).
+
+flash_vol_create
+ Echoing a size to this file (in human readable units, k/M/G) creates a thinly
+ provisioned volume backed by the cache set.
+
+io_error_halflife
+io_error_limit
+ These determines how many errors we accept before disabling the cache.
+ Each error is decayed by the half life (in # ios). If the decaying count
+ reaches io_error_limit dirty data is written out and the cache is disabled.
+
+journal_delay_ms
+ Journal writes will delay for up to this many milliseconds, unless a cache
+ flush happens sooner. Defaults to 100.
+
+root_usage_percent
+ Percentage of the root btree node in use. If this gets too high the node
+ will split, increasing the tree depth.
+
+stop
+ Write to this file to shut down the cache set - waits until all attached
+ backing devices have been shut down.
+
+tree_depth
+ Depth of the btree (A single node btree has depth 0).
+
+unregister
+ Detaches all backing devices and closes the cache devices; if dirty data is
+ present it will disable writeback caching and wait for it to be flushed.
+
+SYSFS - CACHE SET INTERNAL:
+
+This directory also exposes timings for a number of internal operations, with
+separate files for average duration, average frequency, last occurrence and max
+duration: garbage collection, btree read, btree node sorts and btree splits.
+
+active_journal_entries
+ Number of journal entries that are newer than the index.
+
+btree_nodes
+ Total nodes in the btree.
+
+btree_used_percent
+ Average fraction of btree in use.
+
+bset_tree_stats
+ Statistics about the auxiliary search trees
+
+btree_cache_max_chain
+ Longest chain in the btree node cache's hash table
+
+cache_read_races
+ Counts instances where while data was being read from the cache, the bucket
+ was reused and invalidated - i.e. where the pointer was stale after the read
+ completed. When this occurs the data is reread from the backing device.
+
+trigger_gc
+ Writing to this file forces garbage collection to run.
+
+SYSFS - CACHE DEVICE:
+
+block_size
+ Minimum granularity of writes - should match hardware sector size.
+
+btree_written
+ Sum of all btree writes, in (kilo/mega/giga) bytes
+
+bucket_size
+ Size of buckets
+
+cache_replacement_policy
+ One of either lru, fifo or random.
+
+discard
+ Boolean; if on a discard/TRIM will be issued to each bucket before it is
+ reused. Defaults to off, since SATA TRIM is an unqueued command (and thus
+ slow).
+
+freelist_percent
+ Size of the freelist as a percentage of nbuckets. Can be written to to
+ increase the number of buckets kept on the freelist, which lets you
+ artificially reduce the size of the cache at runtime. Mostly for testing
+ purposes (i.e. testing how different size caches affect your hit rate), but
+ since buckets are discarded when they move on to the freelist will also make
+ the SSD's garbage collection easier by effectively giving it more reserved
+ space.
+
+io_errors
+ Number of errors that have occurred, decayed by io_error_halflife.
+
+metadata_written
+ Sum of all non data writes (btree writes and all other metadata).
+
+nbuckets
+ Total buckets in this cache
+
+priority_stats
+ Statistics about how recently data in the cache has been accessed.
+ This can reveal your working set size. Unused is the percentage of
+ the cache that doesn't contain any data. Metadata is bcache's
+ metadata overhead. Average is the average priority of cache buckets.
+ Next is a list of quantiles with the priority threshold of each.
+
+written
+ Sum of all data that has been written to the cache; comparison with
+ btree_written gives the amount of write inflation in bcache.
diff --git a/Documentation/block/cfq-iosched.txt b/Documentation/block/cfq-iosched.txt
index d89b4fe..9887f04 100644
--- a/Documentation/block/cfq-iosched.txt
+++ b/Documentation/block/cfq-iosched.txt
@@ -5,7 +5,7 @@
I/O bandwidth for all the processes which requests an I/O operation.
CFQ maintains the per process queue for the processes which request I/O
-operation(syncronous requests). In case of asynchronous requests, all the
+operation(synchronous requests). In case of asynchronous requests, all the
requests from all the processes are batched together according to their
process's I/O priority.
@@ -66,6 +66,47 @@
value of this is 124ms. In case to favor synchronous requests over asynchronous
one, this value should be decreased relative to fifo_expire_async.
+group_idle
+-----------
+This parameter forces idling at the CFQ group level instead of CFQ
+queue level. This was introduced after after a bottleneck was observed
+in higher end storage due to idle on sequential queue and allow dispatch
+from a single queue. The idea with this parameter is that it can be run with
+slice_idle=0 and group_idle=8, so that idling does not happen on individual
+queues in the group but happens overall on the group and thus still keeps the
+IO controller working.
+Not idling on individual queues in the group will dispatch requests from
+multiple queues in the group at the same time and achieve higher throughput
+on higher end storage.
+
+Default value for this parameter is 8ms.
+
+latency
+-------
+This parameter is used to enable/disable the latency mode of the CFQ
+scheduler. If latency mode (called low_latency) is enabled, CFQ tries
+to recompute the slice time for each process based on the target_latency set
+for the system. This favors fairness over throughput. Disabling low
+latency (setting it to 0) ignores target latency, allowing each process in the
+system to get a full time slice.
+
+By default low latency mode is enabled.
+
+target_latency
+--------------
+This parameter is used to calculate the time slice for a process if cfq's
+latency mode is enabled. It will ensure that sync requests have an estimated
+latency. But if sequential workload is higher(e.g. sequential read),
+then to meet the latency constraints, throughput may decrease because of less
+time for each process to issue I/O request before the cfq queue is switched.
+
+Though this can be overcome by disabling the latency_mode, it may increase
+the read latency for some applications. This parameter allows for changing
+target_latency through the sysfs interface which can provide the balanced
+throughput and read latency.
+
+Default value for target_latency is 300ms.
+
slice_async
-----------
This parameter is same as of slice_sync but for asynchronous queue. The
@@ -98,10 +139,68 @@
request.
In case of storage with several disk, this setting can limit the parallel
-processing of request. Therefore, increasing the value can imporve the
-performace although this can cause the latency of some I/O to increase due
+processing of request. Therefore, increasing the value can improve the
+performance although this can cause the latency of some I/O to increase due
to more number of requests.
+CFQ Group scheduling
+====================
+
+CFQ supports blkio cgroup and has "blkio." prefixed files in each
+blkio cgroup directory. It is weight-based and there are four knobs
+for configuration - weight[_device] and leaf_weight[_device].
+Internal cgroup nodes (the ones with children) can also have tasks in
+them, so the former two configure how much proportion the cgroup as a
+whole is entitled to at its parent's level while the latter two
+configure how much proportion the tasks in the cgroup have compared to
+its direct children.
+
+Another way to think about it is assuming that each internal node has
+an implicit leaf child node which hosts all the tasks whose weight is
+configured by leaf_weight[_device]. Let's assume a blkio hierarchy
+composed of five cgroups - root, A, B, AA and AB - with the following
+weights where the names represent the hierarchy.
+
+ weight leaf_weight
+ root : 125 125
+ A : 500 750
+ B : 250 500
+ AA : 500 500
+ AB : 1000 500
+
+root never has a parent making its weight is meaningless. For backward
+compatibility, weight is always kept in sync with leaf_weight. B, AA
+and AB have no child and thus its tasks have no children cgroup to
+compete with. They always get 100% of what the cgroup won at the
+parent level. Considering only the weights which matter, the hierarchy
+looks like the following.
+
+ root
+ / | \
+ A B leaf
+ 500 250 125
+ / | \
+ AA AB leaf
+ 500 1000 750
+
+If all cgroups have active IOs and competing with each other, disk
+time will be distributed like the following.
+
+Distribution below root. The total active weight at this level is
+A:500 + B:250 + C:125 = 875.
+
+ root-leaf : 125 / 875 =~ 14%
+ A : 500 / 875 =~ 57%
+ B(-leaf) : 250 / 875 =~ 28%
+
+A has children and further distributes its 57% among the children and
+the implicit leaf node. The total active weight at this level is
+AA:500 + AB:1000 + A-leaf:750 = 2250.
+
+ A-leaf : ( 750 / 2250) * A =~ 19%
+ AA(-leaf) : ( 500 / 2250) * A =~ 12%
+ AB(-leaf) : (1000 / 2250) * A =~ 25%
+
CFQ IOPS Mode for group scheduling
===================================
Basic CFQ design is to provide priority based time slices. Higher priority
diff --git a/Documentation/block/queue-sysfs.txt b/Documentation/block/queue-sysfs.txt
index e54ac1d..7d2d046 100644
--- a/Documentation/block/queue-sysfs.txt
+++ b/Documentation/block/queue-sysfs.txt
@@ -93,7 +93,7 @@
queue maintains a separate request pool per each cgroup when
CONFIG_BLK_CGROUP is enabled, and this parameter applies to each such
per-block-cgroup request pool. IOW, if there are N block cgroups,
-each request queue may have upto N request pools, each independently
+each request queue may have up to N request pools, each independently
regulated by nr_requests.
optimal_io_size (RO)
diff --git a/Documentation/blockdev/nbd.txt b/Documentation/blockdev/nbd.txt
index aeb93ff..271e607 100644
--- a/Documentation/blockdev/nbd.txt
+++ b/Documentation/blockdev/nbd.txt
@@ -4,43 +4,13 @@
can use a remote server as one of its block devices. So every time
the client computer wants to read, e.g., /dev/nb0, it sends a
request over TCP to the server, which will reply with the data read.
- This can be used for stations with low disk space (or even diskless -
- if you boot from floppy) to borrow disk space from another computer.
- Unlike NFS, it is possible to put any filesystem on it, etc. It should
- even be possible to use NBD as a root filesystem (I've never tried),
- but it requires a user-level program to be in the initrd to start.
- It also allows you to run block-device in user land (making server
- and client physically the same computer, communicating using loopback).
-
- Current state: It currently works. Network block device is stable.
- I originally thought that it was impossible to swap over TCP. It
- turned out not to be true - swapping over TCP now works and seems
- to be deadlock-free, but it requires heavy patches into Linux's
- network layer.
-
+ This can be used for stations with low disk space (or even diskless)
+ to borrow disk space from another computer.
+ Unlike NFS, it is possible to put any filesystem on it, etc.
+
For more information, or to download the nbd-client and nbd-server
tools, go to http://nbd.sf.net/.
- Howto: To setup nbd, you can simply do the following:
-
- First, serve a device or file from a remote server:
-
- nbd-server <port-number> <device-or-file-to-serve-to-client>
-
- e.g.,
- root@server1 # nbd-server 1234 /dev/sdb1
-
- (serves sdb1 partition on TCP port 1234)
-
- Then, on the local (client) system:
-
- nbd-client <server-name-or-IP> <server-port-number> /dev/nb[0-n]
-
- e.g.,
- root@client1 # nbd-client server1 1234 /dev/nb0
-
- (creates the nb0 device on client1)
-
The nbd kernel module need only be installed on the client
system, as the nbd-server is completely in userspace. In fact,
the nbd-server has been successfully ported to other operating
diff --git a/Documentation/cgroups/00-INDEX b/Documentation/cgroups/00-INDEX
index f78b90a..bc461b6 100644
--- a/Documentation/cgroups/00-INDEX
+++ b/Documentation/cgroups/00-INDEX
@@ -4,8 +4,6 @@
- Description for Block IO Controller, implementation and usage details.
cgroups.txt
- Control Groups definition, implementation details, examples and API.
-cgroup_event_listener.c
- - A user program for cgroup listener.
cpuacct.txt
- CPU Accounting Controller; account CPU usage for groups of tasks.
cpusets.txt
@@ -20,6 +18,8 @@
- Memory Resource Controller; implementation details.
memory.txt
- Memory Resource Controller; design, accounting, interface, testing.
+net_cls.txt
+ - Network classifier cgroups details and usages.
net_prio.txt
- Network priority cgroups details and usages.
resource_counter.txt
diff --git a/Documentation/cgroups/blkio-controller.txt b/Documentation/cgroups/blkio-controller.txt
index b4b1fb3..cd556b9 100644
--- a/Documentation/cgroups/blkio-controller.txt
+++ b/Documentation/cgroups/blkio-controller.txt
@@ -75,7 +75,7 @@
mount -t cgroup -o blkio none /sys/fs/cgroup/blkio
- Specify a bandwidth rate on particular device for root group. The format
- for policy is "<major>:<minor> <byes_per_second>".
+ for policy is "<major>:<minor> <bytes_per_second>".
echo "8:16 1048576" > /sys/fs/cgroup/blkio/blkio.throttle.read_bps_device
@@ -94,13 +94,13 @@
Hierarchical Cgroups
====================
-- Currently none of the IO control policy supports hierarchical groups. But
- cgroup interface does allow creation of hierarchical cgroups and internally
- IO policies treat them as flat hierarchy.
- So this patch will allow creation of cgroup hierarchcy but at the backend
- everything will be treated as flat. So if somebody created a hierarchy like
- as follows.
+Both CFQ and throttling implement hierarchy support; however,
+throttling's hierarchy support is enabled iff "sane_behavior" is
+enabled from cgroup side, which currently is a development option and
+not publicly available.
+
+If somebody created a hierarchy like as follows.
root
/ \
@@ -108,17 +108,20 @@
|
test3
- CFQ and throttling will practically treat all groups at same level.
+CFQ by default and throttling with "sane_behavior" will handle the
+hierarchy correctly. For details on CFQ hierarchy support, refer to
+Documentation/block/cfq-iosched.txt. For throttling, all limits apply
+to the whole subtree while all statistics are local to the IOs
+directly generated by tasks in that cgroup.
+
+Throttling without "sane_behavior" enabled from cgroup side will
+practically treat all groups at same level as if it looks like the
+following.
pivot
/ / \ \
root test1 test2 test3
- Down the line we can implement hierarchical accounting/control support
- and also introduce a new cgroup file "use_hierarchy" which will control
- whether cgroup hierarchy is viewed as flat or hierarchical by the policy..
- This is how memory controller also has implemented the things.
-
Various user visible config options
===================================
CONFIG_BLK_CGROUP
@@ -172,6 +175,12 @@
dev weight
8:16 300
+- blkio.leaf_weight[_device]
+ - Equivalents of blkio.weight[_device] for the purpose of
+ deciding how much weight tasks in the given cgroup has while
+ competing with the cgroup's child cgroups. For details,
+ please refer to Documentation/block/cfq-iosched.txt.
+
- blkio.time
- disk time allocated to cgroup per device in milliseconds. First
two fields specify the major and minor number of the device and
@@ -279,6 +288,11 @@
and minor number of the device and third field specifies the number
of times a group was dequeued from a particular device.
+- blkio.*_recursive
+ - Recursive version of various stats. These files show the
+ same information as their non-recursive counterparts but
+ include stats from all the descendant cgroups.
+
Throttling/Upper limit policy files
-----------------------------------
- blkio.throttle.read_bps_device
diff --git a/Documentation/cgroups/cgroup_event_listener.c b/Documentation/cgroups/cgroup_event_listener.c
deleted file mode 100644
index 3e082f9..0000000
--- a/Documentation/cgroups/cgroup_event_listener.c
+++ /dev/null
@@ -1,110 +0,0 @@
-/*
- * cgroup_event_listener.c - Simple listener of cgroup events
- *
- * Copyright (C) Kirill A. Shutemov <kirill@shutemov.name>
- */
-
-#include <assert.h>
-#include <errno.h>
-#include <fcntl.h>
-#include <libgen.h>
-#include <limits.h>
-#include <stdio.h>
-#include <string.h>
-#include <unistd.h>
-
-#include <sys/eventfd.h>
-
-#define USAGE_STR "Usage: cgroup_event_listener <path-to-control-file> <args>\n"
-
-int main(int argc, char **argv)
-{
- int efd = -1;
- int cfd = -1;
- int event_control = -1;
- char event_control_path[PATH_MAX];
- char line[LINE_MAX];
- int ret;
-
- if (argc != 3) {
- fputs(USAGE_STR, stderr);
- return 1;
- }
-
- cfd = open(argv[1], O_RDONLY);
- if (cfd == -1) {
- fprintf(stderr, "Cannot open %s: %s\n", argv[1],
- strerror(errno));
- goto out;
- }
-
- ret = snprintf(event_control_path, PATH_MAX, "%s/cgroup.event_control",
- dirname(argv[1]));
- if (ret >= PATH_MAX) {
- fputs("Path to cgroup.event_control is too long\n", stderr);
- goto out;
- }
-
- event_control = open(event_control_path, O_WRONLY);
- if (event_control == -1) {
- fprintf(stderr, "Cannot open %s: %s\n", event_control_path,
- strerror(errno));
- goto out;
- }
-
- efd = eventfd(0, 0);
- if (efd == -1) {
- perror("eventfd() failed");
- goto out;
- }
-
- ret = snprintf(line, LINE_MAX, "%d %d %s", efd, cfd, argv[2]);
- if (ret >= LINE_MAX) {
- fputs("Arguments string is too long\n", stderr);
- goto out;
- }
-
- ret = write(event_control, line, strlen(line) + 1);
- if (ret == -1) {
- perror("Cannot write to cgroup.event_control");
- goto out;
- }
-
- while (1) {
- uint64_t result;
-
- ret = read(efd, &result, sizeof(result));
- if (ret == -1) {
- if (errno == EINTR)
- continue;
- perror("Cannot read from eventfd");
- break;
- }
- assert(ret == sizeof(result));
-
- ret = access(event_control_path, W_OK);
- if ((ret == -1) && (errno == ENOENT)) {
- puts("The cgroup seems to have removed.");
- ret = 0;
- break;
- }
-
- if (ret == -1) {
- perror("cgroup.event_control "
- "is not accessible any more");
- break;
- }
-
- printf("%s %s: crossed\n", argv[1], argv[2]);
- }
-
-out:
- if (efd >= 0)
- close(efd);
- if (event_control >= 0)
- close(event_control);
- if (cfd >= 0)
- close(cfd);
-
- return (ret != 0);
-}
diff --git a/Documentation/cgroups/cgroups.txt b/Documentation/cgroups/cgroups.txt
index bcf1a00..638bf17 100644
--- a/Documentation/cgroups/cgroups.txt
+++ b/Documentation/cgroups/cgroups.txt
@@ -442,7 +442,7 @@
You can use the cgroup.procs file instead of the tasks file to move all
threads in a threadgroup at once. Echoing the PID of any task in a
threadgroup to cgroup.procs causes all tasks in that threadgroup to be
-be attached to the cgroup. Writing 0 to cgroup.procs moves all tasks
+attached to the cgroup. Writing 0 to cgroup.procs moves all tasks
in the writing task's threadgroup.
Note: Since every task is always a member of exactly one cgroup in each
@@ -580,6 +580,7 @@
cgroup_for_each_descendant_pre() for details.
void css_offline(struct cgroup *cgrp);
+(cgroup_mutex held by caller)
This is the counterpart of css_online() and called iff css_online()
has succeeded on @cgrp. This signifies the beginning of the end of
diff --git a/Documentation/cgroups/cpusets.txt b/Documentation/cgroups/cpusets.txt
index 12e01d4..7740038 100644
--- a/Documentation/cgroups/cpusets.txt
+++ b/Documentation/cgroups/cpusets.txt
@@ -373,7 +373,7 @@
1.7 What is sched_load_balance ?
--------------------------------
-The kernel scheduler (kernel/sched.c) automatically load balances
+The kernel scheduler (kernel/sched/core.c) automatically load balances
tasks. If one CPU is underutilized, kernel code running on that
CPU will look for tasks on other more overloaded CPUs and move those
tasks to itself, within the constraints of such placement mechanisms
diff --git a/Documentation/cgroups/devices.txt b/Documentation/cgroups/devices.txt
index 16624a7f8..3c1095c 100644
--- a/Documentation/cgroups/devices.txt
+++ b/Documentation/cgroups/devices.txt
@@ -13,9 +13,7 @@
The root device cgroup starts with rwm to 'all'. A child device
cgroup gets a copy of the parent. Administrators can then remove
devices from the whitelist or add new entries. A child cgroup can
-never receive a device access which is denied by its parent. However
-when a device access is removed from a parent it will not also be
-removed from the child(ren).
+never receive a device access which is denied by its parent.
2. User Interface
@@ -50,3 +48,69 @@
A cgroup may not be granted more permissions than the cgroup's
parent has.
+
+4. Hierarchy
+
+device cgroups maintain hierarchy by making sure a cgroup never has more
+access permissions than its parent. Every time an entry is written to
+a cgroup's devices.deny file, all its children will have that entry removed
+from their whitelist and all the locally set whitelist entries will be
+re-evaluated. In case one of the locally set whitelist entries would provide
+more access than the cgroup's parent, it'll be removed from the whitelist.
+
+Example:
+ A
+ / \
+ B
+
+ group behavior exceptions
+ A allow "b 8:* rwm", "c 116:1 rw"
+ B deny "c 1:3 rwm", "c 116:2 rwm", "b 3:* rwm"
+
+If a device is denied in group A:
+ # echo "c 116:* r" > A/devices.deny
+it'll propagate down and after revalidating B's entries, the whitelist entry
+"c 116:2 rwm" will be removed:
+
+ group whitelist entries denied devices
+ A all "b 8:* rwm", "c 116:* rw"
+ B "c 1:3 rwm", "b 3:* rwm" all the rest
+
+In case parent's exceptions change and local exceptions are not allowed
+anymore, they'll be deleted.
+
+Notice that new whitelist entries will not be propagated:
+ A
+ / \
+ B
+
+ group whitelist entries denied devices
+ A "c 1:3 rwm", "c 1:5 r" all the rest
+ B "c 1:3 rwm", "c 1:5 r" all the rest
+
+when adding "c *:3 rwm":
+ # echo "c *:3 rwm" >A/devices.allow
+
+the result:
+ group whitelist entries denied devices
+ A "c *:3 rwm", "c 1:5 r" all the rest
+ B "c 1:3 rwm", "c 1:5 r" all the rest
+
+but now it'll be possible to add new entries to B:
+ # echo "c 2:3 rwm" >B/devices.allow
+ # echo "c 50:3 r" >B/devices.allow
+or even
+ # echo "c *:3 rwm" >B/devices.allow
+
+Allowing or denying all by writing 'a' to devices.allow or devices.deny will
+not be possible once the device cgroups has children.
+
+4.1 Hierarchy (internal implementation)
+
+device cgroups is implemented internally using a behavior (ALLOW, DENY) and a
+list of exceptions. The internal state is controlled using the same user
+interface to preserve compatibility with the previous whitelist-only
+implementation. Removal or addition of exceptions that will reduce the access
+to devices will be propagated down the hierarchy.
+For every propagated exception, the effective rules will be re-evaluated based
+on current parent's access rules.
diff --git a/Documentation/cgroups/memcg_test.txt b/Documentation/cgroups/memcg_test.txt
index fc8fa97..ce94a83 100644
--- a/Documentation/cgroups/memcg_test.txt
+++ b/Documentation/cgroups/memcg_test.txt
@@ -399,8 +399,7 @@
9.10 Memory thresholds
Memory controller implements memory thresholds using cgroups notification
- API. You can use Documentation/cgroups/cgroup_event_listener.c to test
- it.
+ API. You can use tools/cgroup/cgroup_event_listener.c to test it.
(Shell-A) Create cgroup and run event listener
# mkdir /cgroup/A
diff --git a/Documentation/cgroups/memory.txt b/Documentation/cgroups/memory.txt
index 8b8c28b..2a33306 100644
--- a/Documentation/cgroups/memory.txt
+++ b/Documentation/cgroups/memory.txt
@@ -40,6 +40,7 @@
- soft limit
- moving (recharging) account at moving a task is selectable.
- usage threshold notifier
+ - memory pressure notifier
- oom-killer disable knob and oom-notifier
- Root cgroup has no limit controls.
@@ -65,6 +66,7 @@
memory.stat # show various statistics
memory.use_hierarchy # set/show hierarchical account enabled
memory.force_empty # trigger forced move charge to parent
+ memory.pressure_level # set memory pressure notifications
memory.swappiness # set/show swappiness parameter of vmscan
(See sysctl's vm.swappiness)
memory.move_charge_at_immigrate # set/show controls of moving charges
@@ -194,7 +196,7 @@
But see section 8.2: when moving a task to another cgroup, its pages may
be recharged to the new cgroup, if move_charge_at_immigrate has been chosen.
-Exception: If CONFIG_CGROUP_CGROUP_MEMCG_SWAP is not used.
+Exception: If CONFIG_MEMCG_SWAP is not used.
When you do swapoff and make swapped-out pages of shmem(tmpfs) to
be backed into memory in force, charges for pages are accounted against the
caller of swapoff rather than the users of shmem.
@@ -302,7 +304,7 @@
memory usage is too high.
* slab pages: pages allocated by the SLAB or SLUB allocator are tracked. A copy
-of each kmem_cache is created everytime the cache is touched by the first time
+of each kmem_cache is created every time the cache is touched by the first time
from inside the memcg. The creation is done lazily, so some objects can still be
skipped while the cache is being created. All objects in a slab page should
belong to the same memcg. This only fails to hold when a task is migrated to a
@@ -478,7 +480,9 @@
# per-memory cgroup local status
cache - # of bytes of page cache memory.
-rss - # of bytes of anonymous and swap cache memory.
+rss - # of bytes of anonymous and swap cache memory (includes
+ transparent hugepages).
+rss_huge - # of bytes of anonymous transparent hugepages.
mapped_file - # of bytes of mapped file (includes tmpfs/shmem)
pgpgin - # of charging events to the memory cgroup. The charging
event happens each time a page is accounted as either mapped
@@ -486,10 +490,10 @@
pgpgout - # of uncharging events to the memory cgroup. The uncharging
event happens each time a page is unaccounted from the cgroup.
swap - # of bytes of swap usage
-inactive_anon - # of bytes of anonymous memory and swap cache memory on
+inactive_anon - # of bytes of anonymous and swap cache memory on inactive
LRU list.
active_anon - # of bytes of anonymous and swap cache memory on active
- inactive LRU list.
+ LRU list.
inactive_file - # of bytes of file-backed memory on inactive LRU list.
active_file - # of bytes of file-backed memory on active LRU list.
unevictable - # of bytes of memory that cannot be reclaimed (mlocked etc).
@@ -762,12 +766,77 @@
under_oom 0 or 1 (if 1, the memory cgroup is under OOM, tasks may
be stopped.)
-11. TODO
+11. Memory Pressure
-1. Add support for accounting huge pages (as a separate controller)
-2. Make per-cgroup scanner reclaim not-shared pages first
-3. Teach controller to account for shared-pages
-4. Start reclamation in the background when the limit is
+The pressure level notifications can be used to monitor the memory
+allocation cost; based on the pressure, applications can implement
+different strategies of managing their memory resources. The pressure
+levels are defined as following:
+
+The "low" level means that the system is reclaiming memory for new
+allocations. Monitoring this reclaiming activity might be useful for
+maintaining cache level. Upon notification, the program (typically
+"Activity Manager") might analyze vmstat and act in advance (i.e.
+prematurely shutdown unimportant services).
+
+The "medium" level means that the system is experiencing medium memory
+pressure, the system might be making swap, paging out active file caches,
+etc. Upon this event applications may decide to further analyze
+vmstat/zoneinfo/memcg or internal memory usage statistics and free any
+resources that can be easily reconstructed or re-read from a disk.
+
+The "critical" level means that the system is actively thrashing, it is
+about to out of memory (OOM) or even the in-kernel OOM killer is on its
+way to trigger. Applications should do whatever they can to help the
+system. It might be too late to consult with vmstat or any other
+statistics, so it's advisable to take an immediate action.
+
+The events are propagated upward until the event is handled, i.e. the
+events are not pass-through. Here is what this means: for example you have
+three cgroups: A->B->C. Now you set up an event listener on cgroups A, B
+and C, and suppose group C experiences some pressure. In this situation,
+only group C will receive the notification, i.e. groups A and B will not
+receive it. This is done to avoid excessive "broadcasting" of messages,
+which disturbs the system and which is especially bad if we are low on
+memory or thrashing. So, organize the cgroups wisely, or propagate the
+events manually (or, ask us to implement the pass-through events,
+explaining why would you need them.)
+
+The file memory.pressure_level is only used to setup an eventfd. To
+register a notification, an application must:
+
+- create an eventfd using eventfd(2);
+- open memory.pressure_level;
+- write string like "<event_fd> <fd of memory.pressure_level> <level>"
+ to cgroup.event_control.
+
+Application will be notified through eventfd when memory pressure is at
+the specific level (or higher). Read/write operations to
+memory.pressure_level are no implemented.
+
+Test:
+
+ Here is a small script example that makes a new cgroup, sets up a
+ memory limit, sets up a notification in the cgroup and then makes child
+ cgroup experience a critical pressure:
+
+ # cd /sys/fs/cgroup/memory/
+ # mkdir foo
+ # cd foo
+ # cgroup_event_listener memory.pressure_level low &
+ # echo 8000000 > memory.limit_in_bytes
+ # echo 8000000 > memory.memsw.limit_in_bytes
+ # echo $$ > tasks
+ # dd if=/dev/zero | read x
+
+ (Expect a bunch of notifications, and eventually, the oom-killer will
+ trigger.)
+
+12. TODO
+
+1. Make per-cgroup scanner reclaim not-shared pages first
+2. Teach controller to account for shared-pages
+3. Start reclamation in the background when the limit is
not yet hit but the usage is getting closer
Summary
diff --git a/Documentation/cgroups/net_cls.txt b/Documentation/cgroups/net_cls.txt
new file mode 100644
index 0000000..9face6b
--- /dev/null
+++ b/Documentation/cgroups/net_cls.txt
@@ -0,0 +1,34 @@
+Network classifier cgroup
+-------------------------
+
+The Network classifier cgroup provides an interface to
+tag network packets with a class identifier (classid).
+
+The Traffic Controller (tc) can be used to assign
+different priorities to packets from different cgroups.
+
+Creating a net_cls cgroups instance creates a net_cls.classid file.
+This net_cls.classid value is initialized to 0.
+
+You can write hexadecimal values to net_cls.classid; the format for these
+values is 0xAAAABBBB; AAAA is the major handle number and BBBB
+is the minor handle number.
+Reading net_cls.classid yields a decimal result.
+
+Example:
+mkdir /sys/fs/cgroup/net_cls
+mount -t cgroup -onet_cls net_cls /sys/fs/cgroup/net_cls
+mkdir /sys/fs/cgroup/net_cls/0
+echo 0x100001 > /sys/fs/cgroup/net_cls/0/net_cls.classid
+ - setting a 10:1 handle.
+
+cat /sys/fs/cgroup/net_cls/0/net_cls.classid
+1048577
+
+configuring tc:
+tc qdisc add dev eth0 root handle 10: htb
+
+tc class add dev eth0 parent 10: classid 10:1 htb rate 40mbit
+ - creating traffic class 10:1
+
+tc filter add dev eth0 parent 10: protocol ip prio 10 handle 1: cgroup
diff --git a/Documentation/clk.txt b/Documentation/clk.txt
index 1943fae0..6f68ba0 100644
--- a/Documentation/clk.txt
+++ b/Documentation/clk.txt
@@ -32,7 +32,7 @@
Tying the two halves of this interface together is struct clk_hw, which
is defined in struct clk_foo and pointed to within struct clk. This
-allows easy for navigation between the two discrete halves of the common
+allows for easy navigation between the two discrete halves of the common
clock interface.
Part 2 - common data structures and api
@@ -174,9 +174,9 @@
};
Below is a matrix detailing which clk_ops are mandatory based upon the
-hardware capbilities of that clock. A cell marked as "y" means
+hardware capabilities of that clock. A cell marked as "y" means
mandatory, a cell marked as "n" implies that either including that
-callback is invalid or otherwise uneccesary. Empty cells are either
+callback is invalid or otherwise unnecessary. Empty cells are either
optional or must be evaluated on a case-by-case basis.
clock hardware characteristics
@@ -231,3 +231,14 @@
statically initialized clock data MUST be defined in a separate file
from the logic that implements its ops. Basically separate the logic
from the data and all is well.
+
+ Part 6 - Disabling clock gating of unused clocks
+
+Sometimes during development it can be useful to be able to bypass the
+default disabling of unused clocks. For example, if drivers aren't enabling
+clocks properly but rely on them being on from the bootloader, bypassing
+the disabling means that the driver will remain functional while the issues
+are sorted out.
+
+To bypass this disabling, include "clk_ignore_unused" in the bootargs to the
+kernel.
diff --git a/Documentation/coccinelle.txt b/Documentation/coccinelle.txt
index cf44eb6..7f773d5 100644
--- a/Documentation/coccinelle.txt
+++ b/Documentation/coccinelle.txt
@@ -6,15 +6,17 @@
Getting Coccinelle
~~~~~~~~~~~~~~~~~~~~
-The semantic patches included in the kernel use the 'virtual rule'
-feature which was introduced in Coccinelle version 0.1.11.
+The semantic patches included in the kernel use features and options
+which are provided by Coccinelle version 1.0.0-rc11 and above.
+Using earlier versions will fail as the option names used by
+the Coccinelle files and coccicheck have been updated.
-Coccinelle (>=0.2.0) is available through the package manager
+Coccinelle is available through the package manager
of many distributions, e.g. :
- - Debian (>=squeeze)
- - Fedora (>=13)
- - Ubuntu (>=10.04 Lucid Lynx)
+ - Debian
+ - Fedora
+ - Ubuntu
- OpenSUSE
- Arch Linux
- NetBSD
@@ -36,11 +38,6 @@
sudo make install
-The semantic patches in the kernel will work best with Coccinelle version
-0.2.4 or later. Using earlier versions may incur some parse errors in the
-semantic patch code, but any results that are obtained should still be
-correct.
-
Using Coccinelle on the Linux kernel
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -48,7 +45,7 @@
Makefile. This target is named 'coccicheck' and calls the 'coccicheck'
front-end in the 'scripts' directory.
-Four modes are defined: patch, report, context, and org. The mode to
+Four basic modes are defined: patch, report, context, and org. The mode to
use is specified by setting the MODE variable with 'MODE=<mode>'.
'patch' proposes a fix, when possible.
@@ -62,18 +59,24 @@
'org' generates a report in the Org mode format of Emacs.
Note that not all semantic patches implement all modes. For easy use
-of Coccinelle, the default mode is "chain" which tries the previous
-modes in the order above until one succeeds.
+of Coccinelle, the default mode is "report".
-To make a report for every semantic patch, run the following command:
+Two other modes provide some common combinations of these modes.
- make coccicheck MODE=report
+'chain' tries the previous modes in the order above until one succeeds.
-NB: The 'report' mode is the default one.
+'rep+ctxt' runs successively the report mode and the context mode.
+ It should be used with the C option (described later)
+ which checks the code on a file basis.
-To produce patches, run:
+Examples:
+ To make a report for every semantic patch, run the following command:
- make coccicheck MODE=patch
+ make coccicheck MODE=report
+
+ To produce patches, run:
+
+ make coccicheck MODE=patch
The coccicheck target applies every semantic patch available in the
@@ -87,6 +90,15 @@
positives. Thus, reports must be carefully checked, and patches
reviewed.
+To enable verbose messages set the V= variable, for example:
+
+ make coccicheck MODE=report V=1
+
+By default, coccicheck tries to run as parallel as possible. To change
+the parallelism, set the J= variable. For example, to run across 4 CPUs:
+
+ make coccicheck MODE=report J=4
+
Using Coccinelle with a single semantic patch
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -110,7 +122,7 @@
For example, to check drivers/net/wireless/ one may write:
make coccicheck M=drivers/net/wireless/
-
+
To apply Coccinelle on a file basis, instead of a directory basis, the
following command may be used:
@@ -120,16 +132,32 @@
make C=2 CHECK="scripts/coccicheck"
+In these modes, which works on a file basis, there is no information
+about semantic patches displayed, and no commit message proposed.
+
This runs every semantic patch in scripts/coccinelle by default. The
COCCI variable may additionally be used to only apply a single
semantic patch as shown in the previous section.
-The "chain" mode is the default. You can select another one with the
+The "report" mode is the default. You can select another one with the
MODE variable explained above.
-In this mode, there is no information about semantic patches
-displayed, and no commit message proposed.
+ Additional flags
+~~~~~~~~~~~~~~~~~~
+Additional flags can be passed to spatch through the SPFLAGS
+variable.
+
+ make SPFLAGS=--use-glimpse coccicheck
+ make SPFLAGS=--use-idutils coccicheck
+
+See spatch --help to learn more about spatch options.
+
+Note that the '--use-glimpse' and '--use-idutils' options
+require external tools for indexing the code. None of them is
+thus active by default. However, by indexing the code with
+one of these tools, and according to the cocci file used,
+spatch could proceed the entire code base more quickly.
Proposing new semantic patches
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/Documentation/console/console.txt b/Documentation/console/console.txt
index 926cf1b..f93810d 100644
--- a/Documentation/console/console.txt
+++ b/Documentation/console/console.txt
@@ -12,20 +12,20 @@
any time with each driver sharing the console with other drivers including
the system driver. However, modular drivers cannot take over the console
that is currently occupied by another modular driver. (Exception: Drivers that
-call take_over_console() will succeed in the takeover regardless of the type
+call do_take_over_console() will succeed in the takeover regardless of the type
of driver occupying the consoles.) They can only take over the console that is
occupied by the system driver. In the same token, if the modular driver is
released by the console, the system driver will take over.
Modular drivers, from the programmer's point of view, has to call:
- take_over_console() - load and bind driver to console layer
- give_up_console() - unbind and unload driver
+ do_take_over_console() - load and bind driver to console layer
+ give_up_console() - unload driver, it will only work if driver is fully unbond
In newer kernels, the following are also available:
- register_con_driver()
- unregister_con_driver()
+ do_register_con_driver()
+ do_unregister_con_driver()
If sysfs is enabled, the contents of /sys/class/vtconsole can be
examined. This shows the console backends currently registered by the
@@ -94,12 +94,12 @@
Notes for developers:
=====================
-take_over_console() is now broken up into:
+do_take_over_console() is now broken up into:
- register_con_driver()
- bind_con_driver() - private function
+ do_register_con_driver()
+ do_bind_con_driver() - private function
-give_up_console() is a wrapper to unregister_con_driver(), and a driver must
+give_up_console() is a wrapper to do_unregister_con_driver(), and a driver must
be fully unbound for this call to succeed. con_is_bound() will check if the
driver is bound or not.
@@ -109,10 +109,10 @@
In order for binding to and unbinding from the console to properly work,
console drivers must follow these guidelines:
-1. All drivers, except system drivers, must call either register_con_driver()
- or take_over_console(). register_con_driver() will just add the driver to
+1. All drivers, except system drivers, must call either do_register_con_driver()
+ or do_take_over_console(). do_register_con_driver() will just add the driver to
the console's internal list. It won't take over the
- console. take_over_console(), as it name implies, will also take over (or
+ console. do_take_over_console(), as it name implies, will also take over (or
bind to) the console.
2. All resources allocated during con->con_init() must be released in
@@ -128,10 +128,10 @@
rebind the driver to the console arrives.
4. Upon exit of the driver, ensure that the driver is totally unbound. If the
- condition is satisfied, then the driver must call unregister_con_driver()
+ condition is satisfied, then the driver must call do_unregister_con_driver()
or give_up_console().
-5. unregister_con_driver() can also be called on conditions which make it
+5. do_unregister_con_driver() can also be called on conditions which make it
impossible for the driver to service console requests. This can happen
with the framebuffer console that suddenly lost all of its drivers.
diff --git a/Documentation/cpu-freq/cpu-drivers.txt b/Documentation/cpu-freq/cpu-drivers.txt
index c436096..19fa98e 100644
--- a/Documentation/cpu-freq/cpu-drivers.txt
+++ b/Documentation/cpu-freq/cpu-drivers.txt
@@ -108,8 +108,15 @@
cpufreq_driver.target is called with
these values.
-For setting some of these values, the frequency table helpers might be
-helpful. See the section 2 for more information on them.
+For setting some of these values (cpuinfo.min[max]_freq, policy->min[max]), the
+frequency table helpers might be helpful. See the section 2 for more information
+on them.
+
+SMP systems normally have same clock source for a group of cpus. For these the
+.init() would be called only once for the first online cpu. Here the .init()
+routine must initialize policy->cpus with mask of all possible cpus (Online +
+Offline) that share the clock. Then the core would copy this mask onto
+policy->related_cpus and will reset policy->cpus to carry only online cpus.
1.3 verify
@@ -178,10 +185,10 @@
As most cpufreq processors only allow for being set to a few specific
frequencies, a "frequency table" with some functions might assist in
some work of the processor driver. Such a "frequency table" consists
-of an array of struct cpufreq_freq_table entries, with any value in
-"index" you want to use, and the corresponding frequency in
+of an array of struct cpufreq_frequency_table entries, with any value in
+"driver_data" you want to use, and the corresponding frequency in
"frequency". At the end of the table, you need to add a
-cpufreq_freq_table entry with frequency set to CPUFREQ_TABLE_END. And
+cpufreq_frequency_table entry with frequency set to CPUFREQ_TABLE_END. And
if you want to skip one entry in the table, set the frequency to
CPUFREQ_ENTRY_INVALID. The entries don't need to be in ascending
order.
@@ -207,10 +214,4 @@
is the corresponding frequency table helper for the ->target
stage. Just pass the values to this function, and the unsigned int
index returns the number of the frequency table entry which contains
-the frequency the CPU shall be set to. PLEASE NOTE: This is not the
-"index" which is in this cpufreq_table_entry.index, but instead
-cpufreq_table[index]. So, the new frequency is
-cpufreq_table[index].frequency, and the value you stored into the
-frequency table "index" field is
-cpufreq_table[index].index.
-
+the frequency the CPU shall be set to.
diff --git a/Documentation/cpu-freq/governors.txt b/Documentation/cpu-freq/governors.txt
index c7a2eb8..219970b 100644
--- a/Documentation/cpu-freq/governors.txt
+++ b/Documentation/cpu-freq/governors.txt
@@ -131,8 +131,8 @@
The sampling rate is limited by the HW transition latency:
transition_latency * 100
Or by kernel restrictions:
-If CONFIG_NO_HZ is set, the limit is 10ms fixed.
-If CONFIG_NO_HZ is not set or nohz=off boot parameter is used, the
+If CONFIG_NO_HZ_COMMON is set, the limit is 10ms fixed.
+If CONFIG_NO_HZ_COMMON is not set or nohz=off boot parameter is used, the
limits depend on the CONFIG_HZ option:
HZ=1000: min=20000us (20ms)
HZ=250: min=80000us (80ms)
@@ -167,6 +167,27 @@
busy, rather than shifting back and forth in speed. This tunable has no
effect on behavior at lower speeds/lower CPU loads.
+powersave_bias: this parameter takes a value between 0 to 1000. It
+defines the percentage (times 10) value of the target frequency that
+will be shaved off of the target. For example, when set to 100 -- 10%,
+when ondemand governor would have targeted 1000 MHz, it will target
+1000 MHz - (10% of 1000 MHz) = 900 MHz instead. This is set to 0
+(disabled) by default.
+When AMD frequency sensitivity powersave bias driver --
+drivers/cpufreq/amd_freq_sensitivity.c is loaded, this parameter
+defines the workload frequency sensitivity threshold in which a lower
+frequency is chosen instead of ondemand governor's original target.
+The frequency sensitivity is a hardware reported (on AMD Family 16h
+Processors and above) value between 0 to 100% that tells software how
+the performance of the workload running on a CPU will change when
+frequency changes. A workload with sensitivity of 0% (memory/IO-bound)
+will not perform any better on higher core frequency, whereas a
+workload with sensitivity of 100% (CPU-bound) will perform better
+higher the frequency. When the driver is loaded, this is set to 400
+by default -- for CPUs running workloads with sensitivity value below
+40%, a lower frequency is chosen. Unloading the driver or writing 0
+will disable this feature.
+
2.5 Conservative
----------------
@@ -191,6 +212,12 @@
default value of '20' it means that if the CPU usage needs to be below
20% between samples to have the frequency decreased.
+sampling_down_factor: similar functionality as in "ondemand" governor.
+But in "conservative", it controls the rate at which the kernel makes
+a decision on when to decrease the frequency while running in any
+speed. Load for frequency increase is still evaluated every
+sampling rate.
+
3. The Governor Interface in the CPUfreq Core
=============================================
diff --git a/Documentation/cpu-freq/user-guide.txt b/Documentation/cpu-freq/user-guide.txt
index 04f6b32..ff2f283 100644
--- a/Documentation/cpu-freq/user-guide.txt
+++ b/Documentation/cpu-freq/user-guide.txt
@@ -190,11 +190,11 @@
first set scaling_max_freq, then
scaling_min_freq.
-affected_cpus : List of CPUs that require software coordination
- of frequency.
+affected_cpus : List of Online CPUs that require software
+ coordination of frequency.
-related_cpus : List of CPUs that need some sort of frequency
- coordination, whether software or hardware.
+related_cpus : List of Online + Offline CPUs that need software
+ coordination of frequency.
scaling_driver : Hardware driver for cpufreq.
diff --git a/Documentation/cpu-hotplug.txt b/Documentation/cpu-hotplug.txt
index 9f40135..edd4b4d 100644
--- a/Documentation/cpu-hotplug.txt
+++ b/Documentation/cpu-hotplug.txt
@@ -128,7 +128,7 @@
"Processor type and Features" -> Support for Hotpluggable CPUs
-Make sure that you have CONFIG_HOTPLUG, and CONFIG_SMP turned on as well.
+Make sure that you have CONFIG_SMP turned on as well.
You would need to enable CONFIG_HOTPLUG_CPU for SMP suspend/resume support
as well.
@@ -370,8 +370,10 @@
CPUs in MADT as hotpluggable CPUS. In the case there are no disabled CPUS
we assume 1/2 the number of CPUs currently present can be hotplugged.
- Caveat: Today's ACPI MADT can only provide 256 entries since the apicid field
- in MADT is only 8 bits.
+ Caveat: ACPI MADT can only provide 256 entries in systems with only ACPI 2.0c
+ or earlier ACPI version supported, because the apicid field in MADT is only
+ 8 bits. From ACPI 3.0, this limitation was removed since the apicid field
+ was extended to 32 bits with x2APIC introduced.
User Space Notification
diff --git a/Documentation/cpuidle/driver.txt b/Documentation/cpuidle/driver.txt
index 7a9e09e..1b0d81d 100644
--- a/Documentation/cpuidle/driver.txt
+++ b/Documentation/cpuidle/driver.txt
@@ -15,11 +15,17 @@
cpuidle driver initializes the cpuidle_device structure for each CPU device
and registers with cpuidle using cpuidle_register_device.
+If all the idle states are the same, the wrapper function cpuidle_register
+could be used instead.
+
It can also support the dynamic changes (like battery <-> AC), by using
cpuidle_pause_and_lock, cpuidle_disable_device and cpuidle_enable_device,
cpuidle_resume_and_unlock.
Interfaces:
+extern int cpuidle_register(struct cpuidle_driver *drv,
+ const struct cpumask *const coupled_cpus);
+extern int cpuidle_unregister(struct cpuidle_driver *drv);
extern int cpuidle_register_driver(struct cpuidle_driver *drv);
extern void cpuidle_unregister_driver(struct cpuidle_driver *drv);
extern int cpuidle_register_device(struct cpuidle_device *dev);
diff --git a/Documentation/crypto/async-tx-api.txt b/Documentation/crypto/async-tx-api.txt
index ba046b8..7bf1be2 100644
--- a/Documentation/crypto/async-tx-api.txt
+++ b/Documentation/crypto/async-tx-api.txt
@@ -222,5 +222,4 @@
include/linux/async_tx.h: core header file for the async_tx api
crypto/async_tx/async_tx.c: async_tx interface to dmaengine and common code
crypto/async_tx/async_memcpy.c: copy offload
-crypto/async_tx/async_memset.c: memory fill offload
crypto/async_tx/async_xor.c: xor and xor zero sum offload
diff --git a/Documentation/device-mapper/cache-policies.txt b/Documentation/device-mapper/cache-policies.txt
new file mode 100644
index 0000000..d7c440b
--- /dev/null
+++ b/Documentation/device-mapper/cache-policies.txt
@@ -0,0 +1,77 @@
+Guidance for writing policies
+=============================
+
+Try to keep transactionality out of it. The core is careful to
+avoid asking about anything that is migrating. This is a pain, but
+makes it easier to write the policies.
+
+Mappings are loaded into the policy at construction time.
+
+Every bio that is mapped by the target is referred to the policy.
+The policy can return a simple HIT or MISS or issue a migration.
+
+Currently there's no way for the policy to issue background work,
+e.g. to start writing back dirty blocks that are going to be evicte
+soon.
+
+Because we map bios, rather than requests it's easy for the policy
+to get fooled by many small bios. For this reason the core target
+issues periodic ticks to the policy. It's suggested that the policy
+doesn't update states (eg, hit counts) for a block more than once
+for each tick. The core ticks by watching bios complete, and so
+trying to see when the io scheduler has let the ios run.
+
+
+Overview of supplied cache replacement policies
+===============================================
+
+multiqueue
+----------
+
+This policy is the default.
+
+The multiqueue policy has two sets of 16 queues: one set for entries
+waiting for the cache and another one for those in the cache.
+Cache entries in the queues are aged based on logical time. Entry into
+the cache is based on variable thresholds and queue selection is based
+on hit count on entry. The policy aims to take different cache miss
+costs into account and to adjust to varying load patterns automatically.
+
+Message and constructor argument pairs are:
+ 'sequential_threshold <#nr_sequential_ios>' and
+ 'random_threshold <#nr_random_ios>'.
+
+The sequential threshold indicates the number of contiguous I/Os
+required before a stream is treated as sequential. The random threshold
+is the number of intervening non-contiguous I/Os that must be seen
+before the stream is treated as random again.
+
+The sequential and random thresholds default to 512 and 4 respectively.
+
+Large, sequential ios are probably better left on the origin device
+since spindles tend to have good bandwidth. The io_tracker counts
+contiguous I/Os to try to spot when the io is in one of these sequential
+modes.
+
+cleaner
+-------
+
+The cleaner writes back all dirty blocks in a cache to decommission it.
+
+Examples
+========
+
+The syntax for a table is:
+ cache <metadata dev> <cache dev> <origin dev> <block size>
+ <#feature_args> [<feature arg>]*
+ <policy> <#policy_args> [<policy arg>]*
+
+The syntax to send a message using the dmsetup command is:
+ dmsetup message <mapped device> 0 sequential_threshold 1024
+ dmsetup message <mapped device> 0 random_threshold 8
+
+Using dmsetup:
+ dmsetup create blah --table "0 268435456 cache /dev/sdb /dev/sdc \
+ /dev/sdd 512 0 mq 4 sequential_threshold 1024 random_threshold 8"
+ creates a 128GB large mapped device named 'blah' with the
+ sequential threshold set to 1024 and the random_threshold set to 8.
diff --git a/Documentation/device-mapper/cache.txt b/Documentation/device-mapper/cache.txt
new file mode 100644
index 0000000..e8cdf72
--- /dev/null
+++ b/Documentation/device-mapper/cache.txt
@@ -0,0 +1,243 @@
+Introduction
+============
+
+dm-cache is a device mapper target written by Joe Thornber, Heinz
+Mauelshagen, and Mike Snitzer.
+
+It aims to improve performance of a block device (eg, a spindle) by
+dynamically migrating some of its data to a faster, smaller device
+(eg, an SSD).
+
+This device-mapper solution allows us to insert this caching at
+different levels of the dm stack, for instance above the data device for
+a thin-provisioning pool. Caching solutions that are integrated more
+closely with the virtual memory system should give better performance.
+
+The target reuses the metadata library used in the thin-provisioning
+library.
+
+The decision as to what data to migrate and when is left to a plug-in
+policy module. Several of these have been written as we experiment,
+and we hope other people will contribute others for specific io
+scenarios (eg. a vm image server).
+
+Glossary
+========
+
+ Migration - Movement of the primary copy of a logical block from one
+ device to the other.
+ Promotion - Migration from slow device to fast device.
+ Demotion - Migration from fast device to slow device.
+
+The origin device always contains a copy of the logical block, which
+may be out of date or kept in sync with the copy on the cache device
+(depending on policy).
+
+Design
+======
+
+Sub-devices
+-----------
+
+The target is constructed by passing three devices to it (along with
+other parameters detailed later):
+
+1. An origin device - the big, slow one.
+
+2. A cache device - the small, fast one.
+
+3. A small metadata device - records which blocks are in the cache,
+ which are dirty, and extra hints for use by the policy object.
+ This information could be put on the cache device, but having it
+ separate allows the volume manager to configure it differently,
+ e.g. as a mirror for extra robustness.
+
+Fixed block size
+----------------
+
+The origin is divided up into blocks of a fixed size. This block size
+is configurable when you first create the cache. Typically we've been
+using block sizes of 256k - 1024k.
+
+Having a fixed block size simplifies the target a lot. But it is
+something of a compromise. For instance, a small part of a block may be
+getting hit a lot, yet the whole block will be promoted to the cache.
+So large block sizes are bad because they waste cache space. And small
+block sizes are bad because they increase the amount of metadata (both
+in core and on disk).
+
+Writeback/writethrough
+----------------------
+
+The cache has two modes, writeback and writethrough.
+
+If writeback, the default, is selected then a write to a block that is
+cached will go only to the cache and the block will be marked dirty in
+the metadata.
+
+If writethrough is selected then a write to a cached block will not
+complete until it has hit both the origin and cache devices. Clean
+blocks should remain clean.
+
+A simple cleaner policy is provided, which will clean (write back) all
+dirty blocks in a cache. Useful for decommissioning a cache.
+
+Migration throttling
+--------------------
+
+Migrating data between the origin and cache device uses bandwidth.
+The user can set a throttle to prevent more than a certain amount of
+migration occurring at any one time. Currently we're not taking any
+account of normal io traffic going to the devices. More work needs
+doing here to avoid migrating during those peak io moments.
+
+For the time being, a message "migration_threshold <#sectors>"
+can be used to set the maximum number of sectors being migrated,
+the default being 204800 sectors (or 100MB).
+
+Updating on-disk metadata
+-------------------------
+
+On-disk metadata is committed every time a REQ_SYNC or REQ_FUA bio is
+written. If no such requests are made then commits will occur every
+second. This means the cache behaves like a physical disk that has a
+write cache (the same is true of the thin-provisioning target). If
+power is lost you may lose some recent writes. The metadata should
+always be consistent in spite of any crash.
+
+The 'dirty' state for a cache block changes far too frequently for us
+to keep updating it on the fly. So we treat it as a hint. In normal
+operation it will be written when the dm device is suspended. If the
+system crashes all cache blocks will be assumed dirty when restarted.
+
+Per-block policy hints
+----------------------
+
+Policy plug-ins can store a chunk of data per cache block. It's up to
+the policy how big this chunk is, but it should be kept small. Like the
+dirty flags this data is lost if there's a crash so a safe fallback
+value should always be possible.
+
+For instance, the 'mq' policy, which is currently the default policy,
+uses this facility to store the hit count of the cache blocks. If
+there's a crash this information will be lost, which means the cache
+may be less efficient until those hit counts are regenerated.
+
+Policy hints affect performance, not correctness.
+
+Policy messaging
+----------------
+
+Policies will have different tunables, specific to each one, so we
+need a generic way of getting and setting these. Device-mapper
+messages are used. Refer to cache-policies.txt.
+
+Discard bitset resolution
+-------------------------
+
+We can avoid copying data during migration if we know the block has
+been discarded. A prime example of this is when mkfs discards the
+whole block device. We store a bitset tracking the discard state of
+blocks. However, we allow this bitset to have a different block size
+from the cache blocks. This is because we need to track the discard
+state for all of the origin device (compare with the dirty bitset
+which is just for the smaller cache device).
+
+Target interface
+================
+
+Constructor
+-----------
+
+ cache <metadata dev> <cache dev> <origin dev> <block size>
+ <#feature args> [<feature arg>]*
+ <policy> <#policy args> [policy args]*
+
+ metadata dev : fast device holding the persistent metadata
+ cache dev : fast device holding cached data blocks
+ origin dev : slow device holding original data blocks
+ block size : cache unit size in sectors
+
+ #feature args : number of feature arguments passed
+ feature args : writethrough. (The default is writeback.)
+
+ policy : the replacement policy to use
+ #policy args : an even number of arguments corresponding to
+ key/value pairs passed to the policy
+ policy args : key/value pairs passed to the policy
+ E.g. 'sequential_threshold 1024'
+ See cache-policies.txt for details.
+
+Optional feature arguments are:
+ writethrough : write through caching that prohibits cache block
+ content from being different from origin block content.
+ Without this argument, the default behaviour is to write
+ back cache block contents later for performance reasons,
+ so they may differ from the corresponding origin blocks.
+
+A policy called 'default' is always registered. This is an alias for
+the policy we currently think is giving best all round performance.
+
+As the default policy could vary between kernels, if you are relying on
+the characteristics of a specific policy, always request it by name.
+
+Status
+------
+
+<#used metadata blocks>/<#total metadata blocks> <#read hits> <#read misses>
+<#write hits> <#write misses> <#demotions> <#promotions> <#blocks in cache>
+<#dirty> <#features> <features>* <#core args> <core args>* <#policy args>
+<policy args>*
+
+#used metadata blocks : Number of metadata blocks used
+#total metadata blocks : Total number of metadata blocks
+#read hits : Number of times a READ bio has been mapped
+ to the cache
+#read misses : Number of times a READ bio has been mapped
+ to the origin
+#write hits : Number of times a WRITE bio has been mapped
+ to the cache
+#write misses : Number of times a WRITE bio has been
+ mapped to the origin
+#demotions : Number of times a block has been removed
+ from the cache
+#promotions : Number of times a block has been moved to
+ the cache
+#blocks in cache : Number of blocks resident in the cache
+#dirty : Number of blocks in the cache that differ
+ from the origin
+#feature args : Number of feature args to follow
+feature args : 'writethrough' (optional)
+#core args : Number of core arguments (must be even)
+core args : Key/value pairs for tuning the core
+ e.g. migration_threshold
+#policy args : Number of policy arguments to follow (must be even)
+policy args : Key/value pairs
+ e.g. 'sequential_threshold 1024
+
+Messages
+--------
+
+Policies will have different tunables, specific to each one, so we
+need a generic way of getting and setting these. Device-mapper
+messages are used. (A sysfs interface would also be possible.)
+
+The message format is:
+
+ <key> <value>
+
+E.g.
+ dmsetup message my_cache 0 sequential_threshold 1024
+
+Examples
+========
+
+The test suite can be found here:
+
+https://github.com/jthornber/thinp-test-suite
+
+dmsetup create my_cache --table '0 41943040 cache /dev/mapper/metadata \
+ /dev/mapper/ssd /dev/mapper/origin 512 1 writeback default 0'
+dmsetup create my_cache --table '0 41943040 cache /dev/mapper/metadata \
+ /dev/mapper/ssd /dev/mapper/origin 1024 1 writeback \
+ mq 4 sequential_threshold 1024 random_threshold 8'
diff --git a/Documentation/device-mapper/dm-raid.txt b/Documentation/device-mapper/dm-raid.txt
index 728c38c..ef8ba9f 100644
--- a/Documentation/device-mapper/dm-raid.txt
+++ b/Documentation/device-mapper/dm-raid.txt
@@ -1,10 +1,13 @@
dm-raid
--------
+=======
The device-mapper RAID (dm-raid) target provides a bridge from DM to MD.
It allows the MD RAID drivers to be accessed using a device-mapper
interface.
+
+Mapping Table Interface
+-----------------------
The target is named "raid" and it accepts the following parameters:
<raid_type> <#raid_params> <raid_params> \
@@ -30,6 +33,7 @@
raid10 Various RAID10 inspired algorithms chosen by additional params
- RAID10: Striped Mirrors (aka 'Striping on top of mirrors')
- RAID1E: Integrated Adjacent Stripe Mirroring
+ - RAID1E: Integrated Offset Stripe Mirroring
- and other similar RAID10 variants
Reference: Chapter 4 of
@@ -46,7 +50,7 @@
followed by optional parameters (in any order):
[sync|nosync] Force or prevent RAID initialization.
- [rebuild <idx>] Rebuild drive number idx (first drive is 0).
+ [rebuild <idx>] Rebuild drive number 'idx' (first drive is 0).
[daemon_sleep <ms>]
Interval between runs of the bitmap daemon that
@@ -55,24 +59,24 @@
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
- [write_mostly <idx>] Drive index is write-mostly
- [max_write_behind <sectors>] See '-write-behind=' (man mdadm)
- [stripe_cache <sectors>] Stripe cache size (higher RAIDs only)
+ [write_mostly <idx>] Mark drive index 'idx' write-mostly.
+ [max_write_behind <sectors>] See '--write-behind=' (man mdadm)
+ [stripe_cache <sectors>] Stripe cache size (RAID 4/5/6 only)
[region_size <sectors>]
The region_size multiplied by the number of regions is the
logical size of the array. The bitmap records the device
synchronisation state for each region.
[raid10_copies <# copies>]
- [raid10_format near]
+ [raid10_format <near|far|offset>]
These two options are used to alter the default layout of
a RAID10 configuration. The number of copies is can be
- specified, but the default is 2. There are other variations
- to how the copies are laid down - the default and only current
- option is "near". Near copies are what most people think of
- with respect to mirroring. If these options are left
- unspecified, or 'raid10_copies 2' and/or 'raid10_format near'
- are given, then the layouts for 2, 3 and 4 devices are:
+ specified, but the default is 2. There are also three
+ variations to how the copies are laid down - the default
+ is "near". Near copies are what most people think of with
+ respect to mirroring. If these options are left unspecified,
+ or 'raid10_copies 2' and/or 'raid10_format near' are given,
+ then the layouts for 2, 3 and 4 devices are:
2 drives 3 drives 4 drives
-------- ---------- --------------
A1 A1 A1 A1 A2 A1 A1 A2 A2
@@ -85,6 +89,33 @@
3-device layout is what might be called a 'RAID1E - Integrated
Adjacent Stripe Mirroring'.
+ If 'raid10_copies 2' and 'raid10_format far', then the layouts
+ for 2, 3 and 4 devices are:
+ 2 drives 3 drives 4 drives
+ -------- -------------- --------------------
+ A1 A2 A1 A2 A3 A1 A2 A3 A4
+ A3 A4 A4 A5 A6 A5 A6 A7 A8
+ A5 A6 A7 A8 A9 A9 A10 A11 A12
+ .. .. .. .. .. .. .. .. ..
+ A2 A1 A3 A1 A2 A2 A1 A4 A3
+ A4 A3 A6 A4 A5 A6 A5 A8 A7
+ A6 A5 A9 A7 A8 A10 A9 A12 A11
+ .. .. .. .. .. .. .. .. ..
+
+ If 'raid10_copies 2' and 'raid10_format offset', then the
+ layouts for 2, 3 and 4 devices are:
+ 2 drives 3 drives 4 drives
+ -------- ------------ -----------------
+ A1 A2 A1 A2 A3 A1 A2 A3 A4
+ A2 A1 A3 A1 A2 A2 A1 A4 A3
+ A3 A4 A4 A5 A6 A5 A6 A7 A8
+ A4 A3 A6 A4 A5 A6 A5 A8 A7
+ A5 A6 A7 A8 A9 A9 A10 A11 A12
+ A6 A5 A9 A7 A8 A10 A9 A12 A11
+ .. .. .. .. .. .. .. .. ..
+ Here we see layouts closely akin to 'RAID1E - Integrated
+ Offset Stripe Mirroring'.
+
<#raid_devs>: The number of devices composing the array.
Each device consists of two entries. The first is the device
containing the metadata (if any); the second is the one containing the
@@ -94,7 +125,7 @@
given for both the metadata and data drives for a given position.
-Example tables
+Example Tables
--------------
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# No metadata devices specified to hold superblock/bitmap info
@@ -113,26 +144,70 @@
raid4 4 2048 sync min_recovery_rate 20 \
5 8:17 8:18 8:33 8:34 8:49 8:50 8:65 8:66 8:81 8:82
+
+Status Output
+-------------
'dmsetup table' displays the table used to construct the mapping.
The optional parameters are always printed in the order listed
above with "sync" or "nosync" always output ahead of the other
arguments, regardless of the order used when originally loading the table.
Arguments that can be repeated are ordered by value.
-'dmsetup status' yields information on the state and health of the
-array.
-The output is as follows:
+
+'dmsetup status' yields information on the state and health of the array.
+The output is as follows (normally a single line, but expanded here for
+clarity):
1: <s> <l> raid \
-2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
+2: <raid_type> <#devices> <health_chars> \
+3: <sync_ratio> <sync_action> <mismatch_cnt>
Line 1 is the standard output produced by device-mapper.
-Line 2 is produced by the raid target, and best explained by example:
- 0 1960893648 raid raid4 5 AAAAA 2/490221568
+Line 2 & 3 are produced by the raid target and are best explained by example:
+ 0 1960893648 raid raid4 5 AAAAA 2/490221568 init 0
Here we can see the RAID type is raid4, there are 5 devices - all of
-which are 'A'live, and the array is 2/490221568 complete with recovery.
-Faulty or missing devices are marked 'D'. Devices that are out-of-sync
-are marked 'a'.
+which are 'A'live, and the array is 2/490221568 complete with its initial
+recovery. Here is a fuller description of the individual fields:
+ <raid_type> Same as the <raid_type> used to create the array.
+ <health_chars> One char for each device, indicating: 'A' = alive and
+ in-sync, 'a' = alive but not in-sync, 'D' = dead/failed.
+ <sync_ratio> The ratio indicating how much of the array has undergone
+ the process described by 'sync_action'. If the
+ 'sync_action' is "check" or "repair", then the process
+ of "resync" or "recover" can be considered complete.
+ <sync_action> One of the following possible states:
+ idle - No synchronization action is being performed.
+ frozen - The current action has been halted.
+ resync - Array is undergoing its initial synchronization
+ or is resynchronizing after an unclean shutdown
+ (possibly aided by a bitmap).
+ recover - A device in the array is being rebuilt or
+ replaced.
+ check - A user-initiated full check of the array is
+ being performed. All blocks are read and
+ checked for consistency. The number of
+ discrepancies found are recorded in
+ <mismatch_cnt>. No changes are made to the
+ array by this action.
+ repair - The same as "check", but discrepancies are
+ corrected.
+ reshape - The array is undergoing a reshape.
+ <mismatch_cnt> The number of discrepancies found between mirror copies
+ in RAID1/10 or wrong parity values found in RAID4/5/6.
+ This value is valid only after a "check" of the array
+ is performed. A healthy array has a 'mismatch_cnt' of 0.
+Message Interface
+-----------------
+The dm-raid target will accept certain actions through the 'message' interface.
+('man dmsetup' for more information on the message interface.) These actions
+include:
+ "idle" - Halt the current sync action.
+ "frozen" - Freeze the current sync action.
+ "resync" - Initiate/continue a resync.
+ "recover"- Initiate/continue a recover process.
+ "check" - Initiate a check (i.e. a "scrub") of the array.
+ "repair" - Initiate a repair of the array.
+ "reshape"- Currently unsupported (-EINVAL).
Version History
---------------
@@ -141,3 +216,11 @@
1.2.0 Handle creation of arrays that contain failed devices.
1.3.0 Added support for RAID 10
1.3.1 Allow device replacement/rebuild for RAID 10
+1.3.2 Fix/improve redundancy checking for RAID10
+1.4.0 Non-functional change. Removes arg from mapping function.
+1.4.1 RAID10 fix redundancy validation checks (commit 55ebbb5).
+1.4.2 Add RAID10 "far" and "offset" algorithm support.
+1.5.0 Add message interface to allow manipulation of the sync_action.
+ New status (STATUSTYPE_INFO) fields: sync_action and mismatch_cnt.
+1.5.1 Add ability to restore transiently failed devices on resume.
+1.5.2 'mismatch_cnt' is zero unless [last_]sync_action is "check".
diff --git a/Documentation/device-mapper/switch.txt b/Documentation/device-mapper/switch.txt
new file mode 100644
index 0000000..2fa7493
--- /dev/null
+++ b/Documentation/device-mapper/switch.txt
@@ -0,0 +1,126 @@
+dm-switch
+=========
+
+The device-mapper switch target creates a device that supports an
+arbitrary mapping of fixed-size regions of I/O across a fixed set of
+paths. The path used for any specific region can be switched
+dynamically by sending the target a message.
+
+It maps I/O to underlying block devices efficiently when there is a large
+number of fixed-sized address regions but there is no simple pattern
+that would allow for a compact representation of the mapping such as
+dm-stripe.
+
+Background
+----------
+
+Dell EqualLogic and some other iSCSI storage arrays use a distributed
+frameless architecture. In this architecture, the storage group
+consists of a number of distinct storage arrays ("members") each having
+independent controllers, disk storage and network adapters. When a LUN
+is created it is spread across multiple members. The details of the
+spreading are hidden from initiators connected to this storage system.
+The storage group exposes a single target discovery portal, no matter
+how many members are being used. When iSCSI sessions are created, each
+session is connected to an eth port on a single member. Data to a LUN
+can be sent on any iSCSI session, and if the blocks being accessed are
+stored on another member the I/O will be forwarded as required. This
+forwarding is invisible to the initiator. The storage layout is also
+dynamic, and the blocks stored on disk may be moved from member to
+member as needed to balance the load.
+
+This architecture simplifies the management and configuration of both
+the storage group and initiators. In a multipathing configuration, it
+is possible to set up multiple iSCSI sessions to use multiple network
+interfaces on both the host and target to take advantage of the
+increased network bandwidth. An initiator could use a simple round
+robin algorithm to send I/O across all paths and let the storage array
+members forward it as necessary, but there is a performance advantage to
+sending data directly to the correct member.
+
+A device-mapper table already lets you map different regions of a
+device onto different targets. However in this architecture the LUN is
+spread with an address region size on the order of 10s of MBs, which
+means the resulting table could have more than a million entries and
+consume far too much memory.
+
+Using this device-mapper switch target we can now build a two-layer
+device hierarchy:
+
+ Upper Tier – Determine which array member the I/O should be sent to.
+ Lower Tier – Load balance amongst paths to a particular member.
+
+The lower tier consists of a single dm multipath device for each member.
+Each of these multipath devices contains the set of paths directly to
+the array member in one priority group, and leverages existing path
+selectors to load balance amongst these paths. We also build a
+non-preferred priority group containing paths to other array members for
+failover reasons.
+
+The upper tier consists of a single dm-switch device. This device uses
+a bitmap to look up the location of the I/O and choose the appropriate
+lower tier device to route the I/O. By using a bitmap we are able to
+use 4 bits for each address range in a 16 member group (which is very
+large for us). This is a much denser representation than the dm table
+b-tree can achieve.
+
+Construction Parameters
+=======================
+
+ <num_paths> <region_size> <num_optional_args> [<optional_args>...]
+ [<dev_path> <offset>]+
+
+<num_paths>
+ The number of paths across which to distribute the I/O.
+
+<region_size>
+ The number of 512-byte sectors in a region. Each region can be redirected
+ to any of the available paths.
+
+<num_optional_args>
+ The number of optional arguments. Currently, no optional arguments
+ are supported and so this must be zero.
+
+<dev_path>
+ The block device that represents a specific path to the device.
+
+<offset>
+ The offset of the start of data on the specific <dev_path> (in units
+ of 512-byte sectors). This number is added to the sector number when
+ forwarding the request to the specific path. Typically it is zero.
+
+Messages
+========
+
+set_region_mappings <index>:<path_nr> [<index>]:<path_nr> [<index>]:<path_nr>...
+
+Modify the region table by specifying which regions are redirected to
+which paths.
+
+<index>
+ The region number (region size was specified in constructor parameters).
+ If index is omitted, the next region (previous index + 1) is used.
+ Expressed in hexadecimal (WITHOUT any prefix like 0x).
+
+<path_nr>
+ The path number in the range 0 ... (<num_paths> - 1).
+ Expressed in hexadecimal (WITHOUT any prefix like 0x).
+
+Status
+======
+
+No status line is reported.
+
+Example
+=======
+
+Assume that you have volumes vg1/switch0 vg1/switch1 vg1/switch2 with
+the same size.
+
+Create a switch device with 64kB region size:
+ dmsetup create switch --table "0 `blockdev --getsize /dev/vg1/switch0`
+ switch 3 128 0 /dev/vg1/switch0 0 /dev/vg1/switch1 0 /dev/vg1/switch2 0"
+
+Set mappings for the first 7 entries to point to devices switch0, switch1,
+switch2, switch0, switch1, switch2, switch1:
+ dmsetup message switch 0 set_region_mappings 0:0 :1 :2 :0 :1 :2 :1
diff --git a/Documentation/devices.txt b/Documentation/devices.txt
index 08f01e7..23721d3 100644
--- a/Documentation/devices.txt
+++ b/Documentation/devices.txt
@@ -100,8 +100,7 @@
10 = /dev/aio Asynchronous I/O notification interface
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.
+ 12 = /dev/oldmem OBSOLETE - replaced by /proc/vmcore
1 block RAM disk
0 = /dev/ram0 First RAM disk
@@ -498,12 +497,8 @@
Each device type has 5 bits (32 minors).
- 13 block 8-bit MFM/RLL/IDE controller
- 0 = /dev/xda First XT disk whole disk
- 64 = /dev/xdb Second XT disk whole disk
-
- Partitions are handled in the same way as IDE disks
- (see major number 3).
+ 13 block Previously used for the XT disk (/dev/xdN)
+ Deleted in kernel v3.9.
14 char Open Sound System (OSS)
0 = /dev/mixer Mixer control
diff --git a/Documentation/devicetree/bindings/arc/interrupts.txt b/Documentation/devicetree/bindings/arc/interrupts.txt
new file mode 100644
index 0000000..9a5d562
--- /dev/null
+++ b/Documentation/devicetree/bindings/arc/interrupts.txt
@@ -0,0 +1,24 @@
+* ARC700 incore Interrupt Controller
+
+ The core interrupt controller provides 32 prioritised interrupts (2 levels)
+ to ARC700 core.
+
+Properties:
+
+- compatible: "snps,arc700-intc"
+- interrupt-controller: This is an interrupt controller.
+- #interrupt-cells: Must be <1>.
+
+ Single Cell "interrupts" property of a device specifies the IRQ number
+ between 0 to 31
+
+ intc accessed via the special ARC AUX register interface, hence "reg" property
+ is not specified.
+
+Example:
+
+ intc: interrupt-controller {
+ compatible = "snps,arc700-intc";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/arm/altera/socfpga-clk-manager.txt b/Documentation/devicetree/bindings/arm/altera/socfpga-clk-manager.txt
new file mode 100644
index 0000000..2c28f1d
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/altera/socfpga-clk-manager.txt
@@ -0,0 +1,11 @@
+Altera SOCFPGA Clock Manager
+
+Required properties:
+- compatible : "altr,clk-mgr"
+- reg : Should contain base address and length for Clock Manager
+
+Example:
+ clkmgr@ffd04000 {
+ compatible = "altr,clk-mgr";
+ reg = <0xffd04000 0x1000>;
+ };
diff --git a/Documentation/devicetree/bindings/arm/altera/socfpga-system.txt b/Documentation/devicetree/bindings/arm/altera/socfpga-system.txt
index 07c65e3..f4d04a0 100644
--- a/Documentation/devicetree/bindings/arm/altera/socfpga-system.txt
+++ b/Documentation/devicetree/bindings/arm/altera/socfpga-system.txt
@@ -3,9 +3,11 @@
Required properties:
- compatible : "altr,sys-mgr"
- reg : Should contain 1 register ranges(address and length)
+- cpu1-start-addr : CPU1 start address in hex.
Example:
sysmgr@ffd08000 {
compatible = "altr,sys-mgr";
reg = <0xffd08000 0x1000>;
+ cpu1-start-addr = <0xffd080c4>;
};
diff --git a/Documentation/devicetree/bindings/arm/arch_timer.txt b/Documentation/devicetree/bindings/arm/arch_timer.txt
index 52478c8..20746e5 100644
--- a/Documentation/devicetree/bindings/arm/arch_timer.txt
+++ b/Documentation/devicetree/bindings/arm/arch_timer.txt
@@ -1,13 +1,14 @@
* ARM architected timer
-ARM Cortex-A7 and Cortex-A15 have a per-core architected timer, which
-provides per-cpu timers.
+ARM cores may have a per-core architected timer, which provides per-cpu timers.
The timer is attached to a GIC to deliver its per-processor interrupts.
** Timer node properties:
-- compatible : Should at least contain "arm,armv7-timer".
+- compatible : Should at least contain one of
+ "arm,armv7-timer"
+ "arm,armv8-timer"
- interrupts : Interrupt list for secure, non-secure, virtual and
hypervisor timers, in that order.
diff --git a/Documentation/devicetree/bindings/arm/armada-370-xp-timer.txt b/Documentation/devicetree/bindings/arm/armada-370-xp-timer.txt
deleted file mode 100644
index 6483011..0000000
--- a/Documentation/devicetree/bindings/arm/armada-370-xp-timer.txt
+++ /dev/null
@@ -1,12 +0,0 @@
-Marvell Armada 370 and Armada XP Global Timers
-----------------------------------------------
-
-Required properties:
-- compatible: Should be "marvell,armada-370-xp-timer"
-- interrupts: Should contain the list of Global Timer interrupts
-- reg: Should contain the base address of the Global Timer registers
-- clocks: clock driving the timer hardware
-
-Optional properties:
-- marvell,timer-25Mhz: Tells whether the Global timer supports the 25
- Mhz fixed mode (available on Armada XP and not on Armada 370)
diff --git a/Documentation/devicetree/bindings/arm/armadeus.txt b/Documentation/devicetree/bindings/arm/armadeus.txt
new file mode 100644
index 0000000..9821283
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/armadeus.txt
@@ -0,0 +1,6 @@
+Armadeus i.MX Platforms Device Tree Bindings
+-----------------------------------------------
+
+APF51: i.MX51 based module.
+Required root node properties:
+ - compatible = "armadeus,imx51-apf51", "fsl,imx51";
diff --git a/Documentation/devicetree/bindings/arm/atmel-adc.txt b/Documentation/devicetree/bindings/arm/atmel-adc.txt
index c63097d..16769d9 100644
--- a/Documentation/devicetree/bindings/arm/atmel-adc.txt
+++ b/Documentation/devicetree/bindings/arm/atmel-adc.txt
@@ -14,9 +14,19 @@
- 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
+ - atmel,adc-res: List of resolution in bits supported by the ADC. List size
+ must be two at least.
+ - atmel,adc-res-names: Contains one identifier string for each resolution
+ in atmel,adc-res property. "lowres" and "highres"
+ identifiers are required.
Optional properties:
- atmel,adc-use-external: Boolean to enable of external triggers
+ - atmel,adc-use-res: String corresponding to an identifier from
+ atmel,adc-res-names property. If not specified, the highest
+ resolution will be used.
+ - atmel,adc-sleep-mode: Boolean to enable sleep mode when no conversion
+ - atmel,adc-sample-hold-time: Sample and Hold Time in microseconds
Optional trigger Nodes:
- Required properties:
@@ -40,6 +50,9 @@
atmel,adc-trigger-register = <0x08>;
atmel,adc-use-external;
atmel,adc-vref = <3300>;
+ atmel,adc-res = <8 10>;
+ atmel,adc-res-names = "lowres", "highres";
+ atmel,adc-use-res = "lowres";
trigger@0 {
trigger-name = "external-rising";
diff --git a/Documentation/devicetree/bindings/arm/atmel-aic.txt b/Documentation/devicetree/bindings/arm/atmel-aic.txt
index 19078bf..ad03121 100644
--- a/Documentation/devicetree/bindings/arm/atmel-aic.txt
+++ b/Documentation/devicetree/bindings/arm/atmel-aic.txt
@@ -4,7 +4,7 @@
- compatible: Should be "atmel,<chip>-aic"
- interrupt-controller: Identifies the node as an interrupt controller.
- interrupt-parent: For single AIC system, it is an empty property.
-- #interrupt-cells: The number of cells to define the interrupts. It sould be 3.
+- #interrupt-cells: The number of cells to define the interrupts. It should be 3.
The first cell is the IRQ number (aka "Peripheral IDentifier" on datasheet).
The second cell is used to specify flags:
bits[3:0] trigger type and level flags:
diff --git a/Documentation/devicetree/bindings/arm/bcm/bcm,kona-timer.txt b/Documentation/devicetree/bindings/arm/bcm/bcm,kona-timer.txt
new file mode 100644
index 0000000..59fa6e6
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/bcm/bcm,kona-timer.txt
@@ -0,0 +1,19 @@
+Broadcom Kona Family timer
+-----------------------------------------------------
+This timer is used in the following Broadcom SoCs:
+ BCM11130, BCM11140, BCM11351, BCM28145, BCM28155
+
+Required properties:
+- compatible : "bcm,kona-timer"
+- reg : Register range for the timer
+- interrupts : interrupt for the timer
+- clock-frequency: frequency that the clock operates
+
+Example:
+ timer@35006000 {
+ compatible = "bcm,kona-timer";
+ reg = <0x35006000 0x1000>;
+ interrupts = <0x0 7 0x4>;
+ clock-frequency = <32768>;
+ };
+
diff --git a/Documentation/devicetree/bindings/arm/cci.txt b/Documentation/devicetree/bindings/arm/cci.txt
new file mode 100644
index 0000000..92d36e2
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/cci.txt
@@ -0,0 +1,172 @@
+=======================================================
+ARM CCI cache coherent interconnect binding description
+=======================================================
+
+ARM multi-cluster systems maintain intra-cluster coherency through a
+cache coherent interconnect (CCI) that is capable of monitoring bus
+transactions and manage coherency, TLB invalidations and memory barriers.
+
+It allows snooping and distributed virtual memory message broadcast across
+clusters, through memory mapped interface, with a global control register
+space and multiple sets of interface control registers, one per slave
+interface.
+
+Bindings for the CCI node follow the ePAPR standard, available from:
+
+www.power.org/documentation/epapr-version-1-1/
+
+with the addition of the bindings described in this document which are
+specific to ARM.
+
+* CCI interconnect node
+
+ Description: Describes a CCI cache coherent Interconnect component
+
+ Node name must be "cci".
+ Node's parent must be the root node /, and the address space visible
+ through the CCI interconnect is the same as the one seen from the
+ root node (ie from CPUs perspective as per DT standard).
+ Every CCI node has to define the following properties:
+
+ - compatible
+ Usage: required
+ Value type: <string>
+ Definition: must be set to
+ "arm,cci-400"
+
+ - reg
+ Usage: required
+ Value type: <prop-encoded-array>
+ Definition: A standard property. Specifies base physical
+ address of CCI control registers common to all
+ interfaces.
+
+ - ranges:
+ Usage: required
+ Value type: <prop-encoded-array>
+ Definition: A standard property. Follow rules in the ePAPR for
+ hierarchical bus addressing. CCI interfaces
+ addresses refer to the parent node addressing
+ scheme to declare their register bases.
+
+ CCI interconnect node can define the following child nodes:
+
+ - CCI control interface nodes
+
+ Node name must be "slave-if".
+ Parent node must be CCI interconnect node.
+
+ A CCI control interface node must contain the following
+ properties:
+
+ - compatible
+ Usage: required
+ Value type: <string>
+ Definition: must be set to
+ "arm,cci-400-ctrl-if"
+
+ - interface-type:
+ Usage: required
+ Value type: <string>
+ Definition: must be set to one of {"ace", "ace-lite"}
+ depending on the interface type the node
+ represents.
+
+ - reg:
+ Usage: required
+ Value type: <prop-encoded-array>
+ Definition: the base address and size of the
+ corresponding interface programming
+ registers.
+
+* CCI interconnect bus masters
+
+ Description: masters in the device tree connected to a CCI port
+ (inclusive of CPUs and their cpu nodes).
+
+ A CCI interconnect bus master node must contain the following
+ properties:
+
+ - cci-control-port:
+ Usage: required
+ Value type: <phandle>
+ Definition: a phandle containing the CCI control interface node
+ the master is connected to.
+
+Example:
+
+ cpus {
+ #size-cells = <0>;
+ #address-cells = <1>;
+
+ CPU0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a15";
+ cci-control-port = <&cci_control1>;
+ reg = <0x0>;
+ };
+
+ CPU1: cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a15";
+ cci-control-port = <&cci_control1>;
+ reg = <0x1>;
+ };
+
+ CPU2: cpu@100 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ cci-control-port = <&cci_control2>;
+ reg = <0x100>;
+ };
+
+ CPU3: cpu@101 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ cci-control-port = <&cci_control2>;
+ reg = <0x101>;
+ };
+
+ };
+
+ dma0: dma@3000000 {
+ compatible = "arm,pl330", "arm,primecell";
+ cci-control-port = <&cci_control0>;
+ reg = <0x0 0x3000000 0x0 0x1000>;
+ interrupts = <10>;
+ #dma-cells = <1>;
+ #dma-channels = <8>;
+ #dma-requests = <32>;
+ };
+
+ cci@2c090000 {
+ compatible = "arm,cci-400";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0x0 0x2c090000 0 0x1000>;
+ ranges = <0x0 0x0 0x2c090000 0x6000>;
+
+ cci_control0: slave-if@1000 {
+ compatible = "arm,cci-400-ctrl-if";
+ interface-type = "ace-lite";
+ reg = <0x1000 0x1000>;
+ };
+
+ cci_control1: slave-if@4000 {
+ compatible = "arm,cci-400-ctrl-if";
+ interface-type = "ace";
+ reg = <0x4000 0x1000>;
+ };
+
+ cci_control2: slave-if@5000 {
+ compatible = "arm,cci-400-ctrl-if";
+ interface-type = "ace";
+ reg = <0x5000 0x1000>;
+ };
+ };
+
+This CCI node corresponds to a CCI component whose control registers sits
+at address 0x000000002c090000.
+CCI slave interface @0x000000002c091000 is connected to dma controller dma0.
+CCI slave interface @0x000000002c094000 is connected to CPUs {CPU0, CPU1};
+CCI slave interface @0x000000002c095000 is connected to CPUs {CPU2, CPU3};
diff --git a/Documentation/devicetree/bindings/arm/fsl.txt b/Documentation/devicetree/bindings/arm/fsl.txt
index f798187..e935d7d 100644
--- a/Documentation/devicetree/bindings/arm/fsl.txt
+++ b/Documentation/devicetree/bindings/arm/fsl.txt
@@ -5,6 +5,14 @@
Required root node properties:
- compatible = "fsl,imx23-evk", "fsl,imx23";
+i.MX25 Product Development Kit
+Required root node properties:
+ - compatible = "fsl,imx25-pdk", "fsl,imx25";
+
+i.MX27 Product Development Kit
+Required root node properties:
+ - compatible = "fsl,imx27-pdk", "fsl,imx27";
+
i.MX28 Evaluation Kit
Required root node properties:
- compatible = "fsl,imx28-evk", "fsl,imx28";
diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt
index 62eb8df..3dfb0c0 100644
--- a/Documentation/devicetree/bindings/arm/gic.txt
+++ b/Documentation/devicetree/bindings/arm/gic.txt
@@ -42,7 +42,7 @@
Optional
- interrupts : Interrupt source of the parent interrupt controller on
- secondary GICs, or VGIC maintainance interrupt on primary GIC (see
+ secondary GICs, or VGIC maintenance interrupt on primary GIC (see
below).
- cpu-offset : per-cpu offset within the distributor and cpu interface
@@ -74,7 +74,7 @@
virtual interface control register base and size. The 2nd additional
region is the GIC virtual cpu interface register base and size.
-- interrupts : VGIC maintainance interrupt.
+- interrupts : VGIC maintenance interrupt.
Example:
diff --git a/Documentation/devicetree/bindings/arm/global_timer.txt b/Documentation/devicetree/bindings/arm/global_timer.txt
new file mode 100644
index 0000000..1e54898
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/global_timer.txt
@@ -0,0 +1,24 @@
+
+* ARM Global Timer
+ Cortex-A9 are often associated with a per-core Global timer.
+
+** Timer node required properties:
+
+- compatible : Should be "arm,cortex-a9-global-timer"
+ Driver supports versions r2p0 and above.
+
+- interrupts : One interrupt to each core
+
+- reg : Specify the base address and the size of the GT timer
+ register window.
+
+- clocks : Should be phandle to a clock.
+
+Example:
+
+ timer@2c000600 {
+ compatible = "arm,cortex-a9-global-timer";
+ reg = <0x2c000600 0x20>;
+ interrupts = <1 13 0xf01>;
+ clocks = <&arm_periph_clk>;
+ };
diff --git a/Documentation/devicetree/bindings/arm/keystone/keystone.txt b/Documentation/devicetree/bindings/arm/keystone/keystone.txt
new file mode 100644
index 0000000..63c0e6a
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/keystone/keystone.txt
@@ -0,0 +1,10 @@
+TI Keystone Platforms Device Tree Bindings
+-----------------------------------------------
+
+Boards with Keystone2 based devices (TCI66xxK2H) SOC shall have the
+following properties.
+
+Required properties:
+ - compatible: All TI specific devices present in Keystone SOC should be in
+ the form "ti,keystone-*". Generic devices like gic, arch_timers, ns16550
+ type UART should use the specified compatible for those devices.
diff --git a/Documentation/devicetree/bindings/arm/kirkwood.txt b/Documentation/devicetree/bindings/arm/kirkwood.txt
new file mode 100644
index 0000000..98cce9a
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/kirkwood.txt
@@ -0,0 +1,27 @@
+Marvell Kirkwood Platforms Device Tree Bindings
+-----------------------------------------------
+
+Boards with a SoC of the Marvell Kirkwood
+shall have the following property:
+
+Required root node property:
+
+compatible: must contain "marvell,kirkwood";
+
+In order to support the kirkwood cpufreq driver, there must be a node
+cpus/cpu@0 with three clocks, "cpu_clk", "ddrclk" and "powersave",
+where the "powersave" clock is a gating clock used to switch the CPU
+between the "cpu_clk" and the "ddrclk".
+
+Example:
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ device_type = "cpu";
+ compatible = "marvell,sheeva-88SV131";
+ clocks = <&core_clk 1>, <&core_clk 3>, <&gate_clk 11>;
+ clock-names = "cpu_clk", "ddrclk", "powersave";
+ };
diff --git a/Documentation/devicetree/bindings/arm/l2cc.txt b/Documentation/devicetree/bindings/arm/l2cc.txt
index cbef09b..69ddf9f 100644
--- a/Documentation/devicetree/bindings/arm/l2cc.txt
+++ b/Documentation/devicetree/bindings/arm/l2cc.txt
@@ -16,6 +16,9 @@
performs the same operation).
"marvell,"aurora-outer-cache: Marvell Controller designed to be
compatible with the ARM one with outer cache mode.
+ "bcm,bcm11351-a2-pl310-cache": For Broadcom bcm11351 chipset where an
+ offset needs to be added to the address before passing down to the L2
+ cache controller
- cache-unified : Specifies the cache is a unified cache.
- cache-level : Should be set to 2 for a level 2 cache.
- reg : Physical base address and size of cache controller's memory mapped
diff --git a/Documentation/devicetree/bindings/arm/msm/ssbi.txt b/Documentation/devicetree/bindings/arm/msm/ssbi.txt
new file mode 100644
index 0000000..54fd5ce
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/msm/ssbi.txt
@@ -0,0 +1,18 @@
+* Qualcomm SSBI
+
+Some Qualcomm MSM devices contain a point-to-point serial bus used to
+communicate with a limited range of devices (mostly power management
+chips).
+
+These require the following properties:
+
+- compatible: "qcom,ssbi"
+
+- qcom,controller-type
+ indicates the SSBI bus variant the controller should use to talk
+ with the slave device. This should be one of "ssbi", "ssbi2", or
+ "pmic-arbiter". The type chosen is determined by the attached
+ slave.
+
+The slave device should be the single child node of the ssbi device
+with a compatible field.
diff --git a/Documentation/devicetree/bindings/arm/msm/timer.txt b/Documentation/devicetree/bindings/arm/msm/timer.txt
index 8c5907b..c6ef8f1 100644
--- a/Documentation/devicetree/bindings/arm/msm/timer.txt
+++ b/Documentation/devicetree/bindings/arm/msm/timer.txt
@@ -3,36 +3,35 @@
Properties:
- compatible : Should at least contain "qcom,msm-timer". More specific
- properties such as "qcom,msm-gpt" and "qcom,msm-dgt" specify a general
- purpose timer and a debug timer respectively.
+ properties specify which subsystem the timers are paired with.
-- interrupts : Interrupt indicating a match event.
+ "qcom,kpss-timer" - krait subsystem
+ "qcom,scss-timer" - scorpion subsystem
-- reg : Specifies the base address of the timer registers. The second region
- specifies an optional register used to configure the clock divider.
+- interrupts : Interrupts for the the debug timer, the first general purpose
+ timer, and optionally a second general purpose timer in that
+ order.
-- clock-frequency : The frequency of the timer in Hz.
+- reg : Specifies the base address of the timer registers.
+
+- clock-frequency : The frequency of the debug timer and the general purpose
+ timer(s) in Hz in that order.
Optional:
- cpu-offset : per-cpu offset used when the timer is accessed without the
- CPU remapping facilities. The offset is cpu-offset * cpu-nr.
+ CPU remapping facilities. The offset is
+ cpu-offset + (0x10000 * cpu-nr).
Example:
- timer@200a004 {
- compatible = "qcom,msm-gpt", "qcom,msm-timer";
- interrupts = <1 2 0x301>;
- reg = <0x0200a004 0x10>;
- clock-frequency = <32768>;
- cpu-offset = <0x40000>;
- };
-
- timer@200a024 {
- compatible = "qcom,msm-dgt", "qcom,msm-timer";
- interrupts = <1 3 0x301>;
- reg = <0x0200a024 0x10>,
- <0x0200a034 0x4>;
- clock-frequency = <6750000>;
+ timer@200a000 {
+ compatible = "qcom,scss-timer", "qcom,msm-timer";
+ interrupts = <1 1 0x301>,
+ <1 2 0x301>,
+ <1 3 0x301>;
+ reg = <0x0200a000 0x100>;
+ clock-frequency = <19200000>,
+ <32768>;
cpu-offset = <0x40000>;
};
diff --git a/Documentation/devicetree/bindings/arm/nspire.txt b/Documentation/devicetree/bindings/arm/nspire.txt
new file mode 100644
index 0000000..4d08518
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/nspire.txt
@@ -0,0 +1,14 @@
+TI-NSPIRE calculators
+
+Required properties:
+- compatible: Compatible property value should contain "ti,nspire".
+ CX models should have "ti,nspire-cx"
+ Touchpad models should have "ti,nspire-tp"
+ Clickpad models should have "ti,nspire-clp"
+
+Example:
+
+/ {
+ model = "TI-NSPIRE CX";
+ compatible = "ti,nspire-cx";
+ ...
diff --git a/Documentation/devicetree/bindings/arm/omap/l3-noc.txt b/Documentation/devicetree/bindings/arm/omap/l3-noc.txt
index 6888a5e..c0105de 100644
--- a/Documentation/devicetree/bindings/arm/omap/l3-noc.txt
+++ b/Documentation/devicetree/bindings/arm/omap/l3-noc.txt
@@ -6,6 +6,7 @@
Required properties:
- compatible : Should be "ti,omap3-l3-smx" for OMAP3 family
Should be "ti,omap4-l3-noc" for OMAP4 family
+- reg: Contains L3 register address range for each noc domain.
- ti,hwmods: "l3_main_1", ... One hwmod for each noc domain.
Examples:
diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt b/Documentation/devicetree/bindings/arm/omap/omap.txt
index d0051a7..6d498c7 100644
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@ -39,16 +39,16 @@
- OMAP3 Tobi with Overo : Commercial expansion board with daughter board
compatible = "ti,omap3-tobi", "ti,omap3-overo", "ti,omap3"
-- OMAP4 SDP : Software Developement Board
+- OMAP4 SDP : Software Development Board
compatible = "ti,omap4-sdp", "ti,omap4430"
- OMAP4 PandaBoard : Low cost community board
compatible = "ti,omap4-panda", "ti,omap4430"
-- OMAP3 EVM : Software Developement Board for OMAP35x, AM/DM37x
+- OMAP3 EVM : Software Development Board for OMAP35x, AM/DM37x
compatible = "ti,omap3-evm", "ti,omap3"
-- AM335X EVM : Software Developement Board for AM335x
+- AM335X EVM : Software Development Board for AM335x
compatible = "ti,am335x-evm", "ti,am33xx", "ti,omap3"
- AM335X Bone : Low cost community board
@@ -56,3 +56,6 @@
- OMAP5 EVM : Evaluation Module
compatible = "ti,omap5-evm", "ti,omap5"
+
+- AM43x EPOS EVM
+ compatible = "ti,am43x-epos-evm", "ti,am4372", "ti,am43"
diff --git a/Documentation/devicetree/bindings/arm/omap/timer.txt b/Documentation/devicetree/bindings/arm/omap/timer.txt
index 8732d4d..d02e27c 100644
--- a/Documentation/devicetree/bindings/arm/omap/timer.txt
+++ b/Documentation/devicetree/bindings/arm/omap/timer.txt
@@ -1,7 +1,20 @@
OMAP Timer bindings
Required properties:
-- compatible: Must be "ti,omap2-timer" for OMAP2+ controllers.
+- compatible: Should be set to one of the below. Please note that
+ OMAP44xx devices have timer instances that are 100%
+ register compatible with OMAP3xxx devices as well as
+ newer timers that are not 100% register compatible.
+ So for OMAP44xx devices timer instances may use
+ different compatible strings.
+
+ ti,omap2420-timer (applicable to OMAP24xx devices)
+ ti,omap3430-timer (applicable to OMAP3xxx/44xx devices)
+ ti,omap4430-timer (applicable to OMAP44xx devices)
+ ti,omap5430-timer (applicable to OMAP543x devices)
+ ti,am335x-timer (applicable to AM335x devices)
+ ti,am335x-timer-1ms (applicable to AM335x devices)
+
- reg: Contains timer register address range (base address and
length).
- interrupts: Contains the interrupt information for the timer. The
@@ -22,7 +35,7 @@
Example:
timer12: timer@48304000 {
- compatible = "ti,omap2-timer";
+ compatible = "ti,omap3430-timer";
reg = <0x48304000 0x400>;
interrupts = <95>;
ti,hwmods = "timer12"
diff --git a/Documentation/devicetree/bindings/arm/primecell.txt b/Documentation/devicetree/bindings/arm/primecell.txt
index 64fc82b..0df6aca 100644
--- a/Documentation/devicetree/bindings/arm/primecell.txt
+++ b/Documentation/devicetree/bindings/arm/primecell.txt
@@ -16,14 +16,31 @@
- clocks : From common clock binding. First clock is phandle to clock for apb
pclk. Additional clocks are optional and specific to those peripherals.
- clock-names : From common clock binding. Shall be "apb_pclk" for first clock.
+- dmas : From common DMA binding. If present, refers to one or more dma channels.
+- dma-names : From common DMA binding, needs to match the 'dmas' property.
+ Devices with exactly one receive and transmit channel shall name
+ these "rx" and "tx", respectively.
+- pinctrl-<n> : Pinctrl states as described in bindings/pinctrl/pinctrl-bindings.txt
+- pinctrl-names : Names corresponding to the numbered pinctrl states
+- interrupts : one or more interrupt specifiers
+- interrupt-names : names corresponding to the interrupts properties
Example:
serial@fff36000 {
compatible = "arm,pl011", "arm,primecell";
arm,primecell-periphid = <0x00341011>;
+
clocks = <&pclk>;
clock-names = "apb_pclk";
-
+
+ dmas = <&dma-controller 4>, <&dma-controller 5>;
+ dma-names = "rx", "tx";
+
+ pinctrl-0 = <&uart0_default_mux>, <&uart0_default_mode>;
+ pinctrl-1 = <&uart0_sleep_mode>;
+ pinctrl-names = "default","sleep";
+
+ interrupts = <0 11 0x4>;
};
diff --git a/Documentation/devicetree/bindings/arm/psci.txt b/Documentation/devicetree/bindings/arm/psci.txt
new file mode 100644
index 0000000..433afe9
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/psci.txt
@@ -0,0 +1,55 @@
+* Power State Coordination Interface (PSCI)
+
+Firmware implementing the PSCI functions described in ARM document number
+ARM DEN 0022A ("Power State Coordination Interface System Software on ARM
+processors") can be used by Linux to initiate various CPU-centric power
+operations.
+
+Issue A of the specification describes functions for CPU suspend, hotplug
+and migration of secure software.
+
+Functions are invoked by trapping to the privilege level of the PSCI
+firmware (specified as part of the binding below) and passing arguments
+in a manner similar to that specified by AAPCS:
+
+ r0 => 32-bit Function ID / return value
+ {r1 - r3} => Parameters
+
+Note that the immediate field of the trapping instruction must be set
+to #0.
+
+
+Main node required properties:
+
+ - compatible : Must be "arm,psci"
+
+ - method : The method of calling the PSCI firmware. Permitted
+ values are:
+
+ "smc" : SMC #0, with the register assignments specified
+ in this binding.
+
+ "hvc" : HVC #0, with the register assignments specified
+ in this binding.
+
+Main node optional properties:
+
+ - cpu_suspend : Function ID for CPU_SUSPEND operation
+
+ - cpu_off : Function ID for CPU_OFF operation
+
+ - cpu_on : Function ID for CPU_ON operation
+
+ - migrate : Function ID for MIGRATE operation
+
+
+Example:
+
+ psci {
+ compatible = "arm,psci";
+ method = "smc";
+ cpu_suspend = <0x95c10000>;
+ cpu_off = <0x95c10001>;
+ cpu_on = <0x95c10002>;
+ migrate = <0x95c10003>;
+ };
diff --git a/Documentation/devicetree/bindings/arm/rtsm-dcscb.txt b/Documentation/devicetree/bindings/arm/rtsm-dcscb.txt
new file mode 100644
index 0000000..3b8fbf3
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/rtsm-dcscb.txt
@@ -0,0 +1,19 @@
+ARM Dual Cluster System Configuration Block
+-------------------------------------------
+
+The Dual Cluster System Configuration Block (DCSCB) provides basic
+functionality for controlling clocks, resets and configuration pins in
+the Dual Cluster System implemented by the Real-Time System Model (RTSM).
+
+Required properties:
+
+- compatible : should be "arm,rtsm,dcscb"
+
+- reg : physical base address and the size of the registers window
+
+Example:
+
+ dcscb@60000000 {
+ compatible = "arm,rtsm,dcscb";
+ reg = <0x60000000 0x1000>;
+ };
diff --git a/Documentation/devicetree/bindings/arm/samsung-boards.txt b/Documentation/devicetree/bindings/arm/samsung-boards.txt
index 0bf68be..2168ed3 100644
--- a/Documentation/devicetree/bindings/arm/samsung-boards.txt
+++ b/Documentation/devicetree/bindings/arm/samsung-boards.txt
@@ -6,3 +6,13 @@
- compatible = should be one or more of the following.
(a) "samsung,smdkv310" - for Samsung's SMDKV310 eval board.
(b) "samsung,exynos4210" - for boards based on Exynos4210 SoC.
+
+Optional:
+ - firmware node, specifying presence and type of secure firmware:
+ - compatible: only "samsung,secure-firmware" is currently supported
+ - reg: address of non-secure SYSRAM used for communication with firmware
+
+ firmware@0203F000 {
+ compatible = "samsung,secure-firmware";
+ reg = <0x0203F000 0x1000>;
+ };
diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
new file mode 100644
index 0000000..47ada1d
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
@@ -0,0 +1,60 @@
+Samsung Exynos Analog to Digital Converter bindings
+
+The devicetree bindings are for the new ADC driver written for
+Exynos4 and upward SoCs from Samsung.
+
+New driver handles the following
+1. Supports ADC IF found on EXYNOS4412/EXYNOS5250
+ and future SoCs from Samsung
+2. Add ADC driver under iio/adc framework
+3. Also adds the Documentation for device tree bindings
+
+Required properties:
+- compatible: Must be "samsung,exynos-adc-v1"
+ for exynos4412/5250 controllers.
+ Must be "samsung,exynos-adc-v2" for
+ future controllers.
+- reg: Contains ADC register address range (base address and
+ length) and the address of the phy enable register.
+- interrupts: Contains the interrupt information for the timer. The
+ format is being dependent on which interrupt controller
+ the Samsung device uses.
+- #io-channel-cells = <1>; As ADC has multiple outputs
+- clocks From common clock binding: handle to adc clock.
+- clock-names From common clock binding: Shall be "adc".
+- vdd-supply VDD input supply.
+
+Note: child nodes can be added for auto probing from device tree.
+
+Example: adding device info in dtsi file
+
+adc: adc@12D10000 {
+ compatible = "samsung,exynos-adc-v1";
+ reg = <0x12D10000 0x100>, <0x10040718 0x4>;
+ interrupts = <0 106 0>;
+ #io-channel-cells = <1>;
+ io-channel-ranges;
+
+ clocks = <&clock 303>;
+ clock-names = "adc";
+
+ vdd-supply = <&buck5_reg>;
+};
+
+
+Example: Adding child nodes in dts file
+
+adc@12D10000 {
+
+ /* NTC thermistor is a hwmon device */
+ ncp15wb473@0 {
+ compatible = "ntc,ncp15wb473";
+ pullup-uV = <1800000>;
+ pullup-ohm = <47000>;
+ pulldown-ohm = <0>;
+ io-channels = <&adc 4>;
+ };
+};
+
+Note: Does not apply to ADC driver under arch/arm/plat-samsung/
+Note: The child node can be added under the adc node or separately.
diff --git a/Documentation/devicetree/bindings/arm/samsung/interrupt-combiner.txt b/Documentation/devicetree/bindings/arm/samsung/interrupt-combiner.txt
index f2f2171..9e5f734 100644
--- a/Documentation/devicetree/bindings/arm/samsung/interrupt-combiner.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/interrupt-combiner.txt
@@ -5,7 +5,7 @@
for the group. The interrupt request from each group are connected to a parent
interrupt controller, such as GIC in case of Exynos4210.
-The interrupt combiner controller consists of multiple combiners. Upto eight
+The interrupt combiner controller consists of multiple combiners. Up to eight
interrupt sources can be connected to a combiner. The combiner outputs one
combined interrupt for its eight interrupt sources. The combined interrupt
is usually connected to a parent interrupt controller.
@@ -14,8 +14,8 @@
controller module (which includes multiple combiners). A combiner in the
interrupt controller module shares config/control registers with other
combiners. For example, a 32-bit interrupt enable/disable config register
-can accommodate upto 4 interrupt combiners (with each combiner supporting
-upto 8 interrupt sources).
+can accommodate up to 4 interrupt combiners (with each combiner supporting
+up to 8 interrupt sources).
Required properties:
- compatible: should be "samsung,exynos4210-combiner".
diff --git a/Documentation/devicetree/bindings/arm/samsung/sysreg.txt b/Documentation/devicetree/bindings/arm/samsung/sysreg.txt
new file mode 100644
index 0000000..5039c0a
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/samsung/sysreg.txt
@@ -0,0 +1,7 @@
+SAMSUNG S5P/Exynos SoC series System Registers (SYSREG)
+
+Properties:
+ - name : should be 'sysreg';
+ - compatible : should contain "samsung,<chip name>-sysreg", "syscon";
+ For Exynos4 SoC series it should be "samsung,exynos4-sysreg", "syscon";
+ - reg : offset and length of the register set.
diff --git a/Documentation/devicetree/bindings/arm/sirf.txt b/Documentation/devicetree/bindings/arm/sirf.txt
index 1881e1c..c6ba6d3 100644
--- a/Documentation/devicetree/bindings/arm/sirf.txt
+++ b/Documentation/devicetree/bindings/arm/sirf.txt
@@ -1,3 +1,9 @@
-prima2 "cb" evaluation board
+CSR SiRFprimaII and SiRFmarco device tree bindings.
+========================================
+
Required root node properties:
- - compatible = "sirf,prima2-cb", "sirf,prima2";
+ - compatible:
+ - "sirf,prima2-cb" : prima2 "cb" evaluation board
+ - "sirf,marco-cb" : marco "cb" evaluation board
+ - "sirf,prima2" : prima2 device based board
+ - "sirf,marco" : marco device based board
diff --git a/Documentation/devicetree/bindings/arm/spear/shirq.txt b/Documentation/devicetree/bindings/arm/spear/shirq.txt
index 13fbb88..715a013 100644
--- a/Documentation/devicetree/bindings/arm/spear/shirq.txt
+++ b/Documentation/devicetree/bindings/arm/spear/shirq.txt
@@ -14,7 +14,7 @@
interrupt multiplexor (one node for all groups). A group in the
interrupt controller shares config/control registers with other groups.
For example, a 32-bit interrupt enable/disable config register can
-accommodate upto 4 interrupt groups.
+accommodate up to 4 interrupt groups.
Required properties:
- compatible: should be, either of
diff --git a/Documentation/devicetree/bindings/arm/ste-nomadik.txt b/Documentation/devicetree/bindings/arm/ste-nomadik.txt
new file mode 100644
index 0000000..6256ec3
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/ste-nomadik.txt
@@ -0,0 +1,32 @@
+ST-Ericsson Nomadik Device Tree Bindings
+
+For various board the "board" node may contain specific properties
+that pertain to this particular board, such as board-specific GPIOs.
+
+Required root node property: src
+- Nomadik System and reset controller used for basic chip control, clock
+ and reset line control.
+- compatible: must be "stericsson,nomadik,src"
+
+Boards with the Nomadik SoC include:
+
+S8815 "MiniKit" manufactured by Calao Systems:
+
+Required root node property:
+
+compatible="calaosystems,usb-s8815";
+
+Required node: usb-s8815
+
+Example:
+
+usb-s8815 {
+ ethernet-gpio {
+ gpios = <&gpio3 19 0x1>;
+ interrupts = <19 0x1>;
+ interrupt-parent = <&gpio3>;
+ };
+ mmcsd-gpio {
+ gpios = <&gpio3 16 0x1>;
+ };
+};
diff --git a/Documentation/devicetree/bindings/arm/ste-u300.txt b/Documentation/devicetree/bindings/arm/ste-u300.txt
new file mode 100644
index 0000000..69b5ab0
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/ste-u300.txt
@@ -0,0 +1,46 @@
+ST-Ericsson U300 Device Tree Bindings
+
+For various board the "board" node may contain specific properties
+that pertain to this particular board, such as board-specific GPIOs
+or board power regulator supplies.
+
+Required root node property:
+
+compatible="stericsson,u300";
+
+Required node: syscon
+This contains the system controller.
+- compatible: must be "stericsson,u300-syscon".
+- reg: the base address and size of the system controller.
+
+Boards with the U300 SoC include:
+
+S365 "Small Board U365":
+
+Required node: s365
+This contains the board-specific information.
+- compatible: must be "stericsson,s365".
+- vana15-supply: the regulator supplying the 1.5V to drive the
+ board.
+- syscon: a pointer to the syscon node so we can acccess the
+ syscon registers to set the board as self-powered.
+
+Example:
+
+/ {
+ model = "ST-Ericsson U300";
+ compatible = "stericsson,u300";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ s365 {
+ compatible = "stericsson,s365";
+ vana15-supply = <&ab3100_ldo_d_reg>;
+ syscon = <&syscon>;
+ };
+
+ syscon: syscon@c0011000 {
+ compatible = "stericsson,u300-syscon";
+ reg = <0xc0011000 0x1000>;
+ };
+};
diff --git a/Documentation/devicetree/bindings/arm/tegra.txt b/Documentation/devicetree/bindings/arm/tegra.txt
index 6e69d2e..ed9c853 100644
--- a/Documentation/devicetree/bindings/arm/tegra.txt
+++ b/Documentation/devicetree/bindings/arm/tegra.txt
@@ -1,14 +1,34 @@
NVIDIA Tegra device tree bindings
-------------------------------------------
-Boards with the tegra20 SoC shall have the following properties:
+SoCs
+-------------------------------------------
-Required root node property:
+Each device tree must specify which Tegra SoC it uses, using one of the
+following compatible values:
-compatible = "nvidia,tegra20";
+ nvidia,tegra20
+ nvidia,tegra30
-Boards with the tegra30 SoC shall have the following properties:
+Boards
+-------------------------------------------
-Required root node property:
+Each device tree must specify which one or more of the following
+board-specific compatible values:
-compatible = "nvidia,tegra30";
+ ad,medcom-wide
+ ad,plutux
+ ad,tamonten
+ ad,tec
+ compal,paz00
+ compulab,trimslice
+ nvidia,beaver
+ nvidia,cardhu
+ nvidia,cardhu-a02
+ nvidia,cardhu-a04
+ nvidia,harmony
+ nvidia,seaboard
+ nvidia,ventana
+ nvidia,whistler
+ toradex,colibri_t20-512
+ toradex,iris
diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt
index b5846e2..1608a54 100644
--- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt
+++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt
@@ -1,19 +1,84 @@
NVIDIA Tegra Power Management Controller (PMC)
-Properties:
+The PMC block interacts with an external Power Management Unit. The PMC
+mostly controls the entry and exit of the system from different sleep
+modes. It provides power-gating controllers for SoC and CPU power-islands.
+
+Required properties:
- name : Should be pmc
- compatible : Should contain "nvidia,tegra<chip>-pmc".
- reg : Offset and length of the register set for the device
+- clocks : Must contain an entry for each entry in clock-names.
+- clock-names : Must include the following entries:
+ "pclk" (The Tegra clock of that name),
+ "clk32k_in" (The 32KHz clock input to Tegra).
+
+Optional properties:
- nvidia,invert-interrupt : If present, inverts the PMU interrupt signal.
The PMU is an external Power Management Unit, whose interrupt output
signal is fed into the PMC. This signal is optionally inverted, and then
fed into the ARM GIC. The PMC is not involved in the detection or
handling of this interrupt signal, merely its inversion.
+- nvidia,suspend-mode : The suspend mode that the platform should use.
+ Valid values are 0, 1 and 2:
+ 0 (LP0): CPU + Core voltage off and DRAM in self-refresh
+ 1 (LP1): CPU voltage off and DRAM in self-refresh
+ 2 (LP2): CPU voltage off
+- nvidia,core-power-req-active-high : Boolean, core power request active-high
+- nvidia,sys-clock-req-active-high : Boolean, system clock request active-high
+- nvidia,combined-power-req : Boolean, combined power request for CPU & Core
+- nvidia,cpu-pwr-good-en : Boolean, CPU power good signal (from PMIC to PMC)
+ is enabled.
+
+Required properties when nvidia,suspend-mode is specified:
+- nvidia,cpu-pwr-good-time : CPU power good time in uS.
+- nvidia,cpu-pwr-off-time : CPU power off time in uS.
+- nvidia,core-pwr-good-time : <Oscillator-stable-time Power-stable-time>
+ Core power good time in uS.
+- nvidia,core-pwr-off-time : Core power off time in uS.
+
+Required properties when nvidia,suspend-mode=<0>:
+- nvidia,lp0-vec : <start length> Starting address and length of LP0 vector
+ The LP0 vector contains the warm boot code that is executed by AVP when
+ resuming from the LP0 state. The AVP (Audio-Video Processor) is an ARM7
+ processor and always being the first boot processor when chip is power on
+ or resume from deep sleep mode. When the system is resumed from the deep
+ sleep mode, the warm boot code will restore some PLLs, clocks and then
+ bring up CPU0 for resuming the system.
Example:
+/ SoC dts including file
pmc@7000f400 {
compatible = "nvidia,tegra20-pmc";
reg = <0x7000e400 0x400>;
+ clocks = <&tegra_car 110>, <&clk32k_in>;
+ clock-names = "pclk", "clk32k_in";
nvidia,invert-interrupt;
+ nvidia,suspend-mode = <1>;
+ nvidia,cpu-pwr-good-time = <2000>;
+ nvidia,cpu-pwr-off-time = <100>;
+ nvidia,core-pwr-good-time = <3845 3845>;
+ nvidia,core-pwr-off-time = <458>;
+ nvidia,core-power-req-active-high;
+ nvidia,sys-clock-req-active-high;
+ nvidia,lp0-vec = <0xbdffd000 0x2000>;
+};
+
+/ Tegra board dts file
+{
+ ...
+ clocks {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ clk32k_in: clock {
+ compatible = "fixed-clock";
+ reg=<0>;
+ #clock-cells = <0>;
+ clock-frequency = <32768>;
+ };
+ };
+ ...
};
diff --git a/Documentation/devicetree/bindings/arm/vt8500.txt b/Documentation/devicetree/bindings/arm/vt8500.txt
index d657832..87dc1dd 100644
--- a/Documentation/devicetree/bindings/arm/vt8500.txt
+++ b/Documentation/devicetree/bindings/arm/vt8500.txt
@@ -12,3 +12,11 @@
Boards with the Wondermedia WM8650 SoC shall have the following properties:
Required root node property:
compatible = "wm,wm8650";
+
+Boards with the Wondermedia WM8750 SoC shall have the following properties:
+Required root node property:
+compatible = "wm,wm8750";
+
+Boards with the Wondermedia WM8850 SoC shall have the following properties:
+Required root node property:
+compatible = "wm,wm8850";
diff --git a/Documentation/devicetree/bindings/ata/ahci-platform.txt b/Documentation/devicetree/bindings/ata/ahci-platform.txt
index b519f9b..3ec0c5c 100644
--- a/Documentation/devicetree/bindings/ata/ahci-platform.txt
+++ b/Documentation/devicetree/bindings/ata/ahci-platform.txt
@@ -12,6 +12,11 @@
- calxeda,port-phys: phandle-combophy and lane assignment, which maps each
SATA port to a combophy and a lane within that
combophy
+- calxeda,sgpio-gpio: phandle-gpio bank, bit offset, and default on or off,
+ which indicates that the driver supports SGPIO
+ indicator lights using the indicated GPIOs
+- calxeda,led-order : a u32 array that map port numbers to offsets within the
+ SGPIO bitstream.
- dma-coherent : Present if dma operations are coherent
Example:
diff --git a/Documentation/devicetree/bindings/ata/atmel-at91_cf.txt b/Documentation/devicetree/bindings/ata/atmel-at91_cf.txt
new file mode 100644
index 0000000..c1d22b3
--- /dev/null
+++ b/Documentation/devicetree/bindings/ata/atmel-at91_cf.txt
@@ -0,0 +1,19 @@
+Atmel AT91RM9200 CompactFlash
+
+Required properties:
+- compatible : "atmel,at91rm9200-cf".
+- reg : should specify localbus address and size used.
+- gpios : specifies the gpio pins to control the CF device. Detect
+ and reset gpio's are mandatory while irq and vcc gpio's are
+ optional and may be set to 0 if not present.
+
+Example:
+compact-flash@50000000 {
+ compatible = "atmel,at91rm9200-cf";
+ reg = <0x50000000 0x30000000>;
+ gpios = <&pioC 13 0 /* irq */
+ &pioC 15 0 /* detect */
+ 0 /* vcc */
+ &pioC 5 0 /* reset */
+ >;
+};
diff --git a/Documentation/devicetree/bindings/ata/imx-pata.txt b/Documentation/devicetree/bindings/ata/imx-pata.txt
new file mode 100644
index 0000000..e38d734
--- /dev/null
+++ b/Documentation/devicetree/bindings/ata/imx-pata.txt
@@ -0,0 +1,17 @@
+* Freescale i.MX PATA Controller
+
+Required properties:
+- compatible: "fsl,imx27-pata"
+- reg: Address range of the PATA Controller
+- interrupts: The interrupt of the PATA Controller
+- clocks: the clocks for the PATA Controller
+
+Example:
+
+ pata: pata@83fe0000 {
+ compatible = "fsl,imx51-pata", "fsl,imx27-pata";
+ reg = <0x83fe0000 0x4000>;
+ interrupts = <70>;
+ clocks = <&clks 161>;
+ status = "disabled";
+ };
diff --git a/Documentation/devicetree/bindings/ata/pata-arasan.txt b/Documentation/devicetree/bindings/ata/pata-arasan.txt
index 95ec7f8..2aff154 100644
--- a/Documentation/devicetree/bindings/ata/pata-arasan.txt
+++ b/Documentation/devicetree/bindings/ata/pata-arasan.txt
@@ -6,6 +6,26 @@
- interrupt-parent: Should be the phandle for the interrupt controller
that services interrupts for this device
- interrupt: Should contain the CF interrupt number
+- clock-frequency: Interface clock rate, in Hz, one of
+ 25000000
+ 33000000
+ 40000000
+ 50000000
+ 66000000
+ 75000000
+ 100000000
+ 125000000
+ 150000000
+ 166000000
+ 200000000
+
+Optional properties:
+- arasan,broken-udma: if present, UDMA mode is unusable
+- arasan,broken-mwdma: if present, MWDMA mode is unusable
+- arasan,broken-pio: if present, PIO mode is unusable
+- dmas: one DMA channel, as described in bindings/dma/dma.txt
+ required unless both UDMA and MWDMA mode are broken
+- dma-names: the corresponding channel name, must be "data"
Example:
@@ -14,4 +34,6 @@
reg = <0xfc000000 0x1000>;
interrupt-parent = <&vic1>;
interrupts = <12>;
+ dmas = <&dma-controller 23>;
+ dma-names = "data";
};
diff --git a/Documentation/devicetree/bindings/bus/imx-weim.txt b/Documentation/devicetree/bindings/bus/imx-weim.txt
new file mode 100644
index 0000000..cedc2a9
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/imx-weim.txt
@@ -0,0 +1,49 @@
+Device tree bindings for i.MX Wireless External Interface Module (WEIM)
+
+The term "wireless" does not imply that the WEIM is literally an interface
+without wires. It simply means that this module was originally designed for
+wireless and mobile applications that use low-power technology.
+
+The actual devices are instantiated from the child nodes of a WEIM node.
+
+Required properties:
+
+ - compatible: Should be set to "fsl,imx6q-weim"
+ - reg: A resource specifier for the register space
+ (see the example below)
+ - clocks: the clock, see the example below.
+ - #address-cells: Must be set to 2 to allow memory address translation
+ - #size-cells: Must be set to 1 to allow CS address passing
+ - ranges: Must be set up to reflect the memory layout with four
+ integer values for each chip-select line in use:
+
+ <cs-number> 0 <physical address of mapping> <size>
+
+Timing property for child nodes. It is mandatory, not optional.
+
+ - fsl,weim-cs-timing: The timing array, contains 6 timing values for the
+ child node. We can get the CS index from the child
+ node's "reg" property. This property contains the values
+ for the registers EIM_CSnGCR1, EIM_CSnGCR2, EIM_CSnRCR1,
+ EIM_CSnRCR2, EIM_CSnWCR1, EIM_CSnWCR2 in this order.
+
+Example for an imx6q-sabreauto board, the NOR flash connected to the WEIM:
+
+ weim: weim@021b8000 {
+ compatible = "fsl,imx6q-weim";
+ reg = <0x021b8000 0x4000>;
+ clocks = <&clks 196>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges = <0 0 0x08000000 0x08000000>;
+
+ nor@0,0 {
+ compatible = "cfi-flash";
+ reg = <0 0 0x02000000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ bank-width = <2>;
+ fsl,weim-cs-timing = <0x00620081 0x00000001 0x1c022000
+ 0x0000c000 0x1404a38e 0x00000000>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/bus/ti-gpmc.txt b/Documentation/devicetree/bindings/bus/ti-gpmc.txt
new file mode 100644
index 0000000..704be93
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/ti-gpmc.txt
@@ -0,0 +1,130 @@
+Device tree bindings for OMAP general purpose memory controllers (GPMC)
+
+The actual devices are instantiated from the child nodes of a GPMC node.
+
+Required properties:
+
+ - compatible: Should be set to one of the following:
+
+ ti,omap2420-gpmc (omap2420)
+ ti,omap2430-gpmc (omap2430)
+ ti,omap3430-gpmc (omap3430 & omap3630)
+ ti,omap4430-gpmc (omap4430 & omap4460 & omap543x)
+ ti,am3352-gpmc (am335x devices)
+
+ - reg: A resource specifier for the register space
+ (see the example below)
+ - ti,hwmods: Should be set to "ti,gpmc" until the DT transition is
+ completed.
+ - #address-cells: Must be set to 2 to allow memory address translation
+ - #size-cells: Must be set to 1 to allow CS address passing
+ - gpmc,num-cs: The maximum number of chip-select lines that controller
+ can support.
+ - gpmc,num-waitpins: The maximum number of wait pins that controller can
+ support.
+ - ranges: Must be set up to reflect the memory layout with four
+ integer values for each chip-select line in use:
+
+ <cs-number> 0 <physical address of mapping> <size>
+
+ Currently, calculated values derived from the contents
+ of the per-CS register GPMC_CONFIG7 (as set up by the
+ bootloader) are used for the physical address decoding.
+ As this will change in the future, filling correct
+ values here is a requirement.
+
+Timing properties for child nodes. All are optional and default to 0.
+
+ - gpmc,sync-clk-ps: Minimum clock period for synchronous mode, in picoseconds
+
+ Chip-select signal timings (in nanoseconds) corresponding to GPMC_CONFIG2:
+ - gpmc,cs-on-ns: Assertion time
+ - gpmc,cs-rd-off-ns: Read deassertion time
+ - gpmc,cs-wr-off-ns: Write deassertion time
+
+ ADV signal timings (in nanoseconds) corresponding to GPMC_CONFIG3:
+ - gpmc,adv-on-ns: Assertion time
+ - gpmc,adv-rd-off-ns: Read deassertion time
+ - gpmc,adv-wr-off-ns: Write deassertion time
+
+ WE signals timings (in nanoseconds) corresponding to GPMC_CONFIG4:
+ - gpmc,we-on-ns Assertion time
+ - gpmc,we-off-ns: Deassertion time
+
+ OE signals timings (in nanoseconds) corresponding to GPMC_CONFIG4:
+ - gpmc,oe-on-ns: Assertion time
+ - gpmc,oe-off-ns: Deassertion time
+
+ Access time and cycle time timings (in nanoseconds) corresponding to
+ GPMC_CONFIG5:
+ - gpmc,page-burst-access-ns: Multiple access word delay
+ - gpmc,access-ns: Start-cycle to first data valid delay
+ - gpmc,rd-cycle-ns: Total read cycle time
+ - gpmc,wr-cycle-ns: Total write cycle time
+ - gpmc,bus-turnaround-ns: Turn-around time between successive accesses
+ - gpmc,cycle2cycle-delay-ns: Delay between chip-select pulses
+ - gpmc,clk-activation-ns: GPMC clock activation time
+ - gpmc,wait-monitoring-ns: Start of wait monitoring with regard to valid
+ data
+
+Boolean timing parameters. If property is present parameter enabled and
+disabled if omitted:
+ - gpmc,adv-extra-delay: ADV signal is delayed by half GPMC clock
+ - gpmc,cs-extra-delay: CS signal is delayed by half GPMC clock
+ - gpmc,cycle2cycle-diffcsen: Add "cycle2cycle-delay" between successive
+ accesses to a different CS
+ - gpmc,cycle2cycle-samecsen: Add "cycle2cycle-delay" between successive
+ accesses to the same CS
+ - gpmc,oe-extra-delay: OE signal is delayed by half GPMC clock
+ - gpmc,we-extra-delay: WE signal is delayed by half GPMC clock
+ - gpmc,time-para-granularity: Multiply all access times by 2
+
+The following are only applicable to OMAP3+ and AM335x:
+ - gpmc,wr-access-ns: In synchronous write mode, for single or
+ burst accesses, defines the number of
+ GPMC_FCLK cycles from start access time
+ to the GPMC_CLK rising edge used by the
+ memory device for the first data capture.
+ - gpmc,wr-data-mux-bus-ns: In address-data multiplex mode, specifies
+ the time when the first data is driven on
+ the address-data bus.
+
+GPMC chip-select settings properties for child nodes. All are optional.
+
+- gpmc,burst-length Page/burst length. Must be 4, 8 or 16.
+- gpmc,burst-wrap Enables wrap bursting
+- gpmc,burst-read Enables read page/burst mode
+- gpmc,burst-write Enables write page/burst mode
+- gpmc,device-width Total width of device(s) connected to a GPMC
+ chip-select in bytes. The GPMC supports 8-bit
+ and 16-bit devices and so this property must be
+ 1 or 2.
+- gpmc,mux-add-data Address and data multiplexing configuration.
+ Valid values are 1 for address-address-data
+ multiplexing mode and 2 for address-data
+ multiplexing mode.
+- gpmc,sync-read Enables synchronous read. Defaults to asynchronous
+ is this is not set.
+- gpmc,sync-write Enables synchronous writes. Defaults to asynchronous
+ is this is not set.
+- gpmc,wait-pin Wait-pin used by client. Must be less than
+ "gpmc,num-waitpins".
+- gpmc,wait-on-read Enables wait monitoring on reads.
+- gpmc,wait-on-write Enables wait monitoring on writes.
+
+Example for an AM33xx board:
+
+ gpmc: gpmc@50000000 {
+ compatible = "ti,am3352-gpmc";
+ ti,hwmods = "gpmc";
+ reg = <0x50000000 0x2000>;
+ interrupts = <100>;
+
+ gpmc,num-cs = <8>;
+ gpmc,num-waitpins = <2>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges = <0 0 0x08000000 0x10000000>; /* CS0 @addr 0x8000000, size 0x10000000 */
+
+ /* child nodes go here */
+ };
diff --git a/Documentation/devicetree/bindings/clock/altr_socfpga.txt b/Documentation/devicetree/bindings/clock/altr_socfpga.txt
new file mode 100644
index 0000000..0045433
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/altr_socfpga.txt
@@ -0,0 +1,25 @@
+Device Tree Clock bindings for Altera's SoCFPGA platform
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible : shall be one of the following:
+ "altr,socfpga-pll-clock" - for a PLL clock
+ "altr,socfpga-perip-clock" - The peripheral clock divided from the
+ PLL clock.
+ "altr,socfpga-gate-clk" - Clocks that directly feed peripherals and
+ can get gated.
+
+- reg : shall be the control register offset from CLOCK_MANAGER's base for the clock.
+- clocks : shall be the input parent clock phandle for the clock. This is
+ either an oscillator or a pll output.
+- #clock-cells : from common clock binding, shall be set to 0.
+
+Optional properties:
+- fixed-divider : If clocks have a fixed divider value, use this property.
+- clk-gate : For "socfpga-gate-clk", clk-gate contains the gating register
+ and the bit index.
+- div-reg : For "socfpga-gate-clk", div-reg contains the divider register, bit shift,
+ and width.
diff --git a/Documentation/devicetree/bindings/clock/axi-clkgen.txt b/Documentation/devicetree/bindings/clock/axi-clkgen.txt
new file mode 100644
index 0000000..028b493
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/axi-clkgen.txt
@@ -0,0 +1,22 @@
+Binding for the axi-clkgen clock generator
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible : shall be "adi,axi-clkgen".
+- #clock-cells : from common clock binding; Should always be set to 0.
+- reg : Address and length of the axi-clkgen register set.
+- clocks : Phandle and clock specifier for the parent clock.
+
+Optional properties:
+- clock-output-names : From common clock binding.
+
+Example:
+ clock@0xff000000 {
+ compatible = "adi,axi-clkgen";
+ #clock-cells = <0>;
+ reg = <0xff000000 0x1000>;
+ clocks = <&osc 1>;
+ };
diff --git a/Documentation/devicetree/bindings/clock/clk-exynos-audss.txt b/Documentation/devicetree/bindings/clock/clk-exynos-audss.txt
new file mode 100644
index 0000000..a120180
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/clk-exynos-audss.txt
@@ -0,0 +1,64 @@
+* Samsung Audio Subsystem Clock Controller
+
+The Samsung Audio Subsystem clock controller generates and supplies clocks
+to Audio Subsystem block available in the S5PV210 and Exynos SoCs. The clock
+binding described here is applicable to all SoC's in Exynos family.
+
+Required Properties:
+
+- compatible: should be one of the following:
+ - "samsung,exynos4210-audss-clock" - controller compatible with all Exynos4 SoCs.
+ - "samsung,exynos5250-audss-clock" - controller compatible with all Exynos5 SoCs.
+
+- reg: physical base address and length of the controller's register set.
+
+- #clock-cells: should be 1.
+
+The following is the list of clocks generated by the controller. Each clock is
+assigned an identifier and client nodes use this identifier to specify the
+clock which they consume. Some of the clocks are available only on a particular
+Exynos4 SoC and this is specified where applicable.
+
+Provided clocks:
+
+Clock ID SoC (if specific)
+-----------------------------------------------
+
+mout_audss 0
+mout_i2s 1
+dout_srp 2
+dout_aud_bus 3
+dout_i2s 4
+srp_clk 5
+i2s_bus 6
+sclk_i2s 7
+pcm_bus 8
+sclk_pcm 9
+
+Example 1: An example of a clock controller node is listed below.
+
+clock_audss: audss-clock-controller@3810000 {
+ compatible = "samsung,exynos5250-audss-clock";
+ reg = <0x03810000 0x0C>;
+ #clock-cells = <1>;
+};
+
+Example 2: I2S controller node that consumes the clock generated by the clock
+ controller. Refer to the standard clock bindings for information
+ about 'clocks' and 'clock-names' property.
+
+i2s0: i2s@03830000 {
+ compatible = "samsung,i2s-v5";
+ reg = <0x03830000 0x100>;
+ dmas = <&pdma0 10
+ &pdma0 9
+ &pdma0 8>;
+ dma-names = "tx", "rx", "tx-sec";
+ clocks = <&clock_audss EXYNOS_I2S_BUS>,
+ <&clock_audss EXYNOS_I2S_BUS>,
+ <&clock_audss EXYNOS_SCLK_I2S>,
+ <&clock_audss EXYNOS_MOUT_AUDSS>,
+ <&clock_audss EXYNOS_MOUT_I2S>;
+ clock-names = "iis", "i2s_opclk0", "i2s_opclk1",
+ "mout_audss", "mout_i2s";
+};
diff --git a/Documentation/devicetree/bindings/clock/exynos4-clock.txt b/Documentation/devicetree/bindings/clock/exynos4-clock.txt
new file mode 100644
index 0000000..14d5c2a
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/exynos4-clock.txt
@@ -0,0 +1,289 @@
+* Samsung Exynos4 Clock Controller
+
+The Exynos4 clock controller generates and supplies clock to various controllers
+within the Exynos4 SoC. The clock binding described here is applicable to all
+SoC's in the Exynos4 family.
+
+Required Properties:
+
+- comptible: should be one of the following.
+ - "samsung,exynos4210-clock" - controller compatible with Exynos4210 SoC.
+ - "samsung,exynos4412-clock" - controller compatible with Exynos4412 SoC.
+
+- reg: physical base address of the controller and length of memory mapped
+ region.
+
+- #clock-cells: should be 1.
+
+The following is the list of clocks generated by the controller. Each clock is
+assigned an identifier and client nodes use this identifier to specify the
+clock which they consume. Some of the clocks are available only on a particular
+Exynos4 SoC and this is specified where applicable.
+
+
+ [Core Clocks]
+
+ Clock ID SoC (if specific)
+ -----------------------------------------------
+
+ xxti 1
+ xusbxti 2
+ fin_pll 3
+ fout_apll 4
+ fout_mpll 5
+ fout_epll 6
+ fout_vpll 7
+ sclk_apll 8
+ sclk_mpll 9
+ sclk_epll 10
+ sclk_vpll 11
+ arm_clk 12
+ aclk200 13
+ aclk100 14
+ aclk160 15
+ aclk133 16
+ mout_mpll_user_t 17 Exynos4x12
+ mout_mpll_user_c 18 Exynos4x12
+ mout_core 19
+ mout_apll 20
+
+
+ [Clock Gate for Special Clocks]
+
+ Clock ID SoC (if specific)
+ -----------------------------------------------
+
+ sclk_fimc0 128
+ sclk_fimc1 129
+ sclk_fimc2 130
+ sclk_fimc3 131
+ sclk_cam0 132
+ sclk_cam1 133
+ sclk_csis0 134
+ sclk_csis1 135
+ sclk_hdmi 136
+ sclk_mixer 137
+ sclk_dac 138
+ sclk_pixel 139
+ sclk_fimd0 140
+ sclk_mdnie0 141 Exynos4412
+ sclk_mdnie_pwm0 12 142 Exynos4412
+ sclk_mipi0 143
+ sclk_audio0 144
+ sclk_mmc0 145
+ sclk_mmc1 146
+ sclk_mmc2 147
+ sclk_mmc3 148
+ sclk_mmc4 149
+ sclk_sata 150 Exynos4210
+ sclk_uart0 151
+ sclk_uart1 152
+ sclk_uart2 153
+ sclk_uart3 154
+ sclk_uart4 155
+ sclk_audio1 156
+ sclk_audio2 157
+ sclk_spdif 158
+ sclk_spi0 159
+ sclk_spi1 160
+ sclk_spi2 161
+ sclk_slimbus 162
+ sclk_fimd1 163 Exynos4210
+ sclk_mipi1 164 Exynos4210
+ sclk_pcm1 165
+ sclk_pcm2 166
+ sclk_i2s1 167
+ sclk_i2s2 168
+ sclk_mipihsi 169 Exynos4412
+ sclk_mfc 170
+ sclk_pcm0 171
+ sclk_g3d 172
+ sclk_pwm_isp 173 Exynos4x12
+ sclk_spi0_isp 174 Exynos4x12
+ sclk_spi1_isp 175 Exynos4x12
+ sclk_uart_isp 176 Exynos4x12
+ sclk_fimg2d 177
+
+ [Peripheral Clock Gates]
+
+ Clock ID SoC (if specific)
+ -----------------------------------------------
+
+ fimc0 256
+ fimc1 257
+ fimc2 258
+ fimc3 259
+ csis0 260
+ csis1 261
+ jpeg 262
+ smmu_fimc0 263
+ smmu_fimc1 264
+ smmu_fimc2 265
+ smmu_fimc3 266
+ smmu_jpeg 267
+ vp 268
+ mixer 269
+ tvenc 270 Exynos4210
+ hdmi 271
+ smmu_tv 272
+ mfc 273
+ smmu_mfcl 274
+ smmu_mfcr 275
+ g3d 276
+ g2d 277
+ rotator 278 Exynos4210
+ mdma 279 Exynos4210
+ smmu_g2d 280 Exynos4210
+ smmu_rotator 281 Exynos4210
+ smmu_mdma 282 Exynos4210
+ fimd0 283
+ mie0 284
+ mdnie0 285 Exynos4412
+ dsim0 286
+ smmu_fimd0 287
+ fimd1 288 Exynos4210
+ mie1 289 Exynos4210
+ dsim1 290 Exynos4210
+ smmu_fimd1 291 Exynos4210
+ pdma0 292
+ pdma1 293
+ pcie_phy 294
+ sata_phy 295 Exynos4210
+ tsi 296
+ sdmmc0 297
+ sdmmc1 298
+ sdmmc2 299
+ sdmmc3 300
+ sdmmc4 301
+ sata 302 Exynos4210
+ sromc 303
+ usb_host 304
+ usb_device 305
+ pcie 306
+ onenand 307
+ nfcon 308
+ smmu_pcie 309
+ gps 310
+ smmu_gps 311
+ uart0 312
+ uart1 313
+ uart2 314
+ uart3 315
+ uart4 316
+ i2c0 317
+ i2c1 318
+ i2c2 319
+ i2c3 320
+ i2c4 321
+ i2c5 322
+ i2c6 323
+ i2c7 324
+ i2c_hdmi 325
+ tsadc 326
+ spi0 327
+ spi1 328
+ spi2 329
+ i2s1 330
+ i2s2 331
+ pcm0 332
+ i2s0 333
+ pcm1 334
+ pcm2 335
+ pwm 336
+ slimbus 337
+ spdif 338
+ ac97 339
+ modemif 340
+ chipid 341
+ sysreg 342
+ hdmi_cec 343
+ mct 344
+ wdt 345
+ rtc 346
+ keyif 347
+ audss 348
+ mipi_hsi 349 Exynos4210
+ mdma2 350 Exynos4210
+ pixelasyncm0 351
+ pixelasyncm1 352
+ fimc_lite0 353 Exynos4x12
+ fimc_lite1 354 Exynos4x12
+ ppmuispx 355 Exynos4x12
+ ppmuispmx 356 Exynos4x12
+ fimc_isp 357 Exynos4x12
+ fimc_drc 358 Exynos4x12
+ fimc_fd 359 Exynos4x12
+ mcuisp 360 Exynos4x12
+ gicisp 361 Exynos4x12
+ smmu_isp 362 Exynos4x12
+ smmu_drc 363 Exynos4x12
+ smmu_fd 364 Exynos4x12
+ smmu_lite0 365 Exynos4x12
+ smmu_lite1 366 Exynos4x12
+ mcuctl_isp 367 Exynos4x12
+ mpwm_isp 368 Exynos4x12
+ i2c0_isp 369 Exynos4x12
+ i2c1_isp 370 Exynos4x12
+ mtcadc_isp 371 Exynos4x12
+ pwm_isp 372 Exynos4x12
+ wdt_isp 373 Exynos4x12
+ uart_isp 374 Exynos4x12
+ asyncaxim 375 Exynos4x12
+ smmu_ispcx 376 Exynos4x12
+ spi0_isp 377 Exynos4x12
+ spi1_isp 378 Exynos4x12
+ pwm_isp_sclk 379 Exynos4x12
+ spi0_isp_sclk 380 Exynos4x12
+ spi1_isp_sclk 381 Exynos4x12
+ uart_isp_sclk 382 Exynos4x12
+
+ [Mux Clocks]
+
+ Clock ID SoC (if specific)
+ -----------------------------------------------
+
+ mout_fimc0 384
+ mout_fimc1 385
+ mout_fimc2 386
+ mout_fimc3 387
+ mout_cam0 388
+ mout_cam1 389
+ mout_csis0 390
+ mout_csis1 391
+ mout_g3d0 392
+ mout_g3d1 393
+ mout_g3d 394
+ aclk400_mcuisp 395 Exynos4x12
+
+ [Div Clocks]
+
+ Clock ID SoC (if specific)
+ -----------------------------------------------
+
+ div_isp0 450 Exynos4x12
+ div_isp1 451 Exynos4x12
+ div_mcuisp0 452 Exynos4x12
+ div_mcuisp1 453 Exynos4x12
+ div_aclk200 454 Exynos4x12
+ div_aclk400_mcuisp 455 Exynos4x12
+
+
+Example 1: An example of a clock controller node is listed below.
+
+ clock: clock-controller@0x10030000 {
+ compatible = "samsung,exynos4210-clock";
+ reg = <0x10030000 0x20000>;
+ #clock-cells = <1>;
+ };
+
+Example 2: UART controller node that consumes the clock generated by the clock
+ controller. Refer to the standard clock bindings for information
+ about 'clocks' and 'clock-names' property.
+
+ serial@13820000 {
+ compatible = "samsung,exynos4210-uart";
+ reg = <0x13820000 0x100>;
+ interrupts = <0 54 0>;
+ clocks = <&clock 314>, <&clock 153>;
+ clock-names = "uart", "clk_uart_baud0";
+ };
diff --git a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
new file mode 100644
index 0000000..781a627
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
@@ -0,0 +1,177 @@
+* Samsung Exynos5250 Clock Controller
+
+The Exynos5250 clock controller generates and supplies clock to various
+controllers within the Exynos5250 SoC.
+
+Required Properties:
+
+- comptible: should be one of the following.
+ - "samsung,exynos5250-clock" - controller compatible with Exynos5250 SoC.
+
+- reg: physical base address of the controller and length of memory mapped
+ region.
+
+- #clock-cells: should be 1.
+
+The following is the list of clocks generated by the controller. Each clock is
+assigned an identifier and client nodes use this identifier to specify the
+clock which they consume.
+
+
+ [Core Clocks]
+
+ Clock ID
+ ----------------------------
+
+ fin_pll 1
+
+ [Clock Gate for Special Clocks]
+
+ Clock ID
+ ----------------------------
+
+ sclk_cam_bayer 128
+ sclk_cam0 129
+ sclk_cam1 130
+ sclk_gscl_wa 131
+ sclk_gscl_wb 132
+ sclk_fimd1 133
+ sclk_mipi1 134
+ sclk_dp 135
+ sclk_hdmi 136
+ sclk_pixel 137
+ sclk_audio0 138
+ sclk_mmc0 139
+ sclk_mmc1 140
+ sclk_mmc2 141
+ sclk_mmc3 142
+ sclk_sata 143
+ sclk_usb3 144
+ sclk_jpeg 145
+ sclk_uart0 146
+ sclk_uart1 147
+ sclk_uart2 148
+ sclk_uart3 149
+ sclk_pwm 150
+ sclk_audio1 151
+ sclk_audio2 152
+ sclk_spdif 153
+ sclk_spi0 154
+ sclk_spi1 155
+ sclk_spi2 156
+
+
+ [Peripheral Clock Gates]
+
+ Clock ID
+ ----------------------------
+
+ gscl0 256
+ gscl1 257
+ gscl2 258
+ gscl3 259
+ gscl_wa 260
+ gscl_wb 261
+ smmu_gscl0 262
+ smmu_gscl1 263
+ smmu_gscl2 264
+ smmu_gscl3 265
+ mfc 266
+ smmu_mfcl 267
+ smmu_mfcr 268
+ rotator 269
+ jpeg 270
+ mdma1 271
+ smmu_rotator 272
+ smmu_jpeg 273
+ smmu_mdma1 274
+ pdma0 275
+ pdma1 276
+ sata 277
+ usbotg 278
+ mipi_hsi 279
+ sdmmc0 280
+ sdmmc1 281
+ sdmmc2 282
+ sdmmc3 283
+ sromc 284
+ usb2 285
+ usb3 286
+ sata_phyctrl 287
+ sata_phyi2c 288
+ uart0 289
+ uart1 290
+ uart2 291
+ uart3 292
+ uart4 293
+ i2c0 294
+ i2c1 295
+ i2c2 296
+ i2c3 297
+ i2c4 298
+ i2c5 299
+ i2c6 300
+ i2c7 301
+ i2c_hdmi 302
+ adc 303
+ spi0 304
+ spi1 305
+ spi2 306
+ i2s1 307
+ i2s2 308
+ pcm1 309
+ pcm2 310
+ pwm 311
+ spdif 312
+ ac97 313
+ hsi2c0 314
+ hsi2c1 315
+ hs12c2 316
+ hs12c3 317
+ chipid 318
+ sysreg 319
+ pmu 320
+ cmu_top 321
+ cmu_core 322
+ cmu_mem 323
+ tzpc0 324
+ tzpc1 325
+ tzpc2 326
+ tzpc3 327
+ tzpc4 328
+ tzpc5 329
+ tzpc6 330
+ tzpc7 331
+ tzpc8 332
+ tzpc9 333
+ hdmi_cec 334
+ mct 335
+ wdt 336
+ rtc 337
+ tmu 338
+ fimd1 339
+ mie1 340
+ dsim0 341
+ dp 342
+ mixer 343
+ hdmi 345
+
+Example 1: An example of a clock controller node is listed below.
+
+ clock: clock-controller@0x10010000 {
+ compatible = "samsung,exynos5250-clock";
+ reg = <0x10010000 0x30000>;
+ #clock-cells = <1>;
+ };
+
+Example 2: UART controller node that consumes the clock generated by the clock
+ controller. Refer to the standard clock bindings for information
+ about 'clocks' and 'clock-names' property.
+
+ serial@13820000 {
+ compatible = "samsung,exynos4210-uart";
+ reg = <0x13820000 0x100>;
+ interrupts = <0 54 0>;
+ clocks = <&clock 314>, <&clock 153>;
+ clock-names = "uart", "clk_uart_baud0";
+ };
diff --git a/Documentation/devicetree/bindings/clock/exynos5420-clock.txt b/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
new file mode 100644
index 0000000..9bcc4b1
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
@@ -0,0 +1,201 @@
+* Samsung Exynos5420 Clock Controller
+
+The Exynos5420 clock controller generates and supplies clock to various
+controllers within the Exynos5420 SoC.
+
+Required Properties:
+
+- comptible: should be one of the following.
+ - "samsung,exynos5420-clock" - controller compatible with Exynos5420 SoC.
+
+- reg: physical base address of the controller and length of memory mapped
+ region.
+
+- #clock-cells: should be 1.
+
+The following is the list of clocks generated by the controller. Each clock is
+assigned an identifier and client nodes use this identifier to specify the
+clock which they consume.
+
+
+ [Core Clocks]
+
+ Clock ID
+ ----------------------------
+
+ fin_pll 1
+
+ [Clock Gate for Special Clocks]
+
+ Clock ID
+ ----------------------------
+ sclk_uart0 128
+ sclk_uart1 129
+ sclk_uart2 130
+ sclk_uart3 131
+ sclk_mmc0 132
+ sclk_mmc1 133
+ sclk_mmc2 134
+ sclk_spi0 135
+ sclk_spi1 136
+ sclk_spi2 137
+ sclk_i2s1 138
+ sclk_i2s2 139
+ sclk_pcm1 140
+ sclk_pcm2 141
+ sclk_spdif 142
+ sclk_hdmi 143
+ sclk_pixel 144
+ sclk_dp1 145
+ sclk_mipi1 146
+ sclk_fimd1 147
+ sclk_maudio0 148
+ sclk_maupcm0 149
+ sclk_usbd300 150
+ sclk_usbd301 151
+ sclk_usbphy300 152
+ sclk_usbphy301 153
+ sclk_unipro 154
+ sclk_pwm 155
+ sclk_gscl_wa 156
+ sclk_gscl_wb 157
+
+ [Peripheral Clock Gates]
+
+ Clock ID
+ ----------------------------
+
+ aclk66_peric 256
+ uart0 257
+ uart1 258
+ uart2 259
+ uart3 260
+ i2c0 261
+ i2c1 262
+ i2c2 263
+ i2c3 264
+ i2c4 265
+ i2c5 266
+ i2c6 267
+ i2c7 268
+ i2c_hdmi 269
+ tsadc 270
+ spi0 271
+ spi1 272
+ spi2 273
+ keyif 274
+ i2s1 275
+ i2s2 276
+ pcm1 277
+ pcm2 278
+ pwm 279
+ spdif 280
+ i2c8 281
+ i2c9 282
+ i2c10 283
+ aclk66_psgen 300
+ chipid 301
+ sysreg 302
+ tzpc0 303
+ tzpc1 304
+ tzpc2 305
+ tzpc3 306
+ tzpc4 307
+ tzpc5 308
+ tzpc6 309
+ tzpc7 310
+ tzpc8 311
+ tzpc9 312
+ hdmi_cec 313
+ seckey 314
+ mct 315
+ wdt 316
+ rtc 317
+ tmu 318
+ tmu_gpu 319
+ pclk66_gpio 330
+ aclk200_fsys2 350
+ mmc0 351
+ mmc1 352
+ mmc2 353
+ sromc 354
+ ufs 355
+ aclk200_fsys 360
+ tsi 361
+ pdma0 362
+ pdma1 363
+ rtic 364
+ usbh20 365
+ usbd300 366
+ usbd301 377
+ aclk400_mscl 380
+ mscl0 381
+ mscl1 382
+ mscl2 383
+ smmu_mscl0 384
+ smmu_mscl1 385
+ smmu_mscl2 386
+ aclk333 400
+ mfc 401
+ smmu_mfcl 402
+ smmu_mfcr 403
+ aclk200_disp1 410
+ dsim1 411
+ dp1 412
+ hdmi 413
+ aclk300_disp1 420
+ fimd1 421
+ smmu_fimd1 422
+ aclk166 430
+ mixer 431
+ aclk266 440
+ rotator 441
+ mdma1 442
+ smmu_rotator 443
+ smmu_mdma1 444
+ aclk300_jpeg 450
+ jpeg 451
+ jpeg2 452
+ smmu_jpeg 453
+ aclk300_gscl 460
+ smmu_gscl0 461
+ smmu_gscl1 462
+ gscl_wa 463
+ gscl_wb 464
+ gscl0 465
+ gscl1 466
+ clk_3aa 467
+ aclk266_g2d 470
+ sss 471
+ slim_sss 472
+ mdma0 473
+ aclk333_g2d 480
+ g2d 481
+ aclk333_432_gscl 490
+ smmu_3aa 491
+ smmu_fimcl0 492
+ smmu_fimcl1 493
+ smmu_fimcl3 494
+ fimc_lite3 495
+ aclk_g3d 500
+ g3d 501
+
+Example 1: An example of a clock controller node is listed below.
+
+ clock: clock-controller@0x10010000 {
+ compatible = "samsung,exynos5420-clock";
+ reg = <0x10010000 0x30000>;
+ #clock-cells = <1>;
+ };
+
+Example 2: UART controller node that consumes the clock generated by the clock
+ controller. Refer to the standard clock bindings for information
+ about 'clocks' and 'clock-names' property.
+
+ serial@13820000 {
+ compatible = "samsung,exynos4210-uart";
+ reg = <0x13820000 0x100>;
+ interrupts = <0 54 0>;
+ clocks = <&clock 259>, <&clock 130>;
+ clock-names = "uart", "clk_uart_baud0";
+ };
diff --git a/Documentation/devicetree/bindings/clock/exynos5440-clock.txt b/Documentation/devicetree/bindings/clock/exynos5440-clock.txt
new file mode 100644
index 0000000..4499e99
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/exynos5440-clock.txt
@@ -0,0 +1,61 @@
+* Samsung Exynos5440 Clock Controller
+
+The Exynos5440 clock controller generates and supplies clock to various
+controllers within the Exynos5440 SoC.
+
+Required Properties:
+
+- comptible: should be "samsung,exynos5440-clock".
+
+- reg: physical base address of the controller and length of memory mapped
+ region.
+
+- #clock-cells: should be 1.
+
+The following is the list of clocks generated by the controller. Each clock is
+assigned an identifier and client nodes use this identifier to specify the
+clock which they consume.
+
+
+ [Core Clocks]
+
+ Clock ID
+ ----------------------------
+
+ xtal 1
+ arm_clk 2
+
+ [Peripheral Clock Gates]
+
+ Clock ID
+ ----------------------------
+
+ spi_baud 16
+ pb0_250 17
+ pr0_250 18
+ pr1_250 19
+ b_250 20
+ b_125 21
+ b_200 22
+ sata 23
+ usb 24
+ gmac0 25
+ cs250 26
+ pb0_250_o 27
+ pr0_250_o 28
+ pr1_250_o 29
+ b_250_o 30
+ b_125_o 31
+ b_200_o 32
+ sata_o 33
+ usb_o 34
+ gmac0_o 35
+ cs250_o 36
+
+Example: An example of a clock controller node is listed below.
+
+ clock: clock-controller@0x10010000 {
+ compatible = "samsung,exynos5440-clock";
+ reg = <0x160000 0x10000>;
+ #clock-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/clock/fixed-factor-clock.txt b/Documentation/devicetree/bindings/clock/fixed-factor-clock.txt
new file mode 100644
index 0000000..5757f9a
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/fixed-factor-clock.txt
@@ -0,0 +1,24 @@
+Binding for simple fixed factor rate clock sources.
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible : shall be "fixed-factor-clock".
+- #clock-cells : from common clock binding; shall be set to 0.
+- clock-div: fixed divider.
+- clock-mult: fixed multiplier.
+- clocks: parent clock.
+
+Optional properties:
+- clock-output-names : From common clock binding.
+
+Example:
+ clock {
+ compatible = "fixed-factor-clock";
+ clocks = <&parentclk>;
+ #clock-cells = <0>;
+ div = <2>;
+ mult = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/clock/imx23-clock.txt b/Documentation/devicetree/bindings/clock/imx23-clock.txt
index baadbb1..5083c0b 100644
--- a/Documentation/devicetree/bindings/clock/imx23-clock.txt
+++ b/Documentation/devicetree/bindings/clock/imx23-clock.txt
@@ -60,11 +60,6 @@
compatible = "fsl,imx23-clkctrl";
reg = <0x80040000 0x2000>;
#clock-cells = <1>;
- clock-output-names =
- ...
- "uart", /* 32 */
- ...
- "end_of_list";
};
auart0: serial@8006c000 {
diff --git a/Documentation/devicetree/bindings/clock/imx25-clock.txt b/Documentation/devicetree/bindings/clock/imx25-clock.txt
index c2a3525..db4f2f0 100644
--- a/Documentation/devicetree/bindings/clock/imx25-clock.txt
+++ b/Documentation/devicetree/bindings/clock/imx25-clock.txt
@@ -146,10 +146,6 @@
compatible = "fsl,imx25-ccm";
reg = <0x53f80000 0x4000>;
interrupts = <31>;
- clock-output-names = ...
- "uart_ipg",
- "uart_serial",
- ...;
};
uart1: serial@43f90000 {
diff --git a/Documentation/devicetree/bindings/clock/imx27-clock.txt b/Documentation/devicetree/bindings/clock/imx27-clock.txt
new file mode 100644
index 0000000..ab1a56e
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/imx27-clock.txt
@@ -0,0 +1,117 @@
+* Clock bindings for Freescale i.MX27
+
+Required properties:
+- compatible: Should be "fsl,imx27-ccm"
+- reg: Address and length of the register set
+- interrupts: Should contain CCM interrupt
+- #clock-cells: Should be <1>
+
+The clock consumer should specify the desired clock by having the clock
+ID in its "clocks" phandle cell. The following is a full list of i.MX27
+clocks and IDs.
+
+ Clock ID
+ -----------------------
+ dummy 0
+ ckih 1
+ ckil 2
+ mpll 3
+ spll 4
+ mpll_main2 5
+ ahb 6
+ ipg 7
+ nfc_div 8
+ per1_div 9
+ per2_div 10
+ per3_div 11
+ per4_div 12
+ vpu_sel 13
+ vpu_div 14
+ usb_div 15
+ cpu_sel 16
+ clko_sel 17
+ cpu_div 18
+ clko_div 19
+ ssi1_sel 20
+ ssi2_sel 21
+ ssi1_div 22
+ ssi2_div 23
+ clko_en 24
+ ssi2_ipg_gate 25
+ ssi1_ipg_gate 26
+ slcdc_ipg_gate 27
+ sdhc3_ipg_gate 28
+ sdhc2_ipg_gate 29
+ sdhc1_ipg_gate 30
+ scc_ipg_gate 31
+ sahara_ipg_gate 32
+ rtc_ipg_gate 33
+ pwm_ipg_gate 34
+ owire_ipg_gate 35
+ lcdc_ipg_gate 36
+ kpp_ipg_gate 37
+ iim_ipg_gate 38
+ i2c2_ipg_gate 39
+ i2c1_ipg_gate 40
+ gpt6_ipg_gate 41
+ gpt5_ipg_gate 42
+ gpt4_ipg_gate 43
+ gpt3_ipg_gate 44
+ gpt2_ipg_gate 45
+ gpt1_ipg_gate 46
+ gpio_ipg_gate 47
+ fec_ipg_gate 48
+ emma_ipg_gate 49
+ dma_ipg_gate 50
+ cspi3_ipg_gate 51
+ cspi2_ipg_gate 52
+ cspi1_ipg_gate 53
+ nfc_baud_gate 54
+ ssi2_baud_gate 55
+ ssi1_baud_gate 56
+ vpu_baud_gate 57
+ per4_gate 58
+ per3_gate 59
+ per2_gate 60
+ per1_gate 61
+ usb_ahb_gate 62
+ slcdc_ahb_gate 63
+ sahara_ahb_gate 64
+ lcdc_ahb_gate 65
+ vpu_ahb_gate 66
+ fec_ahb_gate 67
+ emma_ahb_gate 68
+ emi_ahb_gate 69
+ dma_ahb_gate 70
+ csi_ahb_gate 71
+ brom_ahb_gate 72
+ ata_ahb_gate 73
+ wdog_ipg_gate 74
+ usb_ipg_gate 75
+ uart6_ipg_gate 76
+ uart5_ipg_gate 77
+ uart4_ipg_gate 78
+ uart3_ipg_gate 79
+ uart2_ipg_gate 80
+ uart1_ipg_gate 81
+ ckih_div1p5 82
+ fpm 83
+ mpll_osc_sel 84
+ mpll_sel 85
+
+Examples:
+
+clks: ccm@10027000{
+ compatible = "fsl,imx27-ccm";
+ reg = <0x10027000 0x1000>;
+ #clock-cells = <1>;
+};
+
+uart1: serial@1000a000 {
+ compatible = "fsl,imx27-uart", "fsl,imx21-uart";
+ reg = <0x1000a000 0x1000>;
+ interrupts = <20>;
+ clocks = <&clks 81>, <&clks 61>;
+ clock-names = "ipg", "per";
+ status = "disabled";
+};
diff --git a/Documentation/devicetree/bindings/clock/imx28-clock.txt b/Documentation/devicetree/bindings/clock/imx28-clock.txt
index 52a49a4..e6587af 100644
--- a/Documentation/devicetree/bindings/clock/imx28-clock.txt
+++ b/Documentation/devicetree/bindings/clock/imx28-clock.txt
@@ -83,11 +83,6 @@
compatible = "fsl,imx28-clkctrl";
reg = <0x80040000 0x2000>;
#clock-cells = <1>;
- clock-output-names =
- ...
- "uart", /* 45 */
- ...
- "end_of_list";
};
auart0: serial@8006a000 {
diff --git a/Documentation/devicetree/bindings/clock/imx31-clock.txt b/Documentation/devicetree/bindings/clock/imx31-clock.txt
new file mode 100644
index 0000000..19df842c
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/imx31-clock.txt
@@ -0,0 +1,91 @@
+* Clock bindings for Freescale i.MX31
+
+Required properties:
+- compatible: Should be "fsl,imx31-ccm"
+- reg: Address and length of the register set
+- interrupts: Should contain CCM interrupt
+- #clock-cells: Should be <1>
+
+The clock consumer should specify the desired clock by having the clock
+ID in its "clocks" phandle cell. The following is a full list of i.MX31
+clocks and IDs.
+
+ Clock ID
+ -----------------------
+ dummy 0
+ ckih 1
+ ckil 2
+ mpll 3
+ spll 4
+ upll 5
+ mcu_main 6
+ hsp 7
+ ahb 8
+ nfc 9
+ ipg 10
+ per_div 11
+ per 12
+ csi_sel 13
+ fir_sel 14
+ csi_div 15
+ usb_div_pre 16
+ usb_div_post 17
+ fir_div_pre 18
+ fir_div_post 19
+ sdhc1_gate 20
+ sdhc2_gate 21
+ gpt_gate 22
+ epit1_gate 23
+ epit2_gate 24
+ iim_gate 25
+ ata_gate 26
+ sdma_gate 27
+ cspi3_gate 28
+ rng_gate 29
+ uart1_gate 30
+ uart2_gate 31
+ ssi1_gate 32
+ i2c1_gate 33
+ i2c2_gate 34
+ i2c3_gate 35
+ hantro_gate 36
+ mstick1_gate 37
+ mstick2_gate 38
+ csi_gate 39
+ rtc_gate 40
+ wdog_gate 41
+ pwm_gate 42
+ sim_gate 43
+ ect_gate 44
+ usb_gate 45
+ kpp_gate 46
+ ipu_gate 47
+ uart3_gate 48
+ uart4_gate 49
+ uart5_gate 50
+ owire_gate 51
+ ssi2_gate 52
+ cspi1_gate 53
+ cspi2_gate 54
+ gacc_gate 55
+ emi_gate 56
+ rtic_gate 57
+ firi_gate 58
+
+Examples:
+
+clks: ccm@53f80000{
+ compatible = "fsl,imx31-ccm";
+ reg = <0x53f80000 0x4000>;
+ interrupts = <0 31 0x04 0 53 0x04>;
+ #clock-cells = <1>;
+};
+
+uart1: serial@43f90000 {
+ compatible = "fsl,imx31-uart", "fsl,imx21-uart";
+ reg = <0x43f90000 0x4000>;
+ interrupts = <45>;
+ clocks = <&clks 10>, <&clks 30>;
+ clock-names = "ipg", "per";
+ status = "disabled";
+};
diff --git a/Documentation/devicetree/bindings/clock/imx5-clock.txt b/Documentation/devicetree/bindings/clock/imx5-clock.txt
index 04ad478..f46f562 100644
--- a/Documentation/devicetree/bindings/clock/imx5-clock.txt
+++ b/Documentation/devicetree/bindings/clock/imx5-clock.txt
@@ -38,7 +38,6 @@
usb_phy_podf 23
cpu_podf 24
di_pred 25
- tve_di 26
tve_s 27
uart1_ipg_gate 28
uart1_per_gate 29
@@ -171,6 +170,33 @@
can_sel 156
can1_serial_gate 157
can1_ipg_gate 158
+ owire_gate 159
+ gpu3d_s 160
+ gpu2d_s 161
+ gpu3d_gate 162
+ gpu2d_gate 163
+ garb_gate 164
+ cko1_sel 165
+ cko1_podf 166
+ cko1 167
+ cko2_sel 168
+ cko2_podf 169
+ cko2 170
+ srtc_gate 171
+ pata_gate 172
+ sata_gate 173
+ spdif_xtal_sel 174
+ spdif0_sel 175
+ spdif1_sel 176
+ spdif0_pred 177
+ spdif0_podf 178
+ spdif1_pred 179
+ spdif1_podf 180
+ spdif0_com_sel 181
+ spdif1_com_sel 182
+ spdif0_gate 183
+ spdif1_gate 184
+ spdif_ipg_gate 185
Examples (for mx53):
diff --git a/Documentation/devicetree/bindings/clock/imx6q-clock.txt b/Documentation/devicetree/bindings/clock/imx6q-clock.txt
index d77b4e6..a0e104f 100644
--- a/Documentation/devicetree/bindings/clock/imx6q-clock.txt
+++ b/Documentation/devicetree/bindings/clock/imx6q-clock.txt
@@ -203,6 +203,12 @@
pcie_ref 188
pcie_ref_125m 189
enet_ref 190
+ usbphy1_gate 191
+ usbphy2_gate 192
+ pll4_post_div 193
+ pll5_post_div 194
+ pll5_video_div 195
+ eim_slow 196
Examples:
@@ -211,10 +217,6 @@
reg = <0x020c4000 0x4000>;
interrupts = <0 87 0x04 0 88 0x04>;
#clock-cells = <1>;
- clock-output-names = ...
- "uart_ipg",
- "uart_serial",
- ...;
};
uart1: serial@02020000 {
diff --git a/Documentation/devicetree/bindings/clock/imx6sl-clock.txt b/Documentation/devicetree/bindings/clock/imx6sl-clock.txt
new file mode 100644
index 0000000..15e40bd
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/imx6sl-clock.txt
@@ -0,0 +1,10 @@
+* Clock bindings for Freescale i.MX6 SoloLite
+
+Required properties:
+- compatible: Should be "fsl,imx6sl-ccm"
+- reg: Address and length of the register set
+- #clock-cells: Should be <1>
+
+The clock consumer should specify the desired clock by having the clock
+ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx6sl-clock.h
+for the full list of i.MX6 SoloLite clock IDs.
diff --git a/Documentation/devicetree/bindings/clock/mvebu-gated-clock.txt b/Documentation/devicetree/bindings/clock/mvebu-gated-clock.txt
index 7337005e..cffc93d 100644
--- a/Documentation/devicetree/bindings/clock/mvebu-gated-clock.txt
+++ b/Documentation/devicetree/bindings/clock/mvebu-gated-clock.txt
@@ -89,7 +89,7 @@
16 xor1 XOR DMA 1
17 crypto CESA engine
18 pex1 PCIe Cntrl 1
-19 ge1 Gigabit Ethernet 0
+19 ge1 Gigabit Ethernet 1
20 tdm Time Division Mplx
Required properties:
diff --git a/Documentation/devicetree/bindings/clock/nspire-clock.txt b/Documentation/devicetree/bindings/clock/nspire-clock.txt
new file mode 100644
index 0000000..7c3bc8b
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/nspire-clock.txt
@@ -0,0 +1,24 @@
+TI-NSPIRE Clocks
+
+Required properties:
+- compatible: Valid compatible properties include:
+ "lsi,nspire-cx-ahb-divider" for the AHB divider in the CX model
+ "lsi,nspire-classic-ahb-divider" for the AHB divider in the older model
+ "lsi,nspire-cx-clock" for the base clock in the CX model
+ "lsi,nspire-classic-clock" for the base clock in the older model
+
+- reg: Physical base address of the controller and length of memory mapped
+ region.
+
+Optional:
+- clocks: For the "nspire-*-ahb-divider" compatible clocks, this is the parent
+ clock where it divides the rate from.
+
+Example:
+
+ahb_clk {
+ #clock-cells = <0>;
+ compatible = "lsi,nspire-cx-clock";
+ reg = <0x900B0000 0x4>;
+ clocks = <&base_clk>;
+};
diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra114-car.txt b/Documentation/devicetree/bindings/clock/nvidia,tegra114-car.txt
new file mode 100644
index 0000000..0c80c26
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/nvidia,tegra114-car.txt
@@ -0,0 +1,59 @@
+NVIDIA Tegra114 Clock And Reset Controller
+
+This binding uses the common clock binding:
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+The CAR (Clock And Reset) Controller on Tegra is the HW module responsible
+for muxing and gating Tegra's clocks, and setting their rates.
+
+Required properties :
+- compatible : Should be "nvidia,tegra114-car"
+- reg : Should contain CAR registers location and length
+- clocks : Should contain phandle and clock specifiers for two clocks:
+ the 32 KHz "32k_in", and the board-specific oscillator "osc".
+- #clock-cells : Should be 1.
+ In clock consumers, this cell represents the clock ID exposed by the
+ CAR. The assignments may be found in header file
+ <dt-bindings/clock/tegra114-car.h>.
+
+Example SoC include file:
+
+/ {
+ tegra_car: clock {
+ compatible = "nvidia,tegra114-car";
+ reg = <0x60006000 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ usb@c5004000 {
+ clocks = <&tegra_car TEGRA114_CLK_USB2>;
+ };
+};
+
+Example board file:
+
+/ {
+ clocks {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ osc: clock@0 {
+ compatible = "fixed-clock";
+ reg = <0>;
+ #clock-cells = <0>;
+ clock-frequency = <12000000>;
+ };
+
+ clk_32k: clock@1 {
+ compatible = "fixed-clock";
+ reg = <1>;
+ #clock-cells = <0>;
+ clock-frequency = <32768>;
+ };
+ };
+
+ &tegra_car {
+ clocks = <&clk_32k> <&osc>;
+ };
+};
diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt b/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt
new file mode 100644
index 0000000..fcfed5b
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt
@@ -0,0 +1,59 @@
+NVIDIA Tegra20 Clock And Reset Controller
+
+This binding uses the common clock binding:
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+The CAR (Clock And Reset) Controller on Tegra is the HW module responsible
+for muxing and gating Tegra's clocks, and setting their rates.
+
+Required properties :
+- compatible : Should be "nvidia,tegra20-car"
+- reg : Should contain CAR registers location and length
+- clocks : Should contain phandle and clock specifiers for two clocks:
+ the 32 KHz "32k_in", and the board-specific oscillator "osc".
+- #clock-cells : Should be 1.
+ In clock consumers, this cell represents the clock ID exposed by the
+ CAR. The assignments may be found in header file
+ <dt-bindings/clock/tegra20-car.h>.
+
+Example SoC include file:
+
+/ {
+ tegra_car: clock {
+ compatible = "nvidia,tegra20-car";
+ reg = <0x60006000 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ usb@c5004000 {
+ clocks = <&tegra_car TEGRA20_CLK_USB2>;
+ };
+};
+
+Example board file:
+
+/ {
+ clocks {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ osc: clock@0 {
+ compatible = "fixed-clock";
+ reg = <0>;
+ #clock-cells = <0>;
+ clock-frequency = <12000000>;
+ };
+
+ clk_32k: clock@1 {
+ compatible = "fixed-clock";
+ reg = <1>;
+ #clock-cells = <0>;
+ clock-frequency = <32768>;
+ };
+ };
+
+ &tegra_car {
+ clocks = <&clk_32k> <&osc>;
+ };
+};
diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra30-car.txt b/Documentation/devicetree/bindings/clock/nvidia,tegra30-car.txt
new file mode 100644
index 0000000..0f71408
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/nvidia,tegra30-car.txt
@@ -0,0 +1,59 @@
+NVIDIA Tegra30 Clock And Reset Controller
+
+This binding uses the common clock binding:
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+The CAR (Clock And Reset) Controller on Tegra is the HW module responsible
+for muxing and gating Tegra's clocks, and setting their rates.
+
+Required properties :
+- compatible : Should be "nvidia,tegra30-car"
+- reg : Should contain CAR registers location and length
+- clocks : Should contain phandle and clock specifiers for two clocks:
+ the 32 KHz "32k_in", and the board-specific oscillator "osc".
+- #clock-cells : Should be 1.
+ In clock consumers, this cell represents the clock ID exposed by the
+ CAR. The assignments may be found in header file
+ <dt-bindings/clock/tegra30-car.h>.
+
+Example SoC include file:
+
+/ {
+ tegra_car: clock {
+ compatible = "nvidia,tegra30-car";
+ reg = <0x60006000 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ usb@c5004000 {
+ clocks = <&tegra_car TEGRA30_CLK_USB2>;
+ };
+};
+
+Example board file:
+
+/ {
+ clocks {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ osc: clock@0 {
+ compatible = "fixed-clock";
+ reg = <0>;
+ #clock-cells = <0>;
+ clock-frequency = <12000000>;
+ };
+
+ clk_32k: clock@1 {
+ compatible = "fixed-clock";
+ reg = <1>;
+ #clock-cells = <0>;
+ clock-frequency = <32768>;
+ };
+ };
+
+ &tegra_car {
+ clocks = <&clk_32k> <&osc>;
+ };
+};
diff --git a/Documentation/devicetree/bindings/clock/prima2-clock.txt b/Documentation/devicetree/bindings/clock/prima2-clock.txt
new file mode 100644
index 0000000..5016979
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/prima2-clock.txt
@@ -0,0 +1,73 @@
+* Clock bindings for CSR SiRFprimaII
+
+Required properties:
+- compatible: Should be "sirf,prima2-clkc"
+- reg: Address and length of the register set
+- interrupts: Should contain clock controller interrupt
+- #clock-cells: Should be <1>
+
+The clock consumer should specify the desired clock by having the clock
+ID in its "clocks" phandle cell. The following is a full list of prima2
+clocks and IDs.
+
+ Clock ID
+ ---------------------------
+ rtc 0
+ osc 1
+ pll1 2
+ pll2 3
+ pll3 4
+ mem 5
+ sys 6
+ security 7
+ dsp 8
+ gps 9
+ mf 10
+ io 11
+ cpu 12
+ uart0 13
+ uart1 14
+ uart2 15
+ tsc 16
+ i2c0 17
+ i2c1 18
+ spi0 19
+ spi1 20
+ pwmc 21
+ efuse 22
+ pulse 23
+ dmac0 24
+ dmac1 25
+ nand 26
+ audio 27
+ usp0 28
+ usp1 29
+ usp2 30
+ vip 31
+ gfx 32
+ mm 33
+ lcd 34
+ vpp 35
+ mmc01 36
+ mmc23 37
+ mmc45 38
+ usbpll 39
+ usb0 40
+ usb1 41
+
+Examples:
+
+clks: clock-controller@88000000 {
+ compatible = "sirf,prima2-clkc";
+ reg = <0x88000000 0x1000>;
+ interrupts = <3>;
+ #clock-cells = <1>;
+};
+
+i2c0: i2c@b00e0000 {
+ cell-index = <0>;
+ compatible = "sirf,prima2-i2c";
+ reg = <0xb00e0000 0x10000>;
+ interrupts = <24>;
+ clocks = <&clks 17>;
+};
diff --git a/Documentation/devicetree/bindings/clock/rockchip.txt b/Documentation/devicetree/bindings/clock/rockchip.txt
new file mode 100644
index 0000000..a891c82
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/rockchip.txt
@@ -0,0 +1,74 @@
+Device Tree Clock bindings for arch-rockchip
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+== Gate clocks ==
+
+The gate registers form a continuos block which makes the dt node
+structure a matter of taste, as either all gates can be put into
+one gate clock spanning all registers or they can be divided into
+the 10 individual gates containing 16 clocks each.
+The code supports both approaches.
+
+Required properties:
+- compatible : "rockchip,rk2928-gate-clk"
+- reg : shall be the control register address(es) for the clock.
+- #clock-cells : from common clock binding; shall be set to 1
+- clock-output-names : the corresponding gate names that the clock controls
+- clocks : should contain the parent clock for each individual gate,
+ therefore the number of clocks elements should match the number of
+ clock-output-names
+
+Example using multiple gate clocks:
+
+ clk_gates0: gate-clk@200000d0 {
+ compatible = "rockchip,rk2928-gate-clk";
+ reg = <0x200000d0 0x4>;
+ clocks = <&dummy>, <&dummy>,
+ <&dummy>, <&dummy>,
+ <&dummy>, <&dummy>,
+ <&dummy>, <&dummy>,
+ <&dummy>, <&dummy>,
+ <&dummy>, <&dummy>,
+ <&dummy>, <&dummy>,
+ <&dummy>, <&dummy>;
+
+ clock-output-names =
+ "gate_core_periph", "gate_cpu_gpll",
+ "gate_ddrphy", "gate_aclk_cpu",
+ "gate_hclk_cpu", "gate_pclk_cpu",
+ "gate_atclk_cpu", "gate_i2s0",
+ "gate_i2s0_frac", "gate_i2s1",
+ "gate_i2s1_frac", "gate_i2s2",
+ "gate_i2s2_frac", "gate_spdif",
+ "gate_spdif_frac", "gate_testclk";
+
+ #clock-cells = <1>;
+ };
+
+ clk_gates1: gate-clk@200000d4 {
+ compatible = "rockchip,rk2928-gate-clk";
+ reg = <0x200000d4 0x4>;
+ clocks = <&xin24m>, <&xin24m>,
+ <&xin24m>, <&dummy>,
+ <&dummy>, <&xin24m>,
+ <&xin24m>, <&dummy>,
+ <&xin24m>, <&dummy>,
+ <&xin24m>, <&dummy>,
+ <&xin24m>, <&dummy>,
+ <&xin24m>, <&dummy>;
+
+ clock-output-names =
+ "gate_timer0", "gate_timer1",
+ "gate_timer2", "gate_jtag",
+ "gate_aclk_lcdc1_src", "gate_otgphy0",
+ "gate_otgphy1", "gate_ddr_gpll",
+ "gate_uart0", "gate_frac_uart0",
+ "gate_uart1", "gate_frac_uart1",
+ "gate_uart2", "gate_frac_uart2",
+ "gate_uart3", "gate_frac_uart3";
+
+ #clock-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/clock/silabs,si5351.txt b/Documentation/devicetree/bindings/clock/silabs,si5351.txt
new file mode 100644
index 0000000..c40711e
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/silabs,si5351.txt
@@ -0,0 +1,119 @@
+Binding for Silicon Labs Si5351a/b/c programmable i2c clock generator.
+
+Reference
+[1] Si5351A/B/C Data Sheet
+ http://www.silabs.com/Support%20Documents/TechnicalDocs/Si5351.pdf
+
+The Si5351a/b/c are programmable i2c clock generators with up to 8 output
+clocks. Si5351a also has a reduced pin-count package (MSOP10) where only
+3 output clocks are accessible. The internal structure of the clock
+generators can be found in [1].
+
+==I2C device node==
+
+Required properties:
+- compatible: shall be one of "silabs,si5351{a,a-msop,b,c}".
+- reg: i2c device address, shall be 0x60 or 0x61.
+- #clock-cells: from common clock binding; shall be set to 1.
+- clocks: from common clock binding; list of parent clock
+ handles, shall be xtal reference clock or xtal and clkin for
+ si5351c only.
+- #address-cells: shall be set to 1.
+- #size-cells: shall be set to 0.
+
+Optional properties:
+- silabs,pll-source: pair of (number, source) for each pll. Allows
+ to overwrite clock source of pll A (number=0) or B (number=1).
+
+==Child nodes==
+
+Each of the clock outputs can be overwritten individually by
+using a child node to the I2C device node. If a child node for a clock
+output is not set, the eeprom configuration is not overwritten.
+
+Required child node properties:
+- reg: number of clock output.
+
+Optional child node properties:
+- silabs,clock-source: source clock of the output divider stage N, shall be
+ 0 = multisynth N
+ 1 = multisynth 0 for output clocks 0-3, else multisynth4
+ 2 = xtal
+ 3 = clkin (si5351c only)
+- silabs,drive-strength: output drive strength in mA, shall be one of {2,4,6,8}.
+- silabs,multisynth-source: source pll A(0) or B(1) of corresponding multisynth
+ divider.
+- silabs,pll-master: boolean, multisynth can change pll frequency.
+- silabs,disable-state : clock output disable state, shall be
+ 0 = clock output is driven LOW when disabled
+ 1 = clock output is driven HIGH when disabled
+ 2 = clock output is FLOATING (HIGH-Z) when disabled
+ 3 = clock output is NEVER disabled
+
+==Example==
+
+/* 25MHz reference crystal */
+ref25: ref25M {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <25000000>;
+};
+
+i2c-master-node {
+
+ /* Si5351a msop10 i2c clock generator */
+ si5351a: clock-generator@60 {
+ compatible = "silabs,si5351a-msop";
+ reg = <0x60>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #clock-cells = <1>;
+
+ /* connect xtal input to 25MHz reference */
+ clocks = <&ref25>;
+
+ /* connect xtal input as source of pll0 and pll1 */
+ silabs,pll-source = <0 0>, <1 0>;
+
+ /*
+ * overwrite clkout0 configuration with:
+ * - 8mA output drive strength
+ * - pll0 as clock source of multisynth0
+ * - multisynth0 as clock source of output divider
+ * - multisynth0 can change pll0
+ * - set initial clock frequency of 74.25MHz
+ */
+ clkout0 {
+ reg = <0>;
+ silabs,drive-strength = <8>;
+ silabs,multisynth-source = <0>;
+ silabs,clock-source = <0>;
+ silabs,pll-master;
+ clock-frequency = <74250000>;
+ };
+
+ /*
+ * overwrite clkout1 configuration with:
+ * - 4mA output drive strength
+ * - pll1 as clock source of multisynth1
+ * - multisynth1 as clock source of output divider
+ * - multisynth1 can change pll1
+ */
+ clkout1 {
+ reg = <1>;
+ silabs,drive-strength = <4>;
+ silabs,multisynth-source = <1>;
+ silabs,clock-source = <0>;
+ pll-master;
+ };
+
+ /*
+ * overwrite clkout2 configuration with:
+ * - xtal as clock source of output divider
+ */
+ clkout2 {
+ reg = <2>;
+ silabs,clock-source = <2>;
+ };
+ };
+};
diff --git a/Documentation/devicetree/bindings/clock/st,nomadik.txt b/Documentation/devicetree/bindings/clock/st,nomadik.txt
new file mode 100644
index 0000000..7fc0977
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/st,nomadik.txt
@@ -0,0 +1,104 @@
+ST Microelectronics Nomadik SRC System Reset and Control
+
+This binding uses the common clock binding:
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+The Nomadik SRC controller is responsible of controlling chrystals,
+PLLs and clock gates.
+
+Required properties for the SRC node:
+- compatible: must be "stericsson,nomadik-src"
+- reg: must contain the SRC register base and size
+
+Optional properties for the SRC node:
+- disable-sxtalo: if present this will disable the SXTALO
+ i.e. the driver output for the slow 32kHz chrystal, if the
+ board has its own circuitry for providing this oscillator
+- disable-mxtal: if present this will disable the MXTALO,
+ i.e. the driver output for the main (~19.2 MHz) chrystal,
+ if the board has its own circuitry for providing this
+ osciallator
+
+
+PLL nodes: these nodes represent the two PLLs on the system,
+which should both have the main chrystal, represented as a
+fixed frequency clock, as parent.
+
+Required properties for the two PLL nodes:
+- compatible: must be "st,nomadik-pll-clock"
+- clock-cells: must be 0
+- clock-id: must be 1 or 2 for PLL1 and PLL2 respectively
+- clocks: this clock will have main chrystal as parent
+
+
+HCLK nodes: these represent the clock gates on individual
+lines from the HCLK clock tree and the gate for individual
+lines from the PCLK clock tree.
+
+Requires properties for the HCLK nodes:
+- compatible: must be "st,nomadik-hclk-clock"
+- clock-cells: must be 0
+- clock-id: must be the clock ID from 0 to 63 according to
+ this table:
+
+ 0: HCLKDMA0
+ 1: HCLKSMC
+ 2: HCLKSDRAM
+ 3: HCLKDMA1
+ 4: HCLKCLCD
+ 5: PCLKIRDA
+ 6: PCLKSSP
+ 7: PCLKUART0
+ 8: PCLKSDI
+ 9: PCLKI2C0
+ 10: PCLKI2C1
+ 11: PCLKUART1
+ 12: PCLMSP0
+ 13: HCLKUSB
+ 14: HCLKDIF
+ 15: HCLKSAA
+ 16: HCLKSVA
+ 17: PCLKHSI
+ 18: PCLKXTI
+ 19: PCLKUART2
+ 20: PCLKMSP1
+ 21: PCLKMSP2
+ 22: PCLKOWM
+ 23: HCLKHPI
+ 24: PCLKSKE
+ 25: PCLKHSEM
+ 26: HCLK3D
+ 27: HCLKHASH
+ 28: HCLKCRYP
+ 29: PCLKMSHC
+ 30: HCLKUSBM
+ 31: HCLKRNG
+ (32, 33, 34, 35 RESERVED)
+ 36: CLDCLK
+ 37: IRDACLK
+ 38: SSPICLK
+ 39: UART0CLK
+ 40: SDICLK
+ 41: I2C0CLK
+ 42: I2C1CLK
+ 43: UART1CLK
+ 44: MSPCLK0
+ 45: USBCLK
+ 46: DIFCLK
+ 47: IPI2CCLK
+ 48: IPBMCCLK
+ 49: HSICLKRX
+ 50: HSICLKTX
+ 51: UART2CLK
+ 52: MSPCLK1
+ 53: MSPCLK2
+ 54: OWMCLK
+ (55 RESERVED)
+ 56: SKECLK
+ (57 RESERVED)
+ 58: 3DCLK
+ 59: PCLKMSP3
+ 60: MSPCLK3
+ 61: MSHCCLK
+ 62: USBMCLK
+ 63: RNGCCLK
diff --git a/Documentation/devicetree/bindings/clock/ste-u300-syscon-clock.txt b/Documentation/devicetree/bindings/clock/ste-u300-syscon-clock.txt
new file mode 100644
index 0000000..7cafcb9
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ste-u300-syscon-clock.txt
@@ -0,0 +1,80 @@
+Clock bindings for ST-Ericsson U300 System Controller Clocks
+
+Bindings for the gated system controller clocks:
+
+Required properties:
+- compatible: must be "stericsson,u300-syscon-clk"
+- #clock-cells: must be <0>
+- clock-type: specifies the type of clock:
+ 0 = slow clock
+ 1 = fast clock
+ 2 = rest/remaining clock
+- clock-id: specifies the clock in the type range
+
+Optional properties:
+- clocks: parent clock(s)
+
+The available clocks per type are as follows:
+
+Type: ID: Clock:
+-------------------
+0 0 Slow peripheral bridge clock
+0 1 UART0 clock
+0 4 GPIO clock
+0 6 RTC clock
+0 7 Application timer clock
+0 8 Access timer clock
+
+1 0 Fast peripheral bridge clock
+1 1 I2C bus 0 clock
+1 2 I2C bus 1 clock
+1 5 MMC interface peripheral (silicon) clock
+1 6 SPI clock
+
+2 3 CPU clock
+2 4 DMA controller clock
+2 5 External Memory Interface (EMIF) clock
+2 6 NAND flask interface clock
+2 8 XGAM graphics engine clock
+2 9 Shared External Memory Interface (SEMI) clock
+2 10 AHB Subsystem Bridge clock
+2 12 Interrupt controller clock
+
+Example:
+
+gpio_clk: gpio_clk@13M {
+ #clock-cells = <0>;
+ compatible = "stericsson,u300-syscon-clk";
+ clock-type = <0>; /* Slow */
+ clock-id = <4>;
+ clocks = <&slow_clk>;
+};
+
+gpio: gpio@c0016000 {
+ compatible = "stericsson,gpio-coh901";
+ (...)
+ clocks = <&gpio_clk>;
+};
+
+
+Bindings for the MMC/SD card clock:
+
+Required properties:
+- compatible: must be "stericsson,u300-syscon-mclk"
+- #clock-cells: must be <0>
+
+Optional properties:
+- clocks: parent clock(s)
+
+mmc_mclk: mmc_mclk {
+ #clock-cells = <0>;
+ compatible = "stericsson,u300-syscon-mclk";
+ clocks = <&mmc_pclk>;
+};
+
+mmcsd: mmcsd@c0001000 {
+ compatible = "arm,pl18x", "arm,primecell";
+ clocks = <&mmc_pclk>, <&mmc_mclk>;
+ clock-names = "apb_pclk", "mclk";
+ (...)
+};
diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt
new file mode 100644
index 0000000..d495521
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/sunxi.txt
@@ -0,0 +1,60 @@
+Device Tree Clock bindings for arch-sunxi
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible : shall be one of the following:
+ "allwinner,sun4i-osc-clk" - for a gatable oscillator
+ "allwinner,sun4i-pll1-clk" - for the main PLL clock
+ "allwinner,sun4i-cpu-clk" - for the CPU multiplexer clock
+ "allwinner,sun4i-axi-clk" - for the AXI clock
+ "allwinner,sun4i-axi-gates-clk" - for the AXI gates
+ "allwinner,sun4i-ahb-clk" - for the AHB clock
+ "allwinner,sun4i-ahb-gates-clk" - for the AHB gates on A10
+ "allwinner,sun5i-a13-ahb-gates-clk" - for the AHB gates on A13
+ "allwinner,sun4i-apb0-clk" - for the APB0 clock
+ "allwinner,sun4i-apb0-gates-clk" - for the APB0 gates on A10
+ "allwinner,sun5i-a13-apb0-gates-clk" - for the APB0 gates on A13
+ "allwinner,sun4i-apb1-clk" - for the APB1 clock
+ "allwinner,sun4i-apb1-mux-clk" - for the APB1 clock muxing
+ "allwinner,sun4i-apb1-gates-clk" - for the APB1 gates on A10
+ "allwinner,sun5i-a13-apb1-gates-clk" - for the APB1 gates on A13
+
+Required properties for all clocks:
+- reg : shall be the control register address for the clock.
+- clocks : shall be the input parent clock(s) phandle for the clock
+- #clock-cells : from common clock binding; shall be set to 0 except for
+ "allwinner,*-gates-clk" where it shall be set to 1
+
+Additionally, "allwinner,*-gates-clk" clocks require:
+- clock-output-names : the corresponding gate names that the clock controls
+
+Clock consumers should specify the desired clocks they use with a
+"clocks" phandle cell. Consumers that are using a gated clock should
+provide an additional ID in their clock property. The values of this
+ID are documented in sunxi/<soc>-gates.txt.
+
+For example:
+
+osc24M: osc24M@01c20050 {
+ #clock-cells = <0>;
+ compatible = "allwinner,sun4i-osc-clk";
+ reg = <0x01c20050 0x4>;
+ clocks = <&osc24M_fixed>;
+};
+
+pll1: pll1@01c20000 {
+ #clock-cells = <0>;
+ compatible = "allwinner,sun4i-pll1-clk";
+ reg = <0x01c20000 0x4>;
+ clocks = <&osc24M>;
+};
+
+cpu: cpu@01c20054 {
+ #clock-cells = <0>;
+ compatible = "allwinner,sun4i-cpu-clk";
+ reg = <0x01c20054 0x4>;
+ clocks = <&osc32k>, <&osc24M>, <&pll1>;
+};
diff --git a/Documentation/devicetree/bindings/clock/sunxi/sun4i-a10-gates.txt b/Documentation/devicetree/bindings/clock/sunxi/sun4i-a10-gates.txt
new file mode 100644
index 0000000..6a03475
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/sunxi/sun4i-a10-gates.txt
@@ -0,0 +1,93 @@
+Gate clock outputs
+------------------
+
+ * AXI gates ("allwinner,sun4i-axi-gates-clk")
+
+ DRAM 0
+
+ * AHB gates ("allwinner,sun4i-ahb-gates-clk")
+
+ USB0 0
+ EHCI0 1
+ OHCI0 2*
+ EHCI1 3
+ OHCI1 4*
+ SS 5
+ DMA 6
+ BIST 7
+ MMC0 8
+ MMC1 9
+ MMC2 10
+ MMC3 11
+ MS 12**
+ NAND 13
+ SDRAM 14
+
+ ACE 16
+ EMAC 17
+ TS 18
+
+ SPI0 20
+ SPI1 21
+ SPI2 22
+ SPI3 23
+ PATA 24
+ SATA 25**
+ GPS 26*
+
+ VE 32
+ TVD 33
+ TVE0 34
+ TVE1 35
+ LCD0 36
+ LCD1 37
+
+ CSI0 40
+ CSI1 41
+
+ HDMI 43
+ DE_BE0 44
+ DE_BE1 45
+ DE_FE1 46
+ DE_FE1 47
+
+ MP 50
+
+ MALI400 52
+
+ * APB0 gates ("allwinner,sun4i-apb0-gates-clk")
+
+ CODEC 0
+ SPDIF 1*
+ AC97 2
+ IIS 3
+
+ PIO 5
+ IR0 6
+ IR1 7
+
+ KEYPAD 10
+
+ * APB1 gates ("allwinner,sun4i-apb1-gates-clk")
+
+ I2C0 0
+ I2C1 1
+ I2C2 2
+
+ CAN 4
+ SCR 5
+ PS20 6
+ PS21 7
+
+ UART0 16
+ UART1 17
+ UART2 18
+ UART3 19
+ UART4 20
+ UART5 21
+ UART6 22
+ UART7 23
+
+Notation:
+ [*]: The datasheet didn't mention these, but they are present on AW code
+ [**]: The datasheet had this marked as "NC" but they are used on AW code
diff --git a/Documentation/devicetree/bindings/clock/sunxi/sun5i-a13-gates.txt b/Documentation/devicetree/bindings/clock/sunxi/sun5i-a13-gates.txt
new file mode 100644
index 0000000..006b6df
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/sunxi/sun5i-a13-gates.txt
@@ -0,0 +1,58 @@
+Gate clock outputs
+------------------
+
+ * AXI gates ("allwinner,sun4i-axi-gates-clk")
+
+ DRAM 0
+
+ * AHB gates ("allwinner,sun5i-a13-ahb-gates-clk")
+
+ USBOTG 0
+ EHCI 1
+ OHCI 2
+
+ SS 5
+ DMA 6
+ BIST 7
+ MMC0 8
+ MMC1 9
+ MMC2 10
+
+ NAND 13
+ SDRAM 14
+
+ SPI0 20
+ SPI1 21
+ SPI2 22
+
+ STIMER 28
+
+ VE 32
+
+ LCD 36
+
+ CSI 40
+
+ DE_BE 44
+
+ DE_FE 46
+
+ IEP 51
+ MALI400 52
+
+ * APB0 gates ("allwinner,sun5i-a13-apb0-gates-clk")
+
+ CODEC 0
+
+ PIO 5
+ IR 6
+
+ * APB1 gates ("allwinner,sun5i-a13-apb1-gates-clk")
+
+ I2C0 0
+ I2C1 1
+ I2C2 2
+
+ UART1 17
+
+ UART3 19
diff --git a/Documentation/devicetree/bindings/clock/vf610-clock.txt b/Documentation/devicetree/bindings/clock/vf610-clock.txt
new file mode 100644
index 0000000..c80863d
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/vf610-clock.txt
@@ -0,0 +1,26 @@
+* Clock bindings for Freescale Vybrid VF610 SOC
+
+Required properties:
+- compatible: Should be "fsl,vf610-ccm"
+- reg: Address and length of the register set
+- #clock-cells: Should be <1>
+
+The clock consumer should specify the desired clock by having the clock
+ID in its "clocks" phandle cell. See include/dt-bindings/clock/vf610-clock.h
+for the full list of VF610 clock IDs.
+
+Examples:
+
+clks: ccm@4006b000 {
+ compatible = "fsl,vf610-ccm";
+ reg = <0x4006b000 0x1000>;
+ #clock-cells = <1>;
+};
+
+uart1: serial@40028000 {
+ compatible = "fsl,vf610-uart";
+ reg = <0x40028000 0x1000>;
+ interrupts = <0 62 0x04>;
+ clocks = <&clks VF610_CLK_UART1>;
+ clock-names = "ipg";
+};
diff --git a/Documentation/devicetree/bindings/clock/vt8500.txt b/Documentation/devicetree/bindings/clock/vt8500.txt
index a880c70..91d71cc 100644
--- a/Documentation/devicetree/bindings/clock/vt8500.txt
+++ b/Documentation/devicetree/bindings/clock/vt8500.txt
@@ -8,6 +8,8 @@
- compatible : shall be one of the following:
"via,vt8500-pll-clock" - for a VT8500/WM8505 PLL clock
"wm,wm8650-pll-clock" - for a WM8650 PLL clock
+ "wm,wm8750-pll-clock" - for a WM8750 PLL clock
+ "wm,wm8850-pll-clock" - for a WM8850 PLL clock
"via,vt8500-device-clock" - for a VT/WM device clock
Required properties for PLL clocks:
diff --git a/Documentation/devicetree/bindings/clock/zynq-7000.txt b/Documentation/devicetree/bindings/clock/zynq-7000.txt
index 23ae1db..d99af87 100644
--- a/Documentation/devicetree/bindings/clock/zynq-7000.txt
+++ b/Documentation/devicetree/bindings/clock/zynq-7000.txt
@@ -6,50 +6,99 @@
See clock_bindings.txt for more information on the generic clock bindings.
See Chapter 25 of Zynq TRM for more information about Zynq clocks.
-== PLLs ==
-
-Used to describe the ARM_PLL, DDR_PLL, and IO_PLL.
+== Clock Controller ==
+The clock controller is a logical abstraction of Zynq's clock tree. It reads
+required input clock frequencies from the devicetree and acts as clock provider
+for all clock consumers of PS clocks.
Required properties:
-- #clock-cells : shall be 0 (only one clock is output from this node)
-- compatible : "xlnx,zynq-pll"
-- reg : pair of u32 values, which are the address offsets within the SLCR
- of the relevant PLL_CTRL register and PLL_CFG register respectively
-- clocks : phandle for parent clock. should be the phandle for ps_clk
+ - #clock-cells : Must be 1
+ - compatible : "xlnx,ps7-clkc"
+ - ps-clk-frequency : Frequency of the oscillator providing ps_clk in HZ
+ (usually 33 MHz oscillators are used for Zynq platforms)
+ - clock-output-names : List of strings used to name the clock outputs. Shall be
+ a list of the outputs given below.
Optional properties:
-- clock-output-names : name of the output clock
+ - clocks : as described in the clock bindings
+ - clock-names : as described in the clock bindings
+
+Clock inputs:
+The following strings are optional parameters to the 'clock-names' property in
+order to provide an optional (E)MIO clock source.
+ - swdt_ext_clk
+ - gem0_emio_clk
+ - gem1_emio_clk
+ - mio_clk_XX # with XX = 00..53
+...
+
+Clock outputs:
+ 0: armpll
+ 1: ddrpll
+ 2: iopll
+ 3: cpu_6or4x
+ 4: cpu_3or2x
+ 5: cpu_2x
+ 6: cpu_1x
+ 7: ddr2x
+ 8: ddr3x
+ 9: dci
+ 10: lqspi
+ 11: smc
+ 12: pcap
+ 13: gem0
+ 14: gem1
+ 15: fclk0
+ 16: fclk1
+ 17: fclk2
+ 18: fclk3
+ 19: can0
+ 20: can1
+ 21: sdio0
+ 22: sdio1
+ 23: uart0
+ 24: uart1
+ 25: spi0
+ 26: spi1
+ 27: dma
+ 28: usb0_aper
+ 29: usb1_aper
+ 30: gem0_aper
+ 31: gem1_aper
+ 32: sdio0_aper
+ 33: sdio1_aper
+ 34: spi0_aper
+ 35: spi1_aper
+ 36: can0_aper
+ 37: can1_aper
+ 38: i2c0_aper
+ 39: i2c1_aper
+ 40: uart0_aper
+ 41: uart1_aper
+ 42: gpio_aper
+ 43: lqspi_aper
+ 44: smc_aper
+ 45: swdt
+ 46: dbg_trc
+ 47: dbg_apb
Example:
- armpll: armpll {
- #clock-cells = <0>;
- compatible = "xlnx,zynq-pll";
- clocks = <&ps_clk>;
- reg = <0x100 0x110>;
- clock-output-names = "armpll";
- };
-
-== Peripheral clocks ==
-
-Describes clock node for the SDIO, SMC, SPI, QSPI, and UART clocks.
-
-Required properties:
-- #clock-cells : shall be 1
-- compatible : "xlnx,zynq-periph-clock"
-- reg : a single u32 value, describing the offset within the SLCR where
- the CLK_CTRL register is found for this peripheral
-- clocks : phandle for parent clocks. should hold phandles for
- the IO_PLL, ARM_PLL, and DDR_PLL in order
-- clock-output-names : names of the output clock(s). For peripherals that have
- two output clocks (for example, the UART), two clocks
- should be listed.
-
-Example:
- uart_clk: uart_clk {
+ clkc: clkc {
#clock-cells = <1>;
- compatible = "xlnx,zynq-periph-clock";
- clocks = <&iopll &armpll &ddrpll>;
- reg = <0x154>;
- clock-output-names = "uart0_ref_clk",
- "uart1_ref_clk";
+ compatible = "xlnx,ps7-clkc";
+ ps-clk-frequency = <33333333>;
+ clock-output-names = "armpll", "ddrpll", "iopll", "cpu_6or4x",
+ "cpu_3or2x", "cpu_2x", "cpu_1x", "ddr2x", "ddr3x",
+ "dci", "lqspi", "smc", "pcap", "gem0", "gem1",
+ "fclk0", "fclk1", "fclk2", "fclk3", "can0", "can1",
+ "sdio0", "sdio1", "uart0", "uart1", "spi0", "spi1",
+ "dma", "usb0_aper", "usb1_aper", "gem0_aper",
+ "gem1_aper", "sdio0_aper", "sdio1_aper",
+ "spi0_aper", "spi1_aper", "can0_aper", "can1_aper",
+ "i2c0_aper", "i2c1_aper", "uart0_aper", "uart1_aper",
+ "gpio_aper", "lqspi_aper", "smc_aper", "swdt",
+ "dbg_trc", "dbg_apb";
+ # optional props
+ clocks = <&clkc 16>, <&clk_foo>;
+ clock-names = "gem1_emio_clk", "can_mio_clk_23";
};
diff --git a/Documentation/devicetree/bindings/cpufreq/arm_big_little_dt.txt b/Documentation/devicetree/bindings/cpufreq/arm_big_little_dt.txt
new file mode 100644
index 0000000..0715695
--- /dev/null
+++ b/Documentation/devicetree/bindings/cpufreq/arm_big_little_dt.txt
@@ -0,0 +1,65 @@
+Generic ARM big LITTLE cpufreq driver's DT glue
+-----------------------------------------------
+
+This is DT specific glue layer for generic cpufreq driver for big LITTLE
+systems.
+
+Both required and optional properties listed below must be defined
+under node /cpus/cpu@x. Where x is the first cpu inside a cluster.
+
+FIXME: Cpus should boot in the order specified in DT and all cpus for a cluster
+must be present contiguously. Generic DT driver will check only node 'x' for
+cpu:x.
+
+Required properties:
+- operating-points: Refer to Documentation/devicetree/bindings/power/opp.txt
+ for details
+
+Optional properties:
+- clock-latency: Specify the possible maximum transition latency for clock,
+ in unit of nanoseconds.
+
+Examples:
+
+cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ compatible = "arm,cortex-a15";
+ reg = <0>;
+ next-level-cache = <&L2>;
+ operating-points = <
+ /* kHz uV */
+ 792000 1100000
+ 396000 950000
+ 198000 850000
+ >;
+ clock-latency = <61036>; /* two CLK32 periods */
+ };
+
+ cpu@1 {
+ compatible = "arm,cortex-a15";
+ reg = <1>;
+ next-level-cache = <&L2>;
+ };
+
+ cpu@100 {
+ compatible = "arm,cortex-a7";
+ reg = <100>;
+ next-level-cache = <&L2>;
+ operating-points = <
+ /* kHz uV */
+ 792000 950000
+ 396000 750000
+ 198000 450000
+ >;
+ clock-latency = <61036>; /* two CLK32 periods */
+ };
+
+ cpu@101 {
+ compatible = "arm,cortex-a7";
+ reg = <101>;
+ next-level-cache = <&L2>;
+ };
+};
diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
index 4416ccc..051f764 100644
--- a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
@@ -32,7 +32,7 @@
396000 950000
198000 850000
>;
- transition-latency = <61036>; /* two CLK32 periods */
+ clock-latency = <61036>; /* two CLK32 periods */
};
cpu@1 {
diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
new file mode 100644
index 0000000..caff1a5
--- /dev/null
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
@@ -0,0 +1,28 @@
+
+Exynos5440 cpufreq driver
+-------------------
+
+Exynos5440 SoC cpufreq driver for CPU frequency scaling.
+
+Required properties:
+- interrupts: Interrupt to know the completion of cpu frequency change.
+- operating-points: Table of frequencies and voltage CPU could be transitioned into,
+ in the decreasing order. Frequency should be in KHz units and voltage
+ should be in microvolts.
+
+Optional properties:
+- clock-latency: Clock monitor latency in microsecond.
+
+All the required listed above must be defined under node cpufreq.
+
+Example:
+--------
+ cpufreq@160000 {
+ compatible = "samsung,exynos5440-cpufreq";
+ reg = <0x160000 0x1000>;
+ interrupts = <0 57 0>;
+ operating-points = <
+ 1000000 975000
+ 800000 925000>;
+ clock-latency = <100000>;
+ };
diff --git a/Documentation/devicetree/bindings/crypto/fsl-imx-sahara.txt b/Documentation/devicetree/bindings/crypto/fsl-imx-sahara.txt
new file mode 100644
index 0000000..5c65ecc
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/fsl-imx-sahara.txt
@@ -0,0 +1,15 @@
+Freescale SAHARA Cryptographic Accelerator included in some i.MX chips.
+Currently only i.MX27 is supported.
+
+Required properties:
+- compatible : Should be "fsl,<soc>-sahara"
+- reg : Should contain SAHARA registers location and length
+- interrupts : Should contain SAHARA interrupt number
+
+Example:
+
+sah@10025000 {
+ compatible = "fsl,imx27-sahara";
+ reg = < 0x10025000 0x800>;
+ interrupts = <75>;
+};
diff --git a/Documentation/devicetree/bindings/crypto/fsl-sec4.txt b/Documentation/devicetree/bindings/crypto/fsl-sec4.txt
index fc9ce6f..e402277 100644
--- a/Documentation/devicetree/bindings/crypto/fsl-sec4.txt
+++ b/Documentation/devicetree/bindings/crypto/fsl-sec4.txt
@@ -54,8 +54,13 @@
- compatible
Usage: required
Value type: <string>
- Definition: Must include "fsl,sec-v4.0". Also includes SEC
- ERA versions (optional) with which the device is compatible.
+ Definition: Must include "fsl,sec-v4.0"
+
+ - fsl,sec-era
+ Usage: optional
+ Value type: <u32>
+ Definition: A standard property. Define the 'ERA' of the SEC
+ device.
- #address-cells
Usage: required
@@ -107,7 +112,8 @@
EXAMPLE
crypto@300000 {
- compatible = "fsl,sec-v4.0", "fsl,sec-era-v2.0";
+ compatible = "fsl,sec-v4.0";
+ fsl,sec-era = <2>;
#address-cells = <1>;
#size-cells = <1>;
reg = <0x300000 0x10000>;
diff --git a/Documentation/devicetree/bindings/dma/arm-pl330.txt b/Documentation/devicetree/bindings/dma/arm-pl330.txt
index 36e27d5..2675658 100644
--- a/Documentation/devicetree/bindings/dma/arm-pl330.txt
+++ b/Documentation/devicetree/bindings/dma/arm-pl330.txt
@@ -10,7 +10,11 @@
- interrupts: interrupt number to the cpu.
Optional properties:
-- dma-coherent : Present if dma operations are coherent
+ - dma-coherent : Present if dma operations are coherent
+ - #dma-cells: must be <1>. used to represent the number of integer
+ cells in the dmas property of client device.
+ - dma-channels: contains the total number of DMA channels supported by the DMAC
+ - dma-requests: contains the total number of DMA requests supported by the DMAC
Example:
@@ -18,16 +22,23 @@
compatible = "arm,pl330", "arm,primecell";
reg = <0x12680000 0x1000>;
interrupts = <99>;
+ #dma-cells = <1>;
+ #dma-channels = <8>;
+ #dma-requests = <32>;
};
Client drivers (device nodes requiring dma transfers from dev-to-mem or
-mem-to-dev) should specify the DMA channel numbers using a two-value pair
+mem-to-dev) should specify the DMA channel numbers and dma channel names
as shown below.
[property name] = <[phandle of the dma controller] [dma request id]>;
+ [property name] = <[dma channel name]>
where 'dma request id' is the dma request number which is connected
- to the client controller. The 'property name' is recommended to be
- of the form <name>-dma-channel.
+ to the client controller. The 'property name' 'dmas' and 'dma-names'
+ as required by the generic dma device tree binding helpers. The dma
+ names correspond 1:1 with the dma request ids in the dmas property.
- Example: tx-dma-channel = <&pdma0 12>;
+ Example: dmas = <&pdma0 12
+ &pdma1 11>;
+ dma-names = "tx", "rx";
diff --git a/Documentation/devicetree/bindings/dma/atmel-dma.txt b/Documentation/devicetree/bindings/dma/atmel-dma.txt
index 3c046ee..c280a0e 100644
--- a/Documentation/devicetree/bindings/dma/atmel-dma.txt
+++ b/Documentation/devicetree/bindings/dma/atmel-dma.txt
@@ -1,14 +1,42 @@
* Atmel Direct Memory Access Controller (DMA)
Required properties:
-- compatible: Should be "atmel,<chip>-dma"
-- reg: Should contain DMA registers location and length
-- interrupts: Should contain DMA interrupt
+- compatible: Should be "atmel,<chip>-dma".
+- reg: Should contain DMA registers location and length.
+- interrupts: Should contain DMA interrupt.
+- #dma-cells: Must be <2>, used to represent the number of integer cells in
+the dmas property of client devices.
-Examples:
+Example:
-dma@ffffec00 {
+dma0: dma@ffffec00 {
compatible = "atmel,at91sam9g45-dma";
reg = <0xffffec00 0x200>;
interrupts = <21>;
+ #dma-cells = <2>;
+};
+
+DMA clients connected to the Atmel DMA controller must use the format
+described in the dma.txt file, using a three-cell specifier for each channel:
+a phandle plus two interger cells.
+The three cells in order are:
+
+1. A phandle pointing to the DMA controller.
+2. The memory interface (16 most significant bits), the peripheral interface
+(16 less significant bits).
+3. Parameters for the at91 DMA configuration register which are device
+dependant:
+ - bit 7-0: peripheral identifier for the hardware handshaking interface. The
+ identifier can be different for tx and rx.
+ - bit 11-8: FIFO configuration. 0 for half FIFO, 1 for ALAP, 1 for ASAP.
+
+Example:
+
+i2c0@i2c@f8010000 {
+ compatible = "atmel,at91sam9x5-i2c";
+ reg = <0xf8010000 0x100>;
+ interrupts = <9 4 6>;
+ dmas = <&dma0 1 7>,
+ <&dma0 1 8>;
+ dma-names = "tx", "rx";
};
diff --git a/Documentation/devicetree/bindings/dma/dma.txt b/Documentation/devicetree/bindings/dma/dma.txt
new file mode 100644
index 0000000..8f504e6
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/dma.txt
@@ -0,0 +1,81 @@
+* Generic DMA Controller and DMA request bindings
+
+Generic binding to provide a way for a driver using DMA Engine to retrieve the
+DMA request or channel information that goes from a hardware device to a DMA
+controller.
+
+
+* DMA controller
+
+Required property:
+- #dma-cells: Must be at least 1. Used to provide DMA controller
+ specific information. See DMA client binding below for
+ more details.
+
+Optional properties:
+- dma-channels: Number of DMA channels supported by the controller.
+- dma-requests: Number of DMA requests signals supported by the
+ controller.
+
+Example:
+
+ dma: dma@48000000 {
+ compatible = "ti,omap-sdma";
+ reg = <0x48000000 0x1000>;
+ interrupts = <0 12 0x4
+ 0 13 0x4
+ 0 14 0x4
+ 0 15 0x4>;
+ #dma-cells = <1>;
+ dma-channels = <32>;
+ dma-requests = <127>;
+ };
+
+
+* DMA client
+
+Client drivers should specify the DMA property using a phandle to the controller
+followed by DMA controller specific data.
+
+Required property:
+- dmas: List of one or more DMA specifiers, each consisting of
+ - A phandle pointing to DMA controller node
+ - A number of integer cells, as determined by the
+ #dma-cells property in the node referenced by phandle
+ containing DMA controller specific information. This
+ typically contains a DMA request line number or a
+ channel number, but can contain any data that is used
+ required for configuring a channel.
+- dma-names: Contains one identifier string for each DMA specifier in
+ the dmas property. The specific strings that can be used
+ are defined in the binding of the DMA client device.
+ Multiple DMA specifiers can be used to represent
+ alternatives and in this case the dma-names for those
+ DMA specifiers must be identical (see examples).
+
+Examples:
+
+1. A device with one DMA read channel, one DMA write channel:
+
+ i2c1: i2c@1 {
+ ...
+ dmas = <&dma 2 /* read channel */
+ &dma 3>; /* write channel */
+ dma-names = "rx", "tx";
+ ...
+ };
+
+2. A single read-write channel with three alternative DMA controllers:
+
+ dmas = <&dma1 5
+ &dma2 7
+ &dma3 2>;
+ dma-names = "rx-tx", "rx-tx", "rx-tx";
+
+3. A device with three channels, one of which has two alternatives:
+
+ dmas = <&dma1 2 /* read channel */
+ &dma1 3 /* write channel */
+ &dma2 0 /* error read */
+ &dma3 0>; /* alternative error read */
+ dma-names = "rx", "tx", "error", "error";
diff --git a/Documentation/devicetree/bindings/dma/fsl-imx-dma.txt b/Documentation/devicetree/bindings/dma/fsl-imx-dma.txt
new file mode 100644
index 0000000..2717ecb
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/fsl-imx-dma.txt
@@ -0,0 +1,48 @@
+* Freescale Direct Memory Access (DMA) Controller for i.MX
+
+This document will only describe differences to the generic DMA Controller and
+DMA request bindings as described in dma/dma.txt .
+
+* DMA controller
+
+Required properties:
+- compatible : Should be "fsl,<chip>-dma". chip can be imx1, imx21 or imx27
+- reg : Should contain DMA registers location and length
+- interrupts : First item should be DMA interrupt, second one is optional and
+ should contain DMA Error interrupt
+- #dma-cells : Has to be 1. imx-dma does not support anything else.
+
+Optional properties:
+- #dma-channels : Number of DMA channels supported. Should be 16.
+- #dma-requests : Number of DMA requests supported.
+
+Example:
+
+ dma: dma@10001000 {
+ compatible = "fsl,imx27-dma";
+ reg = <0x10001000 0x1000>;
+ interrupts = <32 33>;
+ #dma-cells = <1>;
+ #dma-channels = <16>;
+ };
+
+
+* DMA client
+
+Clients have to specify the DMA requests with phandles in a list.
+
+Required properties:
+- dmas: List of one or more DMA request specifiers. One DMA request specifier
+ consists of a phandle to the DMA controller followed by the integer
+ specifiying the request line.
+- dma-names: List of string identifiers for the DMA requests. For the correct
+ names, have a look at the specific client driver.
+
+Example:
+
+ sdhci1: sdhci@10013000 {
+ ...
+ dmas = <&dma 7>;
+ dma-names = "rx-tx";
+ ...
+ };
diff --git a/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt b/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt
index d1e3f44..68cee4f5 100644
--- a/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt
+++ b/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt
@@ -4,14 +4,70 @@
- compatible : Should be "fsl,<chip>-sdma"
- reg : Should contain SDMA registers location and length
- interrupts : Should contain SDMA interrupt
+- #dma-cells : Must be <3>.
+ The first cell specifies the DMA request/event ID. See details below
+ about the second and third cell.
- fsl,sdma-ram-script-name : Should contain the full path of SDMA RAM
scripts firmware
+The second cell of dma phandle specifies the peripheral type of DMA transfer.
+The full ID of peripheral types can be found below.
+
+ ID transfer type
+ ---------------------
+ 0 MCU domain SSI
+ 1 Shared SSI
+ 2 MMC
+ 3 SDHC
+ 4 MCU domain UART
+ 5 Shared UART
+ 6 FIRI
+ 7 MCU domain CSPI
+ 8 Shared CSPI
+ 9 SIM
+ 10 ATA
+ 11 CCM
+ 12 External peripheral
+ 13 Memory Stick Host Controller
+ 14 Shared Memory Stick Host Controller
+ 15 DSP
+ 16 Memory
+ 17 FIFO type Memory
+ 18 SPDIF
+ 19 IPU Memory
+ 20 ASRC
+ 21 ESAI
+
+The third cell specifies the transfer priority as below.
+
+ ID transfer priority
+ -------------------------
+ 0 High
+ 1 Medium
+ 2 Low
+
Examples:
sdma@83fb0000 {
compatible = "fsl,imx51-sdma", "fsl,imx35-sdma";
reg = <0x83fb0000 0x4000>;
interrupts = <6>;
+ #dma-cells = <3>;
fsl,sdma-ram-script-name = "sdma-imx51.bin";
};
+
+DMA clients connected to the i.MX SDMA controller must use the format
+described in the dma.txt file.
+
+Examples:
+
+ssi2: ssi@70014000 {
+ compatible = "fsl,imx51-ssi", "fsl,imx21-ssi";
+ reg = <0x70014000 0x4000>;
+ interrupts = <30>;
+ clocks = <&clks 49>;
+ dmas = <&sdma 24 1 0>,
+ <&sdma 25 1 0>;
+ dma-names = "rx", "tx";
+ fsl,fifo-depth = <15>;
+};
diff --git a/Documentation/devicetree/bindings/dma/fsl-mxs-dma.txt b/Documentation/devicetree/bindings/dma/fsl-mxs-dma.txt
index ded0398..a4873e5 100644
--- a/Documentation/devicetree/bindings/dma/fsl-mxs-dma.txt
+++ b/Documentation/devicetree/bindings/dma/fsl-mxs-dma.txt
@@ -3,17 +3,58 @@
Required properties:
- compatible : Should be "fsl,<chip>-dma-apbh" or "fsl,<chip>-dma-apbx"
- reg : Should contain registers location and length
+- interrupts : Should contain the interrupt numbers of DMA channels.
+ If a channel is empty/reserved, 0 should be filled in place.
+- #dma-cells : Must be <1>. The number cell specifies the channel ID.
+- dma-channels : Number of channels supported by the DMA controller
+
+Optional properties:
+- interrupt-names : Name of DMA channel interrupts
Supported chips:
imx23, imx28.
Examples:
-dma-apbh@80004000 {
+
+dma_apbh: dma-apbh@80004000 {
compatible = "fsl,imx28-dma-apbh";
- reg = <0x80004000 2000>;
+ reg = <0x80004000 0x2000>;
+ interrupts = <82 83 84 85
+ 88 88 88 88
+ 88 88 88 88
+ 87 86 0 0>;
+ interrupt-names = "ssp0", "ssp1", "ssp2", "ssp3",
+ "gpmi0", "gmpi1", "gpmi2", "gmpi3",
+ "gpmi4", "gmpi5", "gpmi6", "gmpi7",
+ "hsadc", "lcdif", "empty", "empty";
+ #dma-cells = <1>;
+ dma-channels = <16>;
};
-dma-apbx@80024000 {
+dma_apbx: dma-apbx@80024000 {
compatible = "fsl,imx28-dma-apbx";
- reg = <0x80024000 2000>;
+ reg = <0x80024000 0x2000>;
+ interrupts = <78 79 66 0
+ 80 81 68 69
+ 70 71 72 73
+ 74 75 76 77>;
+ interrupt-names = "auart4-rx", "aurat4-tx", "spdif-tx", "empty",
+ "saif0", "saif1", "i2c0", "i2c1",
+ "auart0-rx", "auart0-tx", "auart1-rx", "auart1-tx",
+ "auart2-rx", "auart2-tx", "auart3-rx", "auart3-tx";
+ #dma-cells = <1>;
+ dma-channels = <16>;
+};
+
+DMA clients connected to the MXS DMA controller must use the format
+described in the dma.txt file.
+
+Examples:
+
+auart0: serial@8006a000 {
+ compatible = "fsl,imx28-auart", "fsl,imx23-auart";
+ reg = <0x8006a000 0x2000>;
+ interrupts = <112>;
+ dmas = <&dma_apbx 8>, <&dma_apbx 9>;
+ dma-names = "rx", "tx";
};
diff --git a/Documentation/devicetree/bindings/dma/shdma.txt b/Documentation/devicetree/bindings/dma/shdma.txt
new file mode 100644
index 0000000..c15994a
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/shdma.txt
@@ -0,0 +1,75 @@
+* SHDMA Device Tree bindings
+
+Sh-/r-mobile and r-car systems often have multiple identical DMA controller
+instances, capable of serving any of a common set of DMA slave devices, using
+the same configuration. To describe this topology we require all compatible
+SHDMA DT nodes to be placed under a DMA multiplexer node. All such compatible
+DMAC instances have the same number of channels and use the same DMA
+descriptors. Therefore respective DMA DT bindings can also all be placed in the
+multiplexer node. Even if there is only one such DMAC instance on a system, it
+still has to be placed under such a multiplexer node.
+
+* DMA multiplexer
+
+Required properties:
+- compatible: should be "renesas,shdma-mux"
+- #dma-cells: should be <1>, see "dmas" property below
+
+Optional properties (currently unused):
+- dma-channels: number of DMA channels
+- dma-requests: number of DMA request signals
+
+* DMA controller
+
+Required properties:
+- compatible: should be "renesas,shdma"
+
+Example:
+ dmac: dma-mux0 {
+ compatible = "renesas,shdma-mux";
+ #dma-cells = <1>;
+ dma-channels = <6>;
+ dma-requests = <256>;
+ reg = <0 0>; /* Needed for AUXDATA */
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ dma0: shdma@fe008020 {
+ compatible = "renesas,shdma";
+ reg = <0xfe008020 0x270>,
+ <0xfe009000 0xc>;
+ interrupt-parent = <&gic>;
+ interrupts = <0 34 4
+ 0 28 4
+ 0 29 4
+ 0 30 4
+ 0 31 4
+ 0 32 4
+ 0 33 4>;
+ interrupt-names = "error",
+ "ch0", "ch1", "ch2", "ch3",
+ "ch4", "ch5";
+ };
+
+ dma1: shdma@fe018020 {
+ ...
+ };
+
+ dma2: shdma@fe028020 {
+ ...
+ };
+ };
+
+* DMA client
+
+Required properties:
+- dmas: a list of <[DMA multiplexer phandle] [MID/RID value]> pairs,
+ where MID/RID values are fixed handles, specified in the SoC
+ manual
+- dma-names: a list of DMA channel names, one per "dmas" entry
+
+Example:
+ dmas = <&dmac 0xd1
+ &dmac 0xd2>;
+ dma-names = "tx", "rx";
diff --git a/Documentation/devicetree/bindings/dma/snps-dma.txt b/Documentation/devicetree/bindings/dma/snps-dma.txt
index c0d85db..d58675e 100644
--- a/Documentation/devicetree/bindings/dma/snps-dma.txt
+++ b/Documentation/devicetree/bindings/dma/snps-dma.txt
@@ -3,15 +3,61 @@
Required properties:
- compatible: "snps,dma-spear1340"
- reg: Address range of the DMAC registers
+- interrupt: Should contain the DMAC interrupt number
+- dma-channels: Number of channels supported by hardware
+- dma-requests: Number of DMA request lines supported, up to 16
+- dma-masters: Number of AHB masters supported by the controller
+- #dma-cells: must be <3>
+- chan_allocation_order: order of allocation of channel, 0 (default): ascending,
+ 1: descending
+- chan_priority: priority of channels. 0 (default): increase from chan 0->n, 1:
+ increase from chan n->0
+- block_size: Maximum block size supported by the controller
+- data_width: Maximum data width supported by hardware per AHB master
+ (0 - 8bits, 1 - 16bits, ..., 5 - 256bits)
+
+
+Optional properties:
- interrupt-parent: Should be the phandle for the interrupt controller
that services interrupts for this device
-- interrupt: Should contain the DMAC interrupt number
+- is_private: The device channels should be marked as private and not for by the
+ general purpose DMA channel allocator. False if not passed.
Example:
- dma@fc000000 {
+ dmahost: dma@fc000000 {
compatible = "snps,dma-spear1340";
reg = <0xfc000000 0x1000>;
interrupt-parent = <&vic1>;
interrupts = <12>;
+
+ dma-channels = <8>;
+ dma-requests = <16>;
+ dma-masters = <2>;
+ #dma-cells = <3>;
+ chan_allocation_order = <1>;
+ chan_priority = <1>;
+ block_size = <0xfff>;
+ data_width = <3 3 0 0>;
+ };
+
+DMA clients connected to the Designware DMA controller must use the format
+described in the dma.txt file, using a four-cell specifier for each channel.
+The four cells in order are:
+
+1. A phandle pointing to the DMA controller
+2. The DMA request line number
+3. Source master for transfers on allocated channel
+4. Destination master for transfers on allocated channel
+
+Example:
+
+ serial@e0000000 {
+ compatible = "arm,pl011", "arm,primecell";
+ reg = <0xe0000000 0x1000>;
+ interrupts = <0 35 0x4>;
+ status = "disabled";
+ dmas = <&dmahost 12 0 1>,
+ <&dmahost 13 0 1 0>;
+ dma-names = "rx", "rx";
};
diff --git a/Documentation/devicetree/bindings/dma/ste-coh901318.txt b/Documentation/devicetree/bindings/dma/ste-coh901318.txt
new file mode 100644
index 0000000..091ad05
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/ste-coh901318.txt
@@ -0,0 +1,32 @@
+ST-Ericsson COH 901 318 DMA Controller
+
+This is a DMA controller which has begun as a fork of the
+ARM PL08x PrimeCell VHDL code.
+
+Required properties:
+- compatible: should be "stericsson,coh901318"
+- reg: register locations and length
+- interrupts: the single DMA IRQ
+- #dma-cells: must be set to <1>, as the channels on the
+ COH 901 318 are simple and identified by a single number
+- dma-channels: the number of DMA channels handled
+
+Example:
+
+dmac: dma-controller@c00020000 {
+ compatible = "stericsson,coh901318";
+ reg = <0xc0020000 0x1000>;
+ interrupt-parent = <&vica>;
+ interrupts = <2>;
+ #dma-cells = <1>;
+ dma-channels = <40>;
+};
+
+Consumers example:
+
+uart0: serial@c0013000 {
+ compatible = "...";
+ (...)
+ dmas = <&dmac 17 &dmac 18>;
+ dma-names = "tx", "rx";
+};
diff --git a/Documentation/devicetree/bindings/dma/ste-dma40.txt b/Documentation/devicetree/bindings/dma/ste-dma40.txt
new file mode 100644
index 0000000..bea5b73
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/ste-dma40.txt
@@ -0,0 +1,66 @@
+* DMA40 DMA Controller
+
+Required properties:
+- compatible: "stericsson,dma40"
+- reg: Address range of the DMAC registers
+- reg-names: Names of the above areas to use during resource look-up
+- interrupt: Should contain the DMAC interrupt number
+- #dma-cells: must be <3>
+- memcpy-channels: Channels to be used for memcpy
+
+Optional properties:
+- dma-channels: Number of channels supported by hardware - if not present
+ the driver will attempt to obtain the information from H/W
+- disabled-channels: Channels which can not be used
+
+Example:
+
+ dma: dma-controller@801C0000 {
+ compatible = "stericsson,db8500-dma40", "stericsson,dma40";
+ reg = <0x801C0000 0x1000 0x40010000 0x800>;
+ reg-names = "base", "lcpa";
+ interrupt-parent = <&intc>;
+ interrupts = <0 25 0x4>;
+
+ #dma-cells = <2>;
+ memcpy-channels = <56 57 58 59 60>;
+ disabled-channels = <12>;
+ dma-channels = <8>;
+ };
+
+Clients
+Required properties:
+- dmas: Comma separated list of dma channel requests
+- dma-names: Names of the aforementioned requested channels
+
+Each dmas request consists of 4 cells:
+ 1. A phandle pointing to the DMA controller
+ 2. Device Type
+ 3. The DMA request line number (only when 'use fixed channel' is set)
+ 4. A 32bit mask specifying; mode, direction and endianess [NB: This list will grow]
+ 0x00000001: Mode:
+ Logical channel when unset
+ Physical channel when set
+ 0x00000002: Direction:
+ Memory to Device when unset
+ Device to Memory when set
+ 0x00000004: Endianess:
+ Little endian when unset
+ Big endian when set
+ 0x00000008: Use fixed channel:
+ Use automatic channel selection when unset
+ Use DMA request line number when set
+
+Example:
+
+ uart@80120000 {
+ compatible = "arm,pl011", "arm,primecell";
+ reg = <0x80120000 0x1000>;
+ interrupts = <0 11 0x4>;
+
+ dmas = <&dma 13 0 0x2>, /* Logical - DevToMem */
+ <&dma 13 0 0x0>; /* Logical - MemToDev */
+ dma-names = "rx", "rx";
+
+ status = "disabled";
+ };
diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt b/Documentation/devicetree/bindings/dma/ti-edma.txt
new file mode 100644
index 0000000..9fbbdb7
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/ti-edma.txt
@@ -0,0 +1,34 @@
+TI EDMA
+
+Required properties:
+- compatible : "ti,edma3"
+- ti,edma-regions: Number of regions
+- ti,edma-slots: Number of slots
+- #dma-cells: Should be set to <1>
+ Clients should use a single channel number per DMA request.
+- dma-channels: Specify total DMA channels per CC
+- reg: Memory map for accessing module
+- interrupt-parent: Interrupt controller the interrupt is routed through
+- interrupts: Exactly 3 interrupts need to be specified in the order:
+ 1. Transfer completion interrupt.
+ 2. Memory protection interrupt.
+ 3. Error interrupt.
+Optional properties:
+- ti,hwmods: Name of the hwmods associated to the EDMA
+- ti,edma-xbar-event-map: Crossbar event to channel map
+
+Example:
+
+edma: edma@49000000 {
+ reg = <0x49000000 0x10000>;
+ interrupt-parent = <&intc>;
+ interrupts = <12 13 14>;
+ compatible = "ti,edma3";
+ ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
+ #dma-cells = <1>;
+ dma-channels = <64>;
+ ti,edma-regions = <4>;
+ ti,edma-slots = <256>;
+ ti,edma-xbar-event-map = <1 12
+ 2 13>;
+};
diff --git a/Documentation/devicetree/bindings/drm/exynos/hdmi.txt b/Documentation/devicetree/bindings/drm/exynos/hdmi.txt
deleted file mode 100644
index 589edee..0000000
--- a/Documentation/devicetree/bindings/drm/exynos/hdmi.txt
+++ /dev/null
@@ -1,22 +0,0 @@
-Device-Tree bindings for drm hdmi driver
-
-Required properties:
-- compatible: value should be "samsung,exynos5-hdmi".
-- reg: physical base address of the hdmi and length of memory mapped
- region.
-- interrupts: interrupt number to the cpu.
-- hpd-gpio: following information about the hotplug gpio pin.
- a) phandle of the gpio controller node.
- b) pin number within the gpio controller.
- c) pin function mode.
- d) optional flags and pull up/down.
- e) drive strength.
-
-Example:
-
- hdmi {
- compatible = "samsung,exynos5-hdmi";
- reg = <0x14530000 0x100000>;
- interrupts = <0 95 0>;
- hpd-gpio = <&gpx3 7 0xf 1 3>;
- };
diff --git a/Documentation/devicetree/bindings/drm/exynos/hdmiddc.txt b/Documentation/devicetree/bindings/drm/exynos/hdmiddc.txt
deleted file mode 100644
index fa166d9..0000000
--- a/Documentation/devicetree/bindings/drm/exynos/hdmiddc.txt
+++ /dev/null
@@ -1,12 +0,0 @@
-Device-Tree bindings for hdmiddc driver
-
-Required properties:
-- compatible: value should be "samsung,exynos5-hdmiddc".
-- reg: I2C address of the hdmiddc device.
-
-Example:
-
- hdmiddc {
- compatible = "samsung,exynos5-hdmiddc";
- reg = <0x50>;
- };
diff --git a/Documentation/devicetree/bindings/drm/exynos/hdmiphy.txt b/Documentation/devicetree/bindings/drm/exynos/hdmiphy.txt
deleted file mode 100644
index 858f4f9..0000000
--- a/Documentation/devicetree/bindings/drm/exynos/hdmiphy.txt
+++ /dev/null
@@ -1,12 +0,0 @@
-Device-Tree bindings for hdmiphy driver
-
-Required properties:
-- compatible: value should be "samsung,exynos5-hdmiphy".
-- reg: I2C address of the hdmiphy device.
-
-Example:
-
- hdmiphy {
- compatible = "samsung,exynos5-hdmiphy";
- reg = <0x38>;
- };
diff --git a/Documentation/devicetree/bindings/drm/exynos/mixer.txt b/Documentation/devicetree/bindings/drm/exynos/mixer.txt
deleted file mode 100644
index 9b2ea03..0000000
--- a/Documentation/devicetree/bindings/drm/exynos/mixer.txt
+++ /dev/null
@@ -1,15 +0,0 @@
-Device-Tree bindings for mixer driver
-
-Required properties:
-- compatible: value should be "samsung,exynos5-mixer".
-- reg: physical base address of the mixer and length of memory mapped
- region.
-- interrupts: interrupt number to the cpu.
-
-Example:
-
- mixer {
- compatible = "samsung,exynos5-mixer";
- reg = <0x14450000 0x10000>;
- interrupts = <0 94 0>;
- };
diff --git a/Documentation/devicetree/bindings/drm/tilcdc/panel.txt b/Documentation/devicetree/bindings/drm/tilcdc/panel.txt
new file mode 100644
index 0000000..9301c33
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/tilcdc/panel.txt
@@ -0,0 +1,59 @@
+Device-Tree bindings for tilcdc DRM generic panel output driver
+
+Required properties:
+ - compatible: value should be "ti,tilcdc,panel".
+ - panel-info: configuration info to configure LCDC correctly for the panel
+ - ac-bias: AC Bias Pin Frequency
+ - ac-bias-intrpt: AC Bias Pin Transitions per Interrupt
+ - dma-burst-sz: DMA burst size
+ - bpp: Bits per pixel
+ - fdd: FIFO DMA Request Delay
+ - sync-edge: Horizontal and Vertical Sync Edge: 0=rising 1=falling
+ - sync-ctrl: Horizontal and Vertical Sync: Control: 0=ignore
+ - raster-order: Raster Data Order Select: 1=Most-to-least 0=Least-to-most
+ - fifo-th: DMA FIFO threshold
+ - display-timings: typical videomode of lcd panel. Multiple video modes
+ can be listed if the panel supports multiple timings, but the 'native-mode'
+ should be the preferred/default resolution. Refer to
+ Documentation/devicetree/bindings/video/display-timing.txt for display
+ timing binding details.
+
+Recommended properties:
+ - pinctrl-names, pinctrl-0: the pincontrol settings to configure
+ muxing properly for pins that connect to TFP410 device
+
+Example:
+
+ /* Settings for CDTech_S035Q01 / LCD3 cape: */
+ lcd3 {
+ compatible = "ti,tilcdc,panel";
+ pinctrl-names = "default";
+ pinctrl-0 = <&bone_lcd3_cape_lcd_pins>;
+ panel-info {
+ ac-bias = <255>;
+ ac-bias-intrpt = <0>;
+ dma-burst-sz = <16>;
+ bpp = <16>;
+ fdd = <0x80>;
+ sync-edge = <0>;
+ sync-ctrl = <1>;
+ raster-order = <0>;
+ fifo-th = <0>;
+ };
+ display-timings {
+ native-mode = <&timing0>;
+ timing0: 320x240 {
+ hactive = <320>;
+ vactive = <240>;
+ hback-porch = <21>;
+ hfront-porch = <58>;
+ hsync-len = <47>;
+ vback-porch = <11>;
+ vfront-porch = <23>;
+ vsync-len = <2>;
+ clock-frequency = <8000000>;
+ hsync-active = <0>;
+ vsync-active = <0>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/drm/tilcdc/slave.txt b/Documentation/devicetree/bindings/drm/tilcdc/slave.txt
new file mode 100644
index 0000000..3d2c524
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/tilcdc/slave.txt
@@ -0,0 +1,18 @@
+Device-Tree bindings for tilcdc DRM encoder slave output driver
+
+Required properties:
+ - compatible: value should be "ti,tilcdc,slave".
+ - i2c: the phandle for the i2c device the encoder slave is connected to
+
+Recommended properties:
+ - pinctrl-names, pinctrl-0: the pincontrol settings to configure
+ muxing properly for pins that connect to TFP410 device
+
+Example:
+
+ hdmi {
+ compatible = "ti,tilcdc,slave";
+ i2c = <&i2c0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&nxp_hdmi_bonelt_pins>;
+ };
diff --git a/Documentation/devicetree/bindings/drm/tilcdc/tfp410.txt b/Documentation/devicetree/bindings/drm/tilcdc/tfp410.txt
new file mode 100644
index 0000000..a58ae77
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/tilcdc/tfp410.txt
@@ -0,0 +1,21 @@
+Device-Tree bindings for tilcdc DRM TFP410 output driver
+
+Required properties:
+ - compatible: value should be "ti,tilcdc,tfp410".
+ - i2c: the phandle for the i2c device to use for DDC
+
+Recommended properties:
+ - pinctrl-names, pinctrl-0: the pincontrol settings to configure
+ muxing properly for pins that connect to TFP410 device
+ - powerdn-gpio: the powerdown GPIO, pulled low to power down the
+ TFP410 device (for DPMS_OFF)
+
+Example:
+
+ dvicape {
+ compatible = "ti,tilcdc,tfp410";
+ i2c = <&i2c2>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&bone_dvi_cape_dvi_00A1_pins>;
+ powerdn-gpio = <&gpio2 31 0>;
+ };
diff --git a/Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt b/Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt
new file mode 100644
index 0000000..fff10da
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt
@@ -0,0 +1,29 @@
+Device-Tree bindings for tilcdc DRM driver
+
+Required properties:
+ - compatible: value should be "ti,am33xx-tilcdc".
+ - interrupts: the interrupt number
+ - reg: base address and size of the LCDC device
+
+Recommended properties:
+ - interrupt-parent: the phandle for the interrupt controller that
+ services interrupts for this device.
+ - ti,hwmods: Name of the hwmod associated to the LCDC
+
+Optional properties:
+ - max-bandwidth: The maximum pixels per second that the memory
+ interface / lcd controller combination can sustain
+ - max-width: The maximum horizontal pixel width supported by
+ the lcd controller.
+ - max-pixelclock: The maximum pixel clock that can be supported
+ by the lcd controller in KHz.
+
+Example:
+
+ fb: fb@4830e000 {
+ compatible = "ti,am33xx-tilcdc";
+ reg = <0x4830e000 0x1000>;
+ interrupt-parent = <&intc>;
+ interrupts = <36>;
+ ti,hwmods = "lcdc";
+ };
diff --git a/Documentation/devicetree/bindings/extcon/extcon-twl.txt b/Documentation/devicetree/bindings/extcon/extcon-twl.txt
new file mode 100644
index 0000000..58f531a
--- /dev/null
+++ b/Documentation/devicetree/bindings/extcon/extcon-twl.txt
@@ -0,0 +1,15 @@
+EXTCON FOR TWL CHIPS
+
+PALMAS USB COMPARATOR
+Required Properties:
+ - compatible : Should be "ti,palmas-usb" or "ti,twl6035-usb"
+ - vbus-supply : phandle to the regulator device tree node.
+
+Optional Properties:
+ - ti,wakeup : To enable the wakeup comparator in probe
+
+palmas-usb {
+ compatible = "ti,twl6035-usb", "ti,palmas-usb";
+ vbus-supply = <&smps10_reg>;
+ ti,wakeup;
+};
diff --git a/Documentation/devicetree/bindings/fb/mxsfb.txt b/Documentation/devicetree/bindings/fb/mxsfb.txt
index b41e5e52..96ec517 100644
--- a/Documentation/devicetree/bindings/fb/mxsfb.txt
+++ b/Documentation/devicetree/bindings/fb/mxsfb.txt
@@ -5,9 +5,16 @@
imx23 and imx28.
- reg: Address and length of the register set for lcdif
- interrupts: Should contain lcdif interrupts
+- display : phandle to display node (see below for details)
-Optional properties:
-- panel-enable-gpios : Should specify the gpio for panel enable
+* display node
+
+Required properties:
+- bits-per-pixel : <16> for RGB565, <32> for RGB888/666.
+- bus-width : number of data lines. Could be <8>, <16>, <18> or <24>.
+
+Required sub-node:
+- display-timings : Refer to binding doc display-timing.txt for details.
Examples:
@@ -15,5 +22,28 @@
compatible = "fsl,imx28-lcdif";
reg = <0x80030000 2000>;
interrupts = <38 86>;
- panel-enable-gpios = <&gpio3 30 0>;
+
+ display: display {
+ bits-per-pixel = <32>;
+ bus-width = <24>;
+
+ display-timings {
+ native-mode = <&timing0>;
+ timing0: timing0 {
+ clock-frequency = <33500000>;
+ hactive = <800>;
+ vactive = <480>;
+ hfront-porch = <164>;
+ hback-porch = <89>;
+ hsync-len = <10>;
+ vback-porch = <23>;
+ vfront-porch = <10>;
+ vsync-len = <10>;
+ hsync-active = <0>;
+ vsync-active = <0>;
+ de-active = <1>;
+ pixelclk-active = <0>;
+ };
+ };
+ };
};
diff --git a/Documentation/devicetree/bindings/gpio/gpio-clps711x.txt b/Documentation/devicetree/bindings/gpio/gpio-clps711x.txt
new file mode 100644
index 0000000..e0d0446
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-clps711x.txt
@@ -0,0 +1,28 @@
+Cirrus Logic CLPS711X GPIO controller
+
+Required properties:
+- compatible: Should be "cirrus,clps711x-gpio"
+- reg: Physical base GPIO controller registers location and length.
+ There should be two registers, first is DATA register, the second
+ is DIRECTION.
+- gpio-controller: Marks the device node as a gpio controller.
+- #gpio-cells: Should be two. The first cell is the pin number and
+ the second cell is used to specify the gpio polarity:
+ 0 = active high
+ 1 = active low
+
+Note: Each GPIO port should have an alias correctly numbered in "aliases"
+node.
+
+Example:
+
+aliases {
+ gpio0 = &porta;
+};
+
+porta: gpio@80000000 {
+ compatible = "cirrus,clps711x-gpio";
+ reg = <0x80000000 0x1>, <0x80000040 0x1>;
+ gpio-controller;
+ #gpio-cells = <2>;
+};
diff --git a/Documentation/devicetree/bindings/gpio/gpio-grgpio.txt b/Documentation/devicetree/bindings/gpio/gpio-grgpio.txt
new file mode 100644
index 0000000..e466598
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-grgpio.txt
@@ -0,0 +1,26 @@
+Aeroflex Gaisler GRGPIO General Purpose I/O cores.
+
+The GRGPIO GPIO core is available in the GRLIB VHDL IP core library.
+
+Note: In the ordinary environment for the GRGPIO core, a Leon SPARC system,
+these properties are built from information in the AMBA plug&play.
+
+Required properties:
+
+- name : Should be "GAISLER_GPIO" or "01_01a"
+
+- reg : Address and length of the register set for the device
+
+- interrupts : Interrupt numbers for this device
+
+Optional properties:
+
+- nbits : The number of gpio lines. If not present driver assumes 32 lines.
+
+- irqmap : An array with an index for each gpio line. An index is either a valid
+ index into the interrupts property array, or 0xffffffff that indicates
+ no irq for that line. Driver provides no interrupt support if not
+ present.
+
+For further information look in the documentation for the GLIB IP core library:
+http://www.gaisler.com/products/grlib/grip.pdf
diff --git a/Documentation/devicetree/bindings/gpio/gpio-mcp23s08.txt b/Documentation/devicetree/bindings/gpio/gpio-mcp23s08.txt
new file mode 100644
index 0000000..629d0ef
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-mcp23s08.txt
@@ -0,0 +1,47 @@
+Microchip MCP2308/MCP23S08/MCP23017/MCP23S17 driver for
+8-/16-bit I/O expander with serial interface (I2C/SPI)
+
+Required properties:
+- compatible : Should be
+ - "mcp,mcp23s08" for 8 GPIO SPI version
+ - "mcp,mcp23s17" for 16 GPIO SPI version
+ - "mcp,mcp23008" for 8 GPIO I2C version or
+ - "mcp,mcp23017" for 16 GPIO I2C version of the chip
+- #gpio-cells : Should be two.
+ - first cell is the pin number
+ - second cell is used to specify flags. Flags are currently unused.
+- gpio-controller : Marks the device node as a GPIO controller.
+- reg : For an address on its bus. I2C uses this a the I2C address of the chip.
+ SPI uses this to specify the chipselect line which the chip is
+ connected to. The driver and the SPI variant of the chip support
+ multiple chips on the same chipselect. Have a look at
+ mcp,spi-present-mask below.
+
+Required device specific properties (only for SPI chips):
+- mcp,spi-present-mask : This is a present flag, that makes only sense for SPI
+ chips - as the name suggests. Multiple SPI chips can share the same
+ SPI chipselect. Set a bit in bit0-7 in this mask to 1 if there is a
+ chip connected with the corresponding spi address set. For example if
+ you have a chip with address 3 connected, you have to set bit3 to 1,
+ which is 0x08. mcp23s08 chip variant only supports bits 0-3. It is not
+ possible to mix mcp23s08 and mcp23s17 on the same chipselect. Set at
+ least one bit to 1 for SPI chips.
+- spi-max-frequency = The maximum frequency this chip is able to handle
+
+Example I2C:
+gpiom1: gpio@20 {
+ compatible = "mcp,mcp23017";
+ gpio-controller;
+ #gpio-cells = <2>;
+ reg = <0x20>;
+};
+
+Example SPI:
+gpiom1: gpio@0 {
+ compatible = "mcp,mcp23s17";
+ gpio-controller;
+ #gpio-cells = <2>;
+ spi-present-mask = <0x01>;
+ reg = <0>;
+ spi-max-frequency = <1000000>;
+};
diff --git a/Documentation/devicetree/bindings/gpio/gpio-msm.txt b/Documentation/devicetree/bindings/gpio/gpio-msm.txt
new file mode 100644
index 0000000..ac20e68
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-msm.txt
@@ -0,0 +1,26 @@
+MSM GPIO controller bindings
+
+Required properties:
+- compatible:
+ - "qcom,msm-gpio" for MSM controllers
+- #gpio-cells : Should be two.
+ - first cell is the pin number
+ - second cell is used to specify optional parameters (unused)
+- gpio-controller : Marks the device node as a GPIO controller.
+- #interrupt-cells : Should be 2.
+- interrupt-controller: Mark the device node as an interrupt controller
+- interrupts : Specify the TLMM summary interrupt number
+- ngpio : Specify the number of MSM GPIOs
+
+Example:
+
+ msmgpio: gpio@fd510000 {
+ compatible = "qcom,msm-gpio";
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ reg = <0xfd510000 0x4000>;
+ interrupts = <0 208 0>;
+ ngpio = <150>;
+ };
diff --git a/Documentation/devicetree/bindings/gpio/gpio-omap.txt b/Documentation/devicetree/bindings/gpio/gpio-omap.txt
index bff51a2..8d95052 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-omap.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-omap.txt
@@ -5,12 +5,12 @@
- "ti,omap2-gpio" for OMAP2 controllers
- "ti,omap3-gpio" for OMAP3 controllers
- "ti,omap4-gpio" for OMAP4 controllers
+- gpio-controller : Marks the device node as a GPIO controller.
- #gpio-cells : Should be two.
- first cell is the pin number
- second cell is used to specify optional parameters (unused)
-- gpio-controller : Marks the device node as a GPIO controller.
+- interrupt-controller: Mark the device node as an interrupt controller.
- #interrupt-cells : Should be 2.
-- interrupt-controller: Mark the device node as an interrupt controller
The first cell is the GPIO number.
The second cell is used to specify flags:
bits[3:0] trigger type and level flags:
@@ -20,8 +20,11 @@
8 = active low level-sensitive.
OMAP specific properties:
-- ti,hwmods: Name of the hwmod associated to the GPIO:
- "gpio<X>", <X> being the 1-based instance number from the HW spec
+- ti,hwmods: Name of the hwmod associated to the GPIO:
+ "gpio<X>", <X> being the 1-based instance number
+ from the HW spec.
+- ti,gpio-always-on: Indicates if a GPIO bank is always powered and
+ so will never lose its logic state.
Example:
@@ -29,8 +32,8 @@
gpio4: gpio4 {
compatible = "ti,omap4-gpio";
ti,hwmods = "gpio4";
- #gpio-cells = <2>;
gpio-controller;
- #interrupt-cells = <2>;
+ #gpio-cells = <2>;
interrupt-controller;
+ #interrupt-cells = <2>;
};
diff --git a/Documentation/devicetree/bindings/gpio/gpio-poweroff.txt b/Documentation/devicetree/bindings/gpio/gpio-poweroff.txt
index 558cdf3..d4eab92 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-poweroff.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-poweroff.txt
@@ -1,4 +1,19 @@
-GPIO line that should be set high/low to power off a device
+Driver a GPIO line that can be used to turn the power off.
+
+The driver supports both level triggered and edge triggered power off.
+At driver load time, the driver will request the given gpio line and
+install a pm_power_off handler. If the optional properties 'input' is
+not found, the GPIO line will be driven in the inactive
+state. Otherwise its configured as an input.
+
+When the pm_power_off is called, the gpio is configured as an output,
+and drive active, so triggering a level triggered power off
+condition. This will also cause an inactive->active edge condition, so
+triggering positive edge triggered power off. After a delay of 100ms,
+the GPIO is set to inactive, thus causing an active->inactive edge,
+triggering negative edge triggered power off. After another 100ms
+delay the GPIO is driver active again. If the power is still on and
+the CPU still running after a 3000ms delay, a WARN_ON(1) is emitted.
Required properties:
- compatible : should be "gpio-poweroff".
@@ -13,10 +28,9 @@
property is not specified, the GPIO is initialized as an output in its
inactive state.
-
Examples:
gpio-poweroff {
compatible = "gpio-poweroff";
- gpios = <&gpio 4 0>; /* GPIO 4 Active Low */
+ gpios = <&gpio 4 0>;
};
diff --git a/Documentation/devicetree/bindings/gpio/gpio-samsung.txt b/Documentation/devicetree/bindings/gpio/gpio-samsung.txt
index f1e5dfe..5375625 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-samsung.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-samsung.txt
@@ -39,46 +39,3 @@
#gpio-cells = <4>;
gpio-controller;
};
-
-
-Samsung S3C24XX GPIO Controller
-
-Required properties:
-- compatible: Compatible property value should be "samsung,s3c24xx-gpio".
-
-- reg: Physical base address of the controller and length of memory mapped
- region.
-
-- #gpio-cells: Should be 3. The syntax of the gpio specifier used by client nodes
- should be the following with values derived from the SoC user manual.
- <[phandle of the gpio controller node]
- [pin number within the gpio controller]
- [mux function]
- [flags and pull up/down]
-
- Values for gpio specifier:
- - Pin number: depending on the controller a number from 0 up to 15.
- - Mux function: Depending on the SoC and the gpio bank the gpio can be set
- as input, output or a special function
- - Flags and Pull Up/Down: the values to use differ for the individual SoCs
- example S3C2416/S3C2450:
- 0 - Pull Up/Down Disabled.
- 1 - Pull Down Enabled.
- 2 - Pull Up Enabled.
- Bit 16 (0x00010000) - Input is active low.
- Consult the user manual for the correct values of Mux and Pull Up/Down.
-
-- gpio-controller: Specifies that the node is a gpio controller.
-- #address-cells: should be 1.
-- #size-cells: should be 1.
-
-Example:
-
- gpa: gpio-controller@56000000 {
- #address-cells = <1>;
- #size-cells = <1>;
- compatible = "samsung,s3c24xx-gpio";
- reg = <0x56000000 0x10>;
- #gpio-cells = <3>;
- gpio-controller;
- };
diff --git a/Documentation/devicetree/bindings/gpio/gpio-stericsson-coh901.txt b/Documentation/devicetree/bindings/gpio/gpio-stericsson-coh901.txt
new file mode 100644
index 0000000..fd665b4
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-stericsson-coh901.txt
@@ -0,0 +1,7 @@
+ST-Ericsson COH 901 571/3 GPIO controller
+
+Required properties:
+- compatible: Compatible property value should be "stericsson,gpio-coh901"
+- reg: Physical base address of the controller and length of memory mapped
+ region.
+- interrupts: the 0...n interrupts assigned to the different GPIO ports/banks.
diff --git a/Documentation/devicetree/bindings/gpio/gpio-vt8500.txt b/Documentation/devicetree/bindings/gpio/gpio-vt8500.txt
deleted file mode 100644
index f4dc523..0000000
--- a/Documentation/devicetree/bindings/gpio/gpio-vt8500.txt
+++ /dev/null
@@ -1,24 +0,0 @@
-VIA/Wondermedia VT8500 GPIO Controller
------------------------------------------------------
-
-Required properties:
-- compatible : "via,vt8500-gpio", "wm,wm8505-gpio"
- or "wm,wm8650-gpio" depending on your SoC
-- reg : Should contain 1 register range (address and length)
-- #gpio-cells : should be <3>.
- 1) bank
- 2) pin number
- 3) flags - should be 0
-
-Example:
-
- gpio: gpio-controller@d8110000 {
- compatible = "via,vt8500-gpio";
- gpio-controller;
- reg = <0xd8110000 0x10000>;
- #gpio-cells = <3>;
- };
-
- vibrate {
- gpios = <&gpio 0 1 0>; /* Bank 0, Pin 1, No flags */
- };
diff --git a/Documentation/devicetree/bindings/gpio/gpio-xilinx.txt b/Documentation/devicetree/bindings/gpio/gpio-xilinx.txt
new file mode 100644
index 0000000..63bf4be
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-xilinx.txt
@@ -0,0 +1,48 @@
+Xilinx plb/axi GPIO controller
+
+Dual channel GPIO controller with configurable number of pins
+(from 1 to 32 per channel). Every pin can be configured as
+input/output/tristate. Both channels share the same global IRQ but
+local interrupts can be enabled on channel basis.
+
+Required properties:
+- compatible : Should be "xlnx,xps-gpio-1.00.a"
+- reg : Address and length of the register set for the device
+- #gpio-cells : Should be two. The first cell is the pin number and the
+ second cell is used to specify optional parameters (currently unused).
+- gpio-controller : Marks the device node as a GPIO controller.
+
+Optional properties:
+- interrupts : Interrupt mapping for GPIO IRQ.
+- interrupt-parent : Phandle for the interrupt controller that
+ services interrupts for this device.
+- xlnx,all-inputs : if n-th bit is setup, GPIO-n is input
+- xlnx,dout-default : if n-th bit is 1, GPIO-n default value is 1
+- xlnx,gpio-width : gpio width
+- xlnx,tri-default : if n-th bit is 1, GPIO-n is in tristate mode
+- xlnx,is-dual : if 1, controller also uses the second channel
+- xlnx,all-inputs-2 : as above but for the second channel
+- xlnx,dout-default-2 : as above but the second channel
+- xlnx,gpio2-width : as above but for the second channel
+- xlnx,tri-default-2 : as above but for the second channel
+
+
+Example:
+gpio: gpio@40000000 {
+ #gpio-cells = <2>;
+ compatible = "xlnx,xps-gpio-1.00.a";
+ gpio-controller ;
+ interrupt-parent = <µblaze_0_intc>;
+ interrupts = < 6 2 >;
+ reg = < 0x40000000 0x10000 >;
+ xlnx,all-inputs = <0x0>;
+ xlnx,all-inputs-2 = <0x0>;
+ xlnx,dout-default = <0x0>;
+ xlnx,dout-default-2 = <0x0>;
+ xlnx,gpio-width = <0x2>;
+ xlnx,gpio2-width = <0x2>;
+ xlnx,interrupt-present = <0x1>;
+ xlnx,is-dual = <0x1>;
+ xlnx,tri-default = <0xffffffff>;
+ xlnx,tri-default-2 = <0xffffffff>;
+} ;
diff --git a/Documentation/devicetree/bindings/gpio/gpio.txt b/Documentation/devicetree/bindings/gpio/gpio.txt
index a336287..d933af3 100644
--- a/Documentation/devicetree/bindings/gpio/gpio.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio.txt
@@ -98,7 +98,7 @@
compatible = "fsl,qe-pario-bank-e", "fsl,qe-pario-bank";
reg = <0x1460 0x18>;
gpio-controller;
- gpio-ranges = <&pinctrl1 20 10>, <&pinctrl2 50 20>;
+ gpio-ranges = <&pinctrl1 0 20 10>, <&pinctrl2 10 50 20>;
}
@@ -107,8 +107,8 @@
Next values specify the base pin and number of pins for the range
handled by 'qe_pio_e' gpio. In the given example from base pin 20 to
- pin 29 under pinctrl1 and pin 50 to pin 69 under pinctrl2 is handled
- by this gpio controller.
+ pin 29 under pinctrl1 with gpio offset 0 and pin 50 to pin 69 under
+ pinctrl2 with gpio offset 10 is handled by this gpio controller.
The pinctrl node must have "#gpio-range-cells" property to show number of
arguments to pass with phandle from gpio controllers node.
diff --git a/Documentation/devicetree/bindings/gpio/men-a021-wdt.txt b/Documentation/devicetree/bindings/gpio/men-a021-wdt.txt
new file mode 100644
index 0000000..370dee3
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/men-a021-wdt.txt
@@ -0,0 +1,25 @@
+Bindings for MEN A21 Watchdog device connected to GPIO lines
+
+Required properties:
+- compatible: "men,a021-wdt"
+- gpios: Specifies the pins that control the Watchdog, order:
+ 1: Watchdog enable
+ 2: Watchdog fast-mode
+ 3: Watchdog trigger
+ 4: Watchdog reset cause bit 0
+ 5: Watchdog reset cause bit 1
+ 6: Watchdog reset cause bit 2
+
+Optional properties:
+- None
+
+Example:
+ watchdog {
+ compatible ="men,a021-wdt";
+ gpios = <&gpio3 9 1 /* WD_EN */
+ &gpio3 10 1 /* WD_FAST */
+ &gpio3 11 1 /* WD_TRIG */
+ &gpio3 6 1 /* RST_CAUSE[0] */
+ &gpio3 7 1 /* RST_CAUSE[1] */
+ &gpio3 8 1>; /* RST_CAUSE[2] */
+ };
diff --git a/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt b/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt
index e137874..9b3f1d4 100644
--- a/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt
+++ b/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt
@@ -1,7 +1,10 @@
* Marvell PXA GPIO controller
Required properties:
-- compatible : Should be "mrvl,pxa-gpio" or "mrvl,mmp-gpio"
+- compatible : Should be "intel,pxa25x-gpio", "intel,pxa26x-gpio",
+ "intel,pxa27x-gpio", "intel,pxa3xx-gpio",
+ "marvell,pxa93x-gpio", "marvell,mmp-gpio" or
+ "marvell,mmp2-gpio".
- reg : Address and length of the register set for the device
- interrupts : Should be the port interrupt shared by all gpio pins.
There're three gpio interrupts in arch-pxa, and they're gpio0,
@@ -18,7 +21,7 @@
Example:
gpio: gpio@d4019000 {
- compatible = "mrvl,mmp-gpio";
+ compatible = "marvell,mmp-gpio";
reg = <0xd4019000 0x1000>;
interrupts = <49>;
interrupt-name = "gpio_mux";
diff --git a/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt b/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt
new file mode 100644
index 0000000..cb3dc7b
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt
@@ -0,0 +1,46 @@
+* Renesas R-Car GPIO Controller
+
+Required Properties:
+
+ - compatible: should be one of the following.
+ - "renesas,gpio-r8a7778": for R8A7778 (R-Mobile M1) compatible GPIO controller.
+ - "renesas,gpio-r8a7779": for R8A7779 (R-Car H1) compatible GPIO controller.
+ - "renesas,gpio-r8a7790": for R8A7790 (R-Car H2) compatible GPIO controller.
+ - "renesas,gpio-rcar": for generic R-Car GPIO controller.
+
+ - reg: Base address and length of each memory resource used by the GPIO
+ controller hardware module.
+
+ - interrupt-parent: phandle of the parent interrupt controller.
+ - interrupts: Interrupt specifier for the controllers interrupt.
+
+ - gpio-controller: Marks the device node as a gpio controller.
+ - #gpio-cells: Should be 2. The first cell is the GPIO number and the second
+ cell specifies GPIO flags, as defined in <dt-bindings/gpio/gpio.h>. Only the
+ GPIO_ACTIVE_HIGH and GPIO_ACTIVE_LOW flags are supported.
+ - gpio-ranges: Range of pins managed by the GPIO controller.
+
+Please refer to gpio.txt in this directory for details of gpio-ranges property
+and the common GPIO bindings used by client devices.
+
+Example: R8A7779 (R-Car H1) GPIO controller nodes
+
+ gpio0: gpio@ffc40000 {
+ compatible = "renesas,gpio-r8a7779", "renesas,gpio-rcar";
+ reg = <0xffc40000 0x2c>;
+ interrupt-parent = <&gic>;
+ interrupts = <0 141 0x4>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ gpio-ranges = <&pfc 0 0 32>;
+ };
+ ...
+ gpio6: gpio@ffc46000 {
+ compatible = "renesas,gpio-r8a7779", "renesas,gpio-rcar";
+ reg = <0xffc46000 0x2c>;
+ interrupt-parent = <&gic>;
+ interrupts = <0 147 0x4>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ gpio-ranges = <&pfc 0 192 9>;
+ };
diff --git a/Documentation/devicetree/bindings/gpu/samsung-g2d.txt b/Documentation/devicetree/bindings/gpu/samsung-g2d.txt
new file mode 100644
index 0000000..3f454ff
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpu/samsung-g2d.txt
@@ -0,0 +1,25 @@
+* Samsung 2D Graphics Accelerator
+
+Required properties:
+ - compatible : value should be one among the following:
+ (a) "samsung,s5pv210-g2d" for G2D IP present in S5PV210 & Exynos4210 SoC
+ (b) "samsung,exynos4212-g2d" for G2D IP present in Exynos4x12 SoCs
+ (c) "samsung,exynos5250-g2d" for G2D IP present in Exynos5250 SoC
+
+ - reg : Physical base address of the IP registers and length of memory
+ mapped region.
+
+ - interrupts : G2D interrupt number to the CPU.
+ - clocks : from common clock binding: handle to G2D clocks.
+ - clock-names : from common clock binding: must contain "sclk_fimg2d" and
+ "fimg2d", corresponding to entries in the clocks property.
+
+Example:
+ g2d@12800000 {
+ compatible = "samsung,s5pv210-g2d";
+ reg = <0x12800000 0x1000>;
+ interrupts = <0 89 0>;
+ clocks = <&clock 177>, <&clock 277>;
+ clock-names = "sclk_fimg2d", "fimg2d";
+ status = "disabled";
+ };
diff --git a/Documentation/devicetree/bindings/hwmon/g762.txt b/Documentation/devicetree/bindings/hwmon/g762.txt
new file mode 100644
index 0000000..25cc6d8
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/g762.txt
@@ -0,0 +1,47 @@
+GMT G762/G763 PWM Fan controller
+
+Required node properties:
+
+ - "compatible": must be either "gmt,g762" or "gmt,g763"
+ - "reg": I2C bus address of the device
+ - "clocks": a fixed clock providing input clock frequency
+ on CLK pin of the chip.
+
+Optional properties:
+
+ - "fan_startv": fan startup voltage. Accepted values are 0, 1, 2 and 3.
+ The higher the more.
+
+ - "pwm_polarity": pwm polarity. Accepted values are 0 (positive duty)
+ and 1 (negative duty).
+
+ - "fan_gear_mode": fan gear mode. Supported values are 0, 1 and 2.
+
+If an optional property is not set in .dts file, then current value is kept
+unmodified (e.g. u-boot installed value).
+
+Additional information on operational parameters for the device is available
+in Documentation/hwmon/g762. A detailed datasheet for the device is available
+at http://natisbad.org/NAS/refs/GMT_EDS-762_763-080710-0.2.pdf.
+
+Example g762 node:
+
+ clocks {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ g762_clk: fixedclk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <8192>;
+ }
+ }
+
+ g762: g762@3e {
+ compatible = "gmt,g762";
+ reg = <0x3e>;
+ clocks = <&g762_clk>
+ fan_gear_mode = <0>; /* chip default */
+ fan_startv = <1>; /* chip default */
+ pwm_polarity = <0>; /* chip default */
+ };
diff --git a/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt b/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
new file mode 100644
index 0000000..c6f6667
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
@@ -0,0 +1,29 @@
+NTC Thermistor hwmon sensors
+-------------------------------
+
+Requires node properties:
+- "compatible" value : one of
+ "ntc,ncp15wb473"
+ "ntc,ncp18wb473"
+ "ntc,ncp21wb473"
+ "ntc,ncp03wb473"
+ "ntc,ncp15wl333"
+- "pullup-uv" Pull up voltage in micro volts
+- "pullup-ohm" Pull up resistor value in ohms
+- "pulldown-ohm" Pull down resistor value in ohms
+- "connected-positive" Always ON, If not specified.
+ Status change is possible.
+- "io-channels" Channel node of ADC to be used for
+ conversion.
+
+Read more about iio bindings at
+ Documentation/devicetree/bindings/iio/iio-bindings.txt
+
+Example:
+ ncp15wb473@0 {
+ compatible = "ntc,ncp15wb473";
+ pullup-uv = <1800000>;
+ pullup-ohm = <47000>;
+ pulldown-ohm = <0>;
+ io-channels = <&adc 3>;
+ };
diff --git a/Documentation/devicetree/bindings/hwrng/timeriomem_rng.txt b/Documentation/devicetree/bindings/hwrng/timeriomem_rng.txt
new file mode 100644
index 0000000..6616d15
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwrng/timeriomem_rng.txt
@@ -0,0 +1,18 @@
+HWRNG support for the timeriomem_rng driver
+
+Required properties:
+- compatible : "timeriomem_rng"
+- reg : base address to sample from
+- period : wait time in microseconds to use between samples
+
+N.B. currently 'reg' must be four bytes wide and aligned
+
+Example:
+
+hwrng@44 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "timeriomem_rng";
+ reg = <0x44 0x04>;
+ period = <1000000>;
+};
diff --git a/Documentation/devicetree/bindings/i2c/brcm,bcm2835-i2c.txt b/Documentation/devicetree/bindings/i2c/brcm,bcm2835-i2c.txt
new file mode 100644
index 0000000..e9de375
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/brcm,bcm2835-i2c.txt
@@ -0,0 +1,20 @@
+Broadcom BCM2835 I2C controller
+
+Required properties:
+- compatible : Should be "brcm,bcm2835-i2c".
+- reg: Should contain register location and length.
+- interrupts: Should contain interrupt.
+- clocks : The clock feeding the I2C controller.
+
+Recommended properties:
+- clock-frequency : desired I2C bus clock frequency in Hz.
+
+Example:
+
+i2c@20205000 {
+ compatible = "brcm,bcm2835-i2c";
+ reg = <0x7e205000 0x1000>;
+ interrupts = <2 21>;
+ clocks = <&clk_i2c>;
+ clock-frequency = <100000>;
+};
diff --git a/Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.txt b/Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.txt
new file mode 100644
index 0000000..1ac8ea8
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.txt
@@ -0,0 +1,80 @@
+GPIO-based I2C Arbitration Using a Challenge & Response Mechanism
+=================================================================
+This uses GPIO lines and a challenge & response mechanism to arbitrate who is
+the master of an I2C bus in a multimaster situation.
+
+In many cases using GPIOs to arbitrate is not needed and a design can use
+the standard I2C multi-master rules. Using GPIOs is generally useful in
+the case where there is a device on the bus that has errata and/or bugs
+that makes standard multimaster mode not feasible.
+
+
+Algorithm:
+
+All masters on the bus have a 'bus claim' line which is an output that the
+others can see. These are all active low with pull-ups enabled. We'll
+describe these lines as:
+
+- OUR_CLAIM: output from us signaling to other hosts that we want the bus
+- THEIR_CLAIMS: output from others signaling that they want the bus
+
+The basic algorithm is to assert your line when you want the bus, then make
+sure that the other side doesn't want it also. A detailed explanation is best
+done with an example.
+
+Let's say we want to claim the bus. We:
+1. Assert OUR_CLAIM.
+2. Waits a little bit for the other sides to notice (slew time, say 10
+ microseconds).
+3. Check THEIR_CLAIMS. If none are asserted then the we have the bus and we are
+ done.
+4. Otherwise, wait for a few milliseconds and see if THEIR_CLAIMS are released.
+5. If not, back off, release the claim and wait for a few more milliseconds.
+6. Go back to 1 (until retry time has expired).
+
+
+Required properties:
+- compatible: i2c-arb-gpio-challenge
+- our-claim-gpio: The GPIO that we use to claim the bus.
+- their-claim-gpios: The GPIOs that the other sides use to claim the bus.
+ Note that some implementations may only support a single other master.
+- Standard I2C mux properties. See mux.txt in this directory.
+- Single I2C child bus node at reg 0. See mux.txt in this directory.
+
+Optional properties:
+- slew-delay-us: microseconds to wait for a GPIO to go high. Default is 10 us.
+- wait-retry-us: we'll attempt another claim after this many microseconds.
+ Default is 3000 us.
+- wait-free-us: we'll give up after this many microseconds. Default is 50000 us.
+
+
+Example:
+ i2c@12CA0000 {
+ compatible = "acme,some-i2c-device";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ i2c-arbitrator {
+ compatible = "i2c-arb-gpio-challenge";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ i2c-parent = <&{/i2c@12CA0000}>;
+
+ our-claim-gpio = <&gpf0 3 1>;
+ their-claim-gpios = <&gpe0 4 1>;
+ slew-delay-us = <10>;
+ wait-retry-us = <3000>;
+ wait-free-us = <50000>;
+
+ i2c@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ i2c@52 {
+ // Normal I2C device
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/i2c/i2c-designware.txt b/Documentation/devicetree/bindings/i2c/i2c-designware.txt
index e42a2ee..7fd7fa2 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-designware.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-designware.txt
@@ -10,6 +10,10 @@
- clock-frequency : desired I2C bus clock frequency in Hz.
+Optional properties :
+ - i2c-sda-hold-time-ns : should contain the SDA hold time in nanoseconds.
+ This option is only supported in hardware blocks version 1.11a or newer.
+
Example :
i2c@f0000 {
@@ -20,3 +24,14 @@
interrupts = <11>;
clock-frequency = <400000>;
};
+
+ i2c@1120000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "snps,designware-i2c";
+ reg = <0x1120000 0x1000>;
+ interrupt-parent = <&ictl>;
+ interrupts = <12 1>;
+ clock-frequency = <400000>;
+ i2c-sda-hold-time-ns = <300>;
+ };
diff --git a/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt b/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt
index f46d928..a1ee681 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt
@@ -6,7 +6,11 @@
- reg : Offset and length of the register set for the device
- compatible : Should be "marvell,mv64xxx-i2c"
- interrupts : The interrupt number
- - clock-frequency : Desired I2C bus clock frequency in Hz.
+
+Optional properties :
+
+ - clock-frequency : Desired I2C bus clock frequency in Hz. If not set the
+default frequency is 100kHz
Examples:
diff --git a/Documentation/devicetree/bindings/i2c/i2c-mxs.txt b/Documentation/devicetree/bindings/i2c/i2c-mxs.txt
index 7a3fe9e..4e1c8ac 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-mxs.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-mxs.txt
@@ -3,10 +3,13 @@
Required properties:
- compatible: Should be "fsl,<chip>-i2c"
- reg: Should contain registers location and length
-- interrupts: Should contain ERROR and DMA interrupts
+- interrupts: Should contain ERROR interrupt number
- clock-frequency: Desired I2C bus clock frequency in Hz.
Only 100000Hz and 400000Hz modes are supported.
-- fsl,i2c-dma-channel: APBX DMA channel for the I2C
+- dmas: DMA specifier, consisting of a phandle to DMA controller node
+ and I2C DMA channel ID.
+ Refer to dma.txt and fsl-mxs-dma.txt for details.
+- dma-names: Must be "rx-tx".
Examples:
@@ -15,7 +18,8 @@
#size-cells = <0>;
compatible = "fsl,imx28-i2c";
reg = <0x80058000 2000>;
- interrupts = <111 68>;
+ interrupts = <111>;
clock-frequency = <100000>;
- fsl,i2c-dma-channel = <6>;
+ dmas = <&dma_apbx 6>;
+ dma-names = "rx-tx";
};
diff --git a/Documentation/devicetree/bindings/i2c/i2c-s3c2410.txt b/Documentation/devicetree/bindings/i2c/i2c-s3c2410.txt
index e9611ac..296eb45 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-s3c2410.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-s3c2410.txt
@@ -8,6 +8,8 @@
(b) "samsung, s3c2440-i2c", for i2c compatible with s3c2440 i2c.
(c) "samsung, s3c2440-hdmiphy-i2c", for s3c2440-like i2c used
inside HDMIPHY block found on several samsung SoCs
+ (d) "samsung, exynos5440-i2c", for s3c2440-like i2c used
+ on EXYNOS5440 which does not need GPIO configuration.
- reg: physical base address of the controller and length of memory mapped
region.
- interrupts: interrupt number to the cpu.
@@ -24,7 +26,7 @@
- pinctrl-names: Should contain only one value - "default".
Optional properties:
- - samsung,i2c-slave-addr: Slave address in multi-master enviroment. If not
+ - samsung,i2c-slave-addr: Slave address in multi-master environment. If not
specified, default value is 0.
- samsung,i2c-max-bus-freq: Desired frequency in Hz of the bus. If not
specified, the default value in Hz is 100000.
diff --git a/Documentation/devicetree/bindings/i2c/i2c-st-ddci2c.txt b/Documentation/devicetree/bindings/i2c/i2c-st-ddci2c.txt
new file mode 100644
index 0000000..bd81a48
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-st-ddci2c.txt
@@ -0,0 +1,15 @@
+ST Microelectronics DDC I2C
+
+Required properties :
+- compatible : Must be "st,ddci2c"
+- reg: physical base address of the controller and length of memory mapped
+ region.
+- interrupts: interrupt number to the cpu.
+- #address-cells = <1>;
+- #size-cells = <0>;
+
+Optional properties:
+- Child nodes conforming to i2c bus binding
+
+Examples :
+
diff --git a/Documentation/devicetree/bindings/i2c/i2c-vt8500.txt b/Documentation/devicetree/bindings/i2c/i2c-vt8500.txt
new file mode 100644
index 0000000..94a425e
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-vt8500.txt
@@ -0,0 +1,24 @@
+* Wondermedia I2C Controller
+
+Required properties :
+
+ - compatible : should be "wm,wm8505-i2c"
+ - reg : Offset and length of the register set for the device
+ - interrupts : <IRQ> where IRQ is the interrupt number
+ - clocks : phandle to the I2C clock source
+
+Optional properties :
+
+ - clock-frequency : desired I2C bus clock frequency in Hz.
+ Valid values are 100000 and 400000.
+ Default to 100000 if not specified, or invalid value.
+
+Example :
+
+ i2c_0: i2c@d8280000 {
+ compatible = "wm,wm8505-i2c";
+ reg = <0xd8280000 0x1000>;
+ interrupts = <19>;
+ clocks = <&clki2c0>;
+ clock-frequency = <400000>;
+ };
diff --git a/Documentation/devicetree/bindings/i2c/ina209.txt b/Documentation/devicetree/bindings/i2c/ina209.txt
new file mode 100644
index 0000000..9dd2bee
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/ina209.txt
@@ -0,0 +1,18 @@
+ina209 properties
+
+Required properties:
+- compatible: Must be "ti,ina209"
+- reg: I2C address
+
+Optional properties:
+
+- shunt-resistor
+ Shunt resistor value in micro-Ohm
+
+Example:
+
+temp-sensor@4c {
+ compatible = "ti,ina209";
+ reg = <0x4c>;
+ shunt-resistor = <5000>;
+};
diff --git a/Documentation/devicetree/bindings/i2c/ina2xx.txt b/Documentation/devicetree/bindings/i2c/ina2xx.txt
new file mode 100644
index 0000000..a2ad85d
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/ina2xx.txt
@@ -0,0 +1,22 @@
+ina2xx properties
+
+Required properties:
+- compatible: Must be one of the following:
+ - "ti,ina219" for ina219
+ - "ti,ina220" for ina220
+ - "ti,ina226" for ina226
+ - "ti,ina230" for ina230
+- reg: I2C address
+
+Optional properties:
+
+- shunt-resistor
+ Shunt resistor value in micro-Ohm
+
+Example:
+
+ina220@44 {
+ compatible = "ti,ina220";
+ reg = <0x44>;
+ shunt-resistor = <1000>;
+};
diff --git a/Documentation/devicetree/bindings/i2c/max6697.txt b/Documentation/devicetree/bindings/i2c/max6697.txt
new file mode 100644
index 0000000..5f79399
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/max6697.txt
@@ -0,0 +1,64 @@
+max6697 properties
+
+Required properties:
+- compatible:
+ Should be one of
+ maxim,max6581
+ maxim,max6602
+ maxim,max6622
+ maxim,max6636
+ maxim,max6689
+ maxim,max6693
+ maxim,max6694
+ maxim,max6697
+ maxim,max6698
+ maxim,max6699
+- reg: I2C address
+
+Optional properties:
+
+- smbus-timeout-disable
+ Set to disable SMBus timeout. If not specified, SMBus timeout will be
+ enabled.
+- extended-range-enable
+ Only valid for MAX6581. Set to enable extended temperature range.
+ Extended temperature will be disabled if not specified.
+- beta-compensation-enable
+ Only valid for MAX6693 and MX6694. Set to enable beta compensation on
+ remote temperature channel 1.
+ Beta compensation will be disabled if not specified.
+- alert-mask
+ Alert bit mask. Alert disabled for bits set.
+ Select bit 0 for local temperature, bit 1..7 for remote temperatures.
+ If not specified, alert will be enabled for all channels.
+- over-temperature-mask
+ Over-temperature bit mask. Over-temperature reporting disabled for
+ bits set.
+ Select bit 0 for local temperature, bit 1..7 for remote temperatures.
+ If not specified, over-temperature reporting will be enabled for all
+ channels.
+- resistance-cancellation
+ Boolean for all chips other than MAX6581. Set to enable resistance
+ cancellation on remote temperature channel 1.
+ For MAX6581, resistance cancellation enabled for all channels if
+ specified as boolean, otherwise as per bit mask specified.
+ Only supported for remote temperatures (bit 1..7).
+ If not specified, resistance cancellation will be disabled for all
+ channels.
+- transistor-ideality
+ For MAX6581 only. Two values; first is bit mask, second is ideality
+ select value as per MAX6581 data sheet. Select bit 1..7 for remote
+ channels.
+ Transistor ideality will be initialized to default (1.008) if not
+ specified.
+
+Example:
+
+temp-sensor@1a {
+ compatible = "maxim,max6697";
+ reg = <0x1a>;
+ smbus-timeout-disable;
+ resistance-cancellation;
+ alert-mask = <0x72>;
+ over-temperature-mask = <0x7f>;
+};
diff --git a/Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.txt b/Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.txt
new file mode 100644
index 0000000..ef77cc7
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.txt
@@ -0,0 +1,60 @@
+NVIDIA Tegra20/Tegra30/Tegra114 I2C controller driver.
+
+Required properties:
+- compatible : should be:
+ "nvidia,tegra114-i2c"
+ "nvidia,tegra30-i2c"
+ "nvidia,tegra20-i2c"
+ "nvidia,tegra20-i2c-dvc"
+ Details of compatible are as follows:
+ nvidia,tegra20-i2c-dvc: Tegra20 has specific I2C controller called as DVC I2C
+ controller. This only support master mode of I2C communication. Register
+ interface/offset and interrupts handling are different than generic I2C
+ controller. Driver of DVC I2C controller is only compatible with
+ "nvidia,tegra20-i2c-dvc".
+ nvidia,tegra20-i2c: Tegra20 has 4 generic I2C controller. This can support
+ master and slave mode of I2C communication. The i2c-tegra driver only
+ support master mode of I2C communication. Driver of I2C controller is
+ only compatible with "nvidia,tegra20-i2c".
+ nvidia,tegra30-i2c: Tegra30 has 5 generic I2C controller. This controller is
+ very much similar to Tegra20 I2C controller with additional feature:
+ Continue Transfer Support. This feature helps to implement M_NO_START
+ as per I2C core API transfer flags. Driver of I2C controller is
+ compatible with "nvidia,tegra30-i2c" to enable the continue transfer
+ support. This is also compatible with "nvidia,tegra20-i2c" without
+ continue transfer support.
+ nvidia,tegra114-i2c: Tegra114 has 5 generic I2C controller. This controller is
+ very much similar to Tegra30 I2C controller with some hardware
+ modification:
+ - Tegra30/Tegra20 I2C controller has 2 clock source called div-clk and
+ fast-clk. Tegra114 has only one clock source called as div-clk and
+ hence clock mechanism is changed in I2C controller.
+ - Tegra30/Tegra20 I2C controller has enabled per packet transfer by
+ default and there is no way to disable it. Tegra114 has this
+ interrupt disable by default and SW need to enable explicitly.
+ Due to above changes, Tegra114 I2C driver makes incompatible with
+ previous hardware driver. Hence, tegra114 I2C controller is compatible
+ with "nvidia,tegra114-i2c".
+- reg: Should contain I2C controller registers physical address and length.
+- interrupts: Should contain I2C controller interrupts.
+- address-cells: Address cells for I2C device address.
+- size-cells: Size of the I2C device address.
+- clocks: Clock ID as per
+ Documentation/devicetree/bindings/clock/tegra<chip-id>.txt
+ for I2C controller.
+- clock-names: Name of the clock:
+ Tegra20/Tegra30 I2C controller: "div-clk and "fast-clk".
+ Tegra114 I2C controller: "div-clk".
+
+Example:
+
+ i2c@7000c000 {
+ compatible = "nvidia,tegra20-i2c";
+ reg = <0x7000c000 0x100>;
+ interrupts = <0 38 0x04>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&tegra_car 12>, <&tegra_car 124>;
+ clock-names = "div-clk", "fast-clk";
+ status = "disabled";
+ };
diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
index 446859f..ad6a738 100644
--- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt
+++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
@@ -35,6 +35,8 @@
fsl,mma8450 MMA8450Q: Xtrinsic Low-power, 3-axis Xtrinsic Accelerometer
fsl,mpr121 MPR121: Proximity Capacitive Touch Sensor Controller
fsl,sgtl5000 SGTL5000: Ultra Low-Power Audio Codec
+infineon,slb9635tt Infineon SLB9635 (Soft-) I2C TPM (old protocol, max 100khz)
+infineon,slb9645tt Infineon SLB9645 I2C TPM (new protocol, max 400khz)
maxim,ds1050 5 Bit Programmable, Pulse-Width Modulator
maxim,max1237 Low-Power, 4-/12-Channel, 2-Wire Serial, 12-Bit ADCs
maxim,max6625 9-Bit/12-Bit Temperature Sensors with I²C-Compatible Serial Interface
diff --git a/Documentation/devicetree/bindings/iio/dac/ad7303.txt b/Documentation/devicetree/bindings/iio/dac/ad7303.txt
new file mode 100644
index 0000000..914610f
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/dac/ad7303.txt
@@ -0,0 +1,23 @@
+Analog Devices AD7303 DAC device driver
+
+Required properties:
+ - compatible: Must be "adi,ad7303"
+ - reg: SPI chip select number for the device
+ - spi-max-frequency: Max SPI frequency to use (< 30000000)
+ - Vdd-supply: Phandle to the Vdd power supply
+
+Optional properties:
+ - REF-supply: Phandle to the external reference voltage supply. This should
+ only be set if there is an external reference voltage connected to the REF
+ pin. If the property is not set Vdd/2 is used as the reference voltage.
+
+Example:
+
+ ad7303@4 {
+ compatible = "adi,ad7303";
+ reg = <4>;
+ spi-max-frequency = <10000000>;
+ Vdd-supply = <&vdd_supply>;
+ adi,use-external-reference;
+ REF-supply = <&vref_supply>;
+ };
diff --git a/Documentation/devicetree/bindings/iio/frequency/adf4350.txt b/Documentation/devicetree/bindings/iio/frequency/adf4350.txt
new file mode 100644
index 0000000..f8c181d
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/frequency/adf4350.txt
@@ -0,0 +1,86 @@
+Analog Devices ADF4350/ADF4351 device driver
+
+Required properties:
+ - compatible: Should be one of
+ * "adi,adf4350": When using the ADF4350 device
+ * "adi,adf4351": When using the ADF4351 device
+ - reg: SPI chip select numbert for the device
+ - spi-max-frequency: Max SPI frequency to use (< 20000000)
+ - clocks: From common clock binding. Clock is phandle to clock for
+ ADF435x Reference Clock (CLKIN).
+
+Optional properties:
+ - gpios: GPIO Lock detect - If set with a valid phandle and GPIO number,
+ pll lock state is tested upon read.
+ - adi,channel-spacing: Channel spacing in Hz (influences MODULUS).
+ - adi,power-up-frequency: If set in Hz the PLL tunes to
+ the desired frequency on probe.
+ - adi,reference-div-factor: If set the driver skips dynamic calculation
+ and uses this default value instead.
+ - adi,reference-doubler-enable: Enables reference doubler.
+ - adi,reference-div2-enable: Enables reference divider.
+ - adi,phase-detector-polarity-positive-enable: Enables positive phase
+ detector polarity. Default = negative.
+ - adi,lock-detect-precision-6ns-enable: Enables 6ns lock detect precision.
+ Default = 10ns.
+ - adi,lock-detect-function-integer-n-enable: Enables lock detect
+ for integer-N mode. Default = factional-N mode.
+ - adi,charge-pump-current: Charge pump current in mA.
+ Default = 2500mA.
+ - adi,muxout-select: On chip multiplexer output selection.
+ Valid values for the multiplexer output are:
+ 0: Three-State Output (default)
+ 1: DVDD
+ 2: DGND
+ 3: R-Counter output
+ 4: N-Divider output
+ 5: Analog lock detect
+ 6: Digital lock detect
+ - adi,low-spur-mode-enable: Enables low spur mode.
+ Default = Low noise mode.
+ - adi,cycle-slip-reduction-enable: Enables cycle slip reduction.
+ - adi,charge-cancellation-enable: Enabled charge pump
+ charge cancellation for integer-N modes.
+ - adi,anti-backlash-3ns-enable: Enables 3ns antibacklash pulse width
+ for integer-N modes.
+ - adi,band-select-clock-mode-high-enable: Enables faster band
+ selection logic.
+ - adi,12bit-clk-divider: Clock divider value used when
+ adi,12bit-clkdiv-mode != 0
+ - adi,clk-divider-mode:
+ Valid values for the clkdiv mode are:
+ 0: Clock divider off (default)
+ 1: Fast lock enable
+ 2: Phase resync enable
+ - adi,aux-output-enable: Enables auxiliary RF output.
+ - adi,aux-output-fundamental-enable: Selects fundamental VCO output on
+ the auxiliary RF output. Default = Output of RF dividers.
+ - adi,mute-till-lock-enable: Enables Mute-Till-Lock-Detect function.
+ - adi,output-power: Output power selection.
+ Valid values for the power mode are:
+ 0: -4dBm (default)
+ 1: -1dBm
+ 2: +2dBm
+ 3: +5dBm
+ - adi,aux-output-power: Auxiliary output power selection.
+ Valid values for the power mode are:
+ 0: -4dBm (default)
+ 1: -1dBm
+ 2: +2dBm
+ 3: +5dBm
+
+
+Example:
+ lo_pll0_rx_adf4351: adf4351-rx-lpc@4 {
+ compatible = "adi,adf4351";
+ reg = <4>;
+ spi-max-frequency = <10000000>;
+ clocks = <&clk0_ad9523 9>;
+ clock-names = "clkin";
+ adi,channel-spacing = <10000>;
+ adi,power-up-frequency = <2400000000>;
+ adi,phase-detector-polarity-positive-enable;
+ adi,charge-pump-current = <2500>;
+ adi,output-power = <3>;
+ adi,mute-till-lock-enable;
+ };
diff --git a/Documentation/devicetree/bindings/iio/iio-bindings.txt b/Documentation/devicetree/bindings/iio/iio-bindings.txt
new file mode 100644
index 0000000..0b447d9a
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/iio-bindings.txt
@@ -0,0 +1,97 @@
+This binding is derived from clock bindings, and based on suggestions
+from Lars-Peter Clausen [1].
+
+Sources of IIO channels can be represented by any node in the device
+tree. Those nodes are designated as IIO providers. IIO consumer
+nodes use a phandle and IIO specifier pair to connect IIO provider
+outputs to IIO inputs. Similar to the gpio specifiers, an IIO
+specifier is an array of one or more cells identifying the IIO
+output on a device. The length of an IIO specifier is defined by the
+value of a #io-channel-cells property in the IIO provider node.
+
+[1] http://marc.info/?l=linux-iio&m=135902119507483&w=2
+
+==IIO providers==
+
+Required properties:
+#io-channel-cells: Number of cells in an IIO specifier; Typically 0 for nodes
+ with a single IIO output and 1 for nodes with multiple
+ IIO outputs.
+
+Example for a simple configuration with no trigger:
+
+ adc: voltage-sensor@35 {
+ compatible = "maxim,max1139";
+ reg = <0x35>;
+ #io-channel-cells = <1>;
+ };
+
+Example for a configuration with trigger:
+
+ adc@35 {
+ compatible = "some-vendor,some-adc";
+ reg = <0x35>;
+
+ adc1: iio-device@0 {
+ #io-channel-cells = <1>;
+ /* other properties */
+ };
+ adc2: iio-device@1 {
+ #io-channel-cells = <1>;
+ /* other properties */
+ };
+ };
+
+==IIO consumers==
+
+Required properties:
+io-channels: List of phandle and IIO specifier pairs, one pair
+ for each IIO input to the device. Note: if the
+ IIO provider specifies '0' for #io-channel-cells,
+ then only the phandle portion of the pair will appear.
+
+Optional properties:
+io-channel-names:
+ List of IIO input name strings sorted in the same
+ order as the io-channels property. Consumers drivers
+ will use io-channel-names to match IIO input names
+ with IIO specifiers.
+io-channel-ranges:
+ Empty property indicating that child nodes can inherit named
+ IIO channels from this node. Useful for bus nodes to provide
+ and IIO channel to their children.
+
+For example:
+
+ device {
+ io-channels = <&adc 1>, <&ref 0>;
+ io-channel-names = "vcc", "vdd";
+ };
+
+This represents a device with two IIO inputs, named "vcc" and "vdd".
+The vcc channel is connected to output 1 of the &adc device, and the
+vdd channel is connected to output 0 of the &ref device.
+
+==Example==
+
+ adc: max1139@35 {
+ compatible = "maxim,max1139";
+ reg = <0x35>;
+ #io-channel-cells = <1>;
+ };
+
+ ...
+
+ iio_hwmon {
+ compatible = "iio-hwmon";
+ io-channels = <&adc 0>, <&adc 1>, <&adc 2>,
+ <&adc 3>, <&adc 4>, <&adc 5>,
+ <&adc 6>, <&adc 7>, <&adc 8>,
+ <&adc 9>;
+ };
+
+ some_consumer {
+ compatible = "some-consumer";
+ io-channels = <&adc 10>, <&adc 11>;
+ io-channel-names = "adc1", "adc2";
+ };
diff --git a/Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt b/Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt
new file mode 100644
index 0000000..011679f
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt
@@ -0,0 +1,18 @@
+* AsahiKASEI AK8975 magnetometer sensor
+
+Required properties:
+
+ - compatible : should be "asahi-kasei,ak8975"
+ - reg : the I2C address of the magnetometer
+
+Optional properties:
+
+ - gpios : should be device tree identifier of the magnetometer DRDY pin
+
+Example:
+
+ak8975@0c {
+ compatible = "asahi-kasei,ak8975";
+ reg = <0x0c>;
+ gpios = <&gpj0 7 0>;
+};
diff --git a/Documentation/devicetree/bindings/input/ads7846.txt b/Documentation/devicetree/bindings/input/ads7846.txt
new file mode 100644
index 0000000..5f7619c
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/ads7846.txt
@@ -0,0 +1,91 @@
+Device tree bindings for TI's ADS7843, ADS7845, ADS7846, ADS7873, TSC2046
+SPI driven touch screen controllers.
+
+The node for this driver must be a child node of a SPI controller, hence
+all mandatory properties described in
+
+ Documentation/devicetree/bindings/spi/spi-bus.txt
+
+must be specified.
+
+Additional required properties:
+
+ compatible Must be one of the following, depending on the
+ model:
+ "ti,tsc2046"
+ "ti,ads7843"
+ "ti,ads7845"
+ "ti,ads7846"
+ "ti,ads7873"
+
+ interrupt-parent
+ interrupts An interrupt node describing the IRQ line the chip's
+ !PENIRQ pin is connected to.
+ vcc-supply A regulator node for the supply voltage.
+
+
+Optional properties:
+
+ ti,vref-delay-usecs vref supply delay in usecs, 0 for
+ external vref (u16).
+ ti,vref-mv The VREF voltage, in millivolts (u16).
+ ti,keep-vref-on set to keep vref on for differential
+ measurements as well
+ ti,swap-xy swap x and y axis
+ ti,settle-delay-usec Settling time of the analog signals;
+ a function of Vcc and the capacitance
+ on the X/Y drivers. If set to non-zero,
+ two samples are taken with settle_delay
+ us apart, and the second one is used.
+ ~150 uSec with 0.01uF caps (u16).
+ ti,penirq-recheck-delay-usecs If set to non-zero, after samples are
+ taken this delay is applied and penirq
+ is rechecked, to help avoid false
+ events. This value is affected by the
+ material used to build the touch layer
+ (u16).
+ ti,x-plate-ohms Resistance of the X-plate,
+ in Ohms (u16).
+ ti,y-plate-ohms Resistance of the Y-plate,
+ in Ohms (u16).
+ ti,x-min Minimum value on the X axis (u16).
+ ti,y-min Minimum value on the Y axis (u16).
+ ti,x-max Maximum value on the X axis (u16).
+ ti,y-max Minimum value on the Y axis (u16).
+ ti,pressure-min Minimum reported pressure value
+ (threshold) - u16.
+ ti,pressure-max Maximum reported pressure value (u16).
+ ti,debounce-max Max number of additional readings per
+ sample (u16).
+ ti,debounce-tol Tolerance used for filtering (u16).
+ ti,debounce-rep Additional consecutive good readings
+ required after the first two (u16).
+ ti,pendown-gpio-debounce Platform specific debounce time for the
+ pendown-gpio (u32).
+ pendown-gpio GPIO handle describing the pin the !PENIRQ
+ line is connected to.
+ linux,wakeup use any event on touchscreen as wakeup event.
+
+
+Example for a TSC2046 chip connected to an McSPI controller of an OMAP SoC::
+
+ spi_controller {
+ tsc2046@0 {
+ reg = <0>; /* CS0 */
+ compatible = "ti,tsc2046";
+ interrupt-parent = <&gpio1>;
+ interrupts = <8 0>; /* BOOT6 / GPIO 8 */
+ spi-max-frequency = <1000000>;
+ pendown-gpio = <&gpio1 8 0>;
+ vcc-supply = <®_vcc3>;
+
+ ti,x-min = /bits/ 16 <0>;
+ ti,x-max = /bits/ 16 <8000>;
+ ti,y-min = /bits/ 16 <0>;
+ ti,y-max = /bits/ 16 <4800>;
+ ti,x-plate-ohms = /bits/ 16 <40>;
+ ti,pressure-max = /bits/ 16 <255>;
+
+ linux,wakeup;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/input/cros-ec-keyb.txt b/Documentation/devicetree/bindings/input/cros-ec-keyb.txt
new file mode 100644
index 0000000..0f6355c
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/cros-ec-keyb.txt
@@ -0,0 +1,72 @@
+ChromeOS EC Keyboard
+
+Google's ChromeOS EC Keyboard is a simple matrix keyboard implemented on
+a separate EC (Embedded Controller) device. It provides a message for reading
+key scans from the EC. These are then converted into keycodes for processing
+by the kernel.
+
+This binding is based on matrix-keymap.txt and extends/modifies it as follows:
+
+Required properties:
+- compatible: "google,cros-ec-keyb"
+
+Optional properties:
+- google,needs-ghost-filter: True to enable a ghost filter for the matrix
+keyboard. This is recommended if the EC does not have its own logic or
+hardware for this.
+
+
+Example:
+
+cros-ec-keyb {
+ compatible = "google,cros-ec-keyb";
+ keypad,num-rows = <8>;
+ keypad,num-columns = <13>;
+ google,needs-ghost-filter;
+ /*
+ * Keymap entries take the form of 0xRRCCKKKK where
+ * RR=Row CC=Column KKKK=Key Code
+ * The values below are for a US keyboard layout and
+ * are taken from the Linux driver. Note that the
+ * 102ND key is not used for US keyboards.
+ */
+ linux,keymap = <
+ /* CAPSLCK F1 B F10 */
+ 0x0001003a 0x0002003b 0x00030030 0x00040044
+ /* N = R_ALT ESC */
+ 0x00060031 0x0008000d 0x000a0064 0x01010001
+ /* F4 G F7 H */
+ 0x0102003e 0x01030022 0x01040041 0x01060023
+ /* ' F9 BKSPACE L_CTRL */
+ 0x01080028 0x01090043 0x010b000e 0x0200001d
+ /* TAB F3 T F6 */
+ 0x0201000f 0x0202003d 0x02030014 0x02040040
+ /* ] Y 102ND [ */
+ 0x0205001b 0x02060015 0x02070056 0x0208001a
+ /* F8 GRAVE F2 5 */
+ 0x02090042 0x03010029 0x0302003c 0x03030006
+ /* F5 6 - \ */
+ 0x0304003f 0x03060007 0x0308000c 0x030b002b
+ /* R_CTRL A D F */
+ 0x04000061 0x0401001e 0x04020020 0x04030021
+ /* S K J ; */
+ 0x0404001f 0x04050025 0x04060024 0x04080027
+ /* L ENTER Z C */
+ 0x04090026 0x040b001c 0x0501002c 0x0502002e
+ /* V X , M */
+ 0x0503002f 0x0504002d 0x05050033 0x05060032
+ /* L_SHIFT / . SPACE */
+ 0x0507002a 0x05080035 0x05090034 0x050B0039
+ /* 1 3 4 2 */
+ 0x06010002 0x06020004 0x06030005 0x06040003
+ /* 8 7 0 9 */
+ 0x06050009 0x06060008 0x0608000b 0x0609000a
+ /* L_ALT DOWN RIGHT Q */
+ 0x060a0038 0x060b006c 0x060c006a 0x07010010
+ /* E R W I */
+ 0x07020012 0x07030013 0x07040011 0x07050017
+ /* U R_SHIFT P O */
+ 0x07060016 0x07070036 0x07080019 0x07090018
+ /* UP LEFT */
+ 0x070b0067 0x070c0069>;
+};
diff --git a/Documentation/devicetree/bindings/input/imx-keypad.txt b/Documentation/devicetree/bindings/input/imx-keypad.txt
new file mode 100644
index 0000000..2ebaf7d
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/imx-keypad.txt
@@ -0,0 +1,53 @@
+* Freescale i.MX Keypad Port(KPP) device tree bindings
+
+The KPP is designed to interface with a keypad matrix with 2-point contact
+or 3-point contact keys. The KPP is designed to simplify the software task
+of scanning a keypad matrix. The KPP is capable of detecting, debouncing,
+and decoding one or multiple keys pressed simultaneously on a keypad.
+
+Required SoC Specific Properties:
+- compatible: Should be "fsl,<soc>-kpp".
+
+- reg: Physical base address of the KPP and length of memory mapped
+ region.
+
+- interrupts: The KPP interrupt number to the CPU(s).
+
+- clocks: The clock provided by the SoC to the KPP. Some SoCs use dummy
+clock(The clock for the KPP is provided by the SoCs automatically).
+
+Required Board Specific Properties:
+- pinctrl-names: The definition can be found at
+pinctrl/pinctrl-bindings.txt.
+
+- pinctrl-0: The definition can be found at
+pinctrl/pinctrl-bindings.txt.
+
+- linux,keymap: The definition can be found at
+bindings/input/matrix-keymap.txt.
+
+Example:
+kpp: kpp@73f94000 {
+ compatible = "fsl,imx51-kpp", "fsl,imx21-kpp";
+ reg = <0x73f94000 0x4000>;
+ interrupts = <60>;
+ clocks = <&clks 0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_kpp_1>;
+ linux,keymap = <0x00000067 /* KEY_UP */
+ 0x0001006c /* KEY_DOWN */
+ 0x00020072 /* KEY_VOLUMEDOWN */
+ 0x00030066 /* KEY_HOME */
+ 0x0100006a /* KEY_RIGHT */
+ 0x01010069 /* KEY_LEFT */
+ 0x0102001c /* KEY_ENTER */
+ 0x01030073 /* KEY_VOLUMEUP */
+ 0x02000040 /* KEY_F6 */
+ 0x02010042 /* KEY_F8 */
+ 0x02020043 /* KEY_F9 */
+ 0x02030044 /* KEY_F10 */
+ 0x0300003b /* KEY_F1 */
+ 0x0301003c /* KEY_F2 */
+ 0x0302003d /* KEY_F3 */
+ 0x03030074>; /* KEY_POWER */
+};
diff --git a/Documentation/devicetree/bindings/input/lpc32xx-key.txt b/Documentation/devicetree/bindings/input/lpc32xx-key.txt
index 31afd50..bcf62f8 100644
--- a/Documentation/devicetree/bindings/input/lpc32xx-key.txt
+++ b/Documentation/devicetree/bindings/input/lpc32xx-key.txt
@@ -1,19 +1,22 @@
NXP LPC32xx Key Scan Interface
+This binding is based on the matrix-keymap binding with the following
+changes:
+
Required Properties:
- compatible: Should be "nxp,lpc3220-key"
- reg: Physical base address of the controller and length of memory mapped
region.
- interrupts: The interrupt number to the cpu.
-- keypad,num-rows: Number of rows and columns, e.g. 1: 1x1, 6: 6x6
-- keypad,num-columns: Must be equal to keypad,num-rows since LPC32xx only
- supports square matrices
- nxp,debounce-delay-ms: Debounce delay in ms
- nxp,scan-delay-ms: Repeated scan period in ms
- linux,keymap: the key-code to be reported when the key is pressed
and released, see also
Documentation/devicetree/bindings/input/matrix-keymap.txt
+Note: keypad,num-rows and keypad,num-columns are required, and must be equal
+since LPC32xx only supports square matrices
+
Example:
key@40050000 {
diff --git a/Documentation/devicetree/bindings/input/matrix-keymap.txt b/Documentation/devicetree/bindings/input/matrix-keymap.txt
index 3cd8b98..c54919f 100644
--- a/Documentation/devicetree/bindings/input/matrix-keymap.txt
+++ b/Documentation/devicetree/bindings/input/matrix-keymap.txt
@@ -9,6 +9,12 @@
row << 24 | column << 16 | key-code
Optional properties:
+Properties for the number of rows and columns are optional because some
+drivers will use fixed values for these.
+- keypad,num-rows: Number of row lines connected to the keypad controller.
+- keypad,num-columns: Number of column lines connected to the keypad
+ controller.
+
Some users of this binding might choose to specify secondary keymaps for
cases where there is a modifier key such as a Fn key. Proposed names
for said properties are "linux,fn-keymap" or with another descriptive
@@ -17,3 +23,5 @@
Example:
linux,keymap = < 0x00030012
0x0102003a >;
+ keypad,num-rows = <2>;
+ keypad,num-columns = <8>;
diff --git a/Documentation/devicetree/bindings/input/nvidia,tegra20-kbc.txt b/Documentation/devicetree/bindings/input/nvidia,tegra20-kbc.txt
index 72683be..2995fae 100644
--- a/Documentation/devicetree/bindings/input/nvidia,tegra20-kbc.txt
+++ b/Documentation/devicetree/bindings/input/nvidia,tegra20-kbc.txt
@@ -1,7 +1,18 @@
* Tegra keyboard controller
+The key controller has maximum 24 pins to make matrix keypad. Any pin
+can be configured as row or column. The maximum column pin can be 8
+and maximum row pins can be 16 for Tegra20/Tegra30.
Required properties:
- compatible: "nvidia,tegra20-kbc"
+- reg: Register base address of KBC.
+- interrupts: Interrupt number for the KBC.
+- nvidia,kbc-row-pins: The KBC pins which are configured as row. This is an
+ array of pin numbers which is used as rows.
+- nvidia,kbc-col-pins: The KBC pins which are configured as column. This is an
+ array of pin numbers which is used as column.
+- linux,keymap: The keymap for keys as described in the binding document
+ devicetree/bindings/input/matrix-keymap.txt.
Optional properties, in addition to those specified by the shared
matrix-keyboard bindings:
@@ -19,5 +30,16 @@
keyboard: keyboard {
compatible = "nvidia,tegra20-kbc";
reg = <0x7000e200 0x100>;
+ interrupts = <0 85 0x04>;
nvidia,ghost-filter;
+ nvidia,debounce-delay-ms = <640>;
+ nvidia,kbc-row-pins = <0 1 2>; /* pin 0, 1, 2 as rows */
+ nvidia,kbc-col-pins = <11 12 13>; /* pin 11, 12, 13 as columns */
+ linux,keymap = <0x00000074
+ 0x00010067
+ 0x00020066
+ 0x01010068
+ 0x02000069
+ 0x02010070
+ 0x02020071>;
};
diff --git a/Documentation/devicetree/bindings/input/omap-keypad.txt b/Documentation/devicetree/bindings/input/omap-keypad.txt
index f2fa5e1..34ed1c6 100644
--- a/Documentation/devicetree/bindings/input/omap-keypad.txt
+++ b/Documentation/devicetree/bindings/input/omap-keypad.txt
@@ -6,19 +6,16 @@
The keypad controller can sense a key-press and key-release and report the
event using a interrupt to the cpu.
+This binding is based on the matrix-keymap binding with the following
+changes:
+
+keypad,num-rows and keypad,num-columns are required.
+
Required SoC Specific Properties:
- compatible: should be one of the following
- "ti,omap4-keypad": For controllers compatible with omap4 keypad
controller.
-Required Board Specific Properties, in addition to those specified by
-the shared matrix-keyboard bindings:
-- keypad,num-rows: Number of row lines connected to the keypad
- controller.
-
-- keypad,num-columns: Number of column lines connected to the
- keypad controller.
-
Optional Properties specific to linux:
- linux,keypad-no-autorepeat: do no enable autorepeat feature.
diff --git a/Documentation/devicetree/bindings/input/ps2keyb-mouse-apbps2.txt b/Documentation/devicetree/bindings/input/ps2keyb-mouse-apbps2.txt
new file mode 100644
index 0000000..3029c56
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/ps2keyb-mouse-apbps2.txt
@@ -0,0 +1,16 @@
+Aeroflex Gaisler APBPS2 PS/2 Core, supporting Keyboard or Mouse.
+
+The APBPS2 PS/2 core is available in the GRLIB VHDL IP core library.
+
+Note: In the ordinary environment for the APBPS2 core, a LEON SPARC system,
+these properties are built from information in the AMBA plug&play and from
+bootloader settings.
+
+Required properties:
+
+- name : Should be "GAISLER_APBPS2" or "01_060"
+- reg : Address and length of the register set for the device
+- interrupts : Interrupt numbers for this device
+
+For further information look in the documentation for the GLIB IP core library:
+http://www.gaisler.com/products/grlib/grip.pdf
diff --git a/Documentation/devicetree/bindings/input/pxa27x-keypad.txt b/Documentation/devicetree/bindings/input/pxa27x-keypad.txt
new file mode 100644
index 0000000..f8674f7
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/pxa27x-keypad.txt
@@ -0,0 +1,60 @@
+* Marvell PXA Keypad controller
+
+Required Properties
+- compatible : should be "marvell,pxa27x-keypad"
+- reg : Address and length of the register set for the device
+- interrupts : The interrupt for the keypad controller
+- marvell,debounce-interval : How long time the key will be
+ recognized when it is pressed. It is a u32 value, and bit[31:16]
+ is debounce interval for direct key and bit[15:0] is debounce
+ interval for matrix key. The value is in binary number of 2ms
+
+Optional Properties For Matrix Keyes
+Please refer to matrix-keymap.txt
+
+Optional Properties for Direct Keyes
+- marvell,direct-key-count : How many direct keyes are used.
+- marvell,direct-key-mask : The mask indicates which keyes
+ are used. If bit[X] of the mask is set, the direct key X
+ is used.
+- marvell,direct-key-low-active : Direct key status register
+ tells the level of pins that connects to the direct keyes.
+ When this property is set, it means that when the pin level
+ is low, the key is pressed(active).
+- marvell,direct-key-map : It is a u16 array. Each item indicates
+ the linux key-code for the direct key.
+
+Optional Properties For Rotary
+- marvell,rotary0 : It is a u32 value. Bit[31:16] is the
+ linux key-code for rotary up. Bit[15:0] is the linux key-code
+ for rotary down. It is for rotary 0.
+- marvell,rotary1 : Same as marvell,rotary0. It is for rotary 1.
+- marvell,rotary-rel-key : When rotary is used for relative axes
+ in the device, the value indicates the key-code for relative
+ axes measurement in the device. It is a u32 value. Bit[31:16]
+ is for rotary 1, and Bit[15:0] is for rotary 0.
+
+Examples:
+ keypad: keypad@d4012000 {
+ keypad,num-rows = <3>;
+ keypad,num-columns = <5>;
+ linux,keymap = <0x0000000e /* KEY_BACKSPACE */
+ 0x0001006b /* KEY_END */
+ 0x00020061 /* KEY_RIGHTCTRL */
+ 0x0003000b /* KEY_0 */
+ 0x00040002 /* KEY_1 */
+ 0x0100008b /* KEY_MENU */
+ 0x01010066 /* KEY_HOME */
+ 0x010200e7 /* KEY_SEND */
+ 0x01030009 /* KEY_8 */
+ 0x0104000a /* KEY_9 */
+ 0x02000160 /* KEY_OK */
+ 0x02010003 /* KEY_2 */
+ 0x02020004 /* KEY_3 */
+ 0x02030005 /* KEY_4 */
+ 0x02040006>; /* KEY_5 */
+ marvell,rotary0 = <0x006c0067>; /* KEY_UP & KEY_DOWN */
+ marvell,direct-key-count = <1>;
+ marvell,direct-key-map = <0x001c>;
+ marvell,debounce-interval = <0x001e001e>;
+ };
diff --git a/Documentation/devicetree/bindings/input/samsung-keypad.txt b/Documentation/devicetree/bindings/input/samsung-keypad.txt
index ce3e394..942d071 100644
--- a/Documentation/devicetree/bindings/input/samsung-keypad.txt
+++ b/Documentation/devicetree/bindings/input/samsung-keypad.txt
@@ -25,14 +25,6 @@
- samsung,keypad-num-columns: Number of column lines connected to the
keypad controller.
-- row-gpios: List of gpios used as row lines. The gpio specifier for
- this property depends on the gpio controller to which these row lines
- are connected.
-
-- col-gpios: List of gpios used as column lines. The gpio specifier for
- this property depends on the gpio controller to which these column
- lines are connected.
-
- Keys represented as child nodes: Each key connected to the keypad
controller is represented as a child node to the keypad controller
device node and should include the following properties.
@@ -41,6 +33,9 @@
- linux,code: the key-code to be reported when the key is pressed
and released.
+- pinctrl-0: Should specify pin control groups used for this controller.
+- pinctrl-names: Should contain only one value - "default".
+
Optional Properties specific to linux:
- linux,keypad-no-autorepeat: do no enable autorepeat feature.
- linux,keypad-wakeup: use any event on keypad as wakeup event.
@@ -56,17 +51,8 @@
linux,input-no-autorepeat;
linux,input-wakeup;
- row-gpios = <&gpx2 0 3 3 0
- &gpx2 1 3 3 0>;
-
- col-gpios = <&gpx1 0 3 0 0
- &gpx1 1 3 0 0
- &gpx1 2 3 0 0
- &gpx1 3 3 0 0
- &gpx1 4 3 0 0
- &gpx1 5 3 0 0
- &gpx1 6 3 0 0
- &gpx1 7 3 0 0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&keypad_rows &keypad_columns>;
key_1 {
keypad,row = <0>;
diff --git a/Documentation/devicetree/bindings/input/tca8418_keypad.txt b/Documentation/devicetree/bindings/input/tca8418_keypad.txt
index 2a1538f..2551850 100644
--- a/Documentation/devicetree/bindings/input/tca8418_keypad.txt
+++ b/Documentation/devicetree/bindings/input/tca8418_keypad.txt
@@ -1,8 +1,10 @@
+This binding is based on the matrix-keymap binding with the following
+changes:
+
+keypad,num-rows and keypad,num-columns are required.
Required properties:
- compatible: "ti,tca8418"
- reg: the I2C address
- interrupts: IRQ line number, should trigger on falling edge
-- keypad,num-rows: The number of rows
-- keypad,num-columns: The number of columns
- linux,keymap: Keys definitions, see keypad-matrix.
diff --git a/Documentation/devicetree/bindings/input/ti,nspire-keypad.txt b/Documentation/devicetree/bindings/input/ti,nspire-keypad.txt
new file mode 100644
index 0000000..513d94d
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/ti,nspire-keypad.txt
@@ -0,0 +1,60 @@
+TI-NSPIRE Keypad
+
+Required properties:
+- compatible: Compatible property value should be "ti,nspire-keypad".
+
+- reg: Physical base address of the peripheral and length of memory mapped
+ region.
+
+- interrupts: The interrupt number for the peripheral.
+
+- scan-interval: How often to scan in us. Based on a APB speed of 33MHz, the
+ maximum and minimum delay time is ~2000us and ~500us respectively
+
+- row-delay: How long to wait before scanning each row.
+
+- clocks: The clock this peripheral is attached to.
+
+- linux,keymap: The keymap to use
+ (see Documentation/devicetree/bindings/input/matrix-keymap.txt)
+
+Optional properties:
+- active-low: Specify that the keypad is active low (i.e. logical low signifies
+ a key press).
+
+Example:
+
+input {
+ compatible = "ti,nspire-keypad";
+ reg = <0x900E0000 0x1000>;
+ interrupts = <16>;
+
+ scan-interval = <1000>;
+ row-delay = <200>;
+
+ clocks = <&apb_pclk>;
+
+ linux,keymap = <
+ 0x0000001c 0x0001001c 0x00040039
+ 0x0005002c 0x00060015 0x0007000b
+ 0x0008000f 0x0100002d 0x01010011
+ 0x0102002f 0x01030004 0x01040016
+ 0x01050014 0x0106001f 0x01070002
+ 0x010a006a 0x02000013 0x02010010
+ 0x02020019 0x02030007 0x02040018
+ 0x02050031 0x02060032 0x02070005
+ 0x02080028 0x0209006c 0x03000026
+ 0x03010025 0x03020024 0x0303000a
+ 0x03040017 0x03050023 0x03060022
+ 0x03070008 0x03080035 0x03090069
+ 0x04000021 0x04010012 0x04020020
+ 0x0404002e 0x04050030 0x0406001e
+ 0x0407000d 0x04080037 0x04090067
+ 0x05010038 0x0502000c 0x0503001b
+ 0x05040034 0x0505001a 0x05060006
+ 0x05080027 0x0509000e 0x050a006f
+ 0x0600002b 0x0602004e 0x06030068
+ 0x06040003 0x0605006d 0x06060009
+ 0x06070001 0x0609000f 0x0708002a
+ 0x0709001d 0x070a0033 >;
+};
diff --git a/Documentation/devicetree/bindings/input/touchscreen/auo_pixcir_ts.txt b/Documentation/devicetree/bindings/input/touchscreen/auo_pixcir_ts.txt
new file mode 100644
index 0000000..f40f21c
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/auo_pixcir_ts.txt
@@ -0,0 +1,30 @@
+* AUO in-cell touchscreen controller using Pixcir sensors
+
+Required properties:
+- compatible: must be "auo,auo_pixcir_ts"
+- reg: I2C address of the chip
+- interrupts: interrupt to which the chip is connected
+- gpios: gpios the chip is connected to
+ first one is the interrupt gpio and second one the reset gpio
+- x-size: horizontal resolution of touchscreen
+- y-size: vertical resolution of touchscreen
+
+Example:
+
+ i2c@00000000 {
+ /* ... */
+
+ auo_pixcir_ts@5c {
+ compatible = "auo,auo_pixcir_ts";
+ reg = <0x5c>;
+ interrupts = <2 0>;
+
+ gpios = <&gpf 2 0 2>, /* INT */
+ <&gpf 5 1 0>; /* RST */
+
+ x-size = <800>;
+ y-size = <600>;
+ };
+
+ /* ... */
+ };
diff --git a/Documentation/devicetree/bindings/input/touchscreen/sitronix-st1232.txt b/Documentation/devicetree/bindings/input/touchscreen/sitronix-st1232.txt
new file mode 100644
index 0000000..64ad48b
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/sitronix-st1232.txt
@@ -0,0 +1,24 @@
+* Sitronix st1232 touchscreen controller
+
+Required properties:
+- compatible: must be "sitronix,st1232"
+- reg: I2C address of the chip
+- interrupts: interrupt to which the chip is connected
+
+Optional properties:
+- gpios: a phandle to the reset GPIO
+
+Example:
+
+ i2c@00000000 {
+ /* ... */
+
+ touchscreen@55 {
+ compatible = "sitronix,st1232";
+ reg = <0x55>;
+ interrupts = <2 0>;
+ gpios = <&gpio1 166 0>;
+ };
+
+ /* ... */
+ };
diff --git a/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt b/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
new file mode 100644
index 0000000..491c97b
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
@@ -0,0 +1,44 @@
+* TI - TSC ADC (Touschscreen and analog digital converter)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Required properties:
+- child "tsc"
+ ti,wires: Wires refer to application modes i.e. 4/5/8 wire touchscreen
+ support on the platform.
+ ti,x-plate-resistance: X plate resistance
+ ti,coordiante-readouts: The sequencer supports a total of 16
+ programmable steps each step is used to
+ read a single coordinate. A single
+ readout is enough but multiple reads can
+ increase the quality.
+ A value of 5 means, 5 reads for X, 5 for
+ Y and 2 for Z (always). This utilises 12
+ of the 16 software steps available. The
+ remaining 4 can be used by the ADC.
+ ti,wire-config: Different boards could have a different order for
+ connecting wires on touchscreen. We need to provide an
+ 8 bit number where in the 1st four bits represent the
+ analog lines and the next 4 bits represent positive/
+ negative terminal on that input line. Notations to
+ represent the input lines and terminals resoectively
+ is as follows:
+ AIN0 = 0, AIN1 = 1 and so on till AIN7 = 7.
+ XP = 0, XN = 1, YP = 2, YN = 3.
+- child "adc"
+ ti,adc-channels: List of analog inputs available for ADC.
+ AIN0 = 0, AIN1 = 1 and so on till AIN7 = 7.
+
+Example:
+ tscadc: tscadc@44e0d000 {
+ compatible = "ti,am3359-tscadc";
+ tsc {
+ ti,wires = <4>;
+ ti,x-plate-resistance = <200>;
+ ti,coordiante-readouts = <5>;
+ ti,wire-config = <0x00 0x11 0x22 0x33>;
+ };
+
+ adc {
+ ti,adc-channels = <4 5 6 7>;
+ };
+ }
diff --git a/Documentation/devicetree/bindings/interrupt-controller/abilis,tb10x-ictl.txt b/Documentation/devicetree/bindings/interrupt-controller/abilis,tb10x-ictl.txt
new file mode 100644
index 0000000..9d52d5a
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/abilis,tb10x-ictl.txt
@@ -0,0 +1,38 @@
+TB10x Top Level Interrupt Controller
+====================================
+
+The Abilis TB10x SOC contains a custom interrupt controller. It performs
+one-to-one mapping of external interrupt sources to CPU interrupts and
+provides support for reconfigurable trigger modes.
+
+Required properties
+-------------------
+
+- compatible: Should be "abilis,tb10x-ictl"
+- reg: specifies physical base address and size of register range.
+- interrupt-congroller: Identifies the node as an interrupt controller.
+- #interrupt cells: Specifies the number of cells used to encode an interrupt
+ source connected to this controller. The value shall be 2.
+- interrupt-parent: Specifies the parent interrupt controller.
+- interrupts: Specifies the list of interrupt lines which are handled by
+ the interrupt controller in the parent controller's notation. Interrupts
+ are mapped one-to-one to parent interrupts.
+
+Example
+-------
+
+intc: interrupt-controller { /* Parent interrupt controller */
+ interrupt-controller;
+ #interrupt-cells = <1>; /* For example below */
+ /* ... */
+};
+
+tb10x_ictl: pic@2000 { /* TB10x interrupt controller */
+ compatible = "abilis,tb10x-ictl";
+ reg = <0x2000 0x20>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupt-parent = <&intc>;
+ interrupts = <5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
+ 20 21 22 23 24 25 26 27 28 29 30 31>;
+};
diff --git a/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun4i-ic.txt b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun4i-ic.txt
new file mode 100644
index 0000000..57edb30
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun4i-ic.txt
@@ -0,0 +1,21 @@
+Allwinner Sunxi Interrupt Controller
+
+Required properties:
+
+- compatible : should be "allwinner,sun4i-ic"
+- reg : Specifies base physical address and size of the registers.
+- interrupt-controller : Identifies the node as an interrupt controller
+- #interrupt-cells : Specifies the number of cells needed to encode an
+ interrupt source. The value shall be 1.
+
+For the valid interrupt sources for your SoC, see the documentation in
+sunxi/<soc>.txt
+
+Example:
+
+intc: interrupt-controller {
+ compatible = "allwinner,sun4i-ic";
+ reg = <0x01c20400 0x400>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+};
diff --git a/Documentation/devicetree/bindings/interrupt-controller/allwinner,sunxi-ic.txt b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sunxi-ic.txt
deleted file mode 100644
index 7f9fb85..0000000
--- a/Documentation/devicetree/bindings/interrupt-controller/allwinner,sunxi-ic.txt
+++ /dev/null
@@ -1,104 +0,0 @@
-Allwinner Sunxi Interrupt Controller
-
-Required properties:
-
-- compatible : should be "allwinner,sunxi-ic"
-- reg : Specifies base physical address and size of the registers.
-- interrupt-controller : Identifies the node as an interrupt controller
-- #interrupt-cells : Specifies the number of cells needed to encode an
- interrupt source. The value shall be 1.
-
-The interrupt sources are as follows:
-
-0: ENMI
-1: UART0
-2: UART1
-3: UART2
-4: UART3
-5: IR0
-6: IR1
-7: I2C0
-8: I2C1
-9: I2C2
-10: SPI0
-11: SPI1
-12: SPI2
-13: SPDIF
-14: AC97
-15: TS
-16: I2S
-17: UART4
-18: UART5
-19: UART6
-20: UART7
-21: KEYPAD
-22: TIMER0
-23: TIMER1
-24: TIMER2
-25: TIMER3
-26: CAN
-27: DMA
-28: PIO
-29: TOUCH_PANEL
-30: AUDIO_CODEC
-31: LRADC
-32: SDMC0
-33: SDMC1
-34: SDMC2
-35: SDMC3
-36: MEMSTICK
-37: NAND
-38: USB0
-39: USB1
-40: USB2
-41: SCR
-42: CSI0
-43: CSI1
-44: LCDCTRL0
-45: LCDCTRL1
-46: MP
-47: DEFEBE0
-48: DEFEBE1
-49: PMU
-50: SPI3
-51: TZASC
-52: PATA
-53: VE
-54: SS
-55: EMAC
-56: SATA
-57: GPS
-58: HDMI
-59: TVE
-60: ACE
-61: TVD
-62: PS2_0
-63: PS2_1
-64: USB3
-65: USB4
-66: PLE_PFM
-67: TIMER4
-68: TIMER5
-69: GPU_GP
-70: GPU_GPMMU
-71: GPU_PP0
-72: GPU_PPMMU0
-73: GPU_PMU
-74: GPU_RSV0
-75: GPU_RSV1
-76: GPU_RSV2
-77: GPU_RSV3
-78: GPU_RSV4
-79: GPU_RSV5
-80: GPU_RSV6
-82: SYNC_TIMER0
-83: SYNC_TIMER1
-
-Example:
-
-intc: interrupt-controller {
- compatible = "allwinner,sunxi-ic";
- reg = <0x01c20400 0x400>;
- interrupt-controller;
- #interrupt-cells = <2>;
-};
diff --git a/Documentation/devicetree/bindings/interrupt-controller/marvell,orion-intc.txt b/Documentation/devicetree/bindings/interrupt-controller/marvell,orion-intc.txt
new file mode 100644
index 0000000..2c11ac7
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/marvell,orion-intc.txt
@@ -0,0 +1,48 @@
+Marvell Orion SoC interrupt controllers
+
+* Main interrupt controller
+
+Required properties:
+- compatible: shall be "marvell,orion-intc"
+- reg: base address(es) of interrupt registers starting with CAUSE register
+- interrupt-controller: identifies the node as an interrupt controller
+- #interrupt-cells: number of cells to encode an interrupt source, shall be 1
+
+The interrupt sources map to the corresponding bits in the interrupt
+registers, i.e.
+- 0 maps to bit 0 of first base address,
+- 1 maps to bit 1 of first base address,
+- 32 maps to bit 0 of second base address, and so on.
+
+Example:
+ intc: interrupt-controller {
+ compatible = "marvell,orion-intc";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ /* Dove has 64 first level interrupts */
+ reg = <0x20200 0x10>, <0x20210 0x10>;
+ };
+
+* Bridge interrupt controller
+
+Required properties:
+- compatible: shall be "marvell,orion-bridge-intc"
+- reg: base address of bridge interrupt registers starting with CAUSE register
+- interrupts: bridge interrupt of the main interrupt controller
+- interrupt-controller: identifies the node as an interrupt controller
+- #interrupt-cells: number of cells to encode an interrupt source, shall be 1
+
+Optional properties:
+- marvell,#interrupts: number of interrupts provided by bridge interrupt
+ controller, defaults to 32 if not set
+
+Example:
+ bridge_intc: interrupt-controller {
+ compatible = "marvell,orion-bridge-intc";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ reg = <0x20110 0x8>;
+ interrupts = <0>;
+ /* Dove bridge provides 5 interrupts */
+ marvell,#interrupts = <5>;
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt b/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt
new file mode 100644
index 0000000..1f8b0c5
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt
@@ -0,0 +1,16 @@
+DT bindings for the R-/SH-Mobile irqpin controller
+
+Required properties:
+
+- compatible: has to be "renesas,intc-irqpin"
+- #interrupt-cells: has to be <2>: an interrupt index and flags, as defined in
+ interrupts.txt in this directory
+
+Optional properties:
+
+- any properties, listed in interrupts.txt, and any standard resource allocation
+ properties
+- sense-bitfield-width: width of a single sense bitfield in the SENSE register,
+ if different from the default 4 bits
+- control-parent: disable and enable interrupts on the parent interrupt
+ controller, needed for some broken implementations
diff --git a/Documentation/devicetree/bindings/interrupt-controller/samsung,s3c24xx-irq.txt b/Documentation/devicetree/bindings/interrupt-controller/samsung,s3c24xx-irq.txt
new file mode 100644
index 0000000..c54c5a9
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/samsung,s3c24xx-irq.txt
@@ -0,0 +1,53 @@
+Samsung S3C24XX Interrupt Controllers
+
+The S3C24XX SoCs contain a custom set of interrupt controllers providing a
+varying number of interrupt sources. The set consists of a main- and sub-
+controller and on newer SoCs even a second main controller.
+
+Required properties:
+- compatible: Compatible property value should be "samsung,s3c2410-irq"
+ for machines before s3c2416 and "samsung,s3c2416-irq" for s3c2416 and later.
+
+- reg: Physical base address of the controller and length of memory mapped
+ region.
+
+- interrupt-controller : Identifies the node as an interrupt controller
+
+- #interrupt-cells : Specifies the number of cells needed to encode an
+ interrupt source. The value shall be 4 and interrupt descriptor shall
+ have the following format:
+ <ctrl_num parent_irq ctrl_irq type>
+
+ ctrl_num contains the controller to use:
+ - 0 ... main controller
+ - 1 ... sub controller
+ - 2 ... second main controller on s3c2416 and s3c2450
+ parent_irq contains the parent bit in the main controller and will be
+ ignored in main controllers
+ ctrl_irq contains the interrupt bit of the controller
+ type contains the trigger type to use
+
+Example:
+
+ interrupt-controller@4a000000 {
+ compatible = "samsung,s3c2410-irq";
+ reg = <0x4a000000 0x100>;
+ interrupt-controller;
+ #interrupt-cells=<4>;
+ };
+
+ [...]
+
+ serial@50000000 {
+ compatible = "samsung,s3c2410-uart";
+ reg = <0x50000000 0x4000>;
+ interrupt-parent = <&subintc>;
+ interrupts = <1 28 0 4>, <1 28 1 4>;
+ };
+
+ rtc@57000000 {
+ compatible = "samsung,s3c2410-rtc";
+ reg = <0x57000000 0x100>;
+ interrupt-parent = <&intc>;
+ interrupts = <0 30 0 3>, <0 8 0 3>;
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/sunxi/sun4i-a10.txt b/Documentation/devicetree/bindings/interrupt-controller/sunxi/sun4i-a10.txt
new file mode 100644
index 0000000..76b98c8
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/sunxi/sun4i-a10.txt
@@ -0,0 +1,89 @@
+Allwinner A10 (sun4i) interrupt sources
+---------------------------------------
+
+The interrupt sources available for the Allwinner A10 SoC are the
+following one:
+
+0: ENMI
+1: UART0
+2: UART1
+3: UART2
+4: UART3
+5: IR0
+6: IR1
+7: I2C0
+8: I2C1
+9: I2C2
+10: SPI0
+11: SPI1
+12: SPI2
+13: SPDIF
+14: AC97
+15: TS
+16: I2S
+17: UART4
+18: UART5
+19: UART6
+20: UART7
+21: KEYPAD
+22: TIMER0
+23: TIMER1
+24: TIMER2
+25: TIMER3
+26: CAN
+27: DMA
+28: PIO
+29: TOUCH_PANEL
+30: AUDIO_CODEC
+31: LRADC
+32: MMC0
+33: MMC1
+34: MMC2
+35: MMC3
+36: MEMSTICK
+37: NAND
+38: USB0
+39: USB1
+40: USB2
+41: SCR
+42: CSI0
+43: CSI1
+44: LCDCTRL0
+45: LCDCTRL1
+46: MP
+47: DEFEBE0
+48: DEFEBE1
+49: PMU
+50: SPI3
+51: TZASC
+52: PATA
+53: VE
+54: SS
+55: EMAC
+56: SATA
+57: GPS
+58: HDMI
+59: TVE
+60: ACE
+61: TVD
+62: PS2_0
+63: PS2_1
+64: USB3
+65: USB4
+66: PLE_PFM
+67: TIMER4
+68: TIMER5
+69: GPU_GP
+70: GPU_GPMMU
+71: GPU_PP0
+72: GPU_PPMMU0
+73: GPU_PMU
+74: GPU_RSV0
+75: GPU_RSV1
+76: GPU_RSV2
+77: GPU_RSV3
+78: GPU_RSV4
+79: GPU_RSV5
+80: GPU_RSV6
+82: SYNC_TIMER0
+83: SYNC_TIMER1
diff --git a/Documentation/devicetree/bindings/interrupt-controller/sunxi/sun5i-a13.txt b/Documentation/devicetree/bindings/interrupt-controller/sunxi/sun5i-a13.txt
new file mode 100644
index 0000000..2ec3b5c
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/sunxi/sun5i-a13.txt
@@ -0,0 +1,55 @@
+Allwinner A13 (sun5i) interrupt sources
+---------------------------------------
+
+The interrupt sources available for the Allwinner A13 SoC are the
+following one:
+
+0: ENMI
+2: UART1
+4: UART3
+5: IR
+7: I2C0
+8: I2C1
+9: I2C2
+10: SPI0
+11: SPI1
+12: SPI2
+22: TIMER0
+23: TIMER1
+24: TIMER2
+25: TIMER3
+27: DMA
+28: PIO
+29: TOUCH_PANEL
+30: AUDIO_CODEC
+31: LRADC
+32: MMC0
+33: MMC1
+34: MMC2
+37: NAND
+38: USB OTG
+39: USB EHCI
+40: USB OHCI
+42: CSI
+44: LCDCTRL
+47: DEFEBE
+49: PMU
+53: VE
+54: SS
+66: PLE_PFM
+67: TIMER4
+68: TIMER5
+69: GPU_GP
+70: GPU_GPMMU
+71: GPU_PP0
+72: GPU_PPMMU0
+73: GPU_PMU
+74: GPU_RSV0
+75: GPU_RSV1
+76: GPU_RSV2
+77: GPU_RSV3
+78: GPU_RSV4
+79: GPU_RSV5
+80: GPU_RSV6
+82: SYNC_TIMER0
+83: SYNC_TIMER1
diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
new file mode 100644
index 0000000..e34c6cd
--- /dev/null
+++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
@@ -0,0 +1,70 @@
+* ARM System MMU Architecture Implementation
+
+ARM SoCs may contain an implementation of the ARM System Memory
+Management Unit Architecture, which can be used to provide 1 or 2 stages
+of address translation to bus masters external to the CPU.
+
+The SMMU may also raise interrupts in response to various fault
+conditions.
+
+** System MMU required properties:
+
+- compatible : Should be one of:
+
+ "arm,smmu-v1"
+ "arm,smmu-v2"
+ "arm,mmu-400"
+ "arm,mmu-500"
+
+ depending on the particular implementation and/or the
+ version of the architecture implemented.
+
+- reg : Base address and size of the SMMU.
+
+- #global-interrupts : The number of global interrupts exposed by the
+ device.
+
+- interrupts : Interrupt list, with the first #global-irqs entries
+ corresponding to the global interrupts and any
+ following entries corresponding to context interrupts,
+ specified in order of their indexing by the SMMU.
+
+ For SMMUv2 implementations, there must be exactly one
+ interrupt per context bank. In the case of a single,
+ combined interrupt, it must be listed multiple times.
+
+- mmu-masters : A list of phandles to device nodes representing bus
+ masters for which the SMMU can provide a translation
+ and their corresponding StreamIDs (see example below).
+ Each device node linked from this list must have a
+ "#stream-id-cells" property, indicating the number of
+ StreamIDs associated with it.
+
+** System MMU optional properties:
+
+- smmu-parent : When multiple SMMUs are chained together, this
+ property can be used to provide a phandle to the
+ parent SMMU (that is the next SMMU on the path going
+ from the mmu-masters towards memory) node for this
+ SMMU.
+
+Example:
+
+ smmu {
+ compatible = "arm,smmu-v1";
+ reg = <0xba5e0000 0x10000>;
+ #global-interrupts = <2>;
+ interrupts = <0 32 4>,
+ <0 33 4>,
+ <0 34 4>, /* This is the first context interrupt */
+ <0 35 4>,
+ <0 36 4>,
+ <0 37 4>;
+
+ /*
+ * Two DMA controllers, the first with two StreamIDs (0xd01d
+ * and 0xd01e) and the second with only one (0xd11c).
+ */
+ mmu-masters = <&dma0 0xd01d 0xd01e>,
+ <&dma1 0xd11c>;
+ };
diff --git a/Documentation/devicetree/bindings/leds/leds-lp55xx.txt b/Documentation/devicetree/bindings/leds/leds-lp55xx.txt
new file mode 100644
index 0000000..d517688
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-lp55xx.txt
@@ -0,0 +1,147 @@
+Binding for TI/National Semiconductor LP55xx Led Drivers
+
+Required properties:
+- compatible: "national,lp5521" or "national,lp5523" or "ti,lp5562"
+- reg: I2C slave address
+- clock-mode: Input clock mode, (0: automode, 1: internal, 2: external)
+
+Each child has own specific current settings
+- led-cur: Current setting at each led channel (mA x10, 0 if led is not connected)
+- max-cur: Maximun current at each led channel.
+
+Optional properties:
+- label: Used for naming LEDs
+
+Alternatively, each child can have specific channel name
+- chan-name: Name of each channel name
+
+example 1) LP5521
+3 LED channels, external clock used. Channel names are 'lp5521_pri:channel0',
+'lp5521_pri:channel1' and 'lp5521_pri:channel2'
+
+lp5521@32 {
+ compatible = "national,lp5521";
+ reg = <0x32>;
+ label = "lp5521_pri";
+ clock-mode = /bits/ 8 <2>;
+
+ chan0 {
+ led-cur = /bits/ 8 <0x2f>;
+ max-cur = /bits/ 8 <0x5f>;
+ };
+
+ chan1 {
+ led-cur = /bits/ 8 <0x2f>;
+ max-cur = /bits/ 8 <0x5f>;
+ };
+
+ chan2 {
+ led-cur = /bits/ 8 <0x2f>;
+ max-cur = /bits/ 8 <0x5f>;
+ };
+};
+
+example 2) LP5523
+9 LED channels with specific name. Internal clock used.
+The I2C slave address is configurable with ASEL1 and ASEL0 pins.
+Available addresses are 32/33/34/35h.
+
+ASEL1 ASEL0 Address
+-------------------------
+ GND GND 32h
+ GND VEN 33h
+ VEN GND 34h
+ VEN VEN 35h
+
+lp5523@32 {
+ compatible = "national,lp5523";
+ reg = <0x32>;
+ clock-mode = /bits/ 8 <1>;
+
+ chan0 {
+ chan-name = "d1";
+ led-cur = /bits/ 8 <0x14>;
+ max-cur = /bits/ 8 <0x20>;
+ };
+
+ chan1 {
+ chan-name = "d2";
+ led-cur = /bits/ 8 <0x14>;
+ max-cur = /bits/ 8 <0x20>;
+ };
+
+ chan2 {
+ chan-name = "d3";
+ led-cur = /bits/ 8 <0x14>;
+ max-cur = /bits/ 8 <0x20>;
+ };
+
+ chan3 {
+ chan-name = "d4";
+ led-cur = /bits/ 8 <0x14>;
+ max-cur = /bits/ 8 <0x20>;
+ };
+
+ chan4 {
+ chan-name = "d5";
+ led-cur = /bits/ 8 <0x14>;
+ max-cur = /bits/ 8 <0x20>;
+ };
+
+ chan5 {
+ chan-name = "d6";
+ led-cur = /bits/ 8 <0x14>;
+ max-cur = /bits/ 8 <0x20>;
+ };
+
+ chan6 {
+ chan-name = "d7";
+ led-cur = /bits/ 8 <0x14>;
+ max-cur = /bits/ 8 <0x20>;
+ };
+
+ chan7 {
+ chan-name = "d8";
+ led-cur = /bits/ 8 <0x14>;
+ max-cur = /bits/ 8 <0x20>;
+ };
+
+ chan8 {
+ chan-name = "d9";
+ led-cur = /bits/ 8 <0x14>;
+ max-cur = /bits/ 8 <0x20>;
+ };
+};
+
+example 3) LP5562
+4 channels are defined.
+
+lp5562@30 {
+ compatible = "ti,lp5562";
+ reg = <0x30>;
+ clock-mode = /bits/8 <2>;
+
+ chan0 {
+ chan-name = "R";
+ led-cur = /bits/ 8 <0x20>;
+ max-cur = /bits/ 8 <0x60>;
+ };
+
+ chan1 {
+ chan-name = "G";
+ led-cur = /bits/ 8 <0x20>;
+ max-cur = /bits/ 8 <0x60>;
+ };
+
+ chan2 {
+ chan-name = "B";
+ led-cur = /bits/ 8 <0x20>;
+ max-cur = /bits/ 8 <0x60>;
+ };
+
+ chan3 {
+ chan-name = "W";
+ led-cur = /bits/ 8 <0x20>;
+ max-cur = /bits/ 8 <0x60>;
+ };
+};
diff --git a/Documentation/devicetree/bindings/gpio/leds-ns2.txt b/Documentation/devicetree/bindings/leds/leds-ns2.txt
similarity index 100%
rename from Documentation/devicetree/bindings/gpio/leds-ns2.txt
rename to Documentation/devicetree/bindings/leds/leds-ns2.txt
diff --git a/Documentation/devicetree/bindings/leds/leds-pwm.txt b/Documentation/devicetree/bindings/leds/leds-pwm.txt
new file mode 100644
index 0000000..7297107
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-pwm.txt
@@ -0,0 +1,48 @@
+LED connected to PWM
+
+Required properties:
+- compatible : should be "pwm-leds".
+
+Each LED is represented as a sub-node of the pwm-leds device. Each
+node's name represents the name of the corresponding LED.
+
+LED sub-node properties:
+- pwms : PWM property to point to the PWM device (phandle)/port (id) and to
+ specify the period time to be used: <&phandle id period_ns>;
+- pwm-names : (optional) Name to be used by the PWM subsystem for the PWM device
+ For the pwms and pwm-names property please refer to:
+ Documentation/devicetree/bindings/pwm/pwm.txt
+- max-brightness : Maximum brightness possible for the LED
+- label : (optional)
+ see Documentation/devicetree/bindings/leds/common.txt
+- linux,default-trigger : (optional)
+ see Documentation/devicetree/bindings/leds/common.txt
+
+Example:
+
+twl_pwm: pwm {
+ /* provides two PWMs (id 0, 1 for PWM1 and PWM2) */
+ compatible = "ti,twl6030-pwm";
+ #pwm-cells = <2>;
+};
+
+twl_pwmled: pwmled {
+ /* provides one PWM (id 0 for Charing indicator LED) */
+ compatible = "ti,twl6030-pwmled";
+ #pwm-cells = <2>;
+};
+
+pwmleds {
+ compatible = "pwm-leds";
+ kpad {
+ label = "omap4::keypad";
+ pwms = <&twl_pwm 0 7812500>;
+ max-brightness = <127>;
+ };
+
+ charging {
+ label = "omap4:green:chrg";
+ pwms = <&twl_pwmled 0 7812500>;
+ max-brightness = <255>;
+ };
+};
diff --git a/Documentation/devicetree/bindings/leds/tca6507.txt b/Documentation/devicetree/bindings/leds/tca6507.txt
new file mode 100644
index 0000000..80ff3df
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/tca6507.txt
@@ -0,0 +1,33 @@
+LEDs connected to tca6507
+
+Required properties:
+- compatible : should be : "ti,tca6507".
+
+Each led is represented as a sub-node of the ti,tca6507 device.
+
+LED sub-node properties:
+- label : (optional) see Documentation/devicetree/bindings/leds/common.txt
+- reg : number of LED line (could be from 0 to 6)
+- linux,default-trigger : (optional)
+ see Documentation/devicetree/bindings/leds/common.txt
+
+Examples:
+
+tca6507@45 {
+ compatible = "ti,tca6507";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x45>;
+
+ led0: red-aux@0 {
+ label = "red:aux";
+ reg = <0x0>;
+ };
+
+ led1: green-aux@1 {
+ label = "green:aux";
+ reg = <0x5>;
+ linux,default-trigger = "default-on";
+ };
+};
+
diff --git a/Documentation/devicetree/bindings/marvell.txt b/Documentation/devicetree/bindings/marvell.txt
index f1533d9..f7a0da6 100644
--- a/Documentation/devicetree/bindings/marvell.txt
+++ b/Documentation/devicetree/bindings/marvell.txt
@@ -115,6 +115,9 @@
- compatible : "marvell,mv64360-eth-block"
- reg : Offset and length of the register set for this block
+ Optional properties:
+ - clocks : Phandle to the clock control device and gate bit
+
Example Discovery Ethernet block node:
ethernet-block@2000 {
#address-cells = <1>;
diff --git a/Documentation/devicetree/bindings/media/coda.txt b/Documentation/devicetree/bindings/media/coda.txt
new file mode 100644
index 0000000..2865d04
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/coda.txt
@@ -0,0 +1,30 @@
+Chips&Media Coda multi-standard codec IP
+========================================
+
+Coda codec IPs are present in i.MX SoCs in various versions,
+called VPU (Video Processing Unit).
+
+Required properties:
+- compatible : should be "fsl,<chip>-src" for i.MX SoCs:
+ (a) "fsl,imx27-vpu" for CodaDx6 present in i.MX27
+ (b) "fsl,imx53-vpu" for CODA7541 present in i.MX53
+ (c) "fsl,imx6q-vpu" for CODA960 present in i.MX6q
+- reg: should be register base and length as documented in the
+ SoC reference manual
+- interrupts : Should contain the VPU interrupt. For CODA960,
+ a second interrupt is needed for the MJPEG unit.
+- clocks : Should contain the ahb and per clocks, in the order
+ determined by the clock-names property.
+- clock-names : Should be "ahb", "per"
+- iram : phandle pointing to the SRAM device node
+
+Example:
+
+vpu: vpu@63ff4000 {
+ compatible = "fsl,imx53-vpu";
+ reg = <0x63ff4000 0x1000>;
+ interrupts = <9>;
+ clocks = <&clks 63>, <&clks 63>;
+ clock-names = "ahb", "per";
+ iram = <&ocram>;
+};
diff --git a/Documentation/devicetree/bindings/media/exynos-fimc-lite.txt b/Documentation/devicetree/bindings/media/exynos-fimc-lite.txt
new file mode 100644
index 0000000..0bf6fb7
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/exynos-fimc-lite.txt
@@ -0,0 +1,16 @@
+Exynos4x12/Exynos5 SoC series camera host interface (FIMC-LITE)
+
+Required properties:
+
+- compatible : should be one of:
+ "samsung,exynos4212-fimc-lite" for Exynos4212/4412 SoCs,
+ "samsung,exynos5250-fimc-lite" for Exynos5250 compatible
+ devices;
+- reg : physical base address and size of the device memory mapped
+ registers;
+- interrupts : should contain FIMC-LITE interrupt;
+- clocks : FIMC LITE gate clock should be specified in this property.
+- clock-names : should contain "flite" entry.
+
+Each FIMC device should have an alias in the aliases node, in the form of
+fimc-lite<n>, where <n> is an integer specifying the IP block instance.
diff --git a/Documentation/devicetree/bindings/media/exynos4-fimc-is.txt b/Documentation/devicetree/bindings/media/exynos4-fimc-is.txt
new file mode 100644
index 0000000..55c9ad6
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/exynos4-fimc-is.txt
@@ -0,0 +1,49 @@
+Exynos4x12 SoC series Imaging Subsystem (FIMC-IS)
+
+The FIMC-IS is a subsystem for processing image signal from an image sensor.
+The Exynos4x12 SoC series FIMC-IS V1.5 comprises of a dedicated ARM Cortex-A5
+processor, ISP, DRC and FD IP blocks and peripheral devices such as UART, I2C
+and SPI bus controllers, PWM and ADC.
+
+fimc-is node
+------------
+
+Required properties:
+- compatible : should be "samsung,exynos4212-fimc-is" for Exynos4212 and
+ Exynos4412 SoCs;
+- reg : physical base address and length of the registers set;
+- interrupts : must contain two FIMC-IS interrupts, in order: ISP0, ISP1;
+- clocks : list of clock specifiers, corresponding to entries in
+ clock-names property;
+- clock-names : must contain "ppmuispx", "ppmuispx", "lite0", "lite1"
+ "mpll", "sysreg", "isp", "drc", "fd", "mcuisp", "uart",
+ "ispdiv0", "ispdiv1", "mcuispdiv0", "mcuispdiv1", "aclk200",
+ "div_aclk200", "aclk400mcuisp", "div_aclk400mcuisp" entries,
+ matching entries in the clocks property.
+pmu subnode
+-----------
+
+Required properties:
+ - reg : must contain PMU physical base address and size of the register set.
+
+The following are the FIMC-IS peripheral device nodes and can be specified
+either standalone or as the fimc-is node child nodes.
+
+i2c-isp (ISP I2C bus controller) nodes
+------------------------------------------
+
+Required properties:
+
+- compatible : should be "samsung,exynos4212-i2c-isp" for Exynos4212 and
+ Exynos4412 SoCs;
+- reg : physical base address and length of the registers set;
+- clocks : must contain gate clock specifier for this controller;
+- clock-names : must contain "i2c_isp" entry.
+
+For the above nodes it is required to specify a pinctrl state named "default",
+according to the pinctrl bindings defined in ../pinctrl/pinctrl-bindings.txt.
+
+Device tree nodes of the image sensors' controlled directly by the FIMC-IS
+firmware must be child nodes of their corresponding ISP I2C bus controller node.
+The data link of these image sensors must be specified using the common video
+interfaces bindings, defined in video-interfaces.txt.
diff --git a/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt b/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt
new file mode 100644
index 0000000..56e726e
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt
@@ -0,0 +1,16 @@
+Device-Tree bindings for GPIO IR receiver
+
+Required properties:
+ - compatible: should be "gpio-ir-receiver".
+ - gpios: specifies GPIO used for IR signal reception.
+
+Optional properties:
+ - linux,rc-map-name: Linux specific remote control map name.
+
+Example node:
+
+ ir: ir-receiver {
+ compatible = "gpio-ir-receiver";
+ gpios = <&gpio0 19 1>;
+ linux,rc-map-name = "rc-rc6-mce";
+ };
diff --git a/Documentation/devicetree/bindings/media/i2c/mt9p031.txt b/Documentation/devicetree/bindings/media/i2c/mt9p031.txt
new file mode 100644
index 0000000..cb60443
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/mt9p031.txt
@@ -0,0 +1,40 @@
+* Aptina 1/2.5-Inch 5Mp CMOS Digital Image Sensor
+
+The Aptina MT9P031 is a 1/2.5-inch CMOS active pixel digital image sensor with
+an active array size of 2592H x 1944V. It is programmable through a simple
+two-wire serial interface.
+
+Required Properties:
+- compatible: value should be either one among the following
+ (a) "aptina,mt9p031" for mt9p031 sensor
+ (b) "aptina,mt9p031m" for mt9p031m sensor
+
+- input-clock-frequency: Input clock frequency.
+
+- pixel-clock-frequency: Pixel clock frequency.
+
+Optional Properties:
+- reset-gpios: Chip reset GPIO
+
+For further reading on port node refer to
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+
+ i2c0@1c22000 {
+ ...
+ ...
+ mt9p031@5d {
+ compatible = "aptina,mt9p031";
+ reg = <0x5d>;
+ reset-gpios = <&gpio3 30 0>;
+
+ port {
+ mt9p031_1: endpoint {
+ input-clock-frequency = <6000000>;
+ pixel-clock-frequency = <96000000>;
+ };
+ };
+ };
+ ...
+ };
diff --git a/Documentation/devicetree/bindings/media/i2c/tvp514x.txt b/Documentation/devicetree/bindings/media/i2c/tvp514x.txt
new file mode 100644
index 0000000..46752cc
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/tvp514x.txt
@@ -0,0 +1,44 @@
+* Texas Instruments TVP514x video decoder
+
+The TVP5146/TVP5146m2/TVP5147/TVP5147m1 device is high quality, single-chip
+digital video decoder that digitizes and decodes all popular baseband analog
+video formats into digital video component. The tvp514x decoder supports analog-
+to-digital (A/D) conversion of component RGB and YPbPr signals as well as A/D
+conversion and decoding of NTSC, PAL and SECAM composite and S-video into
+component YCbCr.
+
+Required Properties :
+- compatible : value should be either one among the following
+ (a) "ti,tvp5146" for tvp5146 decoder.
+ (b) "ti,tvp5146m2" for tvp5146m2 decoder.
+ (c) "ti,tvp5147" for tvp5147 decoder.
+ (d) "ti,tvp5147m1" for tvp5147m1 decoder.
+
+- hsync-active: HSYNC Polarity configuration for endpoint.
+
+- vsync-active: VSYNC Polarity configuration for endpoint.
+
+- pclk-sample: Clock polarity of the endpoint.
+
+For further reading on port node refer to Documentation/devicetree/bindings/
+media/video-interfaces.txt.
+
+Example:
+
+ i2c0@1c22000 {
+ ...
+ ...
+ tvp514x@5c {
+ compatible = "ti,tvp5146";
+ reg = <0x5c>;
+
+ port {
+ tvp514x_1: endpoint {
+ hsync-active = <1>;
+ vsync-active = <1>;
+ pclk-sample = <0>;
+ };
+ };
+ };
+ ...
+ };
diff --git a/Documentation/devicetree/bindings/media/s5p-mfc.txt b/Documentation/devicetree/bindings/media/s5p-mfc.txt
index 67ec3d4..df37b02 100644
--- a/Documentation/devicetree/bindings/media/s5p-mfc.txt
+++ b/Documentation/devicetree/bindings/media/s5p-mfc.txt
@@ -15,9 +15,35 @@
mapped region.
- interrupts : MFC interrupt number to the CPU.
+ - clocks : from common clock binding: handle to mfc clocks.
+ - clock-names : from common clock binding: must contain "sclk_mfc" and "mfc",
+ corresponding to entries in the clocks property.
- samsung,mfc-r : Base address of the first memory bank used by MFC
for DMA contiguous memory allocation and its size.
- samsung,mfc-l : Base address of the second memory bank used by MFC
for DMA contiguous memory allocation and its size.
+
+Optional properties:
+ - samsung,power-domain : power-domain property defined with a phandle
+ to respective power domain.
+
+Example:
+SoC specific DT entry:
+
+mfc: codec@13400000 {
+ compatible = "samsung,mfc-v5";
+ reg = <0x13400000 0x10000>;
+ interrupts = <0 94 0>;
+ samsung,power-domain = <&pd_mfc>;
+ clocks = <&clock 170>, <&clock 273>;
+ clock-names = "sclk_mfc", "mfc";
+};
+
+Board specific DT entry:
+
+codec@13400000 {
+ samsung,mfc-r = <0x43000000 0x800000>;
+ samsung,mfc-l = <0x51000000 0x800000>;
+};
diff --git a/Documentation/devicetree/bindings/media/samsung-fimc.txt b/Documentation/devicetree/bindings/media/samsung-fimc.txt
new file mode 100644
index 0000000..96312f6
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/samsung-fimc.txt
@@ -0,0 +1,197 @@
+Samsung S5P/EXYNOS SoC Camera Subsystem (FIMC)
+----------------------------------------------
+
+The S5P/Exynos SoC Camera subsystem comprises of multiple sub-devices
+represented by separate device tree nodes. Currently this includes: FIMC (in
+the S5P SoCs series known as CAMIF), MIPI CSIS, FIMC-LITE and FIMC-IS (ISP).
+
+The sub-subdevices are defined as child nodes of the common 'camera' node which
+also includes common properties of the whole subsystem not really specific to
+any single sub-device, like common camera port pins or the CAMCLK clock outputs
+for external image sensors attached to an SoC.
+
+Common 'camera' node
+--------------------
+
+Required properties:
+
+- compatible : must be "samsung,fimc", "simple-bus"
+- clocks : list of clock specifiers, corresponding to entries in
+ the clock-names property;
+- clock-names : must contain "sclk_cam0", "sclk_cam1", "pxl_async0",
+ "pxl_async1" entries, matching entries in the clocks property.
+
+The pinctrl bindings defined in ../pinctrl/pinctrl-bindings.txt must be used
+to define a required pinctrl state named "default" and optional pinctrl states:
+"idle", "active-a", active-b". These optional states can be used to switch the
+camera port pinmux at runtime. The "idle" state should configure both the camera
+ports A and B into high impedance state, especially the CAMCLK clock output
+should be inactive. For the "active-a" state the camera port A must be activated
+and the port B deactivated and for the state "active-b" it should be the other
+way around.
+
+The 'camera' node must include at least one 'fimc' child node.
+
+'fimc' device nodes
+-------------------
+
+Required properties:
+
+- compatible: "samsung,s5pv210-fimc" for S5PV210, "samsung,exynos4210-fimc"
+ for Exynos4210 and "samsung,exynos4212-fimc" for Exynos4x12 SoCs;
+- reg: physical base address and length of the registers set for the device;
+- interrupts: should contain FIMC interrupt;
+- clocks: list of clock specifiers, must contain an entry for each required
+ entry in clock-names;
+- clock-names: must contain "fimc", "sclk_fimc" entries.
+- samsung,pix-limits: an array of maximum supported image sizes in pixels, for
+ details refer to Table 2-1 in the S5PV210 SoC User Manual; The meaning of
+ each cell is as follows:
+ 0 - scaler input horizontal size,
+ 1 - input horizontal size for the scaler bypassed,
+ 2 - REAL_WIDTH without input rotation,
+ 3 - REAL_HEIGHT with input rotation,
+- samsung,sysreg: a phandle to the SYSREG node.
+
+Each FIMC device should have an alias in the aliases node, in the form of
+fimc<n>, where <n> is an integer specifying the IP block instance.
+
+Optional properties:
+
+- clock-frequency: maximum FIMC local clock (LCLK) frequency;
+- samsung,min-pix-sizes: an array specyfing minimum image size in pixels at
+ the FIMC input and output DMA, in the first and second cell respectively.
+ Default value when this property is not present is <16 16>;
+- samsung,min-pix-alignment: minimum supported image height alignment (first
+ cell) and the horizontal image offset (second cell). The values are in pixels
+ and default to <2 1> when this property is not present;
+- samsung,mainscaler-ext: a boolean property indicating whether the FIMC IP
+ supports extended image size and has CIEXTEN register;
+- samsung,rotators: a bitmask specifying whether this IP has the input and
+ the output rotator. Bits 4 and 0 correspond to input and output rotator
+ respectively. If a rotator is present its corresponding bit should be set.
+ Default value when this property is not specified is 0x11.
+- samsung,cam-if: a bolean property indicating whether the IP block includes
+ the camera input interface.
+- samsung,isp-wb: this property must be present if the IP block has the ISP
+ writeback input.
+- samsung,lcd-wb: this property must be present if the IP block has the LCD
+ writeback input.
+
+
+'parallel-ports' node
+---------------------
+
+This node should contain child 'port' nodes specifying active parallel video
+input ports. It includes camera A and camera B inputs. 'reg' property in the
+port nodes specifies data input - 0, 1 indicates input A, B respectively.
+
+Optional properties
+
+- samsung,camclk-out : specifies clock output for remote sensor,
+ 0 - CAM_A_CLKOUT, 1 - CAM_B_CLKOUT;
+
+Image sensor nodes
+------------------
+
+The sensor device nodes should be added to their control bus controller (e.g.
+I2C0) nodes and linked to a port node in the csis or the parallel-ports node,
+using the common video interfaces bindings, defined in video-interfaces.txt.
+The implementation of this bindings requires clock-frequency property to be
+present in the sensor device nodes.
+
+Example:
+
+ aliases {
+ fimc0 = &fimc_0;
+ };
+
+ /* Parallel bus IF sensor */
+ i2c_0: i2c@13860000 {
+ s5k6aa: sensor@3c {
+ compatible = "samsung,s5k6aafx";
+ reg = <0x3c>;
+ vddio-supply = <...>;
+
+ clock-frequency = <24000000>;
+ clocks = <...>;
+ clock-names = "mclk";
+
+ port {
+ s5k6aa_ep: endpoint {
+ remote-endpoint = <&fimc0_ep>;
+ bus-width = <8>;
+ hsync-active = <0>;
+ vsync-active = <1>;
+ pclk-sample = <1>;
+ };
+ };
+ };
+
+ /* MIPI CSI-2 bus IF sensor */
+ s5c73m3: sensor@0x1a {
+ compatible = "samsung,s5c73m3";
+ reg = <0x1a>;
+ vddio-supply = <...>;
+
+ clock-frequency = <24000000>;
+ clocks = <...>;
+ clock-names = "mclk";
+
+ port {
+ s5c73m3_1: endpoint {
+ data-lanes = <1 2 3 4>;
+ remote-endpoint = <&csis0_ep>;
+ };
+ };
+ };
+ };
+
+ camera {
+ compatible = "samsung,fimc", "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ status = "okay";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&cam_port_a_clk_active>;
+
+ /* parallel camera ports */
+ parallel-ports {
+ /* camera A input */
+ port@0 {
+ reg = <0>;
+ fimc0_ep: endpoint {
+ remote-endpoint = <&s5k6aa_ep>;
+ bus-width = <8>;
+ hsync-active = <0>;
+ vsync-active = <1>;
+ pclk-sample = <1>;
+ };
+ };
+ };
+
+ fimc_0: fimc@11800000 {
+ compatible = "samsung,exynos4210-fimc";
+ reg = <0x11800000 0x1000>;
+ interrupts = <0 85 0>;
+ status = "okay";
+ };
+
+ csis_0: csis@11880000 {
+ compatible = "samsung,exynos4210-csis";
+ reg = <0x11880000 0x1000>;
+ interrupts = <0 78 0>;
+ /* camera C input */
+ port@3 {
+ reg = <3>;
+ csis0_ep: endpoint {
+ remote-endpoint = <&s5c73m3_ep>;
+ data-lanes = <1 2 3 4>;
+ samsung,csis-hs-settle = <12>;
+ };
+ };
+ };
+ };
+
+The MIPI-CSIS device binding is defined in samsung-mipi-csis.txt.
diff --git a/Documentation/devicetree/bindings/media/samsung-mipi-csis.txt b/Documentation/devicetree/bindings/media/samsung-mipi-csis.txt
new file mode 100644
index 0000000..be45f0b
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/samsung-mipi-csis.txt
@@ -0,0 +1,81 @@
+Samsung S5P/EXYNOS SoC series MIPI CSI-2 receiver (MIPI CSIS)
+-------------------------------------------------------------
+
+Required properties:
+
+- compatible : "samsung,s5pv210-csis" for S5PV210 (S5PC110),
+ "samsung,exynos4210-csis" for Exynos4210 (S5PC210),
+ "samsung,exynos4212-csis" for Exynos4212/Exynos4412,
+ "samsung,exynos5250-csis" for Exynos5250;
+- reg : offset and length of the register set for the device;
+- interrupts : should contain MIPI CSIS interrupt; the format of the
+ interrupt specifier depends on the interrupt controller;
+- bus-width : maximum number of data lanes supported (SoC specific);
+- vddio-supply : MIPI CSIS I/O and PLL voltage supply (e.g. 1.8V);
+- vddcore-supply : MIPI CSIS Core voltage supply (e.g. 1.1V);
+- clocks : list of clock specifiers, corresponding to entries in
+ clock-names property;
+- clock-names : must contain "csis", "sclk_csis" entries, matching entries
+ in the clocks property.
+
+Optional properties:
+
+- clock-frequency : The IP's main (system bus) clock frequency in Hz, default
+ value when this property is not specified is 166 MHz;
+- samsung,csis-wclk : CSI-2 wrapper clock selection. If this property is present
+ external clock from CMU will be used, or the bus clock if
+ if it's not specified.
+
+The device node should contain one 'port' child node with one child 'endpoint'
+node, according to the bindings defined in Documentation/devicetree/bindings/
+media/video-interfaces.txt. The following are properties specific to those nodes.
+
+port node
+---------
+
+- reg : (required) must be 3 for camera C input (CSIS0) or 4 for
+ camera D input (CSIS1);
+
+endpoint node
+-------------
+
+- data-lanes : (required) an array specifying active physical MIPI-CSI2
+ data input lanes and their mapping to logical lanes; the
+ array's content is unused, only its length is meaningful;
+
+- samsung,csis-hs-settle : (optional) differential receiver (HS-RX) settle time;
+
+
+Example:
+
+ reg0: regulator@0 {
+ };
+
+ reg1: regulator@1 {
+ };
+
+/* SoC properties */
+
+ csis_0: csis@11880000 {
+ compatible = "samsung,exynos4210-csis";
+ reg = <0x11880000 0x1000>;
+ interrupts = <0 78 0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+/* Board properties */
+
+ csis_0: csis@11880000 {
+ clock-frequency = <166000000>;
+ vddio-supply = <®0>;
+ vddcore-supply = <®1>;
+ port {
+ reg = <3>; /* 3 - CSIS0, 4 - CSIS1 */
+ csis0_ep: endpoint {
+ remote-endpoint = <...>;
+ data-lanes = <1>, <2>;
+ samsung,csis-hs-settle = <12>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/media/sh_mobile_ceu.txt b/Documentation/devicetree/bindings/media/sh_mobile_ceu.txt
new file mode 100644
index 0000000..1ce4e46
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/sh_mobile_ceu.txt
@@ -0,0 +1,18 @@
+Bindings, specific for the sh_mobile_ceu_camera.c driver:
+ - compatible: Should be "renesas,sh-mobile-ceu"
+ - reg: register base and size
+ - interrupts: the interrupt number
+ - interrupt-parent: the interrupt controller
+ - renesas,max-width: maximum image width, supported on this SoC
+ - renesas,max-height: maximum image height, supported on this SoC
+
+Example:
+
+ceu0: ceu@0xfe910000 {
+ compatible = "renesas,sh-mobile-ceu";
+ reg = <0xfe910000 0xa0>;
+ interrupt-parent = <&intcs>;
+ interrupts = <0x880>;
+ renesas,max-width = <8188>;
+ renesas,max-height = <8188>;
+};
diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt b/Documentation/devicetree/bindings/media/video-interfaces.txt
new file mode 100644
index 0000000..e022d2d
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/video-interfaces.txt
@@ -0,0 +1,228 @@
+Common bindings for video receiver and transmitter interfaces
+
+General concept
+---------------
+
+Video data pipelines usually consist of external devices, e.g. camera sensors,
+controlled over an I2C, SPI or UART bus, and SoC internal IP blocks, including
+video DMA engines and video data processors.
+
+SoC internal blocks are described by DT nodes, placed similarly to other SoC
+blocks. External devices are represented as child nodes of their respective
+bus controller nodes, e.g. I2C.
+
+Data interfaces on all video devices are described by their child 'port' nodes.
+Configuration of a port depends on other devices participating in the data
+transfer and is described by 'endpoint' subnodes.
+
+device {
+ ...
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ ...
+ endpoint@0 { ... };
+ endpoint@1 { ... };
+ };
+ port@1 { ... };
+ };
+};
+
+If a port can be configured to work with more than one remote device on the same
+bus, an 'endpoint' child node must be provided for each of them. If more than
+one port is present in a device node or there is more than one endpoint at a
+port, or port node needs to be associated with a selected hardware interface,
+a common scheme using '#address-cells', '#size-cells' and 'reg' properties is
+used.
+
+All 'port' nodes can be grouped under optional 'ports' node, which allows to
+specify #address-cells, #size-cells properties independently for the 'port'
+and 'endpoint' nodes and any child device nodes a device might have.
+
+Two 'endpoint' nodes are linked with each other through their 'remote-endpoint'
+phandles. An endpoint subnode of a device contains all properties needed for
+configuration of this device for data exchange with other device. In most
+cases properties at the peer 'endpoint' nodes will be identical, however they
+might need to be different when there is any signal modifications on the bus
+between two devices, e.g. there are logic signal inverters on the lines.
+
+It is allowed for multiple endpoints at a port to be active simultaneously,
+where supported by a device. For example, in case where a data interface of
+a device is partitioned into multiple data busses, e.g. 16-bit input port
+divided into two separate ITU-R BT.656 8-bit busses. In such case bus-width
+and data-shift properties can be used to assign physical data lines to each
+endpoint node (logical bus).
+
+
+Required properties
+-------------------
+
+If there is more than one 'port' or more than one 'endpoint' node or 'reg'
+property is present in port and/or endpoint nodes the following properties
+are required in a relevant parent node:
+
+ - #address-cells : number of cells required to define port/endpoint
+ identifier, should be 1.
+ - #size-cells : should be zero.
+
+Optional endpoint properties
+----------------------------
+
+- remote-endpoint: phandle to an 'endpoint' subnode of a remote device node.
+- slave-mode: a boolean property indicating that the link is run in slave mode.
+ The default when this property is not specified is master mode. In the slave
+ mode horizontal and vertical synchronization signals are provided to the
+ slave device (data source) by the master device (data sink). In the master
+ mode the data source device is also the source of the synchronization signals.
+- bus-width: number of data lines actively used, valid for the parallel busses.
+- data-shift: on the parallel data busses, if bus-width is used to specify the
+ number of data lines, data-shift can be used to specify which data lines are
+ used, e.g. "bus-width=<8>; data-shift=<2>;" means, that lines 9:2 are used.
+- hsync-active: active state of the HSYNC signal, 0/1 for LOW/HIGH respectively.
+- vsync-active: active state of the VSYNC signal, 0/1 for LOW/HIGH respectively.
+ Note, that if HSYNC and VSYNC polarities are not specified, embedded
+ synchronization may be required, where supported.
+- data-active: similar to HSYNC and VSYNC, specifies data line polarity.
+- field-even-active: field signal level during the even field data transmission.
+- pclk-sample: sample data on rising (1) or falling (0) edge of the pixel clock
+ signal.
+- data-lanes: an array of physical data lane indexes. Position of an entry
+ determines the logical lane number, while the value of an entry indicates
+ physical lane, e.g. for 2-lane MIPI CSI-2 bus we could have
+ "data-lanes = <1 2>;", assuming the clock lane is on hardware lane 0.
+ This property is valid for serial busses only (e.g. MIPI CSI-2).
+- clock-lanes: an array of physical clock lane indexes. Position of an entry
+ determines the logical lane number, while the value of an entry indicates
+ physical lane, e.g. for a MIPI CSI-2 bus we could have "clock-lanes = <0>;",
+ which places the clock lane on hardware lane 0. This property is valid for
+ serial busses only (e.g. MIPI CSI-2). Note that for the MIPI CSI-2 bus this
+ array contains only one entry.
+- clock-noncontinuous: a boolean property to allow MIPI CSI-2 non-continuous
+ clock mode.
+
+
+Example
+-------
+
+The example snippet below describes two data pipelines. ov772x and imx074 are
+camera sensors with a parallel and serial (MIPI CSI-2) video bus respectively.
+Both sensors are on the I2C control bus corresponding to the i2c0 controller
+node. ov772x sensor is linked directly to the ceu0 video host interface.
+imx074 is linked to ceu0 through the MIPI CSI-2 receiver (csi2). ceu0 has a
+(single) DMA engine writing captured data to memory. ceu0 node has a single
+'port' node which may indicate that at any time only one of the following data
+pipelines can be active: ov772x -> ceu0 or imx074 -> csi2 -> ceu0.
+
+ ceu0: ceu@0xfe910000 {
+ compatible = "renesas,sh-mobile-ceu";
+ reg = <0xfe910000 0xa0>;
+ interrupts = <0x880>;
+
+ mclk: master_clock {
+ compatible = "renesas,ceu-clock";
+ #clock-cells = <1>;
+ clock-frequency = <50000000>; /* Max clock frequency */
+ clock-output-names = "mclk";
+ };
+
+ port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* Parallel bus endpoint */
+ ceu0_1: endpoint@1 {
+ reg = <1>; /* Local endpoint # */
+ remote = <&ov772x_1_1>; /* Remote phandle */
+ bus-width = <8>; /* Used data lines */
+ data-shift = <2>; /* Lines 9:2 are used */
+
+ /* If hsync-active/vsync-active are missing,
+ embedded BT.656 sync is used */
+ hsync-active = <0>; /* Active low */
+ vsync-active = <0>; /* Active low */
+ data-active = <1>; /* Active high */
+ pclk-sample = <1>; /* Rising */
+ };
+
+ /* MIPI CSI-2 bus endpoint */
+ ceu0_0: endpoint@0 {
+ reg = <0>;
+ remote = <&csi2_2>;
+ };
+ };
+ };
+
+ i2c0: i2c@0xfff20000 {
+ ...
+ ov772x_1: camera@0x21 {
+ compatible = "omnivision,ov772x";
+ reg = <0x21>;
+ vddio-supply = <®ulator1>;
+ vddcore-supply = <®ulator2>;
+
+ clock-frequency = <20000000>;
+ clocks = <&mclk 0>;
+ clock-names = "xclk";
+
+ port {
+ /* With 1 endpoint per port no need for addresses. */
+ ov772x_1_1: endpoint {
+ bus-width = <8>;
+ remote-endpoint = <&ceu0_1>;
+ hsync-active = <1>;
+ vsync-active = <0>; /* Who came up with an
+ inverter here ?... */
+ data-active = <1>;
+ pclk-sample = <1>;
+ };
+ };
+ };
+
+ imx074: camera@0x1a {
+ compatible = "sony,imx074";
+ reg = <0x1a>;
+ vddio-supply = <®ulator1>;
+ vddcore-supply = <®ulator2>;
+
+ clock-frequency = <30000000>; /* Shared clock with ov772x_1 */
+ clocks = <&mclk 0>;
+ clock-names = "sysclk"; /* Assuming this is the
+ name in the datasheet */
+ port {
+ imx074_1: endpoint {
+ clock-lanes = <0>;
+ data-lanes = <1 2>;
+ remote-endpoint = <&csi2_1>;
+ };
+ };
+ };
+ };
+
+ csi2: csi2@0xffc90000 {
+ compatible = "renesas,sh-mobile-csi2";
+ reg = <0xffc90000 0x1000>;
+ interrupts = <0x17a0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@1 {
+ compatible = "renesas,csi2c"; /* One of CSI2I and CSI2C. */
+ reg = <1>; /* CSI-2 PHY #1 of 2: PHY_S,
+ PHY_M has port address 0,
+ is unused. */
+ csi2_1: endpoint {
+ clock-lanes = <0>;
+ data-lanes = <2 1>;
+ remote-endpoint = <&imx074_1>;
+ };
+ };
+ port@2 {
+ reg = <2>; /* port 2: link to the CEU */
+
+ csi2_2: endpoint {
+ remote-endpoint = <&ceu0_0>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/memory-controllers/mvebu-devbus.txt b/Documentation/devicetree/bindings/memory-controllers/mvebu-devbus.txt
new file mode 100644
index 0000000..653c90c
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/mvebu-devbus.txt
@@ -0,0 +1,156 @@
+Device tree bindings for MVEBU Device Bus controllers
+
+The Device Bus controller available in some Marvell's SoC allows to control
+different types of standard memory and I/O devices such as NOR, NAND, and FPGA.
+The actual devices are instantiated from the child nodes of a Device Bus node.
+
+Required properties:
+
+ - compatible: Currently only Armada 370/XP SoC are supported,
+ with this compatible string:
+
+ marvell,mvebu-devbus
+
+ - reg: A resource specifier for the register space.
+ This is the base address of a chip select within
+ the controller's register space.
+ (see the example below)
+
+ - #address-cells: Must be set to 1
+ - #size-cells: Must be set to 1
+ - ranges: Must be set up to reflect the memory layout with four
+ integer values for each chip-select line in use:
+ 0 <physical address of mapping> <size>
+
+Mandatory timing properties for child nodes:
+
+Read parameters:
+
+ - devbus,turn-off-ps: Defines the time during which the controller does not
+ drive the AD bus after the completion of a device read.
+ This prevents contentions on the Device Bus after a read
+ cycle from a slow device.
+
+ - devbus,bus-width: Defines the bus width (e.g. <16>)
+
+ - devbus,badr-skew-ps: Defines the time delay from from A[2:0] toggle,
+ to read data sample. This parameter is useful for
+ synchronous pipelined devices, where the address
+ precedes the read data by one or two cycles.
+
+ - devbus,acc-first-ps: Defines the time delay from the negation of
+ ALE[0] to the cycle that the first read data is sampled
+ by the controller.
+
+ - devbus,acc-next-ps: Defines the time delay between the cycle that
+ samples data N and the cycle that samples data N+1
+ (in burst accesses).
+
+ - devbus,rd-setup-ps: Defines the time delay between DEV_CSn assertion to
+ DEV_OEn assertion. If set to 0 (default),
+ DEV_OEn and DEV_CSn are asserted at the same cycle.
+ This parameter has no affect on <acc-first-ps> parameter
+ (no affect on first data sample). Set <rd-setup-ps>
+ to a value smaller than <acc-first-ps>.
+
+ - devbus,rd-hold-ps: Defines the time between the last data sample to the
+ de-assertion of DEV_CSn. If set to 0 (default),
+ DEV_OEn and DEV_CSn are de-asserted at the same cycle
+ (the cycle of the last data sample).
+ This parameter has no affect on DEV_OEn de-assertion.
+ DEV_OEn is always de-asserted the next cycle after
+ last data sampled. Also this parameter has no
+ affect on <turn-off-ps> parameter.
+ Set <rd-hold-ps> to a value smaller than <turn-off-ps>.
+
+Write parameters:
+
+ - devbus,ale-wr-ps: Defines the time delay from the ALE[0] negation cycle
+ to the DEV_WEn assertion.
+
+ - devbus,wr-low-ps: Defines the time during which DEV_WEn is active.
+ A[2:0] and Data are kept valid as long as DEV_WEn
+ is active. This parameter defines the setup time of
+ address and data to DEV_WEn rise.
+
+ - devbus,wr-high-ps: Defines the time during which DEV_WEn is kept
+ inactive (high) between data beats of a burst write.
+ DEV_A[2:0] and Data are kept valid (do not toggle) for
+ <wr-high-ps> - <tick> ps.
+ This parameter defines the hold time of address and
+ data after DEV_WEn rise.
+
+ - devbus,sync-enable: Synchronous device enable.
+ 1: True
+ 0: False
+
+An example for an Armada XP GP board, with a 16 MiB NOR device as child
+is showed below. Note that the Device Bus driver is in charge of allocating
+the mbus address decoding window for each of its child devices.
+The window is created using the chip select specified in the child
+device node together with the base address and size specified in the ranges
+property. For instance, in the example below the allocated decoding window
+will start at base address 0xf0000000, with a size 0x1000000 (16 MiB)
+for chip select 0 (a.k.a DEV_BOOTCS).
+
+This address window handling is done in this mvebu-devbus only as a temporary
+solution. It will be removed when the support for mbus device tree binding is
+added.
+
+The reg property implicitly specifies the chip select as this:
+
+ 0x10400: DEV_BOOTCS
+ 0x10408: DEV_CS0
+ 0x10410: DEV_CS1
+ 0x10418: DEV_CS2
+ 0x10420: DEV_CS3
+
+Example:
+
+ devbus-bootcs@d0010400 {
+ status = "okay";
+ ranges = <0 0xf0000000 0x1000000>; /* @addr 0xf0000000, size 0x1000000 */
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ /* Device Bus parameters are required */
+
+ /* Read parameters */
+ devbus,bus-width = <8>;
+ devbus,turn-off-ps = <60000>;
+ devbus,badr-skew-ps = <0>;
+ devbus,acc-first-ps = <124000>;
+ devbus,acc-next-ps = <248000>;
+ devbus,rd-setup-ps = <0>;
+ devbus,rd-hold-ps = <0>;
+
+ /* Write parameters */
+ devbus,sync-enable = <0>;
+ devbus,wr-high-ps = <60000>;
+ devbus,wr-low-ps = <60000>;
+ devbus,ale-wr-ps = <60000>;
+
+ flash@0 {
+ compatible = "cfi-flash";
+
+ /* 16 MiB */
+ reg = <0 0x1000000>;
+ bank-width = <2>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ /*
+ * We split the 16 MiB in two partitions,
+ * just as an example.
+ */
+ partition@0 {
+ label = "First";
+ reg = <0 0x800000>;
+ };
+
+ partition@800000 {
+ label = "Second";
+ reg = <0x800000 0x800000>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/metag/meta-intc.txt b/Documentation/devicetree/bindings/metag/meta-intc.txt
new file mode 100644
index 0000000..80994ad
--- /dev/null
+++ b/Documentation/devicetree/bindings/metag/meta-intc.txt
@@ -0,0 +1,82 @@
+* Meta External Trigger Controller Binding
+
+This binding specifies what properties must be available in the device tree
+representation of a Meta external trigger controller.
+
+Required properties:
+
+ - compatible: Specifies the compatibility list for the interrupt controller.
+ The type shall be <string> and the value shall include "img,meta-intc".
+
+ - num-banks: Specifies the number of interrupt banks (each of which can
+ handle 32 interrupt sources).
+
+ - interrupt-controller: The presence of this property identifies the node
+ as an interrupt controller. No property value shall be defined.
+
+ - #interrupt-cells: Specifies the number of cells needed to encode an
+ interrupt source. The type shall be a <u32> and the value shall be 2.
+
+ - #address-cells: Specifies the number of cells needed to encode an
+ address. The type shall be <u32> and the value shall be 0. As such,
+ 'interrupt-map' nodes do not have to specify a parent unit address.
+
+Optional properties:
+
+ - no-mask: The controller doesn't have any mask registers.
+
+* Interrupt Specifier Definition
+
+ Interrupt specifiers consists of 2 cells encoded as follows:
+
+ - <1st-cell>: The interrupt-number that identifies the interrupt source.
+
+ - <2nd-cell>: The Linux interrupt flags containing level-sense information,
+ encoded as follows:
+ 1 = edge triggered
+ 4 = level-sensitive
+
+* Examples
+
+Example 1:
+
+ /*
+ * Meta external trigger block
+ */
+ intc: intc {
+ // This is an interrupt controller node.
+ interrupt-controller;
+
+ // No address cells so that 'interrupt-map' nodes which
+ // reference this interrupt controller node do not need a parent
+ // address specifier.
+ #address-cells = <0>;
+
+ // Two cells to encode interrupt sources.
+ #interrupt-cells = <2>;
+
+ // Number of interrupt banks
+ num-banks = <2>;
+
+ // No HWMASKEXT is available (specify on Chorus2 and Comet ES1)
+ no-mask;
+
+ // Compatible with Meta hardware trigger block.
+ compatible = "img,meta-intc";
+ };
+
+Example 2:
+
+ /*
+ * An interrupt generating device that is wired to a Meta external
+ * trigger block.
+ */
+ uart1: uart@0x02004c00 {
+ // Interrupt source '5' that is level-sensitive.
+ // Note that there are only two cells as specified in the
+ // interrupt parent's '#interrupt-cells' property.
+ interrupts = <5 4 /* level */>;
+
+ // The interrupt controller that this device is wired to.
+ interrupt-parent = <&intc>;
+ };
diff --git a/Documentation/devicetree/bindings/metag/meta.txt b/Documentation/devicetree/bindings/metag/meta.txt
new file mode 100644
index 0000000..f4457f5
--- /dev/null
+++ b/Documentation/devicetree/bindings/metag/meta.txt
@@ -0,0 +1,30 @@
+* Meta Processor Binding
+
+This binding specifies what properties must be available in the device tree
+representation of a Meta Processor Core, which is the root node in the tree.
+
+Required properties:
+
+ - compatible: Specifies the compatibility list for the Meta processor.
+ The type shall be <string> and the value shall include "img,meta".
+
+Optional properties:
+
+ - clocks: Clock consumer specifiers as described in
+ Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+ - clock-names: Clock consumer names as described in
+ Documentation/devicetree/bindings/clock/clock-bindings.txt.
+
+Clocks are identified by name. Valid clocks are:
+
+ - "core": The Meta core clock from which the Meta timers are derived.
+
+* Examples
+
+/ {
+ compatible = "toumaz,tz1090", "img,meta";
+
+ clocks = <&meta_core_clk>;
+ clock-names = "core";
+};
diff --git a/Documentation/devicetree/bindings/mfd/ab8500.txt b/Documentation/devicetree/bindings/mfd/ab8500.txt
index 13b707b..cd9e90c 100644
--- a/Documentation/devicetree/bindings/mfd/ab8500.txt
+++ b/Documentation/devicetree/bindings/mfd/ab8500.txt
@@ -13,9 +13,6 @@
4 = active high level-sensitive
8 = active low level-sensitive
-Optional parent device properties:
-- reg : contains the PRCMU mailbox address for the AB8500 i2c port
-
The AB8500 consists of a large and varied group of sub-devices:
Device IRQ Names Supply Names Description
@@ -86,9 +83,8 @@
- stericsson,amic2-bias-vamic1 : Analoge Mic wishes to use a non-standard Vamic
- stericsson,earpeice-cmv : Earpeice voltage (only: 950 | 1100 | 1270 | 1580)
-ab8500@5 {
+ab8500 {
compatible = "stericsson,ab8500";
- reg = <5>; /* mailbox 5 is i2c */
interrupts = <0 40 0x4>;
interrupt-controller;
#interrupt-cells = <2>;
@@ -124,7 +120,7 @@
"USB_LINK_STATUS",
"USB_ADP_PROBE_PLUG",
"USB_ADP_PROBE_UNPLUG";
- vddulpivio18-supply = <&ab8500_ldo_initcore_reg>;
+ vddulpivio18-supply = <&ab8500_ldo_intcore_reg>;
v-ape-supply = <&db8500_vape_reg>;
musb_1v8-supply = <&db8500_vsmps2_reg>;
};
diff --git a/Documentation/devicetree/bindings/mfd/arizona.txt b/Documentation/devicetree/bindings/mfd/arizona.txt
new file mode 100644
index 0000000..0e295c9
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/arizona.txt
@@ -0,0 +1,62 @@
+Wolfson Arizona class audio SoCs
+
+These devices are audio SoCs with extensive digital capabilites and a range
+of analogue I/O.
+
+Required properties:
+
+ - compatible : one of the following chip-specific strings:
+ "wlf,wm5102"
+ "wlf,wm5110"
+ - reg : I2C slave address when connected using I2C, chip select number when
+ using SPI.
+
+ - interrupts : The interrupt line the /IRQ signal for the device is
+ connected to.
+ - interrupt-controller : Arizona class devices contain interrupt controllers
+ and may provide interrupt services to other devices.
+ - interrupt-parent : The parent interrupt controller.
+ - #interrupt-cells: the number of cells to describe an IRQ, this should be 2.
+ The first cell is the IRQ number.
+ The second cell is the flags, encoded as the trigger masks from
+ Documentation/devicetree/bindings/interrupts.txt
+
+ - gpio-controller : Indicates this device is a GPIO controller.
+ - #gpio-cells : Must be 2. The first cell is the pin number and the
+ second cell is used to specify optional parameters (currently unused).
+
+ - AVDD1-supply, DBVDD1-supply, DBVDD2-supply, DBVDD3-supply, CPVDD-supply,
+ SPKVDDL-supply, SPKVDDR-supply : power supplies for the device, as covered
+ in Documentation/devicetree/bindings/regulator/regulator.txt
+
+Optional properties:
+
+ - wlf,reset : GPIO specifier for the GPIO controlling /RESET
+ - wlf,ldoena : GPIO specifier for the GPIO controlling LDOENA
+
+ - wlf,gpio-defaults : A list of GPIO configuration register values. If
+ absent, no configuration of these registers is performed. If any
+ entry has a value that is out of range for a 16 bit register then
+ the chip default will be used. If present exactly five values must
+ be specified.
+
+Example:
+
+codec: wm5102@1a {
+ compatible = "wlf,wm5102";
+ reg = <0x1a>;
+ interrupts = <347>;
+ #interrupt-cells = <2>;
+ interrupt-parent = <&gic>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ wlf,gpio-defaults = <
+ 0x00000000, /* AIF1TXLRCLK */
+ 0xffffffff,
+ 0xffffffff,
+ 0xffffffff,
+ 0xffffffff,
+ >;
+};
diff --git a/Documentation/devicetree/bindings/mfd/as3711.txt b/Documentation/devicetree/bindings/mfd/as3711.txt
new file mode 100644
index 0000000..d98cf18
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/as3711.txt
@@ -0,0 +1,73 @@
+AS3711 is an I2C PMIC from Austria MicroSystems with multiple DCDC and LDO power
+supplies, a battery charger and an RTC. So far only bindings for the two stepup
+DCDC converters are defined. Other DCDC and LDO supplies are configured, using
+standard regulator properties, they must belong to a sub-node, called
+"regulators" and be called "sd1" to "sd4" and "ldo1" to "ldo8." Stepup converter
+configuration should be placed in a subnode, called "backlight."
+
+Compulsory properties:
+- compatible : must be "ams,as3711"
+- reg : specifies the I2C address
+
+To use the SU1 converter as a backlight source the following two properties must
+be provided:
+- su1-dev : framebuffer phandle
+- su1-max-uA : maximum current
+
+To use the SU2 converter as a backlight source the following two properties must
+be provided:
+- su2-dev : framebuffer phandle
+- su1-max-uA : maximum current
+
+Additionally one of these properties must be provided to select the type of
+feedback used:
+- su2-feedback-voltage : voltage feedback is used
+- su2-feedback-curr1 : CURR1 input used for current feedback
+- su2-feedback-curr2 : CURR2 input used for current feedback
+- su2-feedback-curr3 : CURR3 input used for current feedback
+- su2-feedback-curr-auto: automatic current feedback selection
+
+and one of these to select the over-voltage protection pin
+- su2-fbprot-lx-sd4 : LX_SD4 is used for over-voltage protection
+- su2-fbprot-gpio2 : GPIO2 is used for over-voltage protection
+- su2-fbprot-gpio3 : GPIO3 is used for over-voltage protection
+- su2-fbprot-gpio4 : GPIO4 is used for over-voltage protection
+
+If "su2-feedback-curr-auto" is selected, one or more of the following properties
+have to be specified:
+- su2-auto-curr1 : use CURR1 input for current feedback
+- su2-auto-curr2 : use CURR2 input for current feedback
+- su2-auto-curr3 : use CURR3 input for current feedback
+
+Example:
+
+as3711@40 {
+ compatible = "ams,as3711";
+ reg = <0x40>;
+
+ regulators {
+ sd4 {
+ regulator-name = "1.215V";
+ regulator-min-microvolt = <1215000>;
+ regulator-max-microvolt = <1235000>;
+ };
+ ldo2 {
+ regulator-name = "2.8V CPU";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+ };
+
+ backlight {
+ compatible = "ams,as3711-bl";
+ su2-dev = <&lcdc>;
+ su2-max-uA = <36000>;
+ su2-feedback-curr-auto;
+ su2-fbprot-gpio4;
+ su2-auto-curr1;
+ su2-auto-curr2;
+ su2-auto-curr3;
+ };
+};
diff --git a/Documentation/devicetree/bindings/mfd/cros-ec.txt b/Documentation/devicetree/bindings/mfd/cros-ec.txt
new file mode 100644
index 0000000..e0e59c5
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/cros-ec.txt
@@ -0,0 +1,56 @@
+ChromeOS Embedded Controller
+
+Google's ChromeOS EC is a Cortex-M device which talks to the AP and
+implements various function such as keyboard and battery charging.
+
+The EC can be connect through various means (I2C, SPI, LPC) and the
+compatible string used depends on the inteface. Each connection method has
+its own driver which connects to the top level interface-agnostic EC driver.
+Other Linux driver (such as cros-ec-keyb for the matrix keyboard) connect to
+the top-level driver.
+
+Required properties (I2C):
+- compatible: "google,cros-ec-i2c"
+- reg: I2C slave address
+
+Required properties (SPI):
+- compatible: "google,cros-ec-spi"
+- reg: SPI chip select
+
+Required properties (LPC):
+- compatible: "google,cros-ec-lpc"
+- reg: List of (IO address, size) pairs defining the interface uses
+
+
+Example for I2C:
+
+i2c@12CA0000 {
+ cros-ec@1e {
+ reg = <0x1e>;
+ compatible = "google,cros-ec-i2c";
+ interrupts = <14 0>;
+ interrupt-parent = <&wakeup_eint>;
+ wakeup-source;
+ };
+
+
+Example for SPI:
+
+spi@131b0000 {
+ ec@0 {
+ compatible = "google,cros-ec-spi";
+ reg = <0x0>;
+ interrupts = <14 0>;
+ interrupt-parent = <&wakeup_eint>;
+ wakeup-source;
+ spi-max-frequency = <5000000>;
+ controller-data {
+ cs-gpio = <&gpf0 3 4 3 0>;
+ samsung,spi-cs;
+ samsung,spi-feedback-delay = <2>;
+ };
+ };
+};
+
+
+Example for LPC is not supplied as it is not yet implemented.
diff --git a/Documentation/devicetree/bindings/mfd/max77693.txt b/Documentation/devicetree/bindings/mfd/max77693.txt
new file mode 100644
index 0000000..11921cc
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/max77693.txt
@@ -0,0 +1,55 @@
+Maxim MAX77693 multi-function device
+
+MAX77693 is a Multifunction device with the following submodules:
+- PMIC,
+- CHARGER,
+- LED,
+- MUIC,
+- HAPTIC
+
+It is interfaced to host controller using i2c.
+This document describes the bindings for the mfd device.
+
+Required properties:
+- compatible : Must be "maxim,max77693".
+- reg : Specifies the i2c slave address of PMIC block.
+- interrupts : This i2c device has an IRQ line connected to the main SoC.
+- interrupt-parent : The parent interrupt controller.
+
+Optional properties:
+- regulators : The regulators of max77693 have to be instantiated under subnod
+ named "regulators" using the following format.
+
+ regulators {
+ regualtor-compatible = ESAFEOUT1/ESAFEOUT2/CHARGER
+ standard regulator constratints[*].
+ };
+
+ [*] refer Documentation/devicetree/bindings/regulator/regulator.txt
+
+Example:
+ max77693@66 {
+ compatible = "maxim,max77693";
+ reg = <0x66>;
+ interrupt-parent = <&gpx1>;
+ interrupts = <5 2>;
+
+ regulators {
+ esafeout@1 {
+ regulator-compatible = "ESAFEOUT1";
+ regulator-name = "ESAFEOUT1";
+ regulator-boot-on;
+ };
+ esafeout@2 {
+ regulator-compatible = "ESAFEOUT2";
+ regulator-name = "ESAFEOUT2";
+ };
+ charger@0 {
+ regulator-compatible = "CHARGER";
+ regulator-name = "CHARGER";
+ regulator-min-microamp = <60000>;
+ regulator-max-microamp = <2580000>;
+ regulator-boot-on;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mfd/max8925.txt b/Documentation/devicetree/bindings/mfd/max8925.txt
new file mode 100644
index 0000000..4f0dc66
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/max8925.txt
@@ -0,0 +1,64 @@
+* Maxim max8925 Power Management IC
+
+Required parent device properties:
+- compatible : "maxim,max8925"
+- reg : the I2C slave address for the max8925 chip
+- interrupts : IRQ line for the max8925 chip
+- interrupt-controller: describes the max8925 as an interrupt
+ controller (has its own domain)
+- #interrupt-cells : should be 1.
+ - The cell is the max8925 local IRQ number
+
+Optional parent device properties:
+- maxim,tsc-irq: there are 2 IRQ lines for max8925, one is indicated in
+ interrupts property, the other is indicated here.
+
+max8925 consists of a large and varied group of sub-devices:
+
+Device Supply Names Description
+------ ------------ -----------
+max8925-onkey : : On key
+max8925-rtc : : RTC
+max8925-regulator : : Regulators
+max8925-backlight : : Backlight
+max8925-touch : : Touchscreen
+max8925-power : : Charger
+
+Example:
+
+ pmic: max8925@3c {
+ compatible = "maxim,max8925";
+ reg = <0x3c>;
+ interrupts = <1>;
+ interrupt-parent = <&intcmux4>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ maxim,tsc-irq = <0>;
+
+ regulators {
+ SDV1 {
+ regulator-min-microvolt = <637500>;
+ regulator-max-microvolt = <1425000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ LDO1 {
+ regulator-min-microvolt = <750000>;
+ regulator-max-microvolt = <3900000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ };
+ backlight {
+ maxim,max8925-dual-string = <0>;
+ };
+ charger {
+ batt-detect = <0>;
+ topoff-threshold = <1>;
+ fast-charge = <7>;
+ no-temp-support = <0>;
+ no-insert-detect = <0>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mfd/max8998.txt b/Documentation/devicetree/bindings/mfd/max8998.txt
new file mode 100644
index 0000000..23a3650
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/max8998.txt
@@ -0,0 +1,119 @@
+* Maxim MAX8998, National/TI LP3974 multi-function device
+
+The Maxim MAX8998 is a multi-function device which includes voltage/current
+regulators, real time clock, battery charging controller and several
+other sub-blocks. It is interfaced using an I2C interface. Each sub-block
+is addressed by the host system using different i2c slave address.
+
+PMIC sub-block
+--------------
+
+The PMIC sub-block contains a number of voltage and current regulators,
+with controllable parameters and dynamic voltage scaling capability.
+In addition, it includes a real time clock and battery charging controller
+as well. It is accessible at I2C address 0x66.
+
+Required properties:
+- compatible: Should be one of the following:
+ - "maxim,max8998" for Maxim MAX8998
+ - "national,lp3974" or "ti,lp3974" for National/TI LP3974.
+- reg: Specifies the i2c slave address of the pmic block. It should be 0x66.
+
+Optional properties:
+- interrupt-parent: Specifies the phandle of the interrupt controller to which
+ the interrupts from MAX8998 are routed to.
+- interrupts: Interrupt specifiers for two interrupt sources.
+ - First interrupt specifier is for main interrupt.
+ - Second interrupt specifier is for power-on/-off interrupt.
+- max8998,pmic-buck1-dvs-gpios: GPIO specifiers for two host gpios used
+ for buck 1 dvs. The format of the gpio specifier depends on the gpio
+ controller.
+- max8998,pmic-buck2-dvs-gpio: GPIO specifier for host gpio used
+ for buck 2 dvs. The format of the gpio specifier depends on the gpio
+ controller.
+- max8998,pmic-buck1-default-dvs-idx: Default voltage setting selected from
+ the possible 4 options selectable by the dvs gpios. The value of this
+ property should be 0, 1, 2 or 3. If not specified or out of range,
+ a default value of 0 is taken.
+- max8998,pmic-buck2-default-dvs-idx: Default voltage setting selected from
+ the possible 2 options selectable by the dvs gpios. The value of this
+ property should be 0 or 1. If not specified or out of range, a default
+ value of 0 is taken.
+- max8998,pmic-buck-voltage-lock: If present, disallows changing of
+ preprogrammed buck dvfs voltages.
+
+Additional properties required if max8998,pmic-buck1-dvs-gpios is defined:
+- max8998,pmic-buck1-dvs-voltage: An array of 4 voltage values in microvolts
+ for buck1 regulator that can be selected using dvs gpio.
+
+Additional properties required if max8998,pmic-buck2-dvs-gpio is defined:
+- max8998,pmic-buck2-dvs-voltage: An array of 2 voltage values in microvolts
+ for buck2 regulator that can be selected using dvs gpio.
+
+Regulators: All the regulators of MAX8998 to be instantiated shall be
+listed in a child node named 'regulators'. Each regulator is represented
+by a child node of the 'regulators' node.
+
+ regulator-name {
+ /* standard regulator bindings here */
+ };
+
+Following regulators of the MAX8998 PMIC block are supported. Note that
+the 'n' in regulator name, as in LDOn or BUCKn, represents the LDO or BUCK
+number as described in MAX8998 datasheet.
+
+ - LDOn
+ - valid values for n are 2 to 17
+ - Example: LDO2, LDO10, LDO17
+ - BUCKn
+ - valid values for n are 1 to 4.
+ - Example: BUCK1, BUCK2, BUCK3, BUCK4
+
+ - ENVICHG: Battery Charging Current Monitor Output. This is a fixed
+ voltage type regulator
+
+ - ESAFEOUT1: (ldo19)
+ - ESAFEOUT2: (ld020)
+
+Standard regulator bindings are used inside regulator subnodes. Check
+ Documentation/devicetree/bindings/regulator/regulator.txt
+for more details.
+
+Example:
+
+ pmic@66 {
+ compatible = "maxim,max8998-pmic";
+ reg = <0x66>;
+ interrupt-parent = <&wakeup_eint>;
+ interrupts = <4 0>, <3 0>;
+
+ /* Buck 1 DVS settings */
+ max8998,pmic-buck1-default-dvs-idx = <0>;
+ max8998,pmic-buck1-dvs-gpios = <&gpx0 0 1 0 0>, /* SET1 */
+ <&gpx0 1 1 0 0>; /* SET2 */
+ max8998,pmic-buck1-dvs-voltage = <1350000>, <1300000>,
+ <1000000>, <950000>;
+
+ /* Buck 2 DVS settings */
+ max8998,pmic-buck2-default-dvs-idx = <0>;
+ max8998,pmic-buck2-dvs-gpio = <&gpx0 0 3 0 0>; /* SET3 */
+ max8998,pmic-buck2-dvs-voltage = <1350000>, <1300000>;
+
+ /* Regulators to instantiate */
+ regulators {
+ ldo2_reg: LDO2 {
+ regulator-name = "VDD_ALIVE_1.1V";
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1100000>;
+ regulator-always-on;
+ };
+
+ buck1_reg: BUCK1 {
+ regulator-name = "VDD_ARM_1.2V";
+ regulator-min-microvolt = <950000>;
+ regulator-max-microvolt = <1350000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mfd/mc13xxx.txt b/Documentation/devicetree/bindings/mfd/mc13xxx.txt
index baf0798..abd9e3c 100644
--- a/Documentation/devicetree/bindings/mfd/mc13xxx.txt
+++ b/Documentation/devicetree/bindings/mfd/mc13xxx.txt
@@ -10,10 +10,40 @@
- fsl,mc13xxx-uses-touch : Indicate the touchscreen controller is being used
Sub-nodes:
-- regulators : Contain the regulator nodes. The MC13892 regulators are
- bound using their names as listed below with their registers and bits
- for enabling.
+- regulators : Contain the regulator nodes. The regulators are bound using
+ their names as listed below with their registers and bits for enabling.
+MC13783 regulators:
+ sw1a : regulator SW1A (register 24, bit 0)
+ sw1b : regulator SW1B (register 25, bit 0)
+ sw2a : regulator SW2A (register 26, bit 0)
+ sw2b : regulator SW2B (register 27, bit 0)
+ sw3 : regulator SW3 (register 29, bit 20)
+ vaudio : regulator VAUDIO (register 32, bit 0)
+ viohi : regulator VIOHI (register 32, bit 3)
+ violo : regulator VIOLO (register 32, bit 6)
+ vdig : regulator VDIG (register 32, bit 9)
+ vgen : regulator VGEN (register 32, bit 12)
+ vrfdig : regulator VRFDIG (register 32, bit 15)
+ vrfref : regulator VRFREF (register 32, bit 18)
+ vrfcp : regulator VRFCP (register 32, bit 21)
+ vsim : regulator VSIM (register 33, bit 0)
+ vesim : regulator VESIM (register 33, bit 3)
+ vcam : regulator VCAM (register 33, bit 6)
+ vrfbg : regulator VRFBG (register 33, bit 9)
+ vvib : regulator VVIB (register 33, bit 11)
+ vrf1 : regulator VRF1 (register 33, bit 12)
+ vrf2 : regulator VRF2 (register 33, bit 15)
+ vmmc1 : regulator VMMC1 (register 33, bit 18)
+ vmmc2 : regulator VMMC2 (register 33, bit 21)
+ gpo1 : regulator GPO1 (register 34, bit 6)
+ gpo2 : regulator GPO2 (register 34, bit 8)
+ gpo3 : regulator GPO3 (register 34, bit 10)
+ gpo4 : regulator GPO4 (register 34, bit 12)
+ pwgt1spi : regulator PWGT1SPI (register 34, bit 15)
+ pwgt2spi : regulator PWGT2SPI (register 34, bit 16)
+
+MC13892 regulators:
vcoincell : regulator VCOINCELL (register 13, bit 23)
sw1 : regulator SW1 (register 24, bit 0)
sw2 : regulator SW2 (register 25, bit 0)
diff --git a/Documentation/devicetree/bindings/mfd/omap-usb-host.txt b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
new file mode 100644
index 0000000..b381fa6
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
@@ -0,0 +1,80 @@
+OMAP HS USB Host
+
+Required properties:
+
+- compatible: should be "ti,usbhs-host"
+- reg: should contain one register range i.e. start and length
+- ti,hwmods: must contain "usb_host_hs"
+
+Optional properties:
+
+- num-ports: number of USB ports. Usually this is automatically detected
+ from the IP's revision register but can be overridden by specifying
+ this property. A maximum of 3 ports are supported at the moment.
+
+- portN-mode: String specifying the port mode for port N, where N can be
+ from 1 to 3. If the port mode is not specified, that port is treated
+ as unused. When specified, it must be one of the following.
+ "ehci-phy",
+ "ehci-tll",
+ "ehci-hsic",
+ "ohci-phy-6pin-datse0",
+ "ohci-phy-6pin-dpdm",
+ "ohci-phy-3pin-datse0",
+ "ohci-phy-4pin-dpdm",
+ "ohci-tll-6pin-datse0",
+ "ohci-tll-6pin-dpdm",
+ "ohci-tll-3pin-datse0",
+ "ohci-tll-4pin-dpdm",
+ "ohci-tll-2pin-datse0",
+ "ohci-tll-2pin-dpdm",
+
+- single-ulpi-bypass: Must be present if the controller contains a single
+ ULPI bypass control bit. e.g. OMAP3 silicon <= ES2.1
+
+Required properties if child node exists:
+
+- #address-cells: Must be 1
+- #size-cells: Must be 1
+- ranges: must be present
+
+Properties for children:
+
+The OMAP HS USB Host subsystem contains EHCI and OHCI controllers.
+See Documentation/devicetree/bindings/usb/omap-ehci.txt and
+omap3-ohci.txt
+
+Example for OMAP4:
+
+usbhshost: usbhshost@4a064000 {
+ compatible = "ti,usbhs-host";
+ reg = <0x4a064000 0x800>;
+ ti,hwmods = "usb_host_hs";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ usbhsohci: ohci@4a064800 {
+ compatible = "ti,ohci-omap3", "usb-ohci";
+ reg = <0x4a064800 0x400>;
+ interrupt-parent = <&gic>;
+ interrupts = <0 76 0x4>;
+ };
+
+ usbhsehci: ehci@4a064c00 {
+ compatible = "ti,ehci-omap", "usb-ehci";
+ reg = <0x4a064c00 0x400>;
+ interrupt-parent = <&gic>;
+ interrupts = <0 77 0x4>;
+ };
+};
+
+&usbhshost {
+ port1-mode = "ehci-phy";
+ port2-mode = "ehci-tll";
+ port3-mode = "ehci-phy";
+};
+
+&usbhsehci {
+ phys = <&hsusb1_phy 0 &hsusb3_phy>;
+};
diff --git a/Documentation/devicetree/bindings/mfd/omap-usb-tll.txt b/Documentation/devicetree/bindings/mfd/omap-usb-tll.txt
new file mode 100644
index 0000000..62fe697
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/omap-usb-tll.txt
@@ -0,0 +1,17 @@
+OMAP HS USB Host TLL (Transceiver-Less Interface)
+
+Required properties:
+
+- compatible : should be "ti,usbhs-tll"
+- reg : should contain one register range i.e. start and length
+- interrupts : should contain the TLL module's interrupt
+- ti,hwmod : must contain "usb_tll_hs"
+
+Example:
+
+ usbhstll: usbhstll@4a062000 {
+ compatible = "ti,usbhs-tll";
+ reg = <0x4a062000 0x1000>;
+ interrupts = <78>;
+ ti,hwmods = "usb_tll_hs";
+ };
diff --git a/Documentation/devicetree/bindings/mfd/palmas.txt b/Documentation/devicetree/bindings/mfd/palmas.txt
new file mode 100644
index 0000000..892537d
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/palmas.txt
@@ -0,0 +1,49 @@
+* palmas device tree bindings
+
+The TI palmas family current members :-
+twl6035 (palmas)
+twl6037 (palmas)
+tps65913 (palmas)
+tps65914 (palmas)
+
+Required properties:
+- compatible : Should be from the list
+ ti,twl6035
+ ti,twl6036
+ ti,twl6037
+ ti,tps65913
+ ti,tps65914
+ ti,tps80036
+and also the generic series names
+ ti,palmas
+- interrupt-controller : palmas has its own internal IRQs
+- #interrupt-cells : should be set to 2 for IRQ number and flags
+ The first cell is the IRQ number.
+ The second cell is the flags, encoded as the trigger masks from
+ Documentation/devicetree/bindings/interrupts.txt
+- interrupt-parent : The parent interrupt controller.
+
+Optional properties:
+ ti,mux-padX : set the pad register X (1-2) to the correct muxing for the
+ hardware, if not set will use muxing in OTP.
+
+Example:
+
+palmas {
+ compatible = "ti,twl6035", "ti,palmas";
+ reg = <0x48>
+ interrupt-parent = <&intc>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ ti,mux-pad1 = <0>;
+ ti,mux-pad2 = <0>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pmic {
+ compatible = "ti,twl6035-pmic", "ti,palmas-pmic";
+ ....
+ };
+}
diff --git a/Documentation/devicetree/bindings/mfd/tps6507x.txt b/Documentation/devicetree/bindings/mfd/tps6507x.txt
new file mode 100755
index 0000000..8fffa3c
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/tps6507x.txt
@@ -0,0 +1,91 @@
+TPS6507x Power Management Integrated Circuit
+
+Required properties:
+- compatible: "ti,tps6507x"
+- reg: I2C slave address
+- regulators: This is the list of child nodes that specify the regulator
+ initialization data for defined regulators. Not all regulators for the
+ given device need to be present. The definition for each of these nodes
+ is defined using the standard binding for regulators found at
+ Documentation/devicetree/bindings/regulator/regulator.txt.
+ The regulator is matched with the regulator-compatible.
+
+ The valid regulator-compatible values are:
+ tps6507x: vdcdc1, vdcdc2, vdcdc3, vldo1, vldo2
+- xxx-supply: Input voltage supply regulator.
+ These entries are required if regulators are enabled for a device.
+ Missing of these properties can cause the regulator registration
+ fails.
+ If some of input supply is powered through battery or always-on
+ supply then also it is require to have these parameters with proper
+ node handle of always on power supply.
+ tps6507x:
+ vindcdc1_2-supply: VDCDC1 and VDCDC2 input.
+ vindcdc3-supply : VDCDC3 input.
+ vldo1_2-supply : VLDO1 and VLDO2 input.
+
+Regulator Optional properties:
+- defdcdc_default: It's property of DCDC2 and DCDC3 regulators.
+ 0: If defdcdc pin of DCDC2/DCDC3 is pulled to GND.
+ 1: If defdcdc pin of DCDC2/DCDC3 is driven HIGH.
+ If this property is not defined, it defaults to 0 (not enabled).
+
+Example:
+
+ pmu: tps6507x@48 {
+ compatible = "ti,tps6507x";
+ reg = <0x48>;
+
+ vindcdc1_2-supply = <&vbat>;
+ vindcdc3-supply = <...>;
+ vinldo1_2-supply = <...>;
+
+ regulators {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ vdcdc1_reg: regulator@0 {
+ regulator-compatible = "VDCDC1";
+ reg = <0>;
+ regulator-min-microvolt = <3150000>;
+ regulator-max-microvolt = <3450000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+ vdcdc2_reg: regulator@1 {
+ regulator-compatible = "VDCDC2";
+ reg = <1>;
+ regulator-min-microvolt = <1710000>;
+ regulator-max-microvolt = <3450000>;
+ regulator-always-on;
+ regulator-boot-on;
+ defdcdc_default = <1>;
+ };
+ vdcdc3_reg: regulator@2 {
+ regulator-compatible = "VDCDC3";
+ reg = <2>;
+ regulator-min-microvolt = <950000>
+ regulator-max-microvolt = <1350000>;
+ regulator-always-on;
+ regulator-boot-on;
+ defdcdc_default = <1>;
+ };
+ ldo1_reg: regulator@3 {
+ regulator-compatible = "LDO1";
+ reg = <3>;
+ regulator-min-microvolt = <1710000>;
+ regulator-max-microvolt = <1890000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+ ldo2_reg: regulator@4 {
+ regulator-compatible = "LDO2";
+ reg = <4>;
+ regulator-min-microvolt = <1140000>;
+ regulator-max-microvolt = <1320000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+ };
+
+ };
diff --git a/Documentation/devicetree/bindings/mfd/twl4030-power.txt b/Documentation/devicetree/bindings/mfd/twl4030-power.txt
new file mode 100644
index 0000000..8e15ec3
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/twl4030-power.txt
@@ -0,0 +1,28 @@
+Texas Instruments TWL family (twl4030) reset and power management module
+
+The power management module inside the TWL family provides several facilities
+to control the power resources, including power scripts. For now, the
+binding only supports the complete shutdown of the system after poweroff.
+
+Required properties:
+- compatible : must be "ti,twl4030-power"
+
+Optional properties:
+- ti,use_poweroff: With this flag, the chip will initiates an ACTIVE-to-OFF or
+ SLEEP-to-OFF transition when the system poweroffs.
+
+Example:
+&i2c1 {
+ clock-frequency = <2600000>;
+
+ twl: twl@48 {
+ reg = <0x48>;
+ interrupts = <7>; /* SYS_NIRQ cascaded to intc */
+ interrupt-parent = <&intc>;
+
+ twl_power: power {
+ compatible = "ti,twl4030-power";
+ ti,use_poweroff;
+ };
+ };
+};
diff --git a/Documentation/devicetree/bindings/mips/cavium/dma-engine.txt b/Documentation/devicetree/bindings/mips/cavium/dma-engine.txt
index cb4291e..a5bdff40 100644
--- a/Documentation/devicetree/bindings/mips/cavium/dma-engine.txt
+++ b/Documentation/devicetree/bindings/mips/cavium/dma-engine.txt
@@ -1,7 +1,7 @@
* DMA Engine.
The Octeon DMA Engine transfers between the Boot Bus and main memory.
-The DMA Engine will be refered to by phandle by any device that is
+The DMA Engine will be referred to by phandle by any device that is
connected to it.
Properties:
diff --git a/Documentation/devicetree/bindings/mips/cpu_irq.txt b/Documentation/devicetree/bindings/mips/cpu_irq.txt
new file mode 100644
index 0000000..13aa4b6
--- /dev/null
+++ b/Documentation/devicetree/bindings/mips/cpu_irq.txt
@@ -0,0 +1,47 @@
+MIPS CPU interrupt controller
+
+On MIPS the mips_cpu_intc_init() helper can be used to initialize the 8 CPU
+IRQs from a devicetree file and create a irq_domain for IRQ controller.
+
+With the irq_domain in place we can describe how the 8 IRQs are wired to the
+platforms internal interrupt controller cascade.
+
+Below is an example of a platform describing the cascade inside the devicetree
+and the code used to load it inside arch_init_irq().
+
+Required properties:
+- compatible : Should be "mti,cpu-interrupt-controller"
+
+Example devicetree:
+ cpu-irq: cpu-irq@0 {
+ #address-cells = <0>;
+
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ compatible = "mti,cpu-interrupt-controller";
+ };
+
+ intc: intc@200 {
+ compatible = "ralink,rt2880-intc";
+ reg = <0x200 0x100>;
+
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ interrupt-parent = <&cpu-irq>;
+ interrupts = <2>;
+ };
+
+
+Example platform irq.c:
+static struct of_device_id __initdata of_irq_ids[] = {
+ { .compatible = "mti,cpu-interrupt-controller", .data = mips_cpu_intc_init },
+ { .compatible = "ralink,rt2880-intc", .data = intc_of_init },
+ {},
+};
+
+void __init arch_init_irq(void)
+{
+ of_irq_init(of_irq_ids);
+}
diff --git a/Documentation/devicetree/bindings/mips/ralink.txt b/Documentation/devicetree/bindings/mips/ralink.txt
new file mode 100644
index 0000000..b35a8d0
--- /dev/null
+++ b/Documentation/devicetree/bindings/mips/ralink.txt
@@ -0,0 +1,17 @@
+Ralink MIPS SoC device tree bindings
+
+1. SoCs
+
+Each device tree must specify a compatible value for the Ralink SoC
+it uses in the compatible property of the root node. The compatible
+value must be one of the following values:
+
+ ralink,rt2880-soc
+ ralink,rt3050-soc
+ ralink,rt3052-soc
+ ralink,rt3350-soc
+ ralink,rt3352-soc
+ ralink,rt3883-soc
+ ralink,rt5350-soc
+ ralink,mt7620a-soc
+ ralink,mt7620n-soc
diff --git a/Documentation/devicetree/bindings/misc/smc.txt b/Documentation/devicetree/bindings/misc/smc.txt
new file mode 100644
index 0000000..02b4281
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/smc.txt
@@ -0,0 +1,14 @@
+Broadcom Secure Monitor Bounce buffer
+-----------------------------------------------------
+This binding defines the location of the bounce buffer
+used for non-secure to secure communications.
+
+Required properties:
+- compatible : "bcm,kona-smc"
+- reg : Location and size of bounce buffer
+
+Example:
+ smc@0x3404c000 {
+ compatible = "bcm,bcm11351-smc", "bcm,kona-smc";
+ reg = <0x3404c000 0x400>; //1 KiB in SRAM
+ };
diff --git a/Documentation/devicetree/bindings/misc/sram.txt b/Documentation/devicetree/bindings/misc/sram.txt
new file mode 100644
index 0000000..4d0a00e
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/sram.txt
@@ -0,0 +1,16 @@
+Generic on-chip SRAM
+
+Simple IO memory regions to be managed by the genalloc API.
+
+Required properties:
+
+- compatible : mmio-sram
+
+- reg : SRAM iomem address range
+
+Example:
+
+sram: sram@5c000000 {
+ compatible = "mmio-sram";
+ reg = <0x5c000000 0x40000>; /* 256 KiB SRAM at address 0x5c000000 */
+};
diff --git a/Documentation/devicetree/bindings/mmc/bcm,kona-sdhci.txt b/Documentation/devicetree/bindings/mmc/bcm,kona-sdhci.txt
new file mode 100644
index 0000000..094ae01
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/bcm,kona-sdhci.txt
@@ -0,0 +1,16 @@
+Broadcom BCM281xx SDHCI
+
+This file documents differences between the core properties in mmc.txt
+and the properties present in the bcm281xx SDHCI
+
+Required properties:
+- compatible : Should be "bcm,kona-sdhci"
+
+Example:
+
+sdio2: sdio@0x3f1a0000 {
+ compatible = "bcm,kona-sdhci";
+ reg = <0x3f1a0000 0x10000>;
+ interrupts = <0x0 74 0x4>;
+};
+
diff --git a/Documentation/devicetree/bindings/mmc/brcm,bcm2835-sdhci.txt b/Documentation/devicetree/bindings/mmc/brcm,bcm2835-sdhci.txt
new file mode 100644
index 0000000..59476fb
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/brcm,bcm2835-sdhci.txt
@@ -0,0 +1,18 @@
+Broadcom BCM2835 SDHCI controller
+
+This file documents differences between the core properties described
+by mmc.txt and the properties that represent the BCM2835 controller.
+
+Required properties:
+- compatible : Should be "brcm,bcm2835-sdhci".
+- clocks : The clock feeding the SDHCI controller.
+
+Example:
+
+sdhci: sdhci {
+ compatible = "brcm,bcm2835-sdhci";
+ reg = <0x7e300000 0x100>;
+ interrupts = <2 30>;
+ clocks = <&clk_mmc>;
+ bus-width = <4>;
+};
diff --git a/Documentation/devicetree/bindings/mmc/davinci_mmc.txt b/Documentation/devicetree/bindings/mmc/davinci_mmc.txt
new file mode 100644
index 0000000..e5a0140
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/davinci_mmc.txt
@@ -0,0 +1,33 @@
+* TI Highspeed MMC host controller for DaVinci
+
+The Highspeed MMC Host Controller on TI DaVinci family
+provides an interface for MMC, SD and SDIO types of memory cards.
+
+This file documents the properties used by the davinci_mmc driver.
+
+Required properties:
+- compatible:
+ Should be "ti,da830-mmc": for da830, da850, dm365
+ Should be "ti,dm355-mmc": for dm355, dm644x
+
+Optional properties:
+- bus-width: Number of data lines, can be <1>, <4>, or <8>, default <1>
+- max-frequency: Maximum operating clock frequency, default 25MHz.
+- dmas: List of DMA specifiers with the controller specific format
+ as described in the generic DMA client binding. A tx and rx
+ specifier is required.
+- dma-names: RX and TX DMA request names. These strings correspond
+ 1:1 with the DMA specifiers listed in dmas.
+
+Example:
+mmc0: mmc@1c40000 {
+ compatible = "ti,da830-mmc",
+ reg = <0x40000 0x1000>;
+ interrupts = <16>;
+ status = "okay";
+ bus-width = <4>;
+ max-frequency = <50000000>;
+ dmas = <&edma 16
+ &edma 17>;
+ dma-names = "rx", "tx";
+};
diff --git a/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
index 7927689..6d1c098 100644
--- a/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
+++ b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
@@ -4,18 +4,18 @@
The Synopsis designware mobile storage host controller is used to interface
a SoC with storage medium such as eMMC or SD/MMC cards. This file documents
differences between the core Synopsis dw mshc controller properties described
-by synposis-dw-mshc.txt and the properties used by the Samsung Exynos specific
+by synopsis-dw-mshc.txt and the properties used by the Samsung Exynos specific
extensions to the Synopsis Designware Mobile Storage Host Controller.
Required Properties:
* compatible: should be
- "samsung,exynos4210-dw-mshc": for controllers with Samsung Exynos4210
- specific extentions.
+ specific extensions.
- "samsung,exynos4412-dw-mshc": for controllers with Samsung Exynos4412
- specific extentions.
+ specific extensions.
- "samsung,exynos5250-dw-mshc": for controllers with Samsung Exynos5250
- specific extentions.
+ specific extensions.
* samsung,dw-mshc-ciu-div: Specifies the divider value for the card interface
unit (ciu) clock. This property is applicable only for Exynos5 SoC's and
diff --git a/Documentation/devicetree/bindings/mmc/fsl-imx-mmc.txt b/Documentation/devicetree/bindings/mmc/fsl-imx-mmc.txt
new file mode 100644
index 0000000..db44235
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/fsl-imx-mmc.txt
@@ -0,0 +1,24 @@
+* Freescale Secure Digital Host Controller for i.MX2/3 series
+
+This file documents differences to the properties defined in mmc.txt.
+
+Required properties:
+- compatible : Should be "fsl,<chip>-mmc", chip can be imx21 or imx31
+
+Optional properties:
+- dmas: One DMA phandle with arguments as defined by the devicetree bindings
+ of the used DMA controller.
+- dma-names: Has to be "rx-tx".
+
+Example:
+
+sdhci1: sdhci@10014000 {
+ compatible = "fsl,imx27-mmc", "fsl,imx21-mmc";
+ reg = <0x10014000 0x1000>;
+ interrupts = <11>;
+ dmas = <&dma 7>;
+ dma-names = "rx-tx";
+ bus-width = <4>;
+ cd-gpios = <&gpio3 29>;
+ status = "okay";
+};
diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt b/Documentation/devicetree/bindings/mmc/mmc.txt
index a591c67..458b57f 100644
--- a/Documentation/devicetree/bindings/mmc/mmc.txt
+++ b/Documentation/devicetree/bindings/mmc/mmc.txt
@@ -6,23 +6,46 @@
- reg: Registers location and length.
- interrupts: Interrupts used by the MMC controller.
-Required properties:
-- bus-width: Number of data lines, can be <1>, <4>, or <8>
-
Card detection:
-If no property below is supplied, standard SDHCI card detect is used.
+If no property below is supplied, host native card detect is used.
Only one of the properties in this section should be supplied:
- broken-cd: There is no card detection available; polling must be used.
- cd-gpios: Specify GPIOs for card detection, see gpio binding
- non-removable: non-removable slot (like eMMC); assume always present.
Optional properties:
+- bus-width: Number of data lines, can be <1>, <4>, or <8>. The default
+ will be <1> if the property is absent.
- wp-gpios: Specify GPIOs for write protection, see gpio binding
-- cd-inverted: when present, polarity on the cd gpio line is inverted
-- wp-inverted: when present, polarity on the wp gpio line is inverted
+- cd-inverted: when present, polarity on the CD line is inverted. See the note
+ below for the case, when a GPIO is used for the CD line
+- wp-inverted: when present, polarity on the WP line is inverted. See the note
+ below for the case, when a GPIO is used for the WP line
- max-frequency: maximum operating clock frequency
- no-1-8-v: when present, denotes that 1.8v card voltage is not supported on
this system, even if the controller claims it is.
+- cap-sd-highspeed: SD high-speed timing is supported
+- cap-mmc-highspeed: MMC high-speed timing is supported
+- cap-power-off-card: powering off the card is safe
+- cap-sdio-irq: enable SDIO IRQ signalling on this interface
+- full-pwr-cycle: full power cycle of the card is supported
+
+*NOTE* on CD and WP polarity. To use common for all SD/MMC host controllers line
+polarity properties, we have to fix the meaning of the "normal" and "inverted"
+line levels. We choose to follow the SDHCI standard, which specifies both those
+lines as "active low." Therefore, using the "cd-inverted" property means, that
+the CD line is active high, i.e. it is high, when a card is inserted. Similar
+logic applies to the "wp-inverted" property.
+
+CD and WP lines can be implemented on the hardware in one of two ways: as GPIOs,
+specified in cd-gpios and wp-gpios properties, or as dedicated pins. Polarity of
+dedicated pins can be specified, using *-inverted properties. GPIO polarity can
+also be specified using the OF_GPIO_ACTIVE_LOW flag. This creates an ambiguity
+in the latter case. We choose to use the XOR logic for GPIO CD and WP lines.
+This means, the two properties are "superimposed," for example leaving the
+OF_GPIO_ACTIVE_LOW flag clear and specifying the respective *-inverted
+property results in a double-inversion and actually means the "normal" line
+polarity is in effect.
Optional SDIO properties:
- keep-power-in-suspend: Preserves card power during a suspend/resume cycle
diff --git a/Documentation/devicetree/bindings/mmc/mxs-mmc.txt b/Documentation/devicetree/bindings/mmc/mxs-mmc.txt
index 54949f6..515addc 100644
--- a/Documentation/devicetree/bindings/mmc/mxs-mmc.txt
+++ b/Documentation/devicetree/bindings/mmc/mxs-mmc.txt
@@ -9,15 +9,19 @@
Required properties:
- compatible: Should be "fsl,<chip>-mmc". The supported chips include
imx23 and imx28.
-- interrupts: Should contain ERROR and DMA interrupts
-- fsl,ssp-dma-channel: APBH DMA channel for the SSP
+- interrupts: Should contain ERROR interrupt number
+- dmas: DMA specifier, consisting of a phandle to DMA controller node
+ and SSP DMA channel ID.
+ Refer to dma.txt and fsl-mxs-dma.txt for details.
+- dma-names: Must be "rx-tx".
Examples:
ssp0: ssp@80010000 {
compatible = "fsl,imx28-mmc";
reg = <0x80010000 2000>;
- interrupts = <96 82>;
- fsl,ssp-dma-channel = <0>;
+ interrupts = <96>;
+ dmas = <&dma_apbh 0>;
+ dma-names = "rx-tx";
bus-width = <8>;
};
diff --git a/Documentation/devicetree/bindings/mmc/orion-sdio.txt b/Documentation/devicetree/bindings/mmc/orion-sdio.txt
new file mode 100644
index 0000000..84f0ebd
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/orion-sdio.txt
@@ -0,0 +1,17 @@
+* Marvell orion-sdio controller
+
+This file documents differences between the core properties in mmc.txt
+and the properties used by the orion-sdio driver.
+
+- compatible: Should be "marvell,orion-sdio"
+- clocks: reference to the clock of the SDIO interface
+
+Example:
+
+ mvsdio@d00d4000 {
+ compatible = "marvell,orion-sdio";
+ reg = <0xd00d4000 0x200>;
+ interrupts = <54>;
+ clocks = <&gateclk 17>;
+ status = "disabled";
+ };
diff --git a/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt b/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt
new file mode 100644
index 0000000..8a3d91d
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt
@@ -0,0 +1,23 @@
+* Rockchip specific extensions to the Synopsis Designware Mobile
+ Storage Host Controller
+
+The Synopsis designware mobile storage host controller is used to interface
+a SoC with storage medium such as eMMC or SD/MMC cards. This file documents
+differences between the core Synopsis dw mshc controller properties described
+by synopsis-dw-mshc.txt and the properties used by the Rockchip specific
+extensions to the Synopsis Designware Mobile Storage Host Controller.
+
+Required Properties:
+
+* compatible: should be
+ - "rockchip,rk2928-dw-mshc": for Rockchip RK2928 and following
+
+Example:
+
+ rkdwmmc0@12200000 {
+ compatible = "rockchip,rk2928-dw-mshc";
+ reg = <0x12200000 0x1000>;
+ interrupts = <0 75 0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt b/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt
index 97e9e31..328e990 100644
--- a/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt
+++ b/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt
@@ -5,13 +5,6 @@
core mmc properties described by mmc.txt and the properties used by the
Samsung implmentation of the SDHCI controller.
-Note: The mmc core bindings documentation states that if none of the core
-card-detect bindings are used, then the standard sdhci card detect mechanism
-is used. The Samsung's SDHCI controller bindings extends this as listed below.
-
-[A] The property "samsung,cd-pinmux-gpio" can be used as stated in the
- "Optional Board Specific Properties" section below.
-
Required SoC Specific Properties:
- compatible: should be one of the following
- "samsung,s3c6410-sdhci": For controllers compatible with s3c6410 sdhci
@@ -20,18 +13,8 @@
controller.
Required Board Specific Properties:
-- Samsung GPIO variant (will be completely replaced by pinctrl):
- - gpios: Should specify the gpios used for clock, command and data lines. The
- gpio specifier format depends on the gpio controller.
-- Pinctrl variant (preferred if available):
- - pinctrl-0: Should specify pin control groups used for this controller.
- - pinctrl-names: Should contain only one value - "default".
-
-Optional Board Specific Properties:
-- samsung,cd-pinmux-gpio: Specifies the card detect line that is routed
- through a pinmux to the card-detect pin of the card slot. This property
- should be used only if none of the mmc core card-detect properties are
- used. Only for Samsung GPIO variant.
+- pinctrl-0: Should specify pin control groups used for this controller.
+- pinctrl-names: Should contain only one value - "default".
Example:
sdhci@12530000 {
@@ -39,21 +22,11 @@
reg = <0x12530000 0x100>;
interrupts = <0 75 0>;
bus-width = <4>;
- cd-gpios = <&gpk2 2 2 3 3>;
-
- /* Samsung GPIO variant */
- gpios = <&gpk2 0 2 0 3>, /* clock line */
- <&gpk2 1 2 0 3>, /* command line */
- <&gpk2 3 2 3 3>, /* data line 0 */
- <&gpk2 4 2 3 3>, /* data line 1 */
- <&gpk2 5 2 3 3>, /* data line 2 */
- <&gpk2 6 2 3 3>; /* data line 3 */
-
- /* Pinctrl variant */
- pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus4>;
+ cd-gpios = <&gpk2 2 0>;
pinctrl-names = "default";
+ pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus4>;
};
Note: This example shows both SoC specific and board specific properties
- in a single device node. The properties can be actually be seperated
+ in a single device node. The properties can be actually be separated
into SoC specific node and board specific node.
diff --git a/Documentation/devicetree/bindings/mmc/sdhci-sirf.txt b/Documentation/devicetree/bindings/mmc/sdhci-sirf.txt
new file mode 100644
index 0000000..dd6ed464
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/sdhci-sirf.txt
@@ -0,0 +1,18 @@
+* SiRFprimII/marco/atlas6 SDHCI Controller
+
+This file documents differences between the core properties in mmc.txt
+and the properties used by the sdhci-sirf driver.
+
+Required properties:
+- compatible: sirf,prima2-sdhc
+
+Optional properties:
+- cd-gpios: card detect gpio, with zero flags.
+
+Example:
+
+ sd0: sdhci@56000000 {
+ compatible = "sirf,prima2-sdhc";
+ reg = <0xcd000000 0x100000>;
+ cd-gpios = <&gpio 6 0>;
+ };
diff --git a/Documentation/devicetree/bindings/mmc/synopsis-dw-mshc.txt b/Documentation/devicetree/bindings/mmc/synopsis-dw-mshc.txt
index 06cd32d08..cdcebea 100644
--- a/Documentation/devicetree/bindings/mmc/synopsis-dw-mshc.txt
+++ b/Documentation/devicetree/bindings/mmc/synopsis-dw-mshc.txt
@@ -26,11 +26,32 @@
* bus-width: as documented in mmc core bindings.
* wp-gpios: specifies the write protect gpio line. The format of the
- gpio specifier depends on the gpio controller. If the write-protect
- line is not available, this property is optional.
+ gpio specifier depends on the gpio controller. If a GPIO is not used
+ for write-protect, this property is optional.
+
+ * disable-wp: If the wp-gpios property isn't present then (by default)
+ we'd assume that the write protect is hooked up directly to the
+ controller's special purpose write protect line (accessible via
+ the WRTPRT register). However, it's possible that we simply don't
+ want write protect. In that case specify 'disable-wp'.
+ NOTE: This property is not required for slots known to always
+ connect to eMMC or SDIO cards.
Optional properties:
+* clocks: from common clock binding: handle to biu and ciu clocks for the
+ bus interface unit clock and the card interface unit clock.
+
+* clock-names: from common clock binding: Shall be "biu" and "ciu".
+ If the biu clock is missing we'll simply skip enabling it. If the
+ ciu clock is missing we'll just assume that the clock is running at
+ clock-frequency. It is an error to omit both the ciu clock and the
+ clock-frequency.
+
+* clock-frequency: should be the frequency (in Hz) of the ciu clock. If this
+ is specified and the ciu clock is specified then we'll try to set the ciu
+ clock to this at probe time.
+
* num-slots: specifies the number of slots supported by the controller.
The number of physical slots actually used could be equal or less than the
value specified by num-slots. If this property is not specified, the value
@@ -43,10 +64,13 @@
* card-detect-delay: Delay in milli-seconds before detecting card after card
insert event. The default value is 0.
-* supports-highspeed: Enables support for high speed cards (upto 50MHz)
+* supports-highspeed: Enables support for high speed cards (up to 50MHz)
* broken-cd: as documented in mmc core bindings.
+* vmmc-supply: The phandle to the regulator to use for vmmc. If this is
+ specified we'll defer probe until we can find this regulator.
+
Aliases:
- All the MSHC controller nodes should be represented in the aliases node using
@@ -59,6 +83,8 @@
dwmmc0@12200000 {
compatible = "snps,dw-mshc";
+ clocks = <&clock 351>, <&clock 132>;
+ clock-names = "biu", "ciu";
reg = <0x12200000 0x1000>;
interrupts = <0 75 0>;
#address-cells = <1>;
@@ -66,11 +92,13 @@
};
dwmmc0@12200000 {
+ clock-frequency = <400000000>;
num-slots = <1>;
supports-highspeed;
broken-cd;
fifo-depth = <0x80>;
card-detect-delay = <200>;
+ vmmc-supply = <&buck8>;
slot@0 {
reg = <0>;
diff --git a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
new file mode 100644
index 0000000..df204e1
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
@@ -0,0 +1,20 @@
+* Toshiba Mobile IO SD/MMC controller
+
+The tmio-mmc driver doesn't probe its devices actively, instead its binding to
+devices is managed by either MFD drivers or by the sh_mobile_sdhi platform
+driver. Those drivers supply the tmio-mmc driver with platform data, that either
+describe hardware capabilities, known to them, or are obtained by them from
+their own platform data or from their DT information. In the latter case all
+compulsory and any optional properties, common to all SD/MMC drivers, as
+described in mmc.txt, can be used. Additionally the following tmio_mmc-specific
+optional bindings can be used.
+
+Optional properties:
+- toshiba,mmc-wrprotect-disable: write-protect detection is unavailable
+
+When used with Renesas SDHI hardware, the following compatibility strings
+configure various model-specific properties:
+
+"renesas,sh7372-sdhi": (default) compatible with SH7372
+"renesas,r8a7740-sdhi": compatible with R8A7740: certain MMC/SD commands have to
+ wait for the interface to become idle.
diff --git a/Documentation/devicetree/bindings/mtd/elm.txt b/Documentation/devicetree/bindings/mtd/elm.txt
new file mode 100644
index 0000000..8c1528c
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/elm.txt
@@ -0,0 +1,16 @@
+Error location module
+
+Required properties:
+- compatible: Must be "ti,am33xx-elm"
+- reg: physical base address and size of the registers map.
+- interrupts: Interrupt number for the elm.
+
+Optional properties:
+- ti,hwmods: Name of the hwmod associated to the elm
+
+Example:
+elm: elm@0 {
+ compatible = "ti,am3352-elm";
+ reg = <0x48080000 0x2000>;
+ interrupts = <4>;
+};
diff --git a/Documentation/devicetree/bindings/mtd/fsmc-nand.txt b/Documentation/devicetree/bindings/mtd/fsmc-nand.txt
index e3ea32e..2240ac0 100644
--- a/Documentation/devicetree/bindings/mtd/fsmc-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/fsmc-nand.txt
@@ -1,7 +1,7 @@
* FSMC NAND
Required properties:
-- compatible : "st,spear600-fsmc-nand"
+- compatible : "st,spear600-fsmc-nand", "stericsson,fsmc-nand"
- reg : Address range of the mtd chip
- reg-names: Should contain the reg names "fsmc_regs", "nand_data", "nand_addr" and "nand_cmd"
diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
new file mode 100644
index 0000000..df338cb
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
@@ -0,0 +1,88 @@
+Device tree bindings for GPMC connected NANDs
+
+GPMC connected NAND (found on OMAP boards) are represented as child nodes of
+the GPMC controller with a name of "nand".
+
+All timing relevant properties as well as generic gpmc child properties are
+explained in a separate documents - please refer to
+Documentation/devicetree/bindings/bus/ti-gpmc.txt
+
+For NAND specific properties such as ECC modes or bus width, please refer to
+Documentation/devicetree/bindings/mtd/nand.txt
+
+
+Required properties:
+
+ - reg: The CS line the peripheral is connected to
+
+Optional properties:
+
+ - nand-bus-width: Set this numeric value to 16 if the hardware
+ is wired that way. If not specified, a bus
+ width of 8 is assumed.
+
+ - ti,nand-ecc-opt: A string setting the ECC layout to use. One of:
+
+ "sw" Software method (default)
+ "hw" Hardware method
+ "hw-romcode" gpmc hamming mode method & romcode layout
+ "bch4" 4-bit BCH ecc code
+ "bch8" 8-bit BCH ecc code
+
+ - ti,nand-xfer-type: A string setting the data transfer type. One of:
+
+ "prefetch-polled" Prefetch polled mode (default)
+ "polled" Polled mode, without prefetch
+ "prefetch-dma" Prefetch enabled sDMA mode
+ "prefetch-irq" Prefetch enabled irq mode
+
+ - elm_id: Specifies elm device node. This is required to support BCH
+ error correction using ELM module.
+
+For inline partiton table parsing (optional):
+
+ - #address-cells: should be set to 1
+ - #size-cells: should be set to 1
+
+Example for an AM33xx board:
+
+ gpmc: gpmc@50000000 {
+ compatible = "ti,am3352-gpmc";
+ ti,hwmods = "gpmc";
+ reg = <0x50000000 0x1000000>;
+ interrupts = <100>;
+ gpmc,num-cs = <8>;
+ gpmc,num-waitpins = <2>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges = <0 0 0x08000000 0x2000>; /* CS0: NAND */
+ elm_id = <&elm>;
+
+ nand@0,0 {
+ reg = <0 0 0>; /* CS0, offset 0 */
+ nand-bus-width = <16>;
+ ti,nand-ecc-opt = "bch8";
+ ti,nand-xfer-type = "polled";
+
+ gpmc,sync-clk-ps = <0>;
+ gpmc,cs-on-ns = <0>;
+ gpmc,cs-rd-off-ns = <44>;
+ gpmc,cs-wr-off-ns = <44>;
+ gpmc,adv-on-ns = <6>;
+ gpmc,adv-rd-off-ns = <34>;
+ gpmc,adv-wr-off-ns = <44>;
+ gpmc,we-off-ns = <40>;
+ gpmc,oe-off-ns = <54>;
+ gpmc,access-ns = <64>;
+ gpmc,rd-cycle-ns = <82>;
+ gpmc,wr-cycle-ns = <82>;
+ gpmc,wr-access-ns = <40>;
+ gpmc,wr-data-mux-bus-ns = <0>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ /* partitions go here */
+ };
+ };
+
diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nor.txt b/Documentation/devicetree/bindings/mtd/gpmc-nor.txt
new file mode 100644
index 0000000..420b3ab
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/gpmc-nor.txt
@@ -0,0 +1,98 @@
+Device tree bindings for NOR flash connect to TI GPMC
+
+NOR flash connected to the TI GPMC (found on OMAP boards) are represented as
+child nodes of the GPMC controller with a name of "nor".
+
+All timing relevant properties as well as generic GPMC child properties are
+explained in a separate documents. Please refer to
+Documentation/devicetree/bindings/bus/ti-gpmc.txt
+
+Required properties:
+- bank-width: Width of NOR flash in bytes. GPMC supports 8-bit and
+ 16-bit devices and so must be either 1 or 2 bytes.
+- compatible: Documentation/devicetree/bindings/mtd/mtd-physmap.txt
+- gpmc,cs-on-ns: Chip-select assertion time
+- gpmc,cs-rd-off-ns: Chip-select de-assertion time for reads
+- gpmc,cs-wr-off-ns: Chip-select de-assertion time for writes
+- gpmc,oe-on-ns: Output-enable assertion time
+- gpmc,oe-off-ns: Output-enable de-assertion time
+- gpmc,we-on-ns Write-enable assertion time
+- gpmc,we-off-ns: Write-enable de-assertion time
+- gpmc,access-ns: Start cycle to first data capture (read access)
+- gpmc,rd-cycle-ns: Total read cycle time
+- gpmc,wr-cycle-ns: Total write cycle time
+- linux,mtd-name: Documentation/devicetree/bindings/mtd/mtd-physmap.txt
+- reg: Chip-select, base address (relative to chip-select)
+ and size of NOR flash. Note that base address will be
+ typically 0 as this is the start of the chip-select.
+
+Optional properties:
+- gpmc,XXX Additional GPMC timings and settings parameters. See
+ Documentation/devicetree/bindings/bus/ti-gpmc.txt
+
+Optional properties for partiton table parsing:
+- #address-cells: should be set to 1
+- #size-cells: should be set to 1
+
+Example:
+
+gpmc: gpmc@6e000000 {
+ compatible = "ti,omap3430-gpmc", "simple-bus";
+ ti,hwmods = "gpmc";
+ reg = <0x6e000000 0x1000>;
+ interrupts = <20>;
+ gpmc,num-cs = <8>;
+ gpmc,num-waitpins = <4>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+
+ ranges = <0 0 0x10000000 0x08000000>;
+
+ nor@0,0 {
+ compatible = "cfi-flash";
+ linux,mtd-name= "intel,pf48f6000m0y1be";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0 0 0x08000000>;
+ bank-width = <2>;
+
+ gpmc,mux-add-data;
+ gpmc,cs-on-ns = <0>;
+ gpmc,cs-rd-off-ns = <186>;
+ gpmc,cs-wr-off-ns = <186>;
+ gpmc,adv-on-ns = <12>;
+ gpmc,adv-rd-off-ns = <48>;
+ gpmc,adv-wr-off-ns = <48>;
+ gpmc,oe-on-ns = <54>;
+ gpmc,oe-off-ns = <168>;
+ gpmc,we-on-ns = <54>;
+ gpmc,we-off-ns = <168>;
+ gpmc,rd-cycle-ns = <186>;
+ gpmc,wr-cycle-ns = <186>;
+ gpmc,access-ns = <114>;
+ gpmc,page-burst-access-ns = <6>;
+ gpmc,bus-turnaround-ns = <12>;
+ gpmc,cycle2cycle-delay-ns = <18>;
+ gpmc,wr-data-mux-bus-ns = <90>;
+ gpmc,wr-access-ns = <186>;
+ gpmc,cycle2cycle-samecsen;
+ gpmc,cycle2cycle-diffcsen;
+
+ partition@0 {
+ label = "bootloader-nor";
+ reg = <0 0x40000>;
+ };
+ partition@0x40000 {
+ label = "params-nor";
+ reg = <0x40000 0x40000>;
+ };
+ partition@0x80000 {
+ label = "kernel-nor";
+ reg = <0x80000 0x200000>;
+ };
+ partition@0x280000 {
+ label = "filesystem-nor";
+ reg = <0x240000 0x7d80000>;
+ };
+ };
+};
diff --git a/Documentation/devicetree/bindings/mtd/gpmc-onenand.txt b/Documentation/devicetree/bindings/mtd/gpmc-onenand.txt
new file mode 100644
index 0000000..b752942
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/gpmc-onenand.txt
@@ -0,0 +1,46 @@
+Device tree bindings for GPMC connected OneNANDs
+
+GPMC connected OneNAND (found on OMAP boards) are represented as child nodes of
+the GPMC controller with a name of "onenand".
+
+All timing relevant properties as well as generic gpmc child properties are
+explained in a separate documents - please refer to
+Documentation/devicetree/bindings/bus/ti-gpmc.txt
+
+Required properties:
+
+ - reg: The CS line the peripheral is connected to
+ - gpmc,device-width Width of the ONENAND device connected to the GPMC
+ in bytes. Must be 1 or 2.
+
+Optional properties:
+
+ - dma-channel: DMA Channel index
+
+For inline partiton table parsing (optional):
+
+ - #address-cells: should be set to 1
+ - #size-cells: should be set to 1
+
+Example for an OMAP3430 board:
+
+ gpmc: gpmc@6e000000 {
+ compatible = "ti,omap3430-gpmc";
+ ti,hwmods = "gpmc";
+ reg = <0x6e000000 0x1000000>;
+ interrupts = <20>;
+ gpmc,num-cs = <8>;
+ gpmc,num-waitpins = <4>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+
+ onenand@0 {
+ reg = <0 0 0>; /* CS0, offset 0 */
+ gpmc,device-width = <2>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ /* partitions go here */
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mtd/gpmi-nand.txt b/Documentation/devicetree/bindings/mtd/gpmi-nand.txt
index 3fb3f901..551b2a1 100644
--- a/Documentation/devicetree/bindings/mtd/gpmi-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/gpmi-nand.txt
@@ -7,10 +7,12 @@
- compatible : should be "fsl,<chip>-gpmi-nand"
- reg : should contain registers location and length for gpmi and bch.
- reg-names: Should contain the reg names "gpmi-nand" and "bch"
- - interrupts : The first is the DMA interrupt number for GPMI.
- The second is the BCH interrupt number.
- - interrupt-names : The interrupt names "gpmi-dma", "bch";
- - fsl,gpmi-dma-channel : Should contain the dma channel it uses.
+ - interrupts : BCH interrupt number.
+ - interrupt-names : Should be "bch".
+ - dmas: DMA specifier, consisting of a phandle to DMA controller node
+ and GPMI DMA channel ID.
+ Refer to dma.txt and fsl-mxs-dma.txt for details.
+ - dma-names: Must be "rx-tx".
Optional properties:
- nand-on-flash-bbt: boolean to enable on flash bbt option if not
@@ -27,9 +29,10 @@
#size-cells = <1>;
reg = <0x8000c000 2000>, <0x8000a000 2000>;
reg-names = "gpmi-nand", "bch";
- interrupts = <88>, <41>;
- interrupt-names = "gpmi-dma", "bch";
- fsl,gpmi-dma-channel = <4>;
+ interrupts = <41>;
+ interrupt-names = "bch";
+ dmas = <&dma_apbh 4>;
+ dma-names = "rx-tx";
partition@0 {
...
diff --git a/Documentation/devicetree/bindings/mtd/mtd-physmap.txt b/Documentation/devicetree/bindings/mtd/mtd-physmap.txt
index dab7847..61c5ec850 100644
--- a/Documentation/devicetree/bindings/mtd/mtd-physmap.txt
+++ b/Documentation/devicetree/bindings/mtd/mtd-physmap.txt
@@ -26,6 +26,9 @@
- linux,mtd-name: allow to specify the mtd name for retro capability with
physmap-flash drivers as boot loader pass the mtd partition via the old
device name physmap-flash.
+ - use-advanced-sector-protection: boolean to enable support for the
+ advanced sector protection (Spansion: PPB - Persistent Protection
+ Bits) locking.
For JEDEC compatible devices, the following additional properties
are defined:
diff --git a/Documentation/devicetree/bindings/mtd/partition.txt b/Documentation/devicetree/bindings/mtd/partition.txt
index 6e1f61f1..9315ac9 100644
--- a/Documentation/devicetree/bindings/mtd/partition.txt
+++ b/Documentation/devicetree/bindings/mtd/partition.txt
@@ -5,8 +5,12 @@
used for what purposes, but which don't use an on-flash partition table such
as RedBoot.
-#address-cells & #size-cells must both be present in the mtd device and be
-equal to 1.
+#address-cells & #size-cells must both be present in the mtd device. There are
+two valid values for both:
+<1>: for partitions that require a single 32-bit cell to represent their
+ size/address (aka the value is below 4 GiB)
+<2>: for partitions that require two 32-bit cells to represent their
+ size/address (aka the value is 4 GiB or greater).
Required properties:
- reg : The partition's offset and size within the mtd bank.
@@ -36,3 +40,31 @@
reg = <0x0100000 0x200000>;
};
};
+
+flash@1 {
+ #address-cells = <1>;
+ #size-cells = <2>;
+
+ /* a 4 GiB partition */
+ partition@0 {
+ label = "filesystem";
+ reg = <0x00000000 0x1 0x00000000>;
+ };
+};
+
+flash@2 {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ /* an 8 GiB partition */
+ partition@0 {
+ label = "filesystem #1";
+ reg = <0x0 0x00000000 0x2 0x00000000>;
+ };
+
+ /* a 4 GiB partition */
+ partition@200000000 {
+ label = "filesystem #2";
+ reg = <0x2 0x00000000 0x1 0x00000000>;
+ };
+};
diff --git a/Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt b/Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt
new file mode 100644
index 0000000..b90bfcd
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt
@@ -0,0 +1,22 @@
+* Allwinner EMAC ethernet controller
+
+Required properties:
+- compatible: should be "allwinner,sun4i-emac".
+- reg: address and length of the register set for the device.
+- interrupts: interrupt for the device
+- phy: A phandle to a phy node defining the PHY address (as the reg
+ property, a single integer).
+- clocks: A phandle to the reference clock for this device
+
+Optional properties:
+- (local-)mac-address: mac address to be used by this driver
+
+Example:
+
+emac: ethernet@01c0b000 {
+ compatible = "allwinner,sun4i-emac";
+ reg = <0x01c0b000 0x1000>;
+ interrupts = <55>;
+ clocks = <&ahb_gates 17>;
+ phy = <&phy0>;
+};
diff --git a/Documentation/devicetree/bindings/net/allwinner,sun4i-mdio.txt b/Documentation/devicetree/bindings/net/allwinner,sun4i-mdio.txt
new file mode 100644
index 0000000..00b9f9a
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/allwinner,sun4i-mdio.txt
@@ -0,0 +1,26 @@
+* Allwinner A10 MDIO Ethernet Controller interface
+
+Required properties:
+- compatible: should be "allwinner,sun4i-mdio".
+- reg: address and length of the register set for the device.
+
+Optional properties:
+- phy-supply: phandle to a regulator if the PHY needs one
+
+Example at the SoC level:
+mdio@01c0b080 {
+ compatible = "allwinner,sun4i-mdio";
+ reg = <0x01c0b080 0x14>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+};
+
+And at the board level:
+
+mdio@01c0b080 {
+ phy-supply = <®_emac_3v3>;
+
+ phy0: ethernet-phy@0 {
+ reg = <0>;
+ };
+};
diff --git a/Documentation/devicetree/bindings/net/arc_emac.txt b/Documentation/devicetree/bindings/net/arc_emac.txt
new file mode 100644
index 0000000..bcbc3f0
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/arc_emac.txt
@@ -0,0 +1,38 @@
+* Synopsys ARC EMAC 10/100 Ethernet driver (EMAC)
+
+Required properties:
+- compatible: Should be "snps,arc-emac"
+- reg: Address and length of the register set for the device
+- interrupts: Should contain the EMAC interrupts
+- clock-frequency: CPU frequency. It is needed to calculate and set polling
+period of EMAC.
+- max-speed: Maximum supported data-rate in Mbit/s. In some HW configurations
+bandwidth of external memory controller might be a limiting factor. That's why
+it's required to specify which data-rate is supported on current SoC or FPGA.
+For example if only 10 Mbit/s is supported (10BASE-T) set "10". If 100 Mbit/s is
+supported (100BASE-TX) set "100".
+- phy: PHY device attached to the EMAC via MDIO bus
+
+Child nodes of the driver are the individual PHY devices connected to the
+MDIO bus. They must have a "reg" property given the PHY address on the MDIO bus.
+
+Optional properties:
+- mac-address: 6 bytes, mac address
+
+Examples:
+
+ ethernet@c0fc2000 {
+ compatible = "snps,arc-emac";
+ reg = <0xc0fc2000 0x3c>;
+ interrupts = <6>;
+ mac-address = [ 00 11 22 33 44 55 ];
+ clock-frequency = <80000000>;
+ max-speed = <100>;
+ phy = <&phy0>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+ phy0: ethernet-phy@0 {
+ reg = <1>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/can/atmel-can.txt b/Documentation/devicetree/bindings/net/can/atmel-can.txt
new file mode 100644
index 0000000..72cf0c5
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/can/atmel-can.txt
@@ -0,0 +1,14 @@
+* AT91 CAN *
+
+Required properties:
+ - compatible: Should be "atmel,at91sam9263-can" or "atmel,at91sam9x5-can"
+ - reg: Should contain CAN controller registers location and length
+ - interrupts: Should contain IRQ line for the CAN controller
+
+Example:
+
+ can0: can@f000c000 {
+ compatbile = "atmel,at91sam9x5-can";
+ reg = <0xf000c000 0x300>;
+ interrupts = <40 4 5>
+ };
diff --git a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
index 8ff324e..56d6cc3 100644
--- a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
+++ b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
@@ -16,6 +16,8 @@
- clock-frequency : The oscillator frequency driving the flexcan device
+- xceiver-supply: Regulator that powers the CAN transceiver
+
Example:
can@1c000 {
diff --git a/Documentation/devicetree/bindings/net/cpsw.txt b/Documentation/devicetree/bindings/net/cpsw.txt
index 6ddd028..05d660e 100644
--- a/Documentation/devicetree/bindings/net/cpsw.txt
+++ b/Documentation/devicetree/bindings/net/cpsw.txt
@@ -15,15 +15,25 @@
- mac_control : Specifies Default MAC control register content
for the specific platform
- slaves : Specifies number for slaves
-- cpts_active_slave : Specifies the slave to use for time stamping
+- active_slave : Specifies the slave to use for time stamping,
+ ethtool and SIOCGMIIPHY
- cpts_clock_mult : Numerator to convert input clock ticks into nanoseconds
- cpts_clock_shift : Denominator to convert input clock ticks into nanoseconds
-- phy_id : Specifies slave phy id
-- mac-address : Specifies slave MAC address
Optional properties:
- ti,hwmods : Must be "cpgmac0"
- no_bd_ram : Must be 0 or 1
+- dual_emac : Specifies Switch to act as Dual EMAC
+
+Slave Properties:
+Required properties:
+- phy_id : Specifies slave phy id
+- phy-mode : The interface between the SoC and the PHY (a string
+ that of_get_phy_mode() can understand)
+- mac-address : Specifies slave MAC address
+
+Optional properties:
+- dual_emac_res_vlan : Specifies VID to be used to segregate the ports
Note: "ti,hwmods" field is used to fetch the base address and irq
resources from TI, omap hwmod data base during device registration.
@@ -45,16 +55,18 @@
rx_descs = <64>;
mac_control = <0x20>;
slaves = <2>;
- cpts_active_slave = <0>;
+ active_slave = <0>;
cpts_clock_mult = <0x80000000>;
cpts_clock_shift = <29>;
cpsw_emac0: slave@0 {
phy_id = <&davinci_mdio>, <0>;
+ phy-mode = "rgmii-txid";
/* Filled in by U-Boot */
mac-address = [ 00 00 00 00 00 00 ];
};
cpsw_emac1: slave@1 {
phy_id = <&davinci_mdio>, <1>;
+ phy-mode = "rgmii-txid";
/* Filled in by U-Boot */
mac-address = [ 00 00 00 00 00 00 ];
};
@@ -71,16 +83,18 @@
rx_descs = <64>;
mac_control = <0x20>;
slaves = <2>;
- cpts_active_slave = <0>;
+ active_slave = <0>;
cpts_clock_mult = <0x80000000>;
cpts_clock_shift = <29>;
cpsw_emac0: slave@0 {
phy_id = <&davinci_mdio>, <0>;
+ phy-mode = "rgmii-txid";
/* Filled in by U-Boot */
mac-address = [ 00 00 00 00 00 00 ];
};
cpsw_emac1: slave@1 {
phy_id = <&davinci_mdio>, <1>;
+ phy-mode = "rgmii-txid";
/* Filled in by U-Boot */
mac-address = [ 00 00 00 00 00 00 ];
};
diff --git a/Documentation/devicetree/bindings/net/davicom-dm9000.txt b/Documentation/devicetree/bindings/net/davicom-dm9000.txt
new file mode 100644
index 0000000..2d39c99
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/davicom-dm9000.txt
@@ -0,0 +1,26 @@
+Davicom DM9000 Fast Ethernet controller
+
+Required properties:
+- compatible = "davicom,dm9000";
+- reg : physical addresses and sizes of registers, must contain 2 entries:
+ first entry : address register,
+ second entry : data register.
+- interrupt-parent : interrupt controller to which the device is connected
+- interrupts : interrupt specifier specific to interrupt controller
+
+Optional properties:
+- local-mac-address : A bytestring of 6 bytes specifying Ethernet MAC address
+ to use (from firmware or bootloader)
+- davicom,no-eeprom : Configuration EEPROM is not available
+- davicom,ext-phy : Use external PHY
+
+Example:
+
+ ethernet@18000000 {
+ compatible = "davicom,dm9000";
+ reg = <0x18000000 0x2 0x18000004 0x2>;
+ interrupt-parent = <&gpn>;
+ interrupts = <7 4>;
+ local-mac-address = [00 00 de ad be ef];
+ davicom,no-eeprom;
+ };
diff --git a/Documentation/devicetree/bindings/net/dsa/dsa.txt b/Documentation/devicetree/bindings/net/dsa/dsa.txt
new file mode 100644
index 0000000..49f4f7a
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/dsa/dsa.txt
@@ -0,0 +1,91 @@
+Marvell Distributed Switch Architecture Device Tree Bindings
+------------------------------------------------------------
+
+Required properties:
+- compatible : Should be "marvell,dsa"
+- #address-cells : Must be 2, first cell is the address on the MDIO bus
+ and second cell is the address in the switch tree.
+ Second cell is used only when cascading/chaining.
+- #size-cells : Must be 0
+- dsa,ethernet : Should be a phandle to a valid Ethernet device node
+- dsa,mii-bus : Should be a phandle to a valid MDIO bus device node
+
+Optionnal properties:
+- interrupts : property with a value describing the switch
+ interrupt number (not supported by the driver)
+
+A DSA node can contain multiple switch chips which are therefore child nodes of
+the parent DSA node. The maximum number of allowed child nodes is 4
+(DSA_MAX_SWITCHES).
+Each of these switch child nodes should have the following required properties:
+
+- reg : Describes the switch address on the MII bus
+- #address-cells : Must be 1
+- #size-cells : Must be 0
+
+A switch may have multiple "port" children nodes
+
+Each port children node must have the following mandatory properties:
+- reg : Describes the port address in the switch
+- label : Describes the label associated with this port, special
+ labels are "cpu" to indicate a CPU port and "dsa" to
+ indicate an uplink/downlink port.
+
+Note that a port labelled "dsa" will imply checking for the uplink phandle
+described below.
+
+Optionnal property:
+- link : Should be a phandle to another switch's DSA port.
+ This property is only used when switches are being
+ chained/cascaded together.
+
+Example:
+
+ dsa@0 {
+ compatible = "marvell,dsa";
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ interrupts = <10>;
+ dsa,ethernet = <ðernet0>;
+ dsa,mii-bus = <&mii_bus0>;
+
+ switch@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <16 0>; /* MDIO address 16, switch 0 in tree */
+
+ port@0 {
+ reg = <0>;
+ label = "lan1";
+ };
+
+ port@1 {
+ reg = <1>;
+ label = "lan2";
+ };
+
+ port@5 {
+ reg = <5>;
+ label = "cpu";
+ };
+
+ switch0uplink: port@6 {
+ reg = <6>;
+ label = "dsa";
+ link = <&switch1uplink>;
+ };
+ };
+
+ switch@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <17 1>; /* MDIO address 17, switch 1 in tree */
+
+ switch1uplink: port@0 {
+ reg = <0>;
+ label = "dsa";
+ link = <&switch0uplink>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/gpmc-eth.txt b/Documentation/devicetree/bindings/net/gpmc-eth.txt
new file mode 100644
index 0000000..ace4a64
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/gpmc-eth.txt
@@ -0,0 +1,97 @@
+Device tree bindings for Ethernet chip connected to TI GPMC
+
+Besides being used to interface with external memory devices, the
+General-Purpose Memory Controller can be used to connect Pseudo-SRAM devices
+such as ethernet controllers to processors using the TI GPMC as a data bus.
+
+Ethernet controllers connected to TI GPMC are represented as child nodes of
+the GPMC controller with an "ethernet" name.
+
+All timing relevant properties as well as generic GPMC child properties are
+explained in a separate documents. Please refer to
+Documentation/devicetree/bindings/bus/ti-gpmc.txt
+
+For the properties relevant to the ethernet controller connected to the GPMC
+refer to the binding documentation of the device. For example, the documentation
+for the SMSC 911x is Documentation/devicetree/bindings/net/smsc911x.txt
+
+Child nodes need to specify the GPMC bus address width using the "bank-width"
+property but is possible that an ethernet controller also has a property to
+specify the I/O registers address width. Even when the GPMC has a maximum 16-bit
+address width, it supports devices with 32-bit word registers.
+For example with an SMSC LAN911x/912x controller connected to the TI GPMC on an
+OMAP2+ board, "bank-width = <2>;" and "reg-io-width = <4>;".
+
+Required properties:
+- bank-width: Address width of the device in bytes. GPMC supports 8-bit
+ and 16-bit devices and so must be either 1 or 2 bytes.
+- compatible: Compatible string property for the ethernet child device.
+- gpmc,cs-on-ns: Chip-select assertion time
+- gpmc,cs-rd-off-ns: Chip-select de-assertion time for reads
+- gpmc,cs-wr-off-ns: Chip-select de-assertion time for writes
+- gpmc,oe-on-ns: Output-enable assertion time
+- gpmc,oe-off-ns: Output-enable de-assertion time
+- gpmc,we-on-ns: Write-enable assertion time
+- gpmc,we-off-ns: Write-enable de-assertion time
+- gpmc,access-ns: Start cycle to first data capture (read access)
+- gpmc,rd-cycle-ns: Total read cycle time
+- gpmc,wr-cycle-ns: Total write cycle time
+- reg: Chip-select, base address (relative to chip-select)
+ and size of the memory mapped for the device.
+ Note that base address will be typically 0 as this
+ is the start of the chip-select.
+
+Optional properties:
+- gpmc,XXX Additional GPMC timings and settings parameters. See
+ Documentation/devicetree/bindings/bus/ti-gpmc.txt
+
+Example:
+
+gpmc: gpmc@6e000000 {
+ compatible = "ti,omap3430-gpmc";
+ ti,hwmods = "gpmc";
+ reg = <0x6e000000 0x1000>;
+ interrupts = <20>;
+ gpmc,num-cs = <8>;
+ gpmc,num-waitpins = <4>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+
+ ranges = <5 0 0x2c000000 0x1000000>;
+
+ ethernet@5,0 {
+ compatible = "smsc,lan9221", "smsc,lan9115";
+ reg = <5 0 0xff>;
+ bank-width = <2>;
+
+ gpmc,mux-add-data;
+ gpmc,cs-on-ns = <0>;
+ gpmc,cs-rd-off-ns = <186>;
+ gpmc,cs-wr-off-ns = <186>;
+ gpmc,adv-on-ns = <12>;
+ gpmc,adv-rd-off-ns = <48>;
+ gpmc,adv-wr-off-ns = <48>;
+ gpmc,oe-on-ns = <54>;
+ gpmc,oe-off-ns = <168>;
+ gpmc,we-on-ns = <54>;
+ gpmc,we-off-ns = <168>;
+ gpmc,rd-cycle-ns = <186>;
+ gpmc,wr-cycle-ns = <186>;
+ gpmc,access-ns = <114>;
+ gpmc,page-burst-access-ns = <6>;
+ gpmc,bus-turnaround-ns = <12>;
+ gpmc,cycle2cycle-delay-ns = <18>;
+ gpmc,wr-data-mux-bus-ns = <90>;
+ gpmc,wr-access-ns = <186>;
+ gpmc,cycle2cycle-samecsen;
+ gpmc,cycle2cycle-diffcsen;
+
+ interrupt-parent = <&gpio6>;
+ interrupts = <16>;
+ vmmc-supply = <&vddvario>;
+ vmmc_aux-supply = <&vdd33a>;
+ reg-io-width = <4>;
+
+ smsc,save-mac-address;
+ };
+};
diff --git a/Documentation/devicetree/bindings/net/macb.txt b/Documentation/devicetree/bindings/net/macb.txt
index 44afa0e..4ff6504 100644
--- a/Documentation/devicetree/bindings/net/macb.txt
+++ b/Documentation/devicetree/bindings/net/macb.txt
@@ -4,7 +4,7 @@
- compatible: Should be "cdns,[<chip>-]{macb|gem}"
Use "cdns,at91sam9260-macb" Atmel at91sam9260 and at91sam9263 SoCs.
Use "cdns,at32ap7000-macb" for other 10/100 usage or use the generic form: "cdns,macb".
- Use "cnds,pc302-gem" for Picochip picoXcell pc302 and later devices based on
+ Use "cdns,pc302-gem" for Picochip picoXcell pc302 and later devices based on
the Cadence GEM, or the generic form: "cdns,gem".
- reg: Address and length of the register set for the device
- interrupts: Should contain macb interrupt
diff --git a/Documentation/devicetree/bindings/net/marvell-orion-mdio.txt b/Documentation/devicetree/bindings/net/marvell-orion-mdio.txt
index 34e7aaf..9417e54 100644
--- a/Documentation/devicetree/bindings/net/marvell-orion-mdio.txt
+++ b/Documentation/devicetree/bindings/net/marvell-orion-mdio.txt
@@ -9,6 +9,10 @@
- compatible: "marvell,orion-mdio"
- reg: address and length of the SMI register
+Optional properties:
+- interrupts: interrupt line number for the SMI error/done interrupt
+- clocks: Phandle to the clock control device and gate bit
+
The child nodes of the MDIO driver are the individual PHY devices
connected to this MDIO bus. They must have a "reg" property given the
PHY address on the MDIO bus.
diff --git a/Documentation/devicetree/bindings/net/marvell-orion-net.txt b/Documentation/devicetree/bindings/net/marvell-orion-net.txt
new file mode 100644
index 0000000..a73b79f
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/marvell-orion-net.txt
@@ -0,0 +1,85 @@
+Marvell Orion/Discovery ethernet controller
+=============================================
+
+The Marvell Discovery ethernet controller can be found on Marvell Orion SoCs
+(Kirkwood, Dove, Orion5x, and Discovery Innovation) and as part of Marvell
+Discovery system controller chips (mv64[345]60).
+
+The Discovery ethernet controller is described with two levels of nodes. The
+first level describes the ethernet controller itself and the second level
+describes up to 3 ethernet port nodes within that controller. The reason for
+the multiple levels is that the port registers are interleaved within a single
+set of controller registers. Each port node describes port-specific properties.
+
+Note: The above separation is only true for Discovery system controllers.
+For Orion SoCs we stick to the separation, although there each controller has
+only one port associated. Multiple ports are implemented as multiple single-port
+controllers. As Kirkwood has some issues with proper initialization after reset,
+an extra compatible string is added for it.
+
+* Ethernet controller node
+
+Required controller properties:
+ - #address-cells: shall be 1.
+ - #size-cells: shall be 0.
+ - compatible: shall be one of "marvell,orion-eth", "marvell,kirkwood-eth".
+ - reg: address and length of the controller registers.
+
+Optional controller properties:
+ - clocks: phandle reference to the controller clock.
+ - marvell,tx-checksum-limit: max tx packet size for hardware checksum.
+
+* Ethernet port node
+
+Required port properties:
+ - device_type: shall be "network".
+ - compatible: shall be one of "marvell,orion-eth-port",
+ "marvell,kirkwood-eth-port".
+ - reg: port number relative to ethernet controller, shall be 0, 1, or 2.
+ - interrupts: port interrupt.
+ - local-mac-address: 6 bytes MAC address.
+
+Optional port properties:
+ - marvell,tx-queue-size: size of the transmit ring buffer.
+ - marvell,tx-sram-addr: address of transmit descriptor buffer located in SRAM.
+ - marvell,tx-sram-size: size of transmit descriptor buffer located in SRAM.
+ - marvell,rx-queue-size: size of the receive ring buffer.
+ - marvell,rx-sram-addr: address of receive descriptor buffer located in SRAM.
+ - marvell,rx-sram-size: size of receive descriptor buffer located in SRAM.
+
+and
+
+ - phy-handle: phandle reference to ethernet PHY.
+
+or
+
+ - speed: port speed if no PHY connected.
+ - duplex: port mode if no PHY connected.
+
+* Node example:
+
+mdio-bus {
+ ...
+ ethphy: ethernet-phy@8 {
+ device_type = "ethernet-phy";
+ ...
+ };
+};
+
+eth: ethernet-controller@72000 {
+ compatible = "marvell,orion-eth";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x72000 0x2000>;
+ clocks = <&gate_clk 2>;
+ marvell,tx-checksum-limit = <1600>;
+
+ ethernet@0 {
+ device_type = "network";
+ compatible = "marvell,orion-eth-port";
+ reg = <0>;
+ interrupts = <29>;
+ phy-handle = <ðphy>;
+ local-mac-address = [00 00 00 00 00 00];
+ };
+};
diff --git a/Documentation/devicetree/bindings/net/micrel-ks8851.txt b/Documentation/devicetree/bindings/net/micrel-ks8851.txt
new file mode 100644
index 0000000..11ace3c
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/micrel-ks8851.txt
@@ -0,0 +1,9 @@
+Micrel KS8851 Ethernet mac
+
+Required properties:
+- compatible = "micrel,ks8851-ml" of parallel interface
+- reg : 2 physical address and size of registers for data and command
+- interrupts : interrupt connection
+
+Optional properties:
+- local-mac-address : Ethernet mac address to use
diff --git a/Documentation/devicetree/bindings/net/stmmac.txt b/Documentation/devicetree/bindings/net/stmmac.txt
index 060bbf0..261c563 100644
--- a/Documentation/devicetree/bindings/net/stmmac.txt
+++ b/Documentation/devicetree/bindings/net/stmmac.txt
@@ -12,6 +12,16 @@
property
- phy-mode: String, operation mode of the PHY interface.
Supported values are: "mii", "rmii", "gmii", "rgmii".
+- snps,phy-addr phy address to connect to.
+- snps,reset-gpio gpio number for phy reset.
+- snps,reset-active-low boolean flag to indicate if phy reset is active low.
+- snps,reset-delays-us is triplet of delays
+ The 1st cell is reset pre-delay in micro seconds.
+ The 2nd cell is reset pulse in micro seconds.
+ The 3rd cell is reset post-delay in micro seconds.
+- snps,pbl Programmable Burst Length
+- snps,fixed-burst Program the DMA to use the fixed burst mode
+- snps,mixed-burst Program the DMA to use the mixed burst mode
Optional properties:
- mac-address: 6 bytes, mac address
diff --git a/Documentation/devicetree/bindings/net/via-velocity.txt b/Documentation/devicetree/bindings/net/via-velocity.txt
new file mode 100644
index 0000000..b3db469
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/via-velocity.txt
@@ -0,0 +1,20 @@
+* VIA Velocity 10/100/1000 Network Controller
+
+Required properties:
+- compatible : Should be "via,velocity-vt6110"
+- reg : Address and length of the io space
+- interrupts : Should contain the controller interrupt line
+
+Optional properties:
+- no-eeprom : PCI network cards use an external EEPROM to store data. Embedded
+ devices quite often set this data in uboot and do not provide an eeprom.
+ Specify this option if you have no external eeprom.
+
+Examples:
+
+eth0@d8004000 {
+ compatible = "via,velocity-vt6110";
+ reg = <0xd8004000 0x400>;
+ interrupts = <10>;
+ no-eeprom;
+};
diff --git a/Documentation/devicetree/bindings/pci/designware-pcie.txt b/Documentation/devicetree/bindings/pci/designware-pcie.txt
new file mode 100644
index 0000000..e2371f5
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/designware-pcie.txt
@@ -0,0 +1,73 @@
+* Synopsis Designware PCIe interface
+
+Required properties:
+- compatible: should contain "snps,dw-pcie" to identify the
+ core, plus an identifier for the specific instance, such
+ as "samsung,exynos5440-pcie".
+- reg: base addresses and lengths of the pcie controller,
+ the phy controller, additional register for the phy controller.
+- interrupts: interrupt values for level interrupt,
+ pulse interrupt, special interrupt.
+- clocks: from common clock binding: handle to pci clock.
+- clock-names: from common clock binding: should be "pcie" and "pcie_bus".
+- #address-cells: set to <3>
+- #size-cells: set to <2>
+- device_type: set to "pci"
+- ranges: ranges for the PCI memory and I/O regions
+- #interrupt-cells: set to <1>
+- interrupt-map-mask and interrupt-map: standard PCI properties
+ to define the mapping of the PCIe interface to interrupt
+ numbers.
+- reset-gpio: gpio pin number of power good signal
+
+Example:
+
+SoC specific DT Entry:
+
+ pcie@290000 {
+ compatible = "samsung,exynos5440-pcie", "snps,dw-pcie";
+ reg = <0x290000 0x1000
+ 0x270000 0x1000
+ 0x271000 0x40>;
+ interrupts = <0 20 0>, <0 21 0>, <0 22 0>;
+ clocks = <&clock 28>, <&clock 27>;
+ clock-names = "pcie", "pcie_bus";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ ranges = <0x00000800 0 0x40000000 0x40000000 0 0x00001000 /* configuration space */
+ 0x81000000 0 0 0x40001000 0 0x00010000 /* downstream I/O */
+ 0x82000000 0 0x40011000 0x40011000 0 0x1ffef000>; /* non-prefetchable memory */
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 0>;
+ interrupt-map = <0x0 0 &gic 53>;
+ };
+
+ pcie@2a0000 {
+ compatible = "samsung,exynos5440-pcie", "snps,dw-pcie";
+ reg = <0x2a0000 0x1000
+ 0x272000 0x1000
+ 0x271040 0x40>;
+ interrupts = <0 23 0>, <0 24 0>, <0 25 0>;
+ clocks = <&clock 29>, <&clock 27>;
+ clock-names = "pcie", "pcie_bus";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ ranges = <0x00000800 0 0x60000000 0x60000000 0 0x00001000 /* configuration space */
+ 0x81000000 0 0 0x60001000 0 0x00010000 /* downstream I/O */
+ 0x82000000 0 0x60011000 0x60011000 0 0x1ffef000>; /* non-prefetchable memory */
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 0>;
+ interrupt-map = <0x0 0 &gic 56>;
+ };
+
+Board specific DT Entry:
+
+ pcie@290000 {
+ reset-gpio = <&pin_ctrl 5 0>;
+ };
+
+ pcie@2a0000 {
+ reset-gpio = <&pin_ctrl 22 0>;
+ };
diff --git a/Documentation/devicetree/bindings/pci/mvebu-pci.txt b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
new file mode 100644
index 0000000..f8d4058
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
@@ -0,0 +1,221 @@
+* Marvell EBU PCIe interfaces
+
+Mandatory properties:
+- compatible: one of the following values:
+ marvell,armada-370-pcie
+ marvell,armada-xp-pcie
+ marvell,kirkwood-pcie
+- #address-cells, set to <3>
+- #size-cells, set to <2>
+- #interrupt-cells, set to <1>
+- bus-range: PCI bus numbers covered
+- device_type, set to "pci"
+- ranges: ranges for the PCI memory and I/O regions, as well as the
+ MMIO registers to control the PCIe interfaces.
+
+In addition, the Device Tree node must have sub-nodes describing each
+PCIe interface, having the following mandatory properties:
+- reg: used only for interrupt mapping, so only the first four bytes
+ are used to refer to the correct bus number and device number.
+- assigned-addresses: reference to the MMIO registers used to control
+ this PCIe interface.
+- clocks: the clock associated to this PCIe interface
+- marvell,pcie-port: the physical PCIe port number
+- status: either "disabled" or "okay"
+- device_type, set to "pci"
+- #address-cells, set to <3>
+- #size-cells, set to <2>
+- #interrupt-cells, set to <1>
+- ranges, empty property.
+- interrupt-map-mask and interrupt-map, standard PCI properties to
+ define the mapping of the PCIe interface to interrupt numbers.
+
+and the following optional properties:
+- marvell,pcie-lane: the physical PCIe lane number, for ports having
+ multiple lanes. If this property is not found, we assume that the
+ value is 0.
+
+Example:
+
+pcie-controller {
+ compatible = "marvell,armada-xp-pcie";
+ status = "disabled";
+ device_type = "pci";
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+
+ bus-range = <0x00 0xff>;
+
+ ranges = <0x82000000 0 0xd0040000 0xd0040000 0 0x00002000 /* Port 0.0 registers */
+ 0x82000000 0 0xd0042000 0xd0042000 0 0x00002000 /* Port 2.0 registers */
+ 0x82000000 0 0xd0044000 0xd0044000 0 0x00002000 /* Port 0.1 registers */
+ 0x82000000 0 0xd0048000 0xd0048000 0 0x00002000 /* Port 0.2 registers */
+ 0x82000000 0 0xd004c000 0xd004c000 0 0x00002000 /* Port 0.3 registers */
+ 0x82000000 0 0xd0080000 0xd0080000 0 0x00002000 /* Port 1.0 registers */
+ 0x82000000 0 0xd0082000 0xd0082000 0 0x00002000 /* Port 3.0 registers */
+ 0x82000000 0 0xd0084000 0xd0084000 0 0x00002000 /* Port 1.1 registers */
+ 0x82000000 0 0xd0088000 0xd0088000 0 0x00002000 /* Port 1.2 registers */
+ 0x82000000 0 0xd008c000 0xd008c000 0 0x00002000 /* Port 1.3 registers */
+ 0x82000000 0 0xe0000000 0xe0000000 0 0x08000000 /* non-prefetchable memory */
+ 0x81000000 0 0 0xe8000000 0 0x00100000>; /* downstream I/O */
+
+ pcie@1,0 {
+ device_type = "pci";
+ assigned-addresses = <0x82000800 0 0xd0040000 0 0x2000>;
+ reg = <0x0800 0 0 0 0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ ranges;
+ interrupt-map-mask = <0 0 0 0>;
+ interrupt-map = <0 0 0 0 &mpic 58>;
+ marvell,pcie-port = <0>;
+ marvell,pcie-lane = <0>;
+ clocks = <&gateclk 5>;
+ status = "disabled";
+ };
+
+ pcie@2,0 {
+ device_type = "pci";
+ assigned-addresses = <0x82001000 0 0xd0044000 0 0x2000>;
+ reg = <0x1000 0 0 0 0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ ranges;
+ interrupt-map-mask = <0 0 0 0>;
+ interrupt-map = <0 0 0 0 &mpic 59>;
+ marvell,pcie-port = <0>;
+ marvell,pcie-lane = <1>;
+ clocks = <&gateclk 6>;
+ status = "disabled";
+ };
+
+ pcie@3,0 {
+ device_type = "pci";
+ assigned-addresses = <0x82001800 0 0xd0048000 0 0x2000>;
+ reg = <0x1800 0 0 0 0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ ranges;
+ interrupt-map-mask = <0 0 0 0>;
+ interrupt-map = <0 0 0 0 &mpic 60>;
+ marvell,pcie-port = <0>;
+ marvell,pcie-lane = <2>;
+ clocks = <&gateclk 7>;
+ status = "disabled";
+ };
+
+ pcie@4,0 {
+ device_type = "pci";
+ assigned-addresses = <0x82002000 0 0xd004c000 0 0x2000>;
+ reg = <0x2000 0 0 0 0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ ranges;
+ interrupt-map-mask = <0 0 0 0>;
+ interrupt-map = <0 0 0 0 &mpic 61>;
+ marvell,pcie-port = <0>;
+ marvell,pcie-lane = <3>;
+ clocks = <&gateclk 8>;
+ status = "disabled";
+ };
+
+ pcie@5,0 {
+ device_type = "pci";
+ assigned-addresses = <0x82002800 0 0xd0080000 0 0x2000>;
+ reg = <0x2800 0 0 0 0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ ranges;
+ interrupt-map-mask = <0 0 0 0>;
+ interrupt-map = <0 0 0 0 &mpic 62>;
+ marvell,pcie-port = <1>;
+ marvell,pcie-lane = <0>;
+ clocks = <&gateclk 9>;
+ status = "disabled";
+ };
+
+ pcie@6,0 {
+ device_type = "pci";
+ assigned-addresses = <0x82003000 0 0xd0084000 0 0x2000>;
+ reg = <0x3000 0 0 0 0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ ranges;
+ interrupt-map-mask = <0 0 0 0>;
+ interrupt-map = <0 0 0 0 &mpic 63>;
+ marvell,pcie-port = <1>;
+ marvell,pcie-lane = <1>;
+ clocks = <&gateclk 10>;
+ status = "disabled";
+ };
+
+ pcie@7,0 {
+ device_type = "pci";
+ assigned-addresses = <0x82003800 0 0xd0088000 0 0x2000>;
+ reg = <0x3800 0 0 0 0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ ranges;
+ interrupt-map-mask = <0 0 0 0>;
+ interrupt-map = <0 0 0 0 &mpic 64>;
+ marvell,pcie-port = <1>;
+ marvell,pcie-lane = <2>;
+ clocks = <&gateclk 11>;
+ status = "disabled";
+ };
+
+ pcie@8,0 {
+ device_type = "pci";
+ assigned-addresses = <0x82004000 0 0xd008c000 0 0x2000>;
+ reg = <0x4000 0 0 0 0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ ranges;
+ interrupt-map-mask = <0 0 0 0>;
+ interrupt-map = <0 0 0 0 &mpic 65>;
+ marvell,pcie-port = <1>;
+ marvell,pcie-lane = <3>;
+ clocks = <&gateclk 12>;
+ status = "disabled";
+ };
+ pcie@9,0 {
+ device_type = "pci";
+ assigned-addresses = <0x82004800 0 0xd0042000 0 0x2000>;
+ reg = <0x4800 0 0 0 0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ ranges;
+ interrupt-map-mask = <0 0 0 0>;
+ interrupt-map = <0 0 0 0 &mpic 99>;
+ marvell,pcie-port = <2>;
+ marvell,pcie-lane = <0>;
+ clocks = <&gateclk 26>;
+ status = "disabled";
+ };
+
+ pcie@10,0 {
+ device_type = "pci";
+ assigned-addresses = <0x82005000 0 0xd0082000 0 0x2000>;
+ reg = <0x5000 0 0 0 0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ ranges;
+ interrupt-map-mask = <0 0 0 0>;
+ interrupt-map = <0 0 0 0 &mpic 103>;
+ marvell,pcie-port = <3>;
+ marvell,pcie-lane = <0>;
+ clocks = <&gateclk 27>;
+ status = "disabled";
+ };
+};
diff --git a/Documentation/devicetree/bindings/pci/pci.txt b/Documentation/devicetree/bindings/pci/pci.txt
new file mode 100644
index 0000000..41aeed3
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/pci.txt
@@ -0,0 +1,9 @@
+PCI bus bridges have standardized Device Tree bindings:
+
+PCI Bus Binding to: IEEE Std 1275-1994
+http://www.openfirmware.org/ofwg/bindings/pci/pci2_1.pdf
+
+And for the interrupt mapping part:
+
+Open Firmware Recommended Practice: Interrupt Mapping
+http://www.openfirmware.org/1275/practice/imap/imap0_9d.pdf
diff --git a/Documentation/devicetree/bindings/pci/v3-v360epc-pci.txt b/Documentation/devicetree/bindings/pci/v3-v360epc-pci.txt
new file mode 100644
index 0000000..30b364e
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/v3-v360epc-pci.txt
@@ -0,0 +1,15 @@
+V3 Semiconductor V360 EPC PCI bridge
+
+This bridge is found in the ARM Integrator/AP (Application Platform)
+
+Integrator-specific notes:
+
+- syscon: should contain a link to the syscon device node (since
+ on the Integrator, some registers in the syscon are required to
+ operate the V3).
+
+V360 EPC specific notes:
+
+- reg: should contain the base address of the V3 adapter.
+- interrupts: should contain a reference to the V3 error interrupt
+ as routed on the system.
diff --git a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
new file mode 100644
index 0000000..dff0e5f
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
@@ -0,0 +1,60 @@
+* Allwinner A1X Pin Controller
+
+The pins controlled by sunXi pin controller are organized in banks,
+each bank has 32 pins. Each pin has 7 multiplexing functions, with
+the first two functions being GPIO in and out. The configuration on
+the pins includes drive strength and pull-up.
+
+Required properties:
+- compatible: "allwinner,<soc>-pinctrl". Supported SoCs for now are:
+ sun5i-a13.
+- reg: Should contain the register physical address and length for the
+ pin controller.
+
+Please refer to pinctrl-bindings.txt in this directory for details of the
+common pinctrl bindings used by client devices.
+
+A pinctrl node should contain at least one subnodes representing the
+pinctrl groups available on the machine. Each subnode will list the
+pins it needs, and how they should be configured, with regard to muxer
+configuration, drive strength and pullups. If one of these options is
+not set, its actual value will be unspecified.
+
+Required subnode-properties:
+
+- allwinner,pins: List of strings containing the pin name.
+- allwinner,function: Function to mux the pins listed above to.
+
+Optional subnode-properties:
+- allwinner,drive: Integer. Represents the current sent to the pin
+ 0: 10 mA
+ 1: 20 mA
+ 2: 30 mA
+ 3: 40 mA
+- allwinner,pull: Integer.
+ 0: No resistor
+ 1: Pull-up resistor
+ 2: Pull-down resistor
+
+Examples:
+
+pinctrl@01c20800 {
+ compatible = "allwinner,sun5i-a13-pinctrl";
+ reg = <0x01c20800 0x400>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ uart1_pins_a: uart1@0 {
+ allwinner,pins = "PE10", "PE11";
+ allwinner,function = "uart1";
+ allwinner,drive = <0>;
+ allwinner,pull = <0>;
+ };
+
+ uart1_pins_b: uart1@1 {
+ allwinner,pins = "PG3", "PG4";
+ allwinner,function = "uart1";
+ allwinner,drive = <0>;
+ allwinner,pull = <0>;
+ };
+};
diff --git a/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt
index 3a26812..648d60e 100644
--- a/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt
@@ -1,6 +1,6 @@
* Atmel AT91 Pinmux Controller
-The AT91 Pinmux Controler, enables the IC
+The AT91 Pinmux Controller, enables the IC
to share one PAD to several functional blocks. The sharing is done by
multiplexing the PAD input/output signals. For each PAD there are up to
8 muxing options (called periph modes). Since different modules require
@@ -81,7 +81,8 @@
Required properties for pin configuration node:
- atmel,pins: 4 integers array, represents a group of pins mux and config
setting. The format is atmel,pins = <PIN_BANK PIN_BANK_NUM PERIPH CONFIG>.
- The PERIPH 0 means gpio.
+ The PERIPH 0 means gpio, PERIPH 1 is periph A, PERIPH 2 is periph B...
+ PIN_BANK 0 is pioA, PIN_BANK 1 is pioB...
Bits used for CONFIG:
PULL_UP (1 << 0): indicate this pin need a pull up.
@@ -126,7 +127,7 @@
pinctrl_dbgu: dbgu-0 {
atmel,pins =
<1 14 0x1 0x0 /* PB14 periph A */
- 1 15 0x1 0x1>; /* PB15 periph with pullup */
+ 1 15 0x1 0x1>; /* PB15 periph A with pullup */
};
};
};
diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt b/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt
index 8edc20e..2569866 100644
--- a/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt
+++ b/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt
@@ -5,7 +5,7 @@
Required properties:
- compatible: "brcm,bcm2835-gpio"
-- reg: Should contain the physical address of the GPIO module's registes.
+- reg: Should contain the physical address of the GPIO module's registers.
- gpio-controller: Marks the device node as a GPIO controller.
- #gpio-cells : Should be two. The first cell is the pin number and the
second cell is used to specify optional parameters:
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt
index ab19e6b..3a7caf7 100644
--- a/Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt
@@ -24,9 +24,9 @@
Required properties for pin configuration node:
- fsl,pins: two integers array, represents a group of pins mux and config
setting. The format is fsl,pins = <PIN_FUNC_ID CONFIG>, PIN_FUNC_ID is a
- pin working on a specific function, CONFIG is the pad setting value like
- pull-up on this pin. Please refer to fsl,<soc>-pinctrl.txt for the valid
- pins and functions of each SoC.
+ pin working on a specific function, which consists of a tuple of
+ <mux_reg conf_reg input_reg mux_val input_val>. CONFIG is the pad setting
+ value like pull-up on this pin.
Bits used for CONFIG:
NO_PAD_CTL(1 << 31): indicate this pin does not need config.
@@ -58,7 +58,7 @@
Examples:
usdhc@0219c000 { /* uSDHC4 */
- fsl,card-wired;
+ non-removable;
vmmc-supply = <®_3p3v>;
status = "okay";
pinctrl-names = "default";
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx35-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx35-pinctrl.txt
index 1183f1a..c083dfd 100644
--- a/Documentation/devicetree/bindings/pinctrl/fsl,imx35-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx35-pinctrl.txt
@@ -29,956 +29,5 @@
PAD_CTL_SRE_FAST (1 << 0)
PAD_CTL_SRE_SLOW (0 << 0)
-See below for available PIN_FUNC_ID for imx35:
-0 MX35_PAD_CAPTURE__GPT_CAPIN1
-1 MX35_PAD_CAPTURE__GPT_CMPOUT2
-2 MX35_PAD_CAPTURE__CSPI2_SS1
-3 MX35_PAD_CAPTURE__EPIT1_EPITO
-4 MX35_PAD_CAPTURE__CCM_CLK32K
-5 MX35_PAD_CAPTURE__GPIO1_4
-6 MX35_PAD_COMPARE__GPT_CMPOUT1
-7 MX35_PAD_COMPARE__GPT_CAPIN2
-8 MX35_PAD_COMPARE__GPT_CMPOUT3
-9 MX35_PAD_COMPARE__EPIT2_EPITO
-10 MX35_PAD_COMPARE__GPIO1_5
-11 MX35_PAD_COMPARE__SDMA_EXTDMA_2
-12 MX35_PAD_WDOG_RST__WDOG_WDOG_B
-13 MX35_PAD_WDOG_RST__IPU_FLASH_STROBE
-14 MX35_PAD_WDOG_RST__GPIO1_6
-15 MX35_PAD_GPIO1_0__GPIO1_0
-16 MX35_PAD_GPIO1_0__CCM_PMIC_RDY
-17 MX35_PAD_GPIO1_0__OWIRE_LINE
-18 MX35_PAD_GPIO1_0__SDMA_EXTDMA_0
-19 MX35_PAD_GPIO1_1__GPIO1_1
-20 MX35_PAD_GPIO1_1__PWM_PWMO
-21 MX35_PAD_GPIO1_1__CSPI1_SS2
-22 MX35_PAD_GPIO1_1__SCC_TAMPER_DETECT
-23 MX35_PAD_GPIO1_1__SDMA_EXTDMA_1
-24 MX35_PAD_GPIO2_0__GPIO2_0
-25 MX35_PAD_GPIO2_0__USB_TOP_USBOTG_CLK
-26 MX35_PAD_GPIO3_0__GPIO3_0
-27 MX35_PAD_GPIO3_0__USB_TOP_USBH2_CLK
-28 MX35_PAD_RESET_IN_B__CCM_RESET_IN_B
-29 MX35_PAD_POR_B__CCM_POR_B
-30 MX35_PAD_CLKO__CCM_CLKO
-31 MX35_PAD_CLKO__GPIO1_8
-32 MX35_PAD_BOOT_MODE0__CCM_BOOT_MODE_0
-33 MX35_PAD_BOOT_MODE1__CCM_BOOT_MODE_1
-34 MX35_PAD_CLK_MODE0__CCM_CLK_MODE_0
-35 MX35_PAD_CLK_MODE1__CCM_CLK_MODE_1
-36 MX35_PAD_POWER_FAIL__CCM_DSM_WAKEUP_INT_26
-37 MX35_PAD_VSTBY__CCM_VSTBY
-38 MX35_PAD_VSTBY__GPIO1_7
-39 MX35_PAD_A0__EMI_EIM_DA_L_0
-40 MX35_PAD_A1__EMI_EIM_DA_L_1
-41 MX35_PAD_A2__EMI_EIM_DA_L_2
-42 MX35_PAD_A3__EMI_EIM_DA_L_3
-43 MX35_PAD_A4__EMI_EIM_DA_L_4
-44 MX35_PAD_A5__EMI_EIM_DA_L_5
-45 MX35_PAD_A6__EMI_EIM_DA_L_6
-46 MX35_PAD_A7__EMI_EIM_DA_L_7
-47 MX35_PAD_A8__EMI_EIM_DA_H_8
-48 MX35_PAD_A9__EMI_EIM_DA_H_9
-49 MX35_PAD_A10__EMI_EIM_DA_H_10
-50 MX35_PAD_MA10__EMI_MA10
-51 MX35_PAD_A11__EMI_EIM_DA_H_11
-52 MX35_PAD_A12__EMI_EIM_DA_H_12
-53 MX35_PAD_A13__EMI_EIM_DA_H_13
-54 MX35_PAD_A14__EMI_EIM_DA_H2_14
-55 MX35_PAD_A15__EMI_EIM_DA_H2_15
-56 MX35_PAD_A16__EMI_EIM_A_16
-57 MX35_PAD_A17__EMI_EIM_A_17
-58 MX35_PAD_A18__EMI_EIM_A_18
-59 MX35_PAD_A19__EMI_EIM_A_19
-60 MX35_PAD_A20__EMI_EIM_A_20
-61 MX35_PAD_A21__EMI_EIM_A_21
-62 MX35_PAD_A22__EMI_EIM_A_22
-63 MX35_PAD_A23__EMI_EIM_A_23
-64 MX35_PAD_A24__EMI_EIM_A_24
-65 MX35_PAD_A25__EMI_EIM_A_25
-66 MX35_PAD_SDBA1__EMI_EIM_SDBA1
-67 MX35_PAD_SDBA0__EMI_EIM_SDBA0
-68 MX35_PAD_SD0__EMI_DRAM_D_0
-69 MX35_PAD_SD1__EMI_DRAM_D_1
-70 MX35_PAD_SD2__EMI_DRAM_D_2
-71 MX35_PAD_SD3__EMI_DRAM_D_3
-72 MX35_PAD_SD4__EMI_DRAM_D_4
-73 MX35_PAD_SD5__EMI_DRAM_D_5
-74 MX35_PAD_SD6__EMI_DRAM_D_6
-75 MX35_PAD_SD7__EMI_DRAM_D_7
-76 MX35_PAD_SD8__EMI_DRAM_D_8
-77 MX35_PAD_SD9__EMI_DRAM_D_9
-78 MX35_PAD_SD10__EMI_DRAM_D_10
-79 MX35_PAD_SD11__EMI_DRAM_D_11
-80 MX35_PAD_SD12__EMI_DRAM_D_12
-81 MX35_PAD_SD13__EMI_DRAM_D_13
-82 MX35_PAD_SD14__EMI_DRAM_D_14
-83 MX35_PAD_SD15__EMI_DRAM_D_15
-84 MX35_PAD_SD16__EMI_DRAM_D_16
-85 MX35_PAD_SD17__EMI_DRAM_D_17
-86 MX35_PAD_SD18__EMI_DRAM_D_18
-87 MX35_PAD_SD19__EMI_DRAM_D_19
-88 MX35_PAD_SD20__EMI_DRAM_D_20
-89 MX35_PAD_SD21__EMI_DRAM_D_21
-90 MX35_PAD_SD22__EMI_DRAM_D_22
-91 MX35_PAD_SD23__EMI_DRAM_D_23
-92 MX35_PAD_SD24__EMI_DRAM_D_24
-93 MX35_PAD_SD25__EMI_DRAM_D_25
-94 MX35_PAD_SD26__EMI_DRAM_D_26
-95 MX35_PAD_SD27__EMI_DRAM_D_27
-96 MX35_PAD_SD28__EMI_DRAM_D_28
-97 MX35_PAD_SD29__EMI_DRAM_D_29
-98 MX35_PAD_SD30__EMI_DRAM_D_30
-99 MX35_PAD_SD31__EMI_DRAM_D_31
-100 MX35_PAD_DQM0__EMI_DRAM_DQM_0
-101 MX35_PAD_DQM1__EMI_DRAM_DQM_1
-102 MX35_PAD_DQM2__EMI_DRAM_DQM_2
-103 MX35_PAD_DQM3__EMI_DRAM_DQM_3
-104 MX35_PAD_EB0__EMI_EIM_EB0_B
-105 MX35_PAD_EB1__EMI_EIM_EB1_B
-106 MX35_PAD_OE__EMI_EIM_OE
-107 MX35_PAD_CS0__EMI_EIM_CS0
-108 MX35_PAD_CS1__EMI_EIM_CS1
-109 MX35_PAD_CS1__EMI_NANDF_CE3
-110 MX35_PAD_CS2__EMI_EIM_CS2
-111 MX35_PAD_CS3__EMI_EIM_CS3
-112 MX35_PAD_CS4__EMI_EIM_CS4
-113 MX35_PAD_CS4__EMI_DTACK_B
-114 MX35_PAD_CS4__EMI_NANDF_CE1
-115 MX35_PAD_CS4__GPIO1_20
-116 MX35_PAD_CS5__EMI_EIM_CS5
-117 MX35_PAD_CS5__CSPI2_SS2
-118 MX35_PAD_CS5__CSPI1_SS2
-119 MX35_PAD_CS5__EMI_NANDF_CE2
-120 MX35_PAD_CS5__GPIO1_21
-121 MX35_PAD_NF_CE0__EMI_NANDF_CE0
-122 MX35_PAD_NF_CE0__GPIO1_22
-123 MX35_PAD_ECB__EMI_EIM_ECB
-124 MX35_PAD_LBA__EMI_EIM_LBA
-125 MX35_PAD_BCLK__EMI_EIM_BCLK
-126 MX35_PAD_RW__EMI_EIM_RW
-127 MX35_PAD_RAS__EMI_DRAM_RAS
-128 MX35_PAD_CAS__EMI_DRAM_CAS
-129 MX35_PAD_SDWE__EMI_DRAM_SDWE
-130 MX35_PAD_SDCKE0__EMI_DRAM_SDCKE_0
-131 MX35_PAD_SDCKE1__EMI_DRAM_SDCKE_1
-132 MX35_PAD_SDCLK__EMI_DRAM_SDCLK
-133 MX35_PAD_SDQS0__EMI_DRAM_SDQS_0
-134 MX35_PAD_SDQS1__EMI_DRAM_SDQS_1
-135 MX35_PAD_SDQS2__EMI_DRAM_SDQS_2
-136 MX35_PAD_SDQS3__EMI_DRAM_SDQS_3
-137 MX35_PAD_NFWE_B__EMI_NANDF_WE_B
-138 MX35_PAD_NFWE_B__USB_TOP_USBH2_DATA_3
-139 MX35_PAD_NFWE_B__IPU_DISPB_D0_VSYNC
-140 MX35_PAD_NFWE_B__GPIO2_18
-141 MX35_PAD_NFWE_B__ARM11P_TOP_TRACE_0
-142 MX35_PAD_NFRE_B__EMI_NANDF_RE_B
-143 MX35_PAD_NFRE_B__USB_TOP_USBH2_DIR
-144 MX35_PAD_NFRE_B__IPU_DISPB_BCLK
-145 MX35_PAD_NFRE_B__GPIO2_19
-146 MX35_PAD_NFRE_B__ARM11P_TOP_TRACE_1
-147 MX35_PAD_NFALE__EMI_NANDF_ALE
-148 MX35_PAD_NFALE__USB_TOP_USBH2_STP
-149 MX35_PAD_NFALE__IPU_DISPB_CS0
-150 MX35_PAD_NFALE__GPIO2_20
-151 MX35_PAD_NFALE__ARM11P_TOP_TRACE_2
-152 MX35_PAD_NFCLE__EMI_NANDF_CLE
-153 MX35_PAD_NFCLE__USB_TOP_USBH2_NXT
-154 MX35_PAD_NFCLE__IPU_DISPB_PAR_RS
-155 MX35_PAD_NFCLE__GPIO2_21
-156 MX35_PAD_NFCLE__ARM11P_TOP_TRACE_3
-157 MX35_PAD_NFWP_B__EMI_NANDF_WP_B
-158 MX35_PAD_NFWP_B__USB_TOP_USBH2_DATA_7
-159 MX35_PAD_NFWP_B__IPU_DISPB_WR
-160 MX35_PAD_NFWP_B__GPIO2_22
-161 MX35_PAD_NFWP_B__ARM11P_TOP_TRCTL
-162 MX35_PAD_NFRB__EMI_NANDF_RB
-163 MX35_PAD_NFRB__IPU_DISPB_RD
-164 MX35_PAD_NFRB__GPIO2_23
-165 MX35_PAD_NFRB__ARM11P_TOP_TRCLK
-166 MX35_PAD_D15__EMI_EIM_D_15
-167 MX35_PAD_D14__EMI_EIM_D_14
-168 MX35_PAD_D13__EMI_EIM_D_13
-169 MX35_PAD_D12__EMI_EIM_D_12
-170 MX35_PAD_D11__EMI_EIM_D_11
-171 MX35_PAD_D10__EMI_EIM_D_10
-172 MX35_PAD_D9__EMI_EIM_D_9
-173 MX35_PAD_D8__EMI_EIM_D_8
-174 MX35_PAD_D7__EMI_EIM_D_7
-175 MX35_PAD_D6__EMI_EIM_D_6
-176 MX35_PAD_D5__EMI_EIM_D_5
-177 MX35_PAD_D4__EMI_EIM_D_4
-178 MX35_PAD_D3__EMI_EIM_D_3
-179 MX35_PAD_D2__EMI_EIM_D_2
-180 MX35_PAD_D1__EMI_EIM_D_1
-181 MX35_PAD_D0__EMI_EIM_D_0
-182 MX35_PAD_CSI_D8__IPU_CSI_D_8
-183 MX35_PAD_CSI_D8__KPP_COL_0
-184 MX35_PAD_CSI_D8__GPIO1_20
-185 MX35_PAD_CSI_D8__ARM11P_TOP_EVNTBUS_13
-186 MX35_PAD_CSI_D9__IPU_CSI_D_9
-187 MX35_PAD_CSI_D9__KPP_COL_1
-188 MX35_PAD_CSI_D9__GPIO1_21
-189 MX35_PAD_CSI_D9__ARM11P_TOP_EVNTBUS_14
-190 MX35_PAD_CSI_D10__IPU_CSI_D_10
-191 MX35_PAD_CSI_D10__KPP_COL_2
-192 MX35_PAD_CSI_D10__GPIO1_22
-193 MX35_PAD_CSI_D10__ARM11P_TOP_EVNTBUS_15
-194 MX35_PAD_CSI_D11__IPU_CSI_D_11
-195 MX35_PAD_CSI_D11__KPP_COL_3
-196 MX35_PAD_CSI_D11__GPIO1_23
-197 MX35_PAD_CSI_D12__IPU_CSI_D_12
-198 MX35_PAD_CSI_D12__KPP_ROW_0
-199 MX35_PAD_CSI_D12__GPIO1_24
-200 MX35_PAD_CSI_D13__IPU_CSI_D_13
-201 MX35_PAD_CSI_D13__KPP_ROW_1
-202 MX35_PAD_CSI_D13__GPIO1_25
-203 MX35_PAD_CSI_D14__IPU_CSI_D_14
-204 MX35_PAD_CSI_D14__KPP_ROW_2
-205 MX35_PAD_CSI_D14__GPIO1_26
-206 MX35_PAD_CSI_D15__IPU_CSI_D_15
-207 MX35_PAD_CSI_D15__KPP_ROW_3
-208 MX35_PAD_CSI_D15__GPIO1_27
-209 MX35_PAD_CSI_MCLK__IPU_CSI_MCLK
-210 MX35_PAD_CSI_MCLK__GPIO1_28
-211 MX35_PAD_CSI_VSYNC__IPU_CSI_VSYNC
-212 MX35_PAD_CSI_VSYNC__GPIO1_29
-213 MX35_PAD_CSI_HSYNC__IPU_CSI_HSYNC
-214 MX35_PAD_CSI_HSYNC__GPIO1_30
-215 MX35_PAD_CSI_PIXCLK__IPU_CSI_PIXCLK
-216 MX35_PAD_CSI_PIXCLK__GPIO1_31
-217 MX35_PAD_I2C1_CLK__I2C1_SCL
-218 MX35_PAD_I2C1_CLK__GPIO2_24
-219 MX35_PAD_I2C1_CLK__CCM_USB_BYP_CLK
-220 MX35_PAD_I2C1_DAT__I2C1_SDA
-221 MX35_PAD_I2C1_DAT__GPIO2_25
-222 MX35_PAD_I2C2_CLK__I2C2_SCL
-223 MX35_PAD_I2C2_CLK__CAN1_TXCAN
-224 MX35_PAD_I2C2_CLK__USB_TOP_USBH2_PWR
-225 MX35_PAD_I2C2_CLK__GPIO2_26
-226 MX35_PAD_I2C2_CLK__SDMA_DEBUG_BUS_DEVICE_2
-227 MX35_PAD_I2C2_DAT__I2C2_SDA
-228 MX35_PAD_I2C2_DAT__CAN1_RXCAN
-229 MX35_PAD_I2C2_DAT__USB_TOP_USBH2_OC
-230 MX35_PAD_I2C2_DAT__GPIO2_27
-231 MX35_PAD_I2C2_DAT__SDMA_DEBUG_BUS_DEVICE_3
-232 MX35_PAD_STXD4__AUDMUX_AUD4_TXD
-233 MX35_PAD_STXD4__GPIO2_28
-234 MX35_PAD_STXD4__ARM11P_TOP_ARM_COREASID0
-235 MX35_PAD_SRXD4__AUDMUX_AUD4_RXD
-236 MX35_PAD_SRXD4__GPIO2_29
-237 MX35_PAD_SRXD4__ARM11P_TOP_ARM_COREASID1
-238 MX35_PAD_SCK4__AUDMUX_AUD4_TXC
-239 MX35_PAD_SCK4__GPIO2_30
-240 MX35_PAD_SCK4__ARM11P_TOP_ARM_COREASID2
-241 MX35_PAD_STXFS4__AUDMUX_AUD4_TXFS
-242 MX35_PAD_STXFS4__GPIO2_31
-243 MX35_PAD_STXFS4__ARM11P_TOP_ARM_COREASID3
-244 MX35_PAD_STXD5__AUDMUX_AUD5_TXD
-245 MX35_PAD_STXD5__SPDIF_SPDIF_OUT1
-246 MX35_PAD_STXD5__CSPI2_MOSI
-247 MX35_PAD_STXD5__GPIO1_0
-248 MX35_PAD_STXD5__ARM11P_TOP_ARM_COREASID4
-249 MX35_PAD_SRXD5__AUDMUX_AUD5_RXD
-250 MX35_PAD_SRXD5__SPDIF_SPDIF_IN1
-251 MX35_PAD_SRXD5__CSPI2_MISO
-252 MX35_PAD_SRXD5__GPIO1_1
-253 MX35_PAD_SRXD5__ARM11P_TOP_ARM_COREASID5
-254 MX35_PAD_SCK5__AUDMUX_AUD5_TXC
-255 MX35_PAD_SCK5__SPDIF_SPDIF_EXTCLK
-256 MX35_PAD_SCK5__CSPI2_SCLK
-257 MX35_PAD_SCK5__GPIO1_2
-258 MX35_PAD_SCK5__ARM11P_TOP_ARM_COREASID6
-259 MX35_PAD_STXFS5__AUDMUX_AUD5_TXFS
-260 MX35_PAD_STXFS5__CSPI2_RDY
-261 MX35_PAD_STXFS5__GPIO1_3
-262 MX35_PAD_STXFS5__ARM11P_TOP_ARM_COREASID7
-263 MX35_PAD_SCKR__ESAI_SCKR
-264 MX35_PAD_SCKR__GPIO1_4
-265 MX35_PAD_SCKR__ARM11P_TOP_EVNTBUS_10
-266 MX35_PAD_FSR__ESAI_FSR
-267 MX35_PAD_FSR__GPIO1_5
-268 MX35_PAD_FSR__ARM11P_TOP_EVNTBUS_11
-269 MX35_PAD_HCKR__ESAI_HCKR
-270 MX35_PAD_HCKR__AUDMUX_AUD5_RXFS
-271 MX35_PAD_HCKR__CSPI2_SS0
-272 MX35_PAD_HCKR__IPU_FLASH_STROBE
-273 MX35_PAD_HCKR__GPIO1_6
-274 MX35_PAD_HCKR__ARM11P_TOP_EVNTBUS_12
-275 MX35_PAD_SCKT__ESAI_SCKT
-276 MX35_PAD_SCKT__GPIO1_7
-277 MX35_PAD_SCKT__IPU_CSI_D_0
-278 MX35_PAD_SCKT__KPP_ROW_2
-279 MX35_PAD_FST__ESAI_FST
-280 MX35_PAD_FST__GPIO1_8
-281 MX35_PAD_FST__IPU_CSI_D_1
-282 MX35_PAD_FST__KPP_ROW_3
-283 MX35_PAD_HCKT__ESAI_HCKT
-284 MX35_PAD_HCKT__AUDMUX_AUD5_RXC
-285 MX35_PAD_HCKT__GPIO1_9
-286 MX35_PAD_HCKT__IPU_CSI_D_2
-287 MX35_PAD_HCKT__KPP_COL_3
-288 MX35_PAD_TX5_RX0__ESAI_TX5_RX0
-289 MX35_PAD_TX5_RX0__AUDMUX_AUD4_RXC
-290 MX35_PAD_TX5_RX0__CSPI2_SS2
-291 MX35_PAD_TX5_RX0__CAN2_TXCAN
-292 MX35_PAD_TX5_RX0__UART2_DTR
-293 MX35_PAD_TX5_RX0__GPIO1_10
-294 MX35_PAD_TX5_RX0__EMI_M3IF_CHOSEN_MASTER_0
-295 MX35_PAD_TX4_RX1__ESAI_TX4_RX1
-296 MX35_PAD_TX4_RX1__AUDMUX_AUD4_RXFS
-297 MX35_PAD_TX4_RX1__CSPI2_SS3
-298 MX35_PAD_TX4_RX1__CAN2_RXCAN
-299 MX35_PAD_TX4_RX1__UART2_DSR
-300 MX35_PAD_TX4_RX1__GPIO1_11
-301 MX35_PAD_TX4_RX1__IPU_CSI_D_3
-302 MX35_PAD_TX4_RX1__KPP_ROW_0
-303 MX35_PAD_TX3_RX2__ESAI_TX3_RX2
-304 MX35_PAD_TX3_RX2__I2C3_SCL
-305 MX35_PAD_TX3_RX2__EMI_NANDF_CE1
-306 MX35_PAD_TX3_RX2__GPIO1_12
-307 MX35_PAD_TX3_RX2__IPU_CSI_D_4
-308 MX35_PAD_TX3_RX2__KPP_ROW_1
-309 MX35_PAD_TX2_RX3__ESAI_TX2_RX3
-310 MX35_PAD_TX2_RX3__I2C3_SDA
-311 MX35_PAD_TX2_RX3__EMI_NANDF_CE2
-312 MX35_PAD_TX2_RX3__GPIO1_13
-313 MX35_PAD_TX2_RX3__IPU_CSI_D_5
-314 MX35_PAD_TX2_RX3__KPP_COL_0
-315 MX35_PAD_TX1__ESAI_TX1
-316 MX35_PAD_TX1__CCM_PMIC_RDY
-317 MX35_PAD_TX1__CSPI1_SS2
-318 MX35_PAD_TX1__EMI_NANDF_CE3
-319 MX35_PAD_TX1__UART2_RI
-320 MX35_PAD_TX1__GPIO1_14
-321 MX35_PAD_TX1__IPU_CSI_D_6
-322 MX35_PAD_TX1__KPP_COL_1
-323 MX35_PAD_TX0__ESAI_TX0
-324 MX35_PAD_TX0__SPDIF_SPDIF_EXTCLK
-325 MX35_PAD_TX0__CSPI1_SS3
-326 MX35_PAD_TX0__EMI_DTACK_B
-327 MX35_PAD_TX0__UART2_DCD
-328 MX35_PAD_TX0__GPIO1_15
-329 MX35_PAD_TX0__IPU_CSI_D_7
-330 MX35_PAD_TX0__KPP_COL_2
-331 MX35_PAD_CSPI1_MOSI__CSPI1_MOSI
-332 MX35_PAD_CSPI1_MOSI__GPIO1_16
-333 MX35_PAD_CSPI1_MOSI__ECT_CTI_TRIG_OUT1_2
-334 MX35_PAD_CSPI1_MISO__CSPI1_MISO
-335 MX35_PAD_CSPI1_MISO__GPIO1_17
-336 MX35_PAD_CSPI1_MISO__ECT_CTI_TRIG_OUT1_3
-337 MX35_PAD_CSPI1_SS0__CSPI1_SS0
-338 MX35_PAD_CSPI1_SS0__OWIRE_LINE
-339 MX35_PAD_CSPI1_SS0__CSPI2_SS3
-340 MX35_PAD_CSPI1_SS0__GPIO1_18
-341 MX35_PAD_CSPI1_SS0__ECT_CTI_TRIG_OUT1_4
-342 MX35_PAD_CSPI1_SS1__CSPI1_SS1
-343 MX35_PAD_CSPI1_SS1__PWM_PWMO
-344 MX35_PAD_CSPI1_SS1__CCM_CLK32K
-345 MX35_PAD_CSPI1_SS1__GPIO1_19
-346 MX35_PAD_CSPI1_SS1__IPU_DIAGB_29
-347 MX35_PAD_CSPI1_SS1__ECT_CTI_TRIG_OUT1_5
-348 MX35_PAD_CSPI1_SCLK__CSPI1_SCLK
-349 MX35_PAD_CSPI1_SCLK__GPIO3_4
-350 MX35_PAD_CSPI1_SCLK__IPU_DIAGB_30
-351 MX35_PAD_CSPI1_SCLK__EMI_M3IF_CHOSEN_MASTER_1
-352 MX35_PAD_CSPI1_SPI_RDY__CSPI1_RDY
-353 MX35_PAD_CSPI1_SPI_RDY__GPIO3_5
-354 MX35_PAD_CSPI1_SPI_RDY__IPU_DIAGB_31
-355 MX35_PAD_CSPI1_SPI_RDY__EMI_M3IF_CHOSEN_MASTER_2
-356 MX35_PAD_RXD1__UART1_RXD_MUX
-357 MX35_PAD_RXD1__CSPI2_MOSI
-358 MX35_PAD_RXD1__KPP_COL_4
-359 MX35_PAD_RXD1__GPIO3_6
-360 MX35_PAD_RXD1__ARM11P_TOP_EVNTBUS_16
-361 MX35_PAD_TXD1__UART1_TXD_MUX
-362 MX35_PAD_TXD1__CSPI2_MISO
-363 MX35_PAD_TXD1__KPP_COL_5
-364 MX35_PAD_TXD1__GPIO3_7
-365 MX35_PAD_TXD1__ARM11P_TOP_EVNTBUS_17
-366 MX35_PAD_RTS1__UART1_RTS
-367 MX35_PAD_RTS1__CSPI2_SCLK
-368 MX35_PAD_RTS1__I2C3_SCL
-369 MX35_PAD_RTS1__IPU_CSI_D_0
-370 MX35_PAD_RTS1__KPP_COL_6
-371 MX35_PAD_RTS1__GPIO3_8
-372 MX35_PAD_RTS1__EMI_NANDF_CE1
-373 MX35_PAD_RTS1__ARM11P_TOP_EVNTBUS_18
-374 MX35_PAD_CTS1__UART1_CTS
-375 MX35_PAD_CTS1__CSPI2_RDY
-376 MX35_PAD_CTS1__I2C3_SDA
-377 MX35_PAD_CTS1__IPU_CSI_D_1
-378 MX35_PAD_CTS1__KPP_COL_7
-379 MX35_PAD_CTS1__GPIO3_9
-380 MX35_PAD_CTS1__EMI_NANDF_CE2
-381 MX35_PAD_CTS1__ARM11P_TOP_EVNTBUS_19
-382 MX35_PAD_RXD2__UART2_RXD_MUX
-383 MX35_PAD_RXD2__KPP_ROW_4
-384 MX35_PAD_RXD2__GPIO3_10
-385 MX35_PAD_TXD2__UART2_TXD_MUX
-386 MX35_PAD_TXD2__SPDIF_SPDIF_EXTCLK
-387 MX35_PAD_TXD2__KPP_ROW_5
-388 MX35_PAD_TXD2__GPIO3_11
-389 MX35_PAD_RTS2__UART2_RTS
-390 MX35_PAD_RTS2__SPDIF_SPDIF_IN1
-391 MX35_PAD_RTS2__CAN2_RXCAN
-392 MX35_PAD_RTS2__IPU_CSI_D_2
-393 MX35_PAD_RTS2__KPP_ROW_6
-394 MX35_PAD_RTS2__GPIO3_12
-395 MX35_PAD_RTS2__AUDMUX_AUD5_RXC
-396 MX35_PAD_RTS2__UART3_RXD_MUX
-397 MX35_PAD_CTS2__UART2_CTS
-398 MX35_PAD_CTS2__SPDIF_SPDIF_OUT1
-399 MX35_PAD_CTS2__CAN2_TXCAN
-400 MX35_PAD_CTS2__IPU_CSI_D_3
-401 MX35_PAD_CTS2__KPP_ROW_7
-402 MX35_PAD_CTS2__GPIO3_13
-403 MX35_PAD_CTS2__AUDMUX_AUD5_RXFS
-404 MX35_PAD_CTS2__UART3_TXD_MUX
-405 MX35_PAD_RTCK__ARM11P_TOP_RTCK
-406 MX35_PAD_TCK__SJC_TCK
-407 MX35_PAD_TMS__SJC_TMS
-408 MX35_PAD_TDI__SJC_TDI
-409 MX35_PAD_TDO__SJC_TDO
-410 MX35_PAD_TRSTB__SJC_TRSTB
-411 MX35_PAD_DE_B__SJC_DE_B
-412 MX35_PAD_SJC_MOD__SJC_MOD
-413 MX35_PAD_USBOTG_PWR__USB_TOP_USBOTG_PWR
-414 MX35_PAD_USBOTG_PWR__USB_TOP_USBH2_PWR
-415 MX35_PAD_USBOTG_PWR__GPIO3_14
-416 MX35_PAD_USBOTG_OC__USB_TOP_USBOTG_OC
-417 MX35_PAD_USBOTG_OC__USB_TOP_USBH2_OC
-418 MX35_PAD_USBOTG_OC__GPIO3_15
-419 MX35_PAD_LD0__IPU_DISPB_DAT_0
-420 MX35_PAD_LD0__GPIO2_0
-421 MX35_PAD_LD0__SDMA_SDMA_DEBUG_PC_0
-422 MX35_PAD_LD1__IPU_DISPB_DAT_1
-423 MX35_PAD_LD1__GPIO2_1
-424 MX35_PAD_LD1__SDMA_SDMA_DEBUG_PC_1
-425 MX35_PAD_LD2__IPU_DISPB_DAT_2
-426 MX35_PAD_LD2__GPIO2_2
-427 MX35_PAD_LD2__SDMA_SDMA_DEBUG_PC_2
-428 MX35_PAD_LD3__IPU_DISPB_DAT_3
-429 MX35_PAD_LD3__GPIO2_3
-430 MX35_PAD_LD3__SDMA_SDMA_DEBUG_PC_3
-431 MX35_PAD_LD4__IPU_DISPB_DAT_4
-432 MX35_PAD_LD4__GPIO2_4
-433 MX35_PAD_LD4__SDMA_SDMA_DEBUG_PC_4
-434 MX35_PAD_LD5__IPU_DISPB_DAT_5
-435 MX35_PAD_LD5__GPIO2_5
-436 MX35_PAD_LD5__SDMA_SDMA_DEBUG_PC_5
-437 MX35_PAD_LD6__IPU_DISPB_DAT_6
-438 MX35_PAD_LD6__GPIO2_6
-439 MX35_PAD_LD6__SDMA_SDMA_DEBUG_PC_6
-440 MX35_PAD_LD7__IPU_DISPB_DAT_7
-441 MX35_PAD_LD7__GPIO2_7
-442 MX35_PAD_LD7__SDMA_SDMA_DEBUG_PC_7
-443 MX35_PAD_LD8__IPU_DISPB_DAT_8
-444 MX35_PAD_LD8__GPIO2_8
-445 MX35_PAD_LD8__SDMA_SDMA_DEBUG_PC_8
-446 MX35_PAD_LD9__IPU_DISPB_DAT_9
-447 MX35_PAD_LD9__GPIO2_9
-448 MX35_PAD_LD9__SDMA_SDMA_DEBUG_PC_9
-449 MX35_PAD_LD10__IPU_DISPB_DAT_10
-450 MX35_PAD_LD10__GPIO2_10
-451 MX35_PAD_LD10__SDMA_SDMA_DEBUG_PC_10
-452 MX35_PAD_LD11__IPU_DISPB_DAT_11
-453 MX35_PAD_LD11__GPIO2_11
-454 MX35_PAD_LD11__SDMA_SDMA_DEBUG_PC_11
-455 MX35_PAD_LD11__ARM11P_TOP_TRACE_4
-456 MX35_PAD_LD12__IPU_DISPB_DAT_12
-457 MX35_PAD_LD12__GPIO2_12
-458 MX35_PAD_LD12__SDMA_SDMA_DEBUG_PC_12
-459 MX35_PAD_LD12__ARM11P_TOP_TRACE_5
-460 MX35_PAD_LD13__IPU_DISPB_DAT_13
-461 MX35_PAD_LD13__GPIO2_13
-462 MX35_PAD_LD13__SDMA_SDMA_DEBUG_PC_13
-463 MX35_PAD_LD13__ARM11P_TOP_TRACE_6
-464 MX35_PAD_LD14__IPU_DISPB_DAT_14
-465 MX35_PAD_LD14__GPIO2_14
-466 MX35_PAD_LD14__SDMA_SDMA_DEBUG_EVENT_CHANNEL_0
-467 MX35_PAD_LD14__ARM11P_TOP_TRACE_7
-468 MX35_PAD_LD15__IPU_DISPB_DAT_15
-469 MX35_PAD_LD15__GPIO2_15
-470 MX35_PAD_LD15__SDMA_SDMA_DEBUG_EVENT_CHANNEL_1
-471 MX35_PAD_LD15__ARM11P_TOP_TRACE_8
-472 MX35_PAD_LD16__IPU_DISPB_DAT_16
-473 MX35_PAD_LD16__IPU_DISPB_D12_VSYNC
-474 MX35_PAD_LD16__GPIO2_16
-475 MX35_PAD_LD16__SDMA_SDMA_DEBUG_EVENT_CHANNEL_2
-476 MX35_PAD_LD16__ARM11P_TOP_TRACE_9
-477 MX35_PAD_LD17__IPU_DISPB_DAT_17
-478 MX35_PAD_LD17__IPU_DISPB_CS2
-479 MX35_PAD_LD17__GPIO2_17
-480 MX35_PAD_LD17__SDMA_SDMA_DEBUG_EVENT_CHANNEL_3
-481 MX35_PAD_LD17__ARM11P_TOP_TRACE_10
-482 MX35_PAD_LD18__IPU_DISPB_DAT_18
-483 MX35_PAD_LD18__IPU_DISPB_D0_VSYNC
-484 MX35_PAD_LD18__IPU_DISPB_D12_VSYNC
-485 MX35_PAD_LD18__ESDHC3_CMD
-486 MX35_PAD_LD18__USB_TOP_USBOTG_DATA_3
-487 MX35_PAD_LD18__GPIO3_24
-488 MX35_PAD_LD18__SDMA_SDMA_DEBUG_EVENT_CHANNEL_4
-489 MX35_PAD_LD18__ARM11P_TOP_TRACE_11
-490 MX35_PAD_LD19__IPU_DISPB_DAT_19
-491 MX35_PAD_LD19__IPU_DISPB_BCLK
-492 MX35_PAD_LD19__IPU_DISPB_CS1
-493 MX35_PAD_LD19__ESDHC3_CLK
-494 MX35_PAD_LD19__USB_TOP_USBOTG_DIR
-495 MX35_PAD_LD19__GPIO3_25
-496 MX35_PAD_LD19__SDMA_SDMA_DEBUG_EVENT_CHANNEL_5
-497 MX35_PAD_LD19__ARM11P_TOP_TRACE_12
-498 MX35_PAD_LD20__IPU_DISPB_DAT_20
-499 MX35_PAD_LD20__IPU_DISPB_CS0
-500 MX35_PAD_LD20__IPU_DISPB_SD_CLK
-501 MX35_PAD_LD20__ESDHC3_DAT0
-502 MX35_PAD_LD20__GPIO3_26
-503 MX35_PAD_LD20__SDMA_SDMA_DEBUG_CORE_STATUS_3
-504 MX35_PAD_LD20__ARM11P_TOP_TRACE_13
-505 MX35_PAD_LD21__IPU_DISPB_DAT_21
-506 MX35_PAD_LD21__IPU_DISPB_PAR_RS
-507 MX35_PAD_LD21__IPU_DISPB_SER_RS
-508 MX35_PAD_LD21__ESDHC3_DAT1
-509 MX35_PAD_LD21__USB_TOP_USBOTG_STP
-510 MX35_PAD_LD21__GPIO3_27
-511 MX35_PAD_LD21__SDMA_DEBUG_EVENT_CHANNEL_SEL
-512 MX35_PAD_LD21__ARM11P_TOP_TRACE_14
-513 MX35_PAD_LD22__IPU_DISPB_DAT_22
-514 MX35_PAD_LD22__IPU_DISPB_WR
-515 MX35_PAD_LD22__IPU_DISPB_SD_D_I
-516 MX35_PAD_LD22__ESDHC3_DAT2
-517 MX35_PAD_LD22__USB_TOP_USBOTG_NXT
-518 MX35_PAD_LD22__GPIO3_28
-519 MX35_PAD_LD22__SDMA_DEBUG_BUS_ERROR
-520 MX35_PAD_LD22__ARM11P_TOP_TRCTL
-521 MX35_PAD_LD23__IPU_DISPB_DAT_23
-522 MX35_PAD_LD23__IPU_DISPB_RD
-523 MX35_PAD_LD23__IPU_DISPB_SD_D_IO
-524 MX35_PAD_LD23__ESDHC3_DAT3
-525 MX35_PAD_LD23__USB_TOP_USBOTG_DATA_7
-526 MX35_PAD_LD23__GPIO3_29
-527 MX35_PAD_LD23__SDMA_DEBUG_MATCHED_DMBUS
-528 MX35_PAD_LD23__ARM11P_TOP_TRCLK
-529 MX35_PAD_D3_HSYNC__IPU_DISPB_D3_HSYNC
-530 MX35_PAD_D3_HSYNC__IPU_DISPB_SD_D_IO
-531 MX35_PAD_D3_HSYNC__GPIO3_30
-532 MX35_PAD_D3_HSYNC__SDMA_DEBUG_RTBUFFER_WRITE
-533 MX35_PAD_D3_HSYNC__ARM11P_TOP_TRACE_15
-534 MX35_PAD_D3_FPSHIFT__IPU_DISPB_D3_CLK
-535 MX35_PAD_D3_FPSHIFT__IPU_DISPB_SD_CLK
-536 MX35_PAD_D3_FPSHIFT__GPIO3_31
-537 MX35_PAD_D3_FPSHIFT__SDMA_SDMA_DEBUG_CORE_STATUS_0
-538 MX35_PAD_D3_FPSHIFT__ARM11P_TOP_TRACE_16
-539 MX35_PAD_D3_DRDY__IPU_DISPB_D3_DRDY
-540 MX35_PAD_D3_DRDY__IPU_DISPB_SD_D_O
-541 MX35_PAD_D3_DRDY__GPIO1_0
-542 MX35_PAD_D3_DRDY__SDMA_SDMA_DEBUG_CORE_STATUS_1
-543 MX35_PAD_D3_DRDY__ARM11P_TOP_TRACE_17
-544 MX35_PAD_CONTRAST__IPU_DISPB_CONTR
-545 MX35_PAD_CONTRAST__GPIO1_1
-546 MX35_PAD_CONTRAST__SDMA_SDMA_DEBUG_CORE_STATUS_2
-547 MX35_PAD_CONTRAST__ARM11P_TOP_TRACE_18
-548 MX35_PAD_D3_VSYNC__IPU_DISPB_D3_VSYNC
-549 MX35_PAD_D3_VSYNC__IPU_DISPB_CS1
-550 MX35_PAD_D3_VSYNC__GPIO1_2
-551 MX35_PAD_D3_VSYNC__SDMA_DEBUG_YIELD
-552 MX35_PAD_D3_VSYNC__ARM11P_TOP_TRACE_19
-553 MX35_PAD_D3_REV__IPU_DISPB_D3_REV
-554 MX35_PAD_D3_REV__IPU_DISPB_SER_RS
-555 MX35_PAD_D3_REV__GPIO1_3
-556 MX35_PAD_D3_REV__SDMA_DEBUG_BUS_RWB
-557 MX35_PAD_D3_REV__ARM11P_TOP_TRACE_20
-558 MX35_PAD_D3_CLS__IPU_DISPB_D3_CLS
-559 MX35_PAD_D3_CLS__IPU_DISPB_CS2
-560 MX35_PAD_D3_CLS__GPIO1_4
-561 MX35_PAD_D3_CLS__SDMA_DEBUG_BUS_DEVICE_0
-562 MX35_PAD_D3_CLS__ARM11P_TOP_TRACE_21
-563 MX35_PAD_D3_SPL__IPU_DISPB_D3_SPL
-564 MX35_PAD_D3_SPL__IPU_DISPB_D12_VSYNC
-565 MX35_PAD_D3_SPL__GPIO1_5
-566 MX35_PAD_D3_SPL__SDMA_DEBUG_BUS_DEVICE_1
-567 MX35_PAD_D3_SPL__ARM11P_TOP_TRACE_22
-568 MX35_PAD_SD1_CMD__ESDHC1_CMD
-569 MX35_PAD_SD1_CMD__MSHC_SCLK
-570 MX35_PAD_SD1_CMD__IPU_DISPB_D0_VSYNC
-571 MX35_PAD_SD1_CMD__USB_TOP_USBOTG_DATA_4
-572 MX35_PAD_SD1_CMD__GPIO1_6
-573 MX35_PAD_SD1_CMD__ARM11P_TOP_TRCTL
-574 MX35_PAD_SD1_CLK__ESDHC1_CLK
-575 MX35_PAD_SD1_CLK__MSHC_BS
-576 MX35_PAD_SD1_CLK__IPU_DISPB_BCLK
-577 MX35_PAD_SD1_CLK__USB_TOP_USBOTG_DATA_5
-578 MX35_PAD_SD1_CLK__GPIO1_7
-579 MX35_PAD_SD1_CLK__ARM11P_TOP_TRCLK
-580 MX35_PAD_SD1_DATA0__ESDHC1_DAT0
-581 MX35_PAD_SD1_DATA0__MSHC_DATA_0
-582 MX35_PAD_SD1_DATA0__IPU_DISPB_CS0
-583 MX35_PAD_SD1_DATA0__USB_TOP_USBOTG_DATA_6
-584 MX35_PAD_SD1_DATA0__GPIO1_8
-585 MX35_PAD_SD1_DATA0__ARM11P_TOP_TRACE_23
-586 MX35_PAD_SD1_DATA1__ESDHC1_DAT1
-587 MX35_PAD_SD1_DATA1__MSHC_DATA_1
-588 MX35_PAD_SD1_DATA1__IPU_DISPB_PAR_RS
-589 MX35_PAD_SD1_DATA1__USB_TOP_USBOTG_DATA_0
-590 MX35_PAD_SD1_DATA1__GPIO1_9
-591 MX35_PAD_SD1_DATA1__ARM11P_TOP_TRACE_24
-592 MX35_PAD_SD1_DATA2__ESDHC1_DAT2
-593 MX35_PAD_SD1_DATA2__MSHC_DATA_2
-594 MX35_PAD_SD1_DATA2__IPU_DISPB_WR
-595 MX35_PAD_SD1_DATA2__USB_TOP_USBOTG_DATA_1
-596 MX35_PAD_SD1_DATA2__GPIO1_10
-597 MX35_PAD_SD1_DATA2__ARM11P_TOP_TRACE_25
-598 MX35_PAD_SD1_DATA3__ESDHC1_DAT3
-599 MX35_PAD_SD1_DATA3__MSHC_DATA_3
-600 MX35_PAD_SD1_DATA3__IPU_DISPB_RD
-601 MX35_PAD_SD1_DATA3__USB_TOP_USBOTG_DATA_2
-602 MX35_PAD_SD1_DATA3__GPIO1_11
-603 MX35_PAD_SD1_DATA3__ARM11P_TOP_TRACE_26
-604 MX35_PAD_SD2_CMD__ESDHC2_CMD
-605 MX35_PAD_SD2_CMD__I2C3_SCL
-606 MX35_PAD_SD2_CMD__ESDHC1_DAT4
-607 MX35_PAD_SD2_CMD__IPU_CSI_D_2
-608 MX35_PAD_SD2_CMD__USB_TOP_USBH2_DATA_4
-609 MX35_PAD_SD2_CMD__GPIO2_0
-610 MX35_PAD_SD2_CMD__SPDIF_SPDIF_OUT1
-611 MX35_PAD_SD2_CMD__IPU_DISPB_D12_VSYNC
-612 MX35_PAD_SD2_CLK__ESDHC2_CLK
-613 MX35_PAD_SD2_CLK__I2C3_SDA
-614 MX35_PAD_SD2_CLK__ESDHC1_DAT5
-615 MX35_PAD_SD2_CLK__IPU_CSI_D_3
-616 MX35_PAD_SD2_CLK__USB_TOP_USBH2_DATA_5
-617 MX35_PAD_SD2_CLK__GPIO2_1
-618 MX35_PAD_SD2_CLK__SPDIF_SPDIF_IN1
-619 MX35_PAD_SD2_CLK__IPU_DISPB_CS2
-620 MX35_PAD_SD2_DATA0__ESDHC2_DAT0
-621 MX35_PAD_SD2_DATA0__UART3_RXD_MUX
-622 MX35_PAD_SD2_DATA0__ESDHC1_DAT6
-623 MX35_PAD_SD2_DATA0__IPU_CSI_D_4
-624 MX35_PAD_SD2_DATA0__USB_TOP_USBH2_DATA_6
-625 MX35_PAD_SD2_DATA0__GPIO2_2
-626 MX35_PAD_SD2_DATA0__SPDIF_SPDIF_EXTCLK
-627 MX35_PAD_SD2_DATA1__ESDHC2_DAT1
-628 MX35_PAD_SD2_DATA1__UART3_TXD_MUX
-629 MX35_PAD_SD2_DATA1__ESDHC1_DAT7
-630 MX35_PAD_SD2_DATA1__IPU_CSI_D_5
-631 MX35_PAD_SD2_DATA1__USB_TOP_USBH2_DATA_0
-632 MX35_PAD_SD2_DATA1__GPIO2_3
-633 MX35_PAD_SD2_DATA2__ESDHC2_DAT2
-634 MX35_PAD_SD2_DATA2__UART3_RTS
-635 MX35_PAD_SD2_DATA2__CAN1_RXCAN
-636 MX35_PAD_SD2_DATA2__IPU_CSI_D_6
-637 MX35_PAD_SD2_DATA2__USB_TOP_USBH2_DATA_1
-638 MX35_PAD_SD2_DATA2__GPIO2_4
-639 MX35_PAD_SD2_DATA3__ESDHC2_DAT3
-640 MX35_PAD_SD2_DATA3__UART3_CTS
-641 MX35_PAD_SD2_DATA3__CAN1_TXCAN
-642 MX35_PAD_SD2_DATA3__IPU_CSI_D_7
-643 MX35_PAD_SD2_DATA3__USB_TOP_USBH2_DATA_2
-644 MX35_PAD_SD2_DATA3__GPIO2_5
-645 MX35_PAD_ATA_CS0__ATA_CS0
-646 MX35_PAD_ATA_CS0__CSPI1_SS3
-647 MX35_PAD_ATA_CS0__IPU_DISPB_CS1
-648 MX35_PAD_ATA_CS0__GPIO2_6
-649 MX35_PAD_ATA_CS0__IPU_DIAGB_0
-650 MX35_PAD_ATA_CS0__ARM11P_TOP_MAX1_HMASTER_0
-651 MX35_PAD_ATA_CS1__ATA_CS1
-652 MX35_PAD_ATA_CS1__IPU_DISPB_CS2
-653 MX35_PAD_ATA_CS1__CSPI2_SS0
-654 MX35_PAD_ATA_CS1__GPIO2_7
-655 MX35_PAD_ATA_CS1__IPU_DIAGB_1
-656 MX35_PAD_ATA_CS1__ARM11P_TOP_MAX1_HMASTER_1
-657 MX35_PAD_ATA_DIOR__ATA_DIOR
-658 MX35_PAD_ATA_DIOR__ESDHC3_DAT0
-659 MX35_PAD_ATA_DIOR__USB_TOP_USBOTG_DIR
-660 MX35_PAD_ATA_DIOR__IPU_DISPB_BE0
-661 MX35_PAD_ATA_DIOR__CSPI2_SS1
-662 MX35_PAD_ATA_DIOR__GPIO2_8
-663 MX35_PAD_ATA_DIOR__IPU_DIAGB_2
-664 MX35_PAD_ATA_DIOR__ARM11P_TOP_MAX1_HMASTER_2
-665 MX35_PAD_ATA_DIOW__ATA_DIOW
-666 MX35_PAD_ATA_DIOW__ESDHC3_DAT1
-667 MX35_PAD_ATA_DIOW__USB_TOP_USBOTG_STP
-668 MX35_PAD_ATA_DIOW__IPU_DISPB_BE1
-669 MX35_PAD_ATA_DIOW__CSPI2_MOSI
-670 MX35_PAD_ATA_DIOW__GPIO2_9
-671 MX35_PAD_ATA_DIOW__IPU_DIAGB_3
-672 MX35_PAD_ATA_DIOW__ARM11P_TOP_MAX1_HMASTER_3
-673 MX35_PAD_ATA_DMACK__ATA_DMACK
-674 MX35_PAD_ATA_DMACK__ESDHC3_DAT2
-675 MX35_PAD_ATA_DMACK__USB_TOP_USBOTG_NXT
-676 MX35_PAD_ATA_DMACK__CSPI2_MISO
-677 MX35_PAD_ATA_DMACK__GPIO2_10
-678 MX35_PAD_ATA_DMACK__IPU_DIAGB_4
-679 MX35_PAD_ATA_DMACK__ARM11P_TOP_MAX0_HMASTER_0
-680 MX35_PAD_ATA_RESET_B__ATA_RESET_B
-681 MX35_PAD_ATA_RESET_B__ESDHC3_DAT3
-682 MX35_PAD_ATA_RESET_B__USB_TOP_USBOTG_DATA_0
-683 MX35_PAD_ATA_RESET_B__IPU_DISPB_SD_D_O
-684 MX35_PAD_ATA_RESET_B__CSPI2_RDY
-685 MX35_PAD_ATA_RESET_B__GPIO2_11
-686 MX35_PAD_ATA_RESET_B__IPU_DIAGB_5
-687 MX35_PAD_ATA_RESET_B__ARM11P_TOP_MAX0_HMASTER_1
-688 MX35_PAD_ATA_IORDY__ATA_IORDY
-689 MX35_PAD_ATA_IORDY__ESDHC3_DAT4
-690 MX35_PAD_ATA_IORDY__USB_TOP_USBOTG_DATA_1
-691 MX35_PAD_ATA_IORDY__IPU_DISPB_SD_D_IO
-692 MX35_PAD_ATA_IORDY__ESDHC2_DAT4
-693 MX35_PAD_ATA_IORDY__GPIO2_12
-694 MX35_PAD_ATA_IORDY__IPU_DIAGB_6
-695 MX35_PAD_ATA_IORDY__ARM11P_TOP_MAX0_HMASTER_2
-696 MX35_PAD_ATA_DATA0__ATA_DATA_0
-697 MX35_PAD_ATA_DATA0__ESDHC3_DAT5
-698 MX35_PAD_ATA_DATA0__USB_TOP_USBOTG_DATA_2
-699 MX35_PAD_ATA_DATA0__IPU_DISPB_D12_VSYNC
-700 MX35_PAD_ATA_DATA0__ESDHC2_DAT5
-701 MX35_PAD_ATA_DATA0__GPIO2_13
-702 MX35_PAD_ATA_DATA0__IPU_DIAGB_7
-703 MX35_PAD_ATA_DATA0__ARM11P_TOP_MAX0_HMASTER_3
-704 MX35_PAD_ATA_DATA1__ATA_DATA_1
-705 MX35_PAD_ATA_DATA1__ESDHC3_DAT6
-706 MX35_PAD_ATA_DATA1__USB_TOP_USBOTG_DATA_3
-707 MX35_PAD_ATA_DATA1__IPU_DISPB_SD_CLK
-708 MX35_PAD_ATA_DATA1__ESDHC2_DAT6
-709 MX35_PAD_ATA_DATA1__GPIO2_14
-710 MX35_PAD_ATA_DATA1__IPU_DIAGB_8
-711 MX35_PAD_ATA_DATA1__ARM11P_TOP_TRACE_27
-712 MX35_PAD_ATA_DATA2__ATA_DATA_2
-713 MX35_PAD_ATA_DATA2__ESDHC3_DAT7
-714 MX35_PAD_ATA_DATA2__USB_TOP_USBOTG_DATA_4
-715 MX35_PAD_ATA_DATA2__IPU_DISPB_SER_RS
-716 MX35_PAD_ATA_DATA2__ESDHC2_DAT7
-717 MX35_PAD_ATA_DATA2__GPIO2_15
-718 MX35_PAD_ATA_DATA2__IPU_DIAGB_9
-719 MX35_PAD_ATA_DATA2__ARM11P_TOP_TRACE_28
-720 MX35_PAD_ATA_DATA3__ATA_DATA_3
-721 MX35_PAD_ATA_DATA3__ESDHC3_CLK
-722 MX35_PAD_ATA_DATA3__USB_TOP_USBOTG_DATA_5
-723 MX35_PAD_ATA_DATA3__CSPI2_SCLK
-724 MX35_PAD_ATA_DATA3__GPIO2_16
-725 MX35_PAD_ATA_DATA3__IPU_DIAGB_10
-726 MX35_PAD_ATA_DATA3__ARM11P_TOP_TRACE_29
-727 MX35_PAD_ATA_DATA4__ATA_DATA_4
-728 MX35_PAD_ATA_DATA4__ESDHC3_CMD
-729 MX35_PAD_ATA_DATA4__USB_TOP_USBOTG_DATA_6
-730 MX35_PAD_ATA_DATA4__GPIO2_17
-731 MX35_PAD_ATA_DATA4__IPU_DIAGB_11
-732 MX35_PAD_ATA_DATA4__ARM11P_TOP_TRACE_30
-733 MX35_PAD_ATA_DATA5__ATA_DATA_5
-734 MX35_PAD_ATA_DATA5__USB_TOP_USBOTG_DATA_7
-735 MX35_PAD_ATA_DATA5__GPIO2_18
-736 MX35_PAD_ATA_DATA5__IPU_DIAGB_12
-737 MX35_PAD_ATA_DATA5__ARM11P_TOP_TRACE_31
-738 MX35_PAD_ATA_DATA6__ATA_DATA_6
-739 MX35_PAD_ATA_DATA6__CAN1_TXCAN
-740 MX35_PAD_ATA_DATA6__UART1_DTR
-741 MX35_PAD_ATA_DATA6__AUDMUX_AUD6_TXD
-742 MX35_PAD_ATA_DATA6__GPIO2_19
-743 MX35_PAD_ATA_DATA6__IPU_DIAGB_13
-744 MX35_PAD_ATA_DATA7__ATA_DATA_7
-745 MX35_PAD_ATA_DATA7__CAN1_RXCAN
-746 MX35_PAD_ATA_DATA7__UART1_DSR
-747 MX35_PAD_ATA_DATA7__AUDMUX_AUD6_RXD
-748 MX35_PAD_ATA_DATA7__GPIO2_20
-749 MX35_PAD_ATA_DATA7__IPU_DIAGB_14
-750 MX35_PAD_ATA_DATA8__ATA_DATA_8
-751 MX35_PAD_ATA_DATA8__UART3_RTS
-752 MX35_PAD_ATA_DATA8__UART1_RI
-753 MX35_PAD_ATA_DATA8__AUDMUX_AUD6_TXC
-754 MX35_PAD_ATA_DATA8__GPIO2_21
-755 MX35_PAD_ATA_DATA8__IPU_DIAGB_15
-756 MX35_PAD_ATA_DATA9__ATA_DATA_9
-757 MX35_PAD_ATA_DATA9__UART3_CTS
-758 MX35_PAD_ATA_DATA9__UART1_DCD
-759 MX35_PAD_ATA_DATA9__AUDMUX_AUD6_TXFS
-760 MX35_PAD_ATA_DATA9__GPIO2_22
-761 MX35_PAD_ATA_DATA9__IPU_DIAGB_16
-762 MX35_PAD_ATA_DATA10__ATA_DATA_10
-763 MX35_PAD_ATA_DATA10__UART3_RXD_MUX
-764 MX35_PAD_ATA_DATA10__AUDMUX_AUD6_RXC
-765 MX35_PAD_ATA_DATA10__GPIO2_23
-766 MX35_PAD_ATA_DATA10__IPU_DIAGB_17
-767 MX35_PAD_ATA_DATA11__ATA_DATA_11
-768 MX35_PAD_ATA_DATA11__UART3_TXD_MUX
-769 MX35_PAD_ATA_DATA11__AUDMUX_AUD6_RXFS
-770 MX35_PAD_ATA_DATA11__GPIO2_24
-771 MX35_PAD_ATA_DATA11__IPU_DIAGB_18
-772 MX35_PAD_ATA_DATA12__ATA_DATA_12
-773 MX35_PAD_ATA_DATA12__I2C3_SCL
-774 MX35_PAD_ATA_DATA12__GPIO2_25
-775 MX35_PAD_ATA_DATA12__IPU_DIAGB_19
-776 MX35_PAD_ATA_DATA13__ATA_DATA_13
-777 MX35_PAD_ATA_DATA13__I2C3_SDA
-778 MX35_PAD_ATA_DATA13__GPIO2_26
-779 MX35_PAD_ATA_DATA13__IPU_DIAGB_20
-780 MX35_PAD_ATA_DATA14__ATA_DATA_14
-781 MX35_PAD_ATA_DATA14__IPU_CSI_D_0
-782 MX35_PAD_ATA_DATA14__KPP_ROW_0
-783 MX35_PAD_ATA_DATA14__GPIO2_27
-784 MX35_PAD_ATA_DATA14__IPU_DIAGB_21
-785 MX35_PAD_ATA_DATA15__ATA_DATA_15
-786 MX35_PAD_ATA_DATA15__IPU_CSI_D_1
-787 MX35_PAD_ATA_DATA15__KPP_ROW_1
-788 MX35_PAD_ATA_DATA15__GPIO2_28
-789 MX35_PAD_ATA_DATA15__IPU_DIAGB_22
-790 MX35_PAD_ATA_INTRQ__ATA_INTRQ
-791 MX35_PAD_ATA_INTRQ__IPU_CSI_D_2
-792 MX35_PAD_ATA_INTRQ__KPP_ROW_2
-793 MX35_PAD_ATA_INTRQ__GPIO2_29
-794 MX35_PAD_ATA_INTRQ__IPU_DIAGB_23
-795 MX35_PAD_ATA_BUFF_EN__ATA_BUFFER_EN
-796 MX35_PAD_ATA_BUFF_EN__IPU_CSI_D_3
-797 MX35_PAD_ATA_BUFF_EN__KPP_ROW_3
-798 MX35_PAD_ATA_BUFF_EN__GPIO2_30
-799 MX35_PAD_ATA_BUFF_EN__IPU_DIAGB_24
-800 MX35_PAD_ATA_DMARQ__ATA_DMARQ
-801 MX35_PAD_ATA_DMARQ__IPU_CSI_D_4
-802 MX35_PAD_ATA_DMARQ__KPP_COL_0
-803 MX35_PAD_ATA_DMARQ__GPIO2_31
-804 MX35_PAD_ATA_DMARQ__IPU_DIAGB_25
-805 MX35_PAD_ATA_DMARQ__ECT_CTI_TRIG_IN1_4
-806 MX35_PAD_ATA_DA0__ATA_DA_0
-807 MX35_PAD_ATA_DA0__IPU_CSI_D_5
-808 MX35_PAD_ATA_DA0__KPP_COL_1
-809 MX35_PAD_ATA_DA0__GPIO3_0
-810 MX35_PAD_ATA_DA0__IPU_DIAGB_26
-811 MX35_PAD_ATA_DA0__ECT_CTI_TRIG_IN1_5
-812 MX35_PAD_ATA_DA1__ATA_DA_1
-813 MX35_PAD_ATA_DA1__IPU_CSI_D_6
-814 MX35_PAD_ATA_DA1__KPP_COL_2
-815 MX35_PAD_ATA_DA1__GPIO3_1
-816 MX35_PAD_ATA_DA1__IPU_DIAGB_27
-817 MX35_PAD_ATA_DA1__ECT_CTI_TRIG_IN1_6
-818 MX35_PAD_ATA_DA2__ATA_DA_2
-819 MX35_PAD_ATA_DA2__IPU_CSI_D_7
-820 MX35_PAD_ATA_DA2__KPP_COL_3
-821 MX35_PAD_ATA_DA2__GPIO3_2
-822 MX35_PAD_ATA_DA2__IPU_DIAGB_28
-823 MX35_PAD_ATA_DA2__ECT_CTI_TRIG_IN1_7
-824 MX35_PAD_MLB_CLK__MLB_MLBCLK
-825 MX35_PAD_MLB_CLK__GPIO3_3
-826 MX35_PAD_MLB_DAT__MLB_MLBDAT
-827 MX35_PAD_MLB_DAT__GPIO3_4
-828 MX35_PAD_MLB_SIG__MLB_MLBSIG
-829 MX35_PAD_MLB_SIG__GPIO3_5
-830 MX35_PAD_FEC_TX_CLK__FEC_TX_CLK
-831 MX35_PAD_FEC_TX_CLK__ESDHC1_DAT4
-832 MX35_PAD_FEC_TX_CLK__UART3_RXD_MUX
-833 MX35_PAD_FEC_TX_CLK__USB_TOP_USBH2_DIR
-834 MX35_PAD_FEC_TX_CLK__CSPI2_MOSI
-835 MX35_PAD_FEC_TX_CLK__GPIO3_6
-836 MX35_PAD_FEC_TX_CLK__IPU_DISPB_D12_VSYNC
-837 MX35_PAD_FEC_TX_CLK__ARM11P_TOP_EVNTBUS_0
-838 MX35_PAD_FEC_RX_CLK__FEC_RX_CLK
-839 MX35_PAD_FEC_RX_CLK__ESDHC1_DAT5
-840 MX35_PAD_FEC_RX_CLK__UART3_TXD_MUX
-841 MX35_PAD_FEC_RX_CLK__USB_TOP_USBH2_STP
-842 MX35_PAD_FEC_RX_CLK__CSPI2_MISO
-843 MX35_PAD_FEC_RX_CLK__GPIO3_7
-844 MX35_PAD_FEC_RX_CLK__IPU_DISPB_SD_D_I
-845 MX35_PAD_FEC_RX_CLK__ARM11P_TOP_EVNTBUS_1
-846 MX35_PAD_FEC_RX_DV__FEC_RX_DV
-847 MX35_PAD_FEC_RX_DV__ESDHC1_DAT6
-848 MX35_PAD_FEC_RX_DV__UART3_RTS
-849 MX35_PAD_FEC_RX_DV__USB_TOP_USBH2_NXT
-850 MX35_PAD_FEC_RX_DV__CSPI2_SCLK
-851 MX35_PAD_FEC_RX_DV__GPIO3_8
-852 MX35_PAD_FEC_RX_DV__IPU_DISPB_SD_CLK
-853 MX35_PAD_FEC_RX_DV__ARM11P_TOP_EVNTBUS_2
-854 MX35_PAD_FEC_COL__FEC_COL
-855 MX35_PAD_FEC_COL__ESDHC1_DAT7
-856 MX35_PAD_FEC_COL__UART3_CTS
-857 MX35_PAD_FEC_COL__USB_TOP_USBH2_DATA_0
-858 MX35_PAD_FEC_COL__CSPI2_RDY
-859 MX35_PAD_FEC_COL__GPIO3_9
-860 MX35_PAD_FEC_COL__IPU_DISPB_SER_RS
-861 MX35_PAD_FEC_COL__ARM11P_TOP_EVNTBUS_3
-862 MX35_PAD_FEC_RDATA0__FEC_RDATA_0
-863 MX35_PAD_FEC_RDATA0__PWM_PWMO
-864 MX35_PAD_FEC_RDATA0__UART3_DTR
-865 MX35_PAD_FEC_RDATA0__USB_TOP_USBH2_DATA_1
-866 MX35_PAD_FEC_RDATA0__CSPI2_SS0
-867 MX35_PAD_FEC_RDATA0__GPIO3_10
-868 MX35_PAD_FEC_RDATA0__IPU_DISPB_CS1
-869 MX35_PAD_FEC_RDATA0__ARM11P_TOP_EVNTBUS_4
-870 MX35_PAD_FEC_TDATA0__FEC_TDATA_0
-871 MX35_PAD_FEC_TDATA0__SPDIF_SPDIF_OUT1
-872 MX35_PAD_FEC_TDATA0__UART3_DSR
-873 MX35_PAD_FEC_TDATA0__USB_TOP_USBH2_DATA_2
-874 MX35_PAD_FEC_TDATA0__CSPI2_SS1
-875 MX35_PAD_FEC_TDATA0__GPIO3_11
-876 MX35_PAD_FEC_TDATA0__IPU_DISPB_CS0
-877 MX35_PAD_FEC_TDATA0__ARM11P_TOP_EVNTBUS_5
-878 MX35_PAD_FEC_TX_EN__FEC_TX_EN
-879 MX35_PAD_FEC_TX_EN__SPDIF_SPDIF_IN1
-880 MX35_PAD_FEC_TX_EN__UART3_RI
-881 MX35_PAD_FEC_TX_EN__USB_TOP_USBH2_DATA_3
-882 MX35_PAD_FEC_TX_EN__GPIO3_12
-883 MX35_PAD_FEC_TX_EN__IPU_DISPB_PAR_RS
-884 MX35_PAD_FEC_TX_EN__ARM11P_TOP_EVNTBUS_6
-885 MX35_PAD_FEC_MDC__FEC_MDC
-886 MX35_PAD_FEC_MDC__CAN2_TXCAN
-887 MX35_PAD_FEC_MDC__UART3_DCD
-888 MX35_PAD_FEC_MDC__USB_TOP_USBH2_DATA_4
-889 MX35_PAD_FEC_MDC__GPIO3_13
-890 MX35_PAD_FEC_MDC__IPU_DISPB_WR
-891 MX35_PAD_FEC_MDC__ARM11P_TOP_EVNTBUS_7
-892 MX35_PAD_FEC_MDIO__FEC_MDIO
-893 MX35_PAD_FEC_MDIO__CAN2_RXCAN
-894 MX35_PAD_FEC_MDIO__USB_TOP_USBH2_DATA_5
-895 MX35_PAD_FEC_MDIO__GPIO3_14
-896 MX35_PAD_FEC_MDIO__IPU_DISPB_RD
-897 MX35_PAD_FEC_MDIO__ARM11P_TOP_EVNTBUS_8
-898 MX35_PAD_FEC_TX_ERR__FEC_TX_ERR
-899 MX35_PAD_FEC_TX_ERR__OWIRE_LINE
-900 MX35_PAD_FEC_TX_ERR__SPDIF_SPDIF_EXTCLK
-901 MX35_PAD_FEC_TX_ERR__USB_TOP_USBH2_DATA_6
-902 MX35_PAD_FEC_TX_ERR__GPIO3_15
-903 MX35_PAD_FEC_TX_ERR__IPU_DISPB_D0_VSYNC
-904 MX35_PAD_FEC_TX_ERR__ARM11P_TOP_EVNTBUS_9
-905 MX35_PAD_FEC_RX_ERR__FEC_RX_ERR
-906 MX35_PAD_FEC_RX_ERR__IPU_CSI_D_0
-907 MX35_PAD_FEC_RX_ERR__USB_TOP_USBH2_DATA_7
-908 MX35_PAD_FEC_RX_ERR__KPP_COL_4
-909 MX35_PAD_FEC_RX_ERR__GPIO3_16
-910 MX35_PAD_FEC_RX_ERR__IPU_DISPB_SD_D_IO
-911 MX35_PAD_FEC_CRS__FEC_CRS
-912 MX35_PAD_FEC_CRS__IPU_CSI_D_1
-913 MX35_PAD_FEC_CRS__USB_TOP_USBH2_PWR
-914 MX35_PAD_FEC_CRS__KPP_COL_5
-915 MX35_PAD_FEC_CRS__GPIO3_17
-916 MX35_PAD_FEC_CRS__IPU_FLASH_STROBE
-917 MX35_PAD_FEC_RDATA1__FEC_RDATA_1
-918 MX35_PAD_FEC_RDATA1__IPU_CSI_D_2
-919 MX35_PAD_FEC_RDATA1__AUDMUX_AUD6_RXC
-920 MX35_PAD_FEC_RDATA1__USB_TOP_USBH2_OC
-921 MX35_PAD_FEC_RDATA1__KPP_COL_6
-922 MX35_PAD_FEC_RDATA1__GPIO3_18
-923 MX35_PAD_FEC_RDATA1__IPU_DISPB_BE0
-924 MX35_PAD_FEC_TDATA1__FEC_TDATA_1
-925 MX35_PAD_FEC_TDATA1__IPU_CSI_D_3
-926 MX35_PAD_FEC_TDATA1__AUDMUX_AUD6_RXFS
-927 MX35_PAD_FEC_TDATA1__KPP_COL_7
-928 MX35_PAD_FEC_TDATA1__GPIO3_19
-929 MX35_PAD_FEC_TDATA1__IPU_DISPB_BE1
-930 MX35_PAD_FEC_RDATA2__FEC_RDATA_2
-931 MX35_PAD_FEC_RDATA2__IPU_CSI_D_4
-932 MX35_PAD_FEC_RDATA2__AUDMUX_AUD6_TXD
-933 MX35_PAD_FEC_RDATA2__KPP_ROW_4
-934 MX35_PAD_FEC_RDATA2__GPIO3_20
-935 MX35_PAD_FEC_TDATA2__FEC_TDATA_2
-936 MX35_PAD_FEC_TDATA2__IPU_CSI_D_5
-937 MX35_PAD_FEC_TDATA2__AUDMUX_AUD6_RXD
-938 MX35_PAD_FEC_TDATA2__KPP_ROW_5
-939 MX35_PAD_FEC_TDATA2__GPIO3_21
-940 MX35_PAD_FEC_RDATA3__FEC_RDATA_3
-941 MX35_PAD_FEC_RDATA3__IPU_CSI_D_6
-942 MX35_PAD_FEC_RDATA3__AUDMUX_AUD6_TXC
-943 MX35_PAD_FEC_RDATA3__KPP_ROW_6
-944 MX35_PAD_FEC_RDATA3__GPIO3_22
-945 MX35_PAD_FEC_TDATA3__FEC_TDATA_3
-946 MX35_PAD_FEC_TDATA3__IPU_CSI_D_7
-947 MX35_PAD_FEC_TDATA3__AUDMUX_AUD6_TXFS
-948 MX35_PAD_FEC_TDATA3__KPP_ROW_7
-949 MX35_PAD_FEC_TDATA3__GPIO3_23
-950 MX35_PAD_EXT_ARMCLK__CCM_EXT_ARMCLK
-951 MX35_PAD_TEST_MODE__TCU_TEST_MODE
+Refer to imx35-pinfunc.h in device tree source folder for all available
+imx35 PIN_FUNC_ID.
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx51-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx51-pinctrl.txt
index b96fa4c..4d1408f 100644
--- a/Documentation/devicetree/bindings/pinctrl/fsl,imx51-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx51-pinctrl.txt
@@ -28,760 +28,5 @@
PAD_CTL_SRE_FAST (1 << 0)
PAD_CTL_SRE_SLOW (0 << 0)
-See below for available PIN_FUNC_ID for imx51:
-MX51_PAD_EIM_D16__AUD4_RXFS 0
-MX51_PAD_EIM_D16__AUD5_TXD 1
-MX51_PAD_EIM_D16__EIM_D16 2
-MX51_PAD_EIM_D16__GPIO2_0 3
-MX51_PAD_EIM_D16__I2C1_SDA 4
-MX51_PAD_EIM_D16__UART2_CTS 5
-MX51_PAD_EIM_D16__USBH2_DATA0 6
-MX51_PAD_EIM_D17__AUD5_RXD 7
-MX51_PAD_EIM_D17__EIM_D17 8
-MX51_PAD_EIM_D17__GPIO2_1 9
-MX51_PAD_EIM_D17__UART2_RXD 10
-MX51_PAD_EIM_D17__UART3_CTS 11
-MX51_PAD_EIM_D17__USBH2_DATA1 12
-MX51_PAD_EIM_D18__AUD5_TXC 13
-MX51_PAD_EIM_D18__EIM_D18 14
-MX51_PAD_EIM_D18__GPIO2_2 15
-MX51_PAD_EIM_D18__UART2_TXD 16
-MX51_PAD_EIM_D18__UART3_RTS 17
-MX51_PAD_EIM_D18__USBH2_DATA2 18
-MX51_PAD_EIM_D19__AUD4_RXC 19
-MX51_PAD_EIM_D19__AUD5_TXFS 20
-MX51_PAD_EIM_D19__EIM_D19 21
-MX51_PAD_EIM_D19__GPIO2_3 22
-MX51_PAD_EIM_D19__I2C1_SCL 23
-MX51_PAD_EIM_D19__UART2_RTS 24
-MX51_PAD_EIM_D19__USBH2_DATA3 25
-MX51_PAD_EIM_D20__AUD4_TXD 26
-MX51_PAD_EIM_D20__EIM_D20 27
-MX51_PAD_EIM_D20__GPIO2_4 28
-MX51_PAD_EIM_D20__SRTC_ALARM_DEB 29
-MX51_PAD_EIM_D20__USBH2_DATA4 30
-MX51_PAD_EIM_D21__AUD4_RXD 31
-MX51_PAD_EIM_D21__EIM_D21 32
-MX51_PAD_EIM_D21__GPIO2_5 33
-MX51_PAD_EIM_D21__SRTC_ALARM_DEB 34
-MX51_PAD_EIM_D21__USBH2_DATA5 35
-MX51_PAD_EIM_D22__AUD4_TXC 36
-MX51_PAD_EIM_D22__EIM_D22 37
-MX51_PAD_EIM_D22__GPIO2_6 38
-MX51_PAD_EIM_D22__USBH2_DATA6 39
-MX51_PAD_EIM_D23__AUD4_TXFS 40
-MX51_PAD_EIM_D23__EIM_D23 41
-MX51_PAD_EIM_D23__GPIO2_7 42
-MX51_PAD_EIM_D23__SPDIF_OUT1 43
-MX51_PAD_EIM_D23__USBH2_DATA7 44
-MX51_PAD_EIM_D24__AUD6_RXFS 45
-MX51_PAD_EIM_D24__EIM_D24 46
-MX51_PAD_EIM_D24__GPIO2_8 47
-MX51_PAD_EIM_D24__I2C2_SDA 48
-MX51_PAD_EIM_D24__UART3_CTS 49
-MX51_PAD_EIM_D24__USBOTG_DATA0 50
-MX51_PAD_EIM_D25__EIM_D25 51
-MX51_PAD_EIM_D25__KEY_COL6 52
-MX51_PAD_EIM_D25__UART2_CTS 53
-MX51_PAD_EIM_D25__UART3_RXD 54
-MX51_PAD_EIM_D25__USBOTG_DATA1 55
-MX51_PAD_EIM_D26__EIM_D26 56
-MX51_PAD_EIM_D26__KEY_COL7 57
-MX51_PAD_EIM_D26__UART2_RTS 58
-MX51_PAD_EIM_D26__UART3_TXD 59
-MX51_PAD_EIM_D26__USBOTG_DATA2 60
-MX51_PAD_EIM_D27__AUD6_RXC 61
-MX51_PAD_EIM_D27__EIM_D27 62
-MX51_PAD_EIM_D27__GPIO2_9 63
-MX51_PAD_EIM_D27__I2C2_SCL 64
-MX51_PAD_EIM_D27__UART3_RTS 65
-MX51_PAD_EIM_D27__USBOTG_DATA3 66
-MX51_PAD_EIM_D28__AUD6_TXD 67
-MX51_PAD_EIM_D28__EIM_D28 68
-MX51_PAD_EIM_D28__KEY_ROW4 69
-MX51_PAD_EIM_D28__USBOTG_DATA4 70
-MX51_PAD_EIM_D29__AUD6_RXD 71
-MX51_PAD_EIM_D29__EIM_D29 72
-MX51_PAD_EIM_D29__KEY_ROW5 73
-MX51_PAD_EIM_D29__USBOTG_DATA5 74
-MX51_PAD_EIM_D30__AUD6_TXC 75
-MX51_PAD_EIM_D30__EIM_D30 76
-MX51_PAD_EIM_D30__KEY_ROW6 77
-MX51_PAD_EIM_D30__USBOTG_DATA6 78
-MX51_PAD_EIM_D31__AUD6_TXFS 79
-MX51_PAD_EIM_D31__EIM_D31 80
-MX51_PAD_EIM_D31__KEY_ROW7 81
-MX51_PAD_EIM_D31__USBOTG_DATA7 82
-MX51_PAD_EIM_A16__EIM_A16 83
-MX51_PAD_EIM_A16__GPIO2_10 84
-MX51_PAD_EIM_A16__OSC_FREQ_SEL0 85
-MX51_PAD_EIM_A17__EIM_A17 86
-MX51_PAD_EIM_A17__GPIO2_11 87
-MX51_PAD_EIM_A17__OSC_FREQ_SEL1 88
-MX51_PAD_EIM_A18__BOOT_LPB0 89
-MX51_PAD_EIM_A18__EIM_A18 90
-MX51_PAD_EIM_A18__GPIO2_12 91
-MX51_PAD_EIM_A19__BOOT_LPB1 92
-MX51_PAD_EIM_A19__EIM_A19 93
-MX51_PAD_EIM_A19__GPIO2_13 94
-MX51_PAD_EIM_A20__BOOT_UART_SRC0 95
-MX51_PAD_EIM_A20__EIM_A20 96
-MX51_PAD_EIM_A20__GPIO2_14 97
-MX51_PAD_EIM_A21__BOOT_UART_SRC1 98
-MX51_PAD_EIM_A21__EIM_A21 99
-MX51_PAD_EIM_A21__GPIO2_15 100
-MX51_PAD_EIM_A22__EIM_A22 101
-MX51_PAD_EIM_A22__GPIO2_16 102
-MX51_PAD_EIM_A23__BOOT_HPN_EN 103
-MX51_PAD_EIM_A23__EIM_A23 104
-MX51_PAD_EIM_A23__GPIO2_17 105
-MX51_PAD_EIM_A24__EIM_A24 106
-MX51_PAD_EIM_A24__GPIO2_18 107
-MX51_PAD_EIM_A24__USBH2_CLK 108
-MX51_PAD_EIM_A25__DISP1_PIN4 109
-MX51_PAD_EIM_A25__EIM_A25 110
-MX51_PAD_EIM_A25__GPIO2_19 111
-MX51_PAD_EIM_A25__USBH2_DIR 112
-MX51_PAD_EIM_A26__CSI1_DATA_EN 113
-MX51_PAD_EIM_A26__DISP2_EXT_CLK 114
-MX51_PAD_EIM_A26__EIM_A26 115
-MX51_PAD_EIM_A26__GPIO2_20 116
-MX51_PAD_EIM_A26__USBH2_STP 117
-MX51_PAD_EIM_A27__CSI2_DATA_EN 118
-MX51_PAD_EIM_A27__DISP1_PIN1 119
-MX51_PAD_EIM_A27__EIM_A27 120
-MX51_PAD_EIM_A27__GPIO2_21 121
-MX51_PAD_EIM_A27__USBH2_NXT 122
-MX51_PAD_EIM_EB0__EIM_EB0 123
-MX51_PAD_EIM_EB1__EIM_EB1 124
-MX51_PAD_EIM_EB2__AUD5_RXFS 125
-MX51_PAD_EIM_EB2__CSI1_D2 126
-MX51_PAD_EIM_EB2__EIM_EB2 127
-MX51_PAD_EIM_EB2__FEC_MDIO 128
-MX51_PAD_EIM_EB2__GPIO2_22 129
-MX51_PAD_EIM_EB2__GPT_CMPOUT1 130
-MX51_PAD_EIM_EB3__AUD5_RXC 131
-MX51_PAD_EIM_EB3__CSI1_D3 132
-MX51_PAD_EIM_EB3__EIM_EB3 133
-MX51_PAD_EIM_EB3__FEC_RDATA1 134
-MX51_PAD_EIM_EB3__GPIO2_23 135
-MX51_PAD_EIM_EB3__GPT_CMPOUT2 136
-MX51_PAD_EIM_OE__EIM_OE 137
-MX51_PAD_EIM_OE__GPIO2_24 138
-MX51_PAD_EIM_CS0__EIM_CS0 139
-MX51_PAD_EIM_CS0__GPIO2_25 140
-MX51_PAD_EIM_CS1__EIM_CS1 141
-MX51_PAD_EIM_CS1__GPIO2_26 142
-MX51_PAD_EIM_CS2__AUD5_TXD 143
-MX51_PAD_EIM_CS2__CSI1_D4 144
-MX51_PAD_EIM_CS2__EIM_CS2 145
-MX51_PAD_EIM_CS2__FEC_RDATA2 146
-MX51_PAD_EIM_CS2__GPIO2_27 147
-MX51_PAD_EIM_CS2__USBOTG_STP 148
-MX51_PAD_EIM_CS3__AUD5_RXD 149
-MX51_PAD_EIM_CS3__CSI1_D5 150
-MX51_PAD_EIM_CS3__EIM_CS3 151
-MX51_PAD_EIM_CS3__FEC_RDATA3 152
-MX51_PAD_EIM_CS3__GPIO2_28 153
-MX51_PAD_EIM_CS3__USBOTG_NXT 154
-MX51_PAD_EIM_CS4__AUD5_TXC 155
-MX51_PAD_EIM_CS4__CSI1_D6 156
-MX51_PAD_EIM_CS4__EIM_CS4 157
-MX51_PAD_EIM_CS4__FEC_RX_ER 158
-MX51_PAD_EIM_CS4__GPIO2_29 159
-MX51_PAD_EIM_CS4__USBOTG_CLK 160
-MX51_PAD_EIM_CS5__AUD5_TXFS 161
-MX51_PAD_EIM_CS5__CSI1_D7 162
-MX51_PAD_EIM_CS5__DISP1_EXT_CLK 163
-MX51_PAD_EIM_CS5__EIM_CS5 164
-MX51_PAD_EIM_CS5__FEC_CRS 165
-MX51_PAD_EIM_CS5__GPIO2_30 166
-MX51_PAD_EIM_CS5__USBOTG_DIR 167
-MX51_PAD_EIM_DTACK__EIM_DTACK 168
-MX51_PAD_EIM_DTACK__GPIO2_31 169
-MX51_PAD_EIM_LBA__EIM_LBA 170
-MX51_PAD_EIM_LBA__GPIO3_1 171
-MX51_PAD_EIM_CRE__EIM_CRE 172
-MX51_PAD_EIM_CRE__GPIO3_2 173
-MX51_PAD_DRAM_CS1__DRAM_CS1 174
-MX51_PAD_NANDF_WE_B__GPIO3_3 175
-MX51_PAD_NANDF_WE_B__NANDF_WE_B 176
-MX51_PAD_NANDF_WE_B__PATA_DIOW 177
-MX51_PAD_NANDF_WE_B__SD3_DATA0 178
-MX51_PAD_NANDF_RE_B__GPIO3_4 179
-MX51_PAD_NANDF_RE_B__NANDF_RE_B 180
-MX51_PAD_NANDF_RE_B__PATA_DIOR 181
-MX51_PAD_NANDF_RE_B__SD3_DATA1 182
-MX51_PAD_NANDF_ALE__GPIO3_5 183
-MX51_PAD_NANDF_ALE__NANDF_ALE 184
-MX51_PAD_NANDF_ALE__PATA_BUFFER_EN 185
-MX51_PAD_NANDF_CLE__GPIO3_6 186
-MX51_PAD_NANDF_CLE__NANDF_CLE 187
-MX51_PAD_NANDF_CLE__PATA_RESET_B 188
-MX51_PAD_NANDF_WP_B__GPIO3_7 189
-MX51_PAD_NANDF_WP_B__NANDF_WP_B 190
-MX51_PAD_NANDF_WP_B__PATA_DMACK 191
-MX51_PAD_NANDF_WP_B__SD3_DATA2 192
-MX51_PAD_NANDF_RB0__ECSPI2_SS1 193
-MX51_PAD_NANDF_RB0__GPIO3_8 194
-MX51_PAD_NANDF_RB0__NANDF_RB0 195
-MX51_PAD_NANDF_RB0__PATA_DMARQ 196
-MX51_PAD_NANDF_RB0__SD3_DATA3 197
-MX51_PAD_NANDF_RB1__CSPI_MOSI 198
-MX51_PAD_NANDF_RB1__ECSPI2_RDY 199
-MX51_PAD_NANDF_RB1__GPIO3_9 200
-MX51_PAD_NANDF_RB1__NANDF_RB1 201
-MX51_PAD_NANDF_RB1__PATA_IORDY 202
-MX51_PAD_NANDF_RB1__SD4_CMD 203
-MX51_PAD_NANDF_RB2__DISP2_WAIT 204
-MX51_PAD_NANDF_RB2__ECSPI2_SCLK 205
-MX51_PAD_NANDF_RB2__FEC_COL 206
-MX51_PAD_NANDF_RB2__GPIO3_10 207
-MX51_PAD_NANDF_RB2__NANDF_RB2 208
-MX51_PAD_NANDF_RB2__USBH3_H3_DP 209
-MX51_PAD_NANDF_RB2__USBH3_NXT 210
-MX51_PAD_NANDF_RB3__DISP1_WAIT 211
-MX51_PAD_NANDF_RB3__ECSPI2_MISO 212
-MX51_PAD_NANDF_RB3__FEC_RX_CLK 213
-MX51_PAD_NANDF_RB3__GPIO3_11 214
-MX51_PAD_NANDF_RB3__NANDF_RB3 215
-MX51_PAD_NANDF_RB3__USBH3_CLK 216
-MX51_PAD_NANDF_RB3__USBH3_H3_DM 217
-MX51_PAD_GPIO_NAND__GPIO_NAND 218
-MX51_PAD_GPIO_NAND__PATA_INTRQ 219
-MX51_PAD_NANDF_CS0__GPIO3_16 220
-MX51_PAD_NANDF_CS0__NANDF_CS0 221
-MX51_PAD_NANDF_CS1__GPIO3_17 222
-MX51_PAD_NANDF_CS1__NANDF_CS1 223
-MX51_PAD_NANDF_CS2__CSPI_SCLK 224
-MX51_PAD_NANDF_CS2__FEC_TX_ER 225
-MX51_PAD_NANDF_CS2__GPIO3_18 226
-MX51_PAD_NANDF_CS2__NANDF_CS2 227
-MX51_PAD_NANDF_CS2__PATA_CS_0 228
-MX51_PAD_NANDF_CS2__SD4_CLK 229
-MX51_PAD_NANDF_CS2__USBH3_H1_DP 230
-MX51_PAD_NANDF_CS3__FEC_MDC 231
-MX51_PAD_NANDF_CS3__GPIO3_19 232
-MX51_PAD_NANDF_CS3__NANDF_CS3 233
-MX51_PAD_NANDF_CS3__PATA_CS_1 234
-MX51_PAD_NANDF_CS3__SD4_DAT0 235
-MX51_PAD_NANDF_CS3__USBH3_H1_DM 236
-MX51_PAD_NANDF_CS4__FEC_TDATA1 237
-MX51_PAD_NANDF_CS4__GPIO3_20 238
-MX51_PAD_NANDF_CS4__NANDF_CS4 239
-MX51_PAD_NANDF_CS4__PATA_DA_0 240
-MX51_PAD_NANDF_CS4__SD4_DAT1 241
-MX51_PAD_NANDF_CS4__USBH3_STP 242
-MX51_PAD_NANDF_CS5__FEC_TDATA2 243
-MX51_PAD_NANDF_CS5__GPIO3_21 244
-MX51_PAD_NANDF_CS5__NANDF_CS5 245
-MX51_PAD_NANDF_CS5__PATA_DA_1 246
-MX51_PAD_NANDF_CS5__SD4_DAT2 247
-MX51_PAD_NANDF_CS5__USBH3_DIR 248
-MX51_PAD_NANDF_CS6__CSPI_SS3 249
-MX51_PAD_NANDF_CS6__FEC_TDATA3 250
-MX51_PAD_NANDF_CS6__GPIO3_22 251
-MX51_PAD_NANDF_CS6__NANDF_CS6 252
-MX51_PAD_NANDF_CS6__PATA_DA_2 253
-MX51_PAD_NANDF_CS6__SD4_DAT3 254
-MX51_PAD_NANDF_CS7__FEC_TX_EN 255
-MX51_PAD_NANDF_CS7__GPIO3_23 256
-MX51_PAD_NANDF_CS7__NANDF_CS7 257
-MX51_PAD_NANDF_CS7__SD3_CLK 258
-MX51_PAD_NANDF_RDY_INT__ECSPI2_SS0 259
-MX51_PAD_NANDF_RDY_INT__FEC_TX_CLK 260
-MX51_PAD_NANDF_RDY_INT__GPIO3_24 261
-MX51_PAD_NANDF_RDY_INT__NANDF_RDY_INT 262
-MX51_PAD_NANDF_RDY_INT__SD3_CMD 263
-MX51_PAD_NANDF_D15__ECSPI2_MOSI 264
-MX51_PAD_NANDF_D15__GPIO3_25 265
-MX51_PAD_NANDF_D15__NANDF_D15 266
-MX51_PAD_NANDF_D15__PATA_DATA15 267
-MX51_PAD_NANDF_D15__SD3_DAT7 268
-MX51_PAD_NANDF_D14__ECSPI2_SS3 269
-MX51_PAD_NANDF_D14__GPIO3_26 270
-MX51_PAD_NANDF_D14__NANDF_D14 271
-MX51_PAD_NANDF_D14__PATA_DATA14 272
-MX51_PAD_NANDF_D14__SD3_DAT6 273
-MX51_PAD_NANDF_D13__ECSPI2_SS2 274
-MX51_PAD_NANDF_D13__GPIO3_27 275
-MX51_PAD_NANDF_D13__NANDF_D13 276
-MX51_PAD_NANDF_D13__PATA_DATA13 277
-MX51_PAD_NANDF_D13__SD3_DAT5 278
-MX51_PAD_NANDF_D12__ECSPI2_SS1 279
-MX51_PAD_NANDF_D12__GPIO3_28 280
-MX51_PAD_NANDF_D12__NANDF_D12 281
-MX51_PAD_NANDF_D12__PATA_DATA12 282
-MX51_PAD_NANDF_D12__SD3_DAT4 283
-MX51_PAD_NANDF_D11__FEC_RX_DV 284
-MX51_PAD_NANDF_D11__GPIO3_29 285
-MX51_PAD_NANDF_D11__NANDF_D11 286
-MX51_PAD_NANDF_D11__PATA_DATA11 287
-MX51_PAD_NANDF_D11__SD3_DATA3 288
-MX51_PAD_NANDF_D10__GPIO3_30 289
-MX51_PAD_NANDF_D10__NANDF_D10 290
-MX51_PAD_NANDF_D10__PATA_DATA10 291
-MX51_PAD_NANDF_D10__SD3_DATA2 292
-MX51_PAD_NANDF_D9__FEC_RDATA0 293
-MX51_PAD_NANDF_D9__GPIO3_31 294
-MX51_PAD_NANDF_D9__NANDF_D9 295
-MX51_PAD_NANDF_D9__PATA_DATA9 296
-MX51_PAD_NANDF_D9__SD3_DATA1 297
-MX51_PAD_NANDF_D8__FEC_TDATA0 298
-MX51_PAD_NANDF_D8__GPIO4_0 299
-MX51_PAD_NANDF_D8__NANDF_D8 300
-MX51_PAD_NANDF_D8__PATA_DATA8 301
-MX51_PAD_NANDF_D8__SD3_DATA0 302
-MX51_PAD_NANDF_D7__GPIO4_1 303
-MX51_PAD_NANDF_D7__NANDF_D7 304
-MX51_PAD_NANDF_D7__PATA_DATA7 305
-MX51_PAD_NANDF_D7__USBH3_DATA0 306
-MX51_PAD_NANDF_D6__GPIO4_2 307
-MX51_PAD_NANDF_D6__NANDF_D6 308
-MX51_PAD_NANDF_D6__PATA_DATA6 309
-MX51_PAD_NANDF_D6__SD4_LCTL 310
-MX51_PAD_NANDF_D6__USBH3_DATA1 311
-MX51_PAD_NANDF_D5__GPIO4_3 312
-MX51_PAD_NANDF_D5__NANDF_D5 313
-MX51_PAD_NANDF_D5__PATA_DATA5 314
-MX51_PAD_NANDF_D5__SD4_WP 315
-MX51_PAD_NANDF_D5__USBH3_DATA2 316
-MX51_PAD_NANDF_D4__GPIO4_4 317
-MX51_PAD_NANDF_D4__NANDF_D4 318
-MX51_PAD_NANDF_D4__PATA_DATA4 319
-MX51_PAD_NANDF_D4__SD4_CD 320
-MX51_PAD_NANDF_D4__USBH3_DATA3 321
-MX51_PAD_NANDF_D3__GPIO4_5 322
-MX51_PAD_NANDF_D3__NANDF_D3 323
-MX51_PAD_NANDF_D3__PATA_DATA3 324
-MX51_PAD_NANDF_D3__SD4_DAT4 325
-MX51_PAD_NANDF_D3__USBH3_DATA4 326
-MX51_PAD_NANDF_D2__GPIO4_6 327
-MX51_PAD_NANDF_D2__NANDF_D2 328
-MX51_PAD_NANDF_D2__PATA_DATA2 329
-MX51_PAD_NANDF_D2__SD4_DAT5 330
-MX51_PAD_NANDF_D2__USBH3_DATA5 331
-MX51_PAD_NANDF_D1__GPIO4_7 332
-MX51_PAD_NANDF_D1__NANDF_D1 333
-MX51_PAD_NANDF_D1__PATA_DATA1 334
-MX51_PAD_NANDF_D1__SD4_DAT6 335
-MX51_PAD_NANDF_D1__USBH3_DATA6 336
-MX51_PAD_NANDF_D0__GPIO4_8 337
-MX51_PAD_NANDF_D0__NANDF_D0 338
-MX51_PAD_NANDF_D0__PATA_DATA0 339
-MX51_PAD_NANDF_D0__SD4_DAT7 340
-MX51_PAD_NANDF_D0__USBH3_DATA7 341
-MX51_PAD_CSI1_D8__CSI1_D8 342
-MX51_PAD_CSI1_D8__GPIO3_12 343
-MX51_PAD_CSI1_D9__CSI1_D9 344
-MX51_PAD_CSI1_D9__GPIO3_13 345
-MX51_PAD_CSI1_D10__CSI1_D10 346
-MX51_PAD_CSI1_D11__CSI1_D11 347
-MX51_PAD_CSI1_D12__CSI1_D12 348
-MX51_PAD_CSI1_D13__CSI1_D13 349
-MX51_PAD_CSI1_D14__CSI1_D14 350
-MX51_PAD_CSI1_D15__CSI1_D15 351
-MX51_PAD_CSI1_D16__CSI1_D16 352
-MX51_PAD_CSI1_D17__CSI1_D17 353
-MX51_PAD_CSI1_D18__CSI1_D18 354
-MX51_PAD_CSI1_D19__CSI1_D19 355
-MX51_PAD_CSI1_VSYNC__CSI1_VSYNC 356
-MX51_PAD_CSI1_VSYNC__GPIO3_14 357
-MX51_PAD_CSI1_HSYNC__CSI1_HSYNC 358
-MX51_PAD_CSI1_HSYNC__GPIO3_15 359
-MX51_PAD_CSI1_PIXCLK__CSI1_PIXCLK 360
-MX51_PAD_CSI1_MCLK__CSI1_MCLK 361
-MX51_PAD_CSI2_D12__CSI2_D12 362
-MX51_PAD_CSI2_D12__GPIO4_9 363
-MX51_PAD_CSI2_D13__CSI2_D13 364
-MX51_PAD_CSI2_D13__GPIO4_10 365
-MX51_PAD_CSI2_D14__CSI2_D14 366
-MX51_PAD_CSI2_D15__CSI2_D15 367
-MX51_PAD_CSI2_D16__CSI2_D16 368
-MX51_PAD_CSI2_D17__CSI2_D17 369
-MX51_PAD_CSI2_D18__CSI2_D18 370
-MX51_PAD_CSI2_D18__GPIO4_11 371
-MX51_PAD_CSI2_D19__CSI2_D19 372
-MX51_PAD_CSI2_D19__GPIO4_12 373
-MX51_PAD_CSI2_VSYNC__CSI2_VSYNC 374
-MX51_PAD_CSI2_VSYNC__GPIO4_13 375
-MX51_PAD_CSI2_HSYNC__CSI2_HSYNC 376
-MX51_PAD_CSI2_HSYNC__GPIO4_14 377
-MX51_PAD_CSI2_PIXCLK__CSI2_PIXCLK 378
-MX51_PAD_CSI2_PIXCLK__GPIO4_15 379
-MX51_PAD_I2C1_CLK__GPIO4_16 380
-MX51_PAD_I2C1_CLK__I2C1_CLK 381
-MX51_PAD_I2C1_DAT__GPIO4_17 382
-MX51_PAD_I2C1_DAT__I2C1_DAT 383
-MX51_PAD_AUD3_BB_TXD__AUD3_TXD 384
-MX51_PAD_AUD3_BB_TXD__GPIO4_18 385
-MX51_PAD_AUD3_BB_RXD__AUD3_RXD 386
-MX51_PAD_AUD3_BB_RXD__GPIO4_19 387
-MX51_PAD_AUD3_BB_RXD__UART3_RXD 388
-MX51_PAD_AUD3_BB_CK__AUD3_TXC 389
-MX51_PAD_AUD3_BB_CK__GPIO4_20 390
-MX51_PAD_AUD3_BB_FS__AUD3_TXFS 391
-MX51_PAD_AUD3_BB_FS__GPIO4_21 392
-MX51_PAD_AUD3_BB_FS__UART3_TXD 393
-MX51_PAD_CSPI1_MOSI__ECSPI1_MOSI 394
-MX51_PAD_CSPI1_MOSI__GPIO4_22 395
-MX51_PAD_CSPI1_MOSI__I2C1_SDA 396
-MX51_PAD_CSPI1_MISO__AUD4_RXD 397
-MX51_PAD_CSPI1_MISO__ECSPI1_MISO 398
-MX51_PAD_CSPI1_MISO__GPIO4_23 399
-MX51_PAD_CSPI1_SS0__AUD4_TXC 400
-MX51_PAD_CSPI1_SS0__ECSPI1_SS0 401
-MX51_PAD_CSPI1_SS0__GPIO4_24 402
-MX51_PAD_CSPI1_SS1__AUD4_TXD 403
-MX51_PAD_CSPI1_SS1__ECSPI1_SS1 404
-MX51_PAD_CSPI1_SS1__GPIO4_25 405
-MX51_PAD_CSPI1_RDY__AUD4_TXFS 406
-MX51_PAD_CSPI1_RDY__ECSPI1_RDY 407
-MX51_PAD_CSPI1_RDY__GPIO4_26 408
-MX51_PAD_CSPI1_SCLK__ECSPI1_SCLK 409
-MX51_PAD_CSPI1_SCLK__GPIO4_27 410
-MX51_PAD_CSPI1_SCLK__I2C1_SCL 411
-MX51_PAD_UART1_RXD__GPIO4_28 412
-MX51_PAD_UART1_RXD__UART1_RXD 413
-MX51_PAD_UART1_TXD__GPIO4_29 414
-MX51_PAD_UART1_TXD__PWM2_PWMO 415
-MX51_PAD_UART1_TXD__UART1_TXD 416
-MX51_PAD_UART1_RTS__GPIO4_30 417
-MX51_PAD_UART1_RTS__UART1_RTS 418
-MX51_PAD_UART1_CTS__GPIO4_31 419
-MX51_PAD_UART1_CTS__UART1_CTS 420
-MX51_PAD_UART2_RXD__FIRI_TXD 421
-MX51_PAD_UART2_RXD__GPIO1_20 422
-MX51_PAD_UART2_RXD__UART2_RXD 423
-MX51_PAD_UART2_TXD__FIRI_RXD 424
-MX51_PAD_UART2_TXD__GPIO1_21 425
-MX51_PAD_UART2_TXD__UART2_TXD 426
-MX51_PAD_UART3_RXD__CSI1_D0 427
-MX51_PAD_UART3_RXD__GPIO1_22 428
-MX51_PAD_UART3_RXD__UART1_DTR 429
-MX51_PAD_UART3_RXD__UART3_RXD 430
-MX51_PAD_UART3_TXD__CSI1_D1 431
-MX51_PAD_UART3_TXD__GPIO1_23 432
-MX51_PAD_UART3_TXD__UART1_DSR 433
-MX51_PAD_UART3_TXD__UART3_TXD 434
-MX51_PAD_OWIRE_LINE__GPIO1_24 435
-MX51_PAD_OWIRE_LINE__OWIRE_LINE 436
-MX51_PAD_OWIRE_LINE__SPDIF_OUT 437
-MX51_PAD_KEY_ROW0__KEY_ROW0 438
-MX51_PAD_KEY_ROW1__KEY_ROW1 439
-MX51_PAD_KEY_ROW2__KEY_ROW2 440
-MX51_PAD_KEY_ROW3__KEY_ROW3 441
-MX51_PAD_KEY_COL0__KEY_COL0 442
-MX51_PAD_KEY_COL0__PLL1_BYP 443
-MX51_PAD_KEY_COL1__KEY_COL1 444
-MX51_PAD_KEY_COL1__PLL2_BYP 445
-MX51_PAD_KEY_COL2__KEY_COL2 446
-MX51_PAD_KEY_COL2__PLL3_BYP 447
-MX51_PAD_KEY_COL3__KEY_COL3 448
-MX51_PAD_KEY_COL4__I2C2_SCL 449
-MX51_PAD_KEY_COL4__KEY_COL4 450
-MX51_PAD_KEY_COL4__SPDIF_OUT1 451
-MX51_PAD_KEY_COL4__UART1_RI 452
-MX51_PAD_KEY_COL4__UART3_RTS 453
-MX51_PAD_KEY_COL5__I2C2_SDA 454
-MX51_PAD_KEY_COL5__KEY_COL5 455
-MX51_PAD_KEY_COL5__UART1_DCD 456
-MX51_PAD_KEY_COL5__UART3_CTS 457
-MX51_PAD_USBH1_CLK__CSPI_SCLK 458
-MX51_PAD_USBH1_CLK__GPIO1_25 459
-MX51_PAD_USBH1_CLK__I2C2_SCL 460
-MX51_PAD_USBH1_CLK__USBH1_CLK 461
-MX51_PAD_USBH1_DIR__CSPI_MOSI 462
-MX51_PAD_USBH1_DIR__GPIO1_26 463
-MX51_PAD_USBH1_DIR__I2C2_SDA 464
-MX51_PAD_USBH1_DIR__USBH1_DIR 465
-MX51_PAD_USBH1_STP__CSPI_RDY 466
-MX51_PAD_USBH1_STP__GPIO1_27 467
-MX51_PAD_USBH1_STP__UART3_RXD 468
-MX51_PAD_USBH1_STP__USBH1_STP 469
-MX51_PAD_USBH1_NXT__CSPI_MISO 470
-MX51_PAD_USBH1_NXT__GPIO1_28 471
-MX51_PAD_USBH1_NXT__UART3_TXD 472
-MX51_PAD_USBH1_NXT__USBH1_NXT 473
-MX51_PAD_USBH1_DATA0__GPIO1_11 474
-MX51_PAD_USBH1_DATA0__UART2_CTS 475
-MX51_PAD_USBH1_DATA0__USBH1_DATA0 476
-MX51_PAD_USBH1_DATA1__GPIO1_12 477
-MX51_PAD_USBH1_DATA1__UART2_RXD 478
-MX51_PAD_USBH1_DATA1__USBH1_DATA1 479
-MX51_PAD_USBH1_DATA2__GPIO1_13 480
-MX51_PAD_USBH1_DATA2__UART2_TXD 481
-MX51_PAD_USBH1_DATA2__USBH1_DATA2 482
-MX51_PAD_USBH1_DATA3__GPIO1_14 483
-MX51_PAD_USBH1_DATA3__UART2_RTS 484
-MX51_PAD_USBH1_DATA3__USBH1_DATA3 485
-MX51_PAD_USBH1_DATA4__CSPI_SS0 486
-MX51_PAD_USBH1_DATA4__GPIO1_15 487
-MX51_PAD_USBH1_DATA4__USBH1_DATA4 488
-MX51_PAD_USBH1_DATA5__CSPI_SS1 489
-MX51_PAD_USBH1_DATA5__GPIO1_16 490
-MX51_PAD_USBH1_DATA5__USBH1_DATA5 491
-MX51_PAD_USBH1_DATA6__CSPI_SS3 492
-MX51_PAD_USBH1_DATA6__GPIO1_17 493
-MX51_PAD_USBH1_DATA6__USBH1_DATA6 494
-MX51_PAD_USBH1_DATA7__ECSPI1_SS3 495
-MX51_PAD_USBH1_DATA7__ECSPI2_SS3 496
-MX51_PAD_USBH1_DATA7__GPIO1_18 497
-MX51_PAD_USBH1_DATA7__USBH1_DATA7 498
-MX51_PAD_DI1_PIN11__DI1_PIN11 499
-MX51_PAD_DI1_PIN11__ECSPI1_SS2 500
-MX51_PAD_DI1_PIN11__GPIO3_0 501
-MX51_PAD_DI1_PIN12__DI1_PIN12 502
-MX51_PAD_DI1_PIN12__GPIO3_1 503
-MX51_PAD_DI1_PIN13__DI1_PIN13 504
-MX51_PAD_DI1_PIN13__GPIO3_2 505
-MX51_PAD_DI1_D0_CS__DI1_D0_CS 506
-MX51_PAD_DI1_D0_CS__GPIO3_3 507
-MX51_PAD_DI1_D1_CS__DI1_D1_CS 508
-MX51_PAD_DI1_D1_CS__DISP1_PIN14 509
-MX51_PAD_DI1_D1_CS__DISP1_PIN5 510
-MX51_PAD_DI1_D1_CS__GPIO3_4 511
-MX51_PAD_DISPB2_SER_DIN__DISP1_PIN1 512
-MX51_PAD_DISPB2_SER_DIN__DISPB2_SER_DIN 513
-MX51_PAD_DISPB2_SER_DIN__GPIO3_5 514
-MX51_PAD_DISPB2_SER_DIO__DISP1_PIN6 515
-MX51_PAD_DISPB2_SER_DIO__DISPB2_SER_DIO 516
-MX51_PAD_DISPB2_SER_DIO__GPIO3_6 517
-MX51_PAD_DISPB2_SER_CLK__DISP1_PIN17 518
-MX51_PAD_DISPB2_SER_CLK__DISP1_PIN7 519
-MX51_PAD_DISPB2_SER_CLK__DISPB2_SER_CLK 520
-MX51_PAD_DISPB2_SER_CLK__GPIO3_7 521
-MX51_PAD_DISPB2_SER_RS__DISP1_EXT_CLK 522
-MX51_PAD_DISPB2_SER_RS__DISP1_PIN16 523
-MX51_PAD_DISPB2_SER_RS__DISP1_PIN8 524
-MX51_PAD_DISPB2_SER_RS__DISPB2_SER_RS 525
-MX51_PAD_DISPB2_SER_RS__DISPB2_SER_RS 526
-MX51_PAD_DISPB2_SER_RS__GPIO3_8 527
-MX51_PAD_DISP1_DAT0__DISP1_DAT0 528
-MX51_PAD_DISP1_DAT1__DISP1_DAT1 529
-MX51_PAD_DISP1_DAT2__DISP1_DAT2 530
-MX51_PAD_DISP1_DAT3__DISP1_DAT3 531
-MX51_PAD_DISP1_DAT4__DISP1_DAT4 532
-MX51_PAD_DISP1_DAT5__DISP1_DAT5 533
-MX51_PAD_DISP1_DAT6__BOOT_USB_SRC 534
-MX51_PAD_DISP1_DAT6__DISP1_DAT6 535
-MX51_PAD_DISP1_DAT7__BOOT_EEPROM_CFG 536
-MX51_PAD_DISP1_DAT7__DISP1_DAT7 537
-MX51_PAD_DISP1_DAT8__BOOT_SRC0 538
-MX51_PAD_DISP1_DAT8__DISP1_DAT8 539
-MX51_PAD_DISP1_DAT9__BOOT_SRC1 540
-MX51_PAD_DISP1_DAT9__DISP1_DAT9 541
-MX51_PAD_DISP1_DAT10__BOOT_SPARE_SIZE 542
-MX51_PAD_DISP1_DAT10__DISP1_DAT10 543
-MX51_PAD_DISP1_DAT11__BOOT_LPB_FREQ2 544
-MX51_PAD_DISP1_DAT11__DISP1_DAT11 545
-MX51_PAD_DISP1_DAT12__BOOT_MLC_SEL 546
-MX51_PAD_DISP1_DAT12__DISP1_DAT12 547
-MX51_PAD_DISP1_DAT13__BOOT_MEM_CTL0 548
-MX51_PAD_DISP1_DAT13__DISP1_DAT13 549
-MX51_PAD_DISP1_DAT14__BOOT_MEM_CTL1 550
-MX51_PAD_DISP1_DAT14__DISP1_DAT14 551
-MX51_PAD_DISP1_DAT15__BOOT_BUS_WIDTH 552
-MX51_PAD_DISP1_DAT15__DISP1_DAT15 553
-MX51_PAD_DISP1_DAT16__BOOT_PAGE_SIZE0 554
-MX51_PAD_DISP1_DAT16__DISP1_DAT16 555
-MX51_PAD_DISP1_DAT17__BOOT_PAGE_SIZE1 556
-MX51_PAD_DISP1_DAT17__DISP1_DAT17 557
-MX51_PAD_DISP1_DAT18__BOOT_WEIM_MUXED0 558
-MX51_PAD_DISP1_DAT18__DISP1_DAT18 559
-MX51_PAD_DISP1_DAT18__DISP2_PIN11 560
-MX51_PAD_DISP1_DAT18__DISP2_PIN5 561
-MX51_PAD_DISP1_DAT19__BOOT_WEIM_MUXED1 562
-MX51_PAD_DISP1_DAT19__DISP1_DAT19 563
-MX51_PAD_DISP1_DAT19__DISP2_PIN12 564
-MX51_PAD_DISP1_DAT19__DISP2_PIN6 565
-MX51_PAD_DISP1_DAT20__BOOT_MEM_TYPE0 566
-MX51_PAD_DISP1_DAT20__DISP1_DAT20 567
-MX51_PAD_DISP1_DAT20__DISP2_PIN13 568
-MX51_PAD_DISP1_DAT20__DISP2_PIN7 569
-MX51_PAD_DISP1_DAT21__BOOT_MEM_TYPE1 570
-MX51_PAD_DISP1_DAT21__DISP1_DAT21 571
-MX51_PAD_DISP1_DAT21__DISP2_PIN14 572
-MX51_PAD_DISP1_DAT21__DISP2_PIN8 573
-MX51_PAD_DISP1_DAT22__BOOT_LPB_FREQ0 574
-MX51_PAD_DISP1_DAT22__DISP1_DAT22 575
-MX51_PAD_DISP1_DAT22__DISP2_D0_CS 576
-MX51_PAD_DISP1_DAT22__DISP2_DAT16 577
-MX51_PAD_DISP1_DAT23__BOOT_LPB_FREQ1 578
-MX51_PAD_DISP1_DAT23__DISP1_DAT23 579
-MX51_PAD_DISP1_DAT23__DISP2_D1_CS 580
-MX51_PAD_DISP1_DAT23__DISP2_DAT17 581
-MX51_PAD_DISP1_DAT23__DISP2_SER_CS 582
-MX51_PAD_DI1_PIN3__DI1_PIN3 583
-MX51_PAD_DI1_PIN2__DI1_PIN2 584
-MX51_PAD_DI_GP2__DISP1_SER_CLK 585
-MX51_PAD_DI_GP2__DISP2_WAIT 586
-MX51_PAD_DI_GP3__CSI1_DATA_EN 587
-MX51_PAD_DI_GP3__DISP1_SER_DIO 588
-MX51_PAD_DI_GP3__FEC_TX_ER 589
-MX51_PAD_DI2_PIN4__CSI2_DATA_EN 590
-MX51_PAD_DI2_PIN4__DI2_PIN4 591
-MX51_PAD_DI2_PIN4__FEC_CRS 592
-MX51_PAD_DI2_PIN2__DI2_PIN2 593
-MX51_PAD_DI2_PIN2__FEC_MDC 594
-MX51_PAD_DI2_PIN3__DI2_PIN3 595
-MX51_PAD_DI2_PIN3__FEC_MDIO 596
-MX51_PAD_DI2_DISP_CLK__DI2_DISP_CLK 597
-MX51_PAD_DI2_DISP_CLK__FEC_RDATA1 598
-MX51_PAD_DI_GP4__DI2_PIN15 599
-MX51_PAD_DI_GP4__DISP1_SER_DIN 600
-MX51_PAD_DI_GP4__DISP2_PIN1 601
-MX51_PAD_DI_GP4__FEC_RDATA2 602
-MX51_PAD_DISP2_DAT0__DISP2_DAT0 603
-MX51_PAD_DISP2_DAT0__FEC_RDATA3 604
-MX51_PAD_DISP2_DAT0__KEY_COL6 605
-MX51_PAD_DISP2_DAT0__UART3_RXD 606
-MX51_PAD_DISP2_DAT0__USBH3_CLK 607
-MX51_PAD_DISP2_DAT1__DISP2_DAT1 608
-MX51_PAD_DISP2_DAT1__FEC_RX_ER 609
-MX51_PAD_DISP2_DAT1__KEY_COL7 610
-MX51_PAD_DISP2_DAT1__UART3_TXD 611
-MX51_PAD_DISP2_DAT1__USBH3_DIR 612
-MX51_PAD_DISP2_DAT2__DISP2_DAT2 613
-MX51_PAD_DISP2_DAT3__DISP2_DAT3 614
-MX51_PAD_DISP2_DAT4__DISP2_DAT4 615
-MX51_PAD_DISP2_DAT5__DISP2_DAT5 616
-MX51_PAD_DISP2_DAT6__DISP2_DAT6 617
-MX51_PAD_DISP2_DAT6__FEC_TDATA1 618
-MX51_PAD_DISP2_DAT6__GPIO1_19 619
-MX51_PAD_DISP2_DAT6__KEY_ROW4 620
-MX51_PAD_DISP2_DAT6__USBH3_STP 621
-MX51_PAD_DISP2_DAT7__DISP2_DAT7 622
-MX51_PAD_DISP2_DAT7__FEC_TDATA2 623
-MX51_PAD_DISP2_DAT7__GPIO1_29 624
-MX51_PAD_DISP2_DAT7__KEY_ROW5 625
-MX51_PAD_DISP2_DAT7__USBH3_NXT 626
-MX51_PAD_DISP2_DAT8__DISP2_DAT8 627
-MX51_PAD_DISP2_DAT8__FEC_TDATA3 628
-MX51_PAD_DISP2_DAT8__GPIO1_30 629
-MX51_PAD_DISP2_DAT8__KEY_ROW6 630
-MX51_PAD_DISP2_DAT8__USBH3_DATA0 631
-MX51_PAD_DISP2_DAT9__AUD6_RXC 632
-MX51_PAD_DISP2_DAT9__DISP2_DAT9 633
-MX51_PAD_DISP2_DAT9__FEC_TX_EN 634
-MX51_PAD_DISP2_DAT9__GPIO1_31 635
-MX51_PAD_DISP2_DAT9__USBH3_DATA1 636
-MX51_PAD_DISP2_DAT10__DISP2_DAT10 637
-MX51_PAD_DISP2_DAT10__DISP2_SER_CS 638
-MX51_PAD_DISP2_DAT10__FEC_COL 639
-MX51_PAD_DISP2_DAT10__KEY_ROW7 640
-MX51_PAD_DISP2_DAT10__USBH3_DATA2 641
-MX51_PAD_DISP2_DAT11__AUD6_TXD 642
-MX51_PAD_DISP2_DAT11__DISP2_DAT11 643
-MX51_PAD_DISP2_DAT11__FEC_RX_CLK 644
-MX51_PAD_DISP2_DAT11__GPIO1_10 645
-MX51_PAD_DISP2_DAT11__USBH3_DATA3 646
-MX51_PAD_DISP2_DAT12__AUD6_RXD 647
-MX51_PAD_DISP2_DAT12__DISP2_DAT12 648
-MX51_PAD_DISP2_DAT12__FEC_RX_DV 649
-MX51_PAD_DISP2_DAT12__USBH3_DATA4 650
-MX51_PAD_DISP2_DAT13__AUD6_TXC 651
-MX51_PAD_DISP2_DAT13__DISP2_DAT13 652
-MX51_PAD_DISP2_DAT13__FEC_TX_CLK 653
-MX51_PAD_DISP2_DAT13__USBH3_DATA5 654
-MX51_PAD_DISP2_DAT14__AUD6_TXFS 655
-MX51_PAD_DISP2_DAT14__DISP2_DAT14 656
-MX51_PAD_DISP2_DAT14__FEC_RDATA0 657
-MX51_PAD_DISP2_DAT14__USBH3_DATA6 658
-MX51_PAD_DISP2_DAT15__AUD6_RXFS 659
-MX51_PAD_DISP2_DAT15__DISP1_SER_CS 660
-MX51_PAD_DISP2_DAT15__DISP2_DAT15 661
-MX51_PAD_DISP2_DAT15__FEC_TDATA0 662
-MX51_PAD_DISP2_DAT15__USBH3_DATA7 663
-MX51_PAD_SD1_CMD__AUD5_RXFS 664
-MX51_PAD_SD1_CMD__CSPI_MOSI 665
-MX51_PAD_SD1_CMD__SD1_CMD 666
-MX51_PAD_SD1_CLK__AUD5_RXC 667
-MX51_PAD_SD1_CLK__CSPI_SCLK 668
-MX51_PAD_SD1_CLK__SD1_CLK 669
-MX51_PAD_SD1_DATA0__AUD5_TXD 670
-MX51_PAD_SD1_DATA0__CSPI_MISO 671
-MX51_PAD_SD1_DATA0__SD1_DATA0 672
-MX51_PAD_EIM_DA0__EIM_DA0 673
-MX51_PAD_EIM_DA1__EIM_DA1 674
-MX51_PAD_EIM_DA2__EIM_DA2 675
-MX51_PAD_EIM_DA3__EIM_DA3 676
-MX51_PAD_SD1_DATA1__AUD5_RXD 677
-MX51_PAD_SD1_DATA1__SD1_DATA1 678
-MX51_PAD_EIM_DA4__EIM_DA4 679
-MX51_PAD_EIM_DA5__EIM_DA5 680
-MX51_PAD_EIM_DA6__EIM_DA6 681
-MX51_PAD_EIM_DA7__EIM_DA7 682
-MX51_PAD_SD1_DATA2__AUD5_TXC 683
-MX51_PAD_SD1_DATA2__SD1_DATA2 684
-MX51_PAD_EIM_DA10__EIM_DA10 685
-MX51_PAD_EIM_DA11__EIM_DA11 686
-MX51_PAD_EIM_DA8__EIM_DA8 687
-MX51_PAD_EIM_DA9__EIM_DA9 688
-MX51_PAD_SD1_DATA3__AUD5_TXFS 689
-MX51_PAD_SD1_DATA3__CSPI_SS1 690
-MX51_PAD_SD1_DATA3__SD1_DATA3 691
-MX51_PAD_GPIO1_0__CSPI_SS2 692
-MX51_PAD_GPIO1_0__GPIO1_0 693
-MX51_PAD_GPIO1_0__SD1_CD 694
-MX51_PAD_GPIO1_1__CSPI_MISO 695
-MX51_PAD_GPIO1_1__GPIO1_1 696
-MX51_PAD_GPIO1_1__SD1_WP 697
-MX51_PAD_EIM_DA12__EIM_DA12 698
-MX51_PAD_EIM_DA13__EIM_DA13 699
-MX51_PAD_EIM_DA14__EIM_DA14 700
-MX51_PAD_EIM_DA15__EIM_DA15 701
-MX51_PAD_SD2_CMD__CSPI_MOSI 702
-MX51_PAD_SD2_CMD__I2C1_SCL 703
-MX51_PAD_SD2_CMD__SD2_CMD 704
-MX51_PAD_SD2_CLK__CSPI_SCLK 705
-MX51_PAD_SD2_CLK__I2C1_SDA 706
-MX51_PAD_SD2_CLK__SD2_CLK 707
-MX51_PAD_SD2_DATA0__CSPI_MISO 708
-MX51_PAD_SD2_DATA0__SD1_DAT4 709
-MX51_PAD_SD2_DATA0__SD2_DATA0 710
-MX51_PAD_SD2_DATA1__SD1_DAT5 711
-MX51_PAD_SD2_DATA1__SD2_DATA1 712
-MX51_PAD_SD2_DATA1__USBH3_H2_DP 713
-MX51_PAD_SD2_DATA2__SD1_DAT6 714
-MX51_PAD_SD2_DATA2__SD2_DATA2 715
-MX51_PAD_SD2_DATA2__USBH3_H2_DM 716
-MX51_PAD_SD2_DATA3__CSPI_SS2 717
-MX51_PAD_SD2_DATA3__SD1_DAT7 718
-MX51_PAD_SD2_DATA3__SD2_DATA3 719
-MX51_PAD_GPIO1_2__CCM_OUT_2 720
-MX51_PAD_GPIO1_2__GPIO1_2 721
-MX51_PAD_GPIO1_2__I2C2_SCL 722
-MX51_PAD_GPIO1_2__PLL1_BYP 723
-MX51_PAD_GPIO1_2__PWM1_PWMO 724
-MX51_PAD_GPIO1_3__GPIO1_3 725
-MX51_PAD_GPIO1_3__I2C2_SDA 726
-MX51_PAD_GPIO1_3__PLL2_BYP 727
-MX51_PAD_GPIO1_3__PWM2_PWMO 728
-MX51_PAD_PMIC_INT_REQ__PMIC_INT_REQ 729
-MX51_PAD_PMIC_INT_REQ__PMIC_PMU_IRQ_B 730
-MX51_PAD_GPIO1_4__DISP2_EXT_CLK 731
-MX51_PAD_GPIO1_4__EIM_RDY 732
-MX51_PAD_GPIO1_4__GPIO1_4 733
-MX51_PAD_GPIO1_4__WDOG1_WDOG_B 734
-MX51_PAD_GPIO1_5__CSI2_MCLK 735
-MX51_PAD_GPIO1_5__DISP2_PIN16 736
-MX51_PAD_GPIO1_5__GPIO1_5 737
-MX51_PAD_GPIO1_5__WDOG2_WDOG_B 738
-MX51_PAD_GPIO1_6__DISP2_PIN17 739
-MX51_PAD_GPIO1_6__GPIO1_6 740
-MX51_PAD_GPIO1_6__REF_EN_B 741
-MX51_PAD_GPIO1_7__CCM_OUT_0 742
-MX51_PAD_GPIO1_7__GPIO1_7 743
-MX51_PAD_GPIO1_7__SD2_WP 744
-MX51_PAD_GPIO1_7__SPDIF_OUT1 745
-MX51_PAD_GPIO1_8__CSI2_DATA_EN 746
-MX51_PAD_GPIO1_8__GPIO1_8 747
-MX51_PAD_GPIO1_8__SD2_CD 748
-MX51_PAD_GPIO1_8__USBH3_PWR 749
-MX51_PAD_GPIO1_9__CCM_OUT_1 750
-MX51_PAD_GPIO1_9__DISP2_D1_CS 751
-MX51_PAD_GPIO1_9__DISP2_SER_CS 752
-MX51_PAD_GPIO1_9__GPIO1_9 753
-MX51_PAD_GPIO1_9__SD2_LCTL 754
-MX51_PAD_GPIO1_9__USBH3_OC 755
+Refer to imx51-pinfunc.h in device tree source folder for all available
+imx51 PIN_FUNC_ID.
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx53-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx53-pinctrl.txt
index ca85ca4..25dcb77 100644
--- a/Documentation/devicetree/bindings/pinctrl/fsl,imx53-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx53-pinctrl.txt
@@ -28,1175 +28,5 @@
PAD_CTL_SRE_FAST (1 << 0)
PAD_CTL_SRE_SLOW (0 << 0)
-See below for available PIN_FUNC_ID for imx53:
-MX53_PAD_GPIO_19__KPP_COL_5 0
-MX53_PAD_GPIO_19__GPIO4_5 1
-MX53_PAD_GPIO_19__CCM_CLKO 2
-MX53_PAD_GPIO_19__SPDIF_OUT1 3
-MX53_PAD_GPIO_19__RTC_CE_RTC_EXT_TRIG2 4
-MX53_PAD_GPIO_19__ECSPI1_RDY 5
-MX53_PAD_GPIO_19__FEC_TDATA_3 6
-MX53_PAD_GPIO_19__SRC_INT_BOOT 7
-MX53_PAD_KEY_COL0__KPP_COL_0 8
-MX53_PAD_KEY_COL0__GPIO4_6 9
-MX53_PAD_KEY_COL0__AUDMUX_AUD5_TXC 10
-MX53_PAD_KEY_COL0__UART4_TXD_MUX 11
-MX53_PAD_KEY_COL0__ECSPI1_SCLK 12
-MX53_PAD_KEY_COL0__FEC_RDATA_3 13
-MX53_PAD_KEY_COL0__SRC_ANY_PU_RST 14
-MX53_PAD_KEY_ROW0__KPP_ROW_0 15
-MX53_PAD_KEY_ROW0__GPIO4_7 16
-MX53_PAD_KEY_ROW0__AUDMUX_AUD5_TXD 17
-MX53_PAD_KEY_ROW0__UART4_RXD_MUX 18
-MX53_PAD_KEY_ROW0__ECSPI1_MOSI 19
-MX53_PAD_KEY_ROW0__FEC_TX_ER 20
-MX53_PAD_KEY_COL1__KPP_COL_1 21
-MX53_PAD_KEY_COL1__GPIO4_8 22
-MX53_PAD_KEY_COL1__AUDMUX_AUD5_TXFS 23
-MX53_PAD_KEY_COL1__UART5_TXD_MUX 24
-MX53_PAD_KEY_COL1__ECSPI1_MISO 25
-MX53_PAD_KEY_COL1__FEC_RX_CLK 26
-MX53_PAD_KEY_COL1__USBPHY1_TXREADY 27
-MX53_PAD_KEY_ROW1__KPP_ROW_1 28
-MX53_PAD_KEY_ROW1__GPIO4_9 29
-MX53_PAD_KEY_ROW1__AUDMUX_AUD5_RXD 30
-MX53_PAD_KEY_ROW1__UART5_RXD_MUX 31
-MX53_PAD_KEY_ROW1__ECSPI1_SS0 32
-MX53_PAD_KEY_ROW1__FEC_COL 33
-MX53_PAD_KEY_ROW1__USBPHY1_RXVALID 34
-MX53_PAD_KEY_COL2__KPP_COL_2 35
-MX53_PAD_KEY_COL2__GPIO4_10 36
-MX53_PAD_KEY_COL2__CAN1_TXCAN 37
-MX53_PAD_KEY_COL2__FEC_MDIO 38
-MX53_PAD_KEY_COL2__ECSPI1_SS1 39
-MX53_PAD_KEY_COL2__FEC_RDATA_2 40
-MX53_PAD_KEY_COL2__USBPHY1_RXACTIVE 41
-MX53_PAD_KEY_ROW2__KPP_ROW_2 42
-MX53_PAD_KEY_ROW2__GPIO4_11 43
-MX53_PAD_KEY_ROW2__CAN1_RXCAN 44
-MX53_PAD_KEY_ROW2__FEC_MDC 45
-MX53_PAD_KEY_ROW2__ECSPI1_SS2 46
-MX53_PAD_KEY_ROW2__FEC_TDATA_2 47
-MX53_PAD_KEY_ROW2__USBPHY1_RXERROR 48
-MX53_PAD_KEY_COL3__KPP_COL_3 49
-MX53_PAD_KEY_COL3__GPIO4_12 50
-MX53_PAD_KEY_COL3__USBOH3_H2_DP 51
-MX53_PAD_KEY_COL3__SPDIF_IN1 52
-MX53_PAD_KEY_COL3__I2C2_SCL 53
-MX53_PAD_KEY_COL3__ECSPI1_SS3 54
-MX53_PAD_KEY_COL3__FEC_CRS 55
-MX53_PAD_KEY_COL3__USBPHY1_SIECLOCK 56
-MX53_PAD_KEY_ROW3__KPP_ROW_3 57
-MX53_PAD_KEY_ROW3__GPIO4_13 58
-MX53_PAD_KEY_ROW3__USBOH3_H2_DM 59
-MX53_PAD_KEY_ROW3__CCM_ASRC_EXT_CLK 60
-MX53_PAD_KEY_ROW3__I2C2_SDA 61
-MX53_PAD_KEY_ROW3__OSC32K_32K_OUT 62
-MX53_PAD_KEY_ROW3__CCM_PLL4_BYP 63
-MX53_PAD_KEY_ROW3__USBPHY1_LINESTATE_0 64
-MX53_PAD_KEY_COL4__KPP_COL_4 65
-MX53_PAD_KEY_COL4__GPIO4_14 66
-MX53_PAD_KEY_COL4__CAN2_TXCAN 67
-MX53_PAD_KEY_COL4__IPU_SISG_4 68
-MX53_PAD_KEY_COL4__UART5_RTS 69
-MX53_PAD_KEY_COL4__USBOH3_USBOTG_OC 70
-MX53_PAD_KEY_COL4__USBPHY1_LINESTATE_1 71
-MX53_PAD_KEY_ROW4__KPP_ROW_4 72
-MX53_PAD_KEY_ROW4__GPIO4_15 73
-MX53_PAD_KEY_ROW4__CAN2_RXCAN 74
-MX53_PAD_KEY_ROW4__IPU_SISG_5 75
-MX53_PAD_KEY_ROW4__UART5_CTS 76
-MX53_PAD_KEY_ROW4__USBOH3_USBOTG_PWR 77
-MX53_PAD_KEY_ROW4__USBPHY1_VBUSVALID 78
-MX53_PAD_DI0_DISP_CLK__IPU_DI0_DISP_CLK 79
-MX53_PAD_DI0_DISP_CLK__GPIO4_16 80
-MX53_PAD_DI0_DISP_CLK__USBOH3_USBH2_DIR 81
-MX53_PAD_DI0_DISP_CLK__SDMA_DEBUG_CORE_STATE_0 82
-MX53_PAD_DI0_DISP_CLK__EMI_EMI_DEBUG_0 83
-MX53_PAD_DI0_DISP_CLK__USBPHY1_AVALID 84
-MX53_PAD_DI0_PIN15__IPU_DI0_PIN15 85
-MX53_PAD_DI0_PIN15__GPIO4_17 86
-MX53_PAD_DI0_PIN15__AUDMUX_AUD6_TXC 87
-MX53_PAD_DI0_PIN15__SDMA_DEBUG_CORE_STATE_1 88
-MX53_PAD_DI0_PIN15__EMI_EMI_DEBUG_1 89
-MX53_PAD_DI0_PIN15__USBPHY1_BVALID 90
-MX53_PAD_DI0_PIN2__IPU_DI0_PIN2 91
-MX53_PAD_DI0_PIN2__GPIO4_18 92
-MX53_PAD_DI0_PIN2__AUDMUX_AUD6_TXD 93
-MX53_PAD_DI0_PIN2__SDMA_DEBUG_CORE_STATE_2 94
-MX53_PAD_DI0_PIN2__EMI_EMI_DEBUG_2 95
-MX53_PAD_DI0_PIN2__USBPHY1_ENDSESSION 96
-MX53_PAD_DI0_PIN3__IPU_DI0_PIN3 97
-MX53_PAD_DI0_PIN3__GPIO4_19 98
-MX53_PAD_DI0_PIN3__AUDMUX_AUD6_TXFS 99
-MX53_PAD_DI0_PIN3__SDMA_DEBUG_CORE_STATE_3 100
-MX53_PAD_DI0_PIN3__EMI_EMI_DEBUG_3 101
-MX53_PAD_DI0_PIN3__USBPHY1_IDDIG 102
-MX53_PAD_DI0_PIN4__IPU_DI0_PIN4 103
-MX53_PAD_DI0_PIN4__GPIO4_20 104
-MX53_PAD_DI0_PIN4__AUDMUX_AUD6_RXD 105
-MX53_PAD_DI0_PIN4__ESDHC1_WP 106
-MX53_PAD_DI0_PIN4__SDMA_DEBUG_YIELD 107
-MX53_PAD_DI0_PIN4__EMI_EMI_DEBUG_4 108
-MX53_PAD_DI0_PIN4__USBPHY1_HOSTDISCONNECT 109
-MX53_PAD_DISP0_DAT0__IPU_DISP0_DAT_0 110
-MX53_PAD_DISP0_DAT0__GPIO4_21 111
-MX53_PAD_DISP0_DAT0__CSPI_SCLK 112
-MX53_PAD_DISP0_DAT0__USBOH3_USBH2_DATA_0 113
-MX53_PAD_DISP0_DAT0__SDMA_DEBUG_CORE_RUN 114
-MX53_PAD_DISP0_DAT0__EMI_EMI_DEBUG_5 115
-MX53_PAD_DISP0_DAT0__USBPHY2_TXREADY 116
-MX53_PAD_DISP0_DAT1__IPU_DISP0_DAT_1 117
-MX53_PAD_DISP0_DAT1__GPIO4_22 118
-MX53_PAD_DISP0_DAT1__CSPI_MOSI 119
-MX53_PAD_DISP0_DAT1__USBOH3_USBH2_DATA_1 120
-MX53_PAD_DISP0_DAT1__SDMA_DEBUG_EVENT_CHANNEL_SEL 121
-MX53_PAD_DISP0_DAT1__EMI_EMI_DEBUG_6 122
-MX53_PAD_DISP0_DAT1__USBPHY2_RXVALID 123
-MX53_PAD_DISP0_DAT2__IPU_DISP0_DAT_2 124
-MX53_PAD_DISP0_DAT2__GPIO4_23 125
-MX53_PAD_DISP0_DAT2__CSPI_MISO 126
-MX53_PAD_DISP0_DAT2__USBOH3_USBH2_DATA_2 127
-MX53_PAD_DISP0_DAT2__SDMA_DEBUG_MODE 128
-MX53_PAD_DISP0_DAT2__EMI_EMI_DEBUG_7 129
-MX53_PAD_DISP0_DAT2__USBPHY2_RXACTIVE 130
-MX53_PAD_DISP0_DAT3__IPU_DISP0_DAT_3 131
-MX53_PAD_DISP0_DAT3__GPIO4_24 132
-MX53_PAD_DISP0_DAT3__CSPI_SS0 133
-MX53_PAD_DISP0_DAT3__USBOH3_USBH2_DATA_3 134
-MX53_PAD_DISP0_DAT3__SDMA_DEBUG_BUS_ERROR 135
-MX53_PAD_DISP0_DAT3__EMI_EMI_DEBUG_8 136
-MX53_PAD_DISP0_DAT3__USBPHY2_RXERROR 137
-MX53_PAD_DISP0_DAT4__IPU_DISP0_DAT_4 138
-MX53_PAD_DISP0_DAT4__GPIO4_25 139
-MX53_PAD_DISP0_DAT4__CSPI_SS1 140
-MX53_PAD_DISP0_DAT4__USBOH3_USBH2_DATA_4 141
-MX53_PAD_DISP0_DAT4__SDMA_DEBUG_BUS_RWB 142
-MX53_PAD_DISP0_DAT4__EMI_EMI_DEBUG_9 143
-MX53_PAD_DISP0_DAT4__USBPHY2_SIECLOCK 144
-MX53_PAD_DISP0_DAT5__IPU_DISP0_DAT_5 145
-MX53_PAD_DISP0_DAT5__GPIO4_26 146
-MX53_PAD_DISP0_DAT5__CSPI_SS2 147
-MX53_PAD_DISP0_DAT5__USBOH3_USBH2_DATA_5 148
-MX53_PAD_DISP0_DAT5__SDMA_DEBUG_MATCHED_DMBUS 149
-MX53_PAD_DISP0_DAT5__EMI_EMI_DEBUG_10 150
-MX53_PAD_DISP0_DAT5__USBPHY2_LINESTATE_0 151
-MX53_PAD_DISP0_DAT6__IPU_DISP0_DAT_6 152
-MX53_PAD_DISP0_DAT6__GPIO4_27 153
-MX53_PAD_DISP0_DAT6__CSPI_SS3 154
-MX53_PAD_DISP0_DAT6__USBOH3_USBH2_DATA_6 155
-MX53_PAD_DISP0_DAT6__SDMA_DEBUG_RTBUFFER_WRITE 156
-MX53_PAD_DISP0_DAT6__EMI_EMI_DEBUG_11 157
-MX53_PAD_DISP0_DAT6__USBPHY2_LINESTATE_1 158
-MX53_PAD_DISP0_DAT7__IPU_DISP0_DAT_7 159
-MX53_PAD_DISP0_DAT7__GPIO4_28 160
-MX53_PAD_DISP0_DAT7__CSPI_RDY 161
-MX53_PAD_DISP0_DAT7__USBOH3_USBH2_DATA_7 162
-MX53_PAD_DISP0_DAT7__SDMA_DEBUG_EVENT_CHANNEL_0 163
-MX53_PAD_DISP0_DAT7__EMI_EMI_DEBUG_12 164
-MX53_PAD_DISP0_DAT7__USBPHY2_VBUSVALID 165
-MX53_PAD_DISP0_DAT8__IPU_DISP0_DAT_8 166
-MX53_PAD_DISP0_DAT8__GPIO4_29 167
-MX53_PAD_DISP0_DAT8__PWM1_PWMO 168
-MX53_PAD_DISP0_DAT8__WDOG1_WDOG_B 169
-MX53_PAD_DISP0_DAT8__SDMA_DEBUG_EVENT_CHANNEL_1 170
-MX53_PAD_DISP0_DAT8__EMI_EMI_DEBUG_13 171
-MX53_PAD_DISP0_DAT8__USBPHY2_AVALID 172
-MX53_PAD_DISP0_DAT9__IPU_DISP0_DAT_9 173
-MX53_PAD_DISP0_DAT9__GPIO4_30 174
-MX53_PAD_DISP0_DAT9__PWM2_PWMO 175
-MX53_PAD_DISP0_DAT9__WDOG2_WDOG_B 176
-MX53_PAD_DISP0_DAT9__SDMA_DEBUG_EVENT_CHANNEL_2 177
-MX53_PAD_DISP0_DAT9__EMI_EMI_DEBUG_14 178
-MX53_PAD_DISP0_DAT9__USBPHY2_VSTATUS_0 179
-MX53_PAD_DISP0_DAT10__IPU_DISP0_DAT_10 180
-MX53_PAD_DISP0_DAT10__GPIO4_31 181
-MX53_PAD_DISP0_DAT10__USBOH3_USBH2_STP 182
-MX53_PAD_DISP0_DAT10__SDMA_DEBUG_EVENT_CHANNEL_3 183
-MX53_PAD_DISP0_DAT10__EMI_EMI_DEBUG_15 184
-MX53_PAD_DISP0_DAT10__USBPHY2_VSTATUS_1 185
-MX53_PAD_DISP0_DAT11__IPU_DISP0_DAT_11 186
-MX53_PAD_DISP0_DAT11__GPIO5_5 187
-MX53_PAD_DISP0_DAT11__USBOH3_USBH2_NXT 188
-MX53_PAD_DISP0_DAT11__SDMA_DEBUG_EVENT_CHANNEL_4 189
-MX53_PAD_DISP0_DAT11__EMI_EMI_DEBUG_16 190
-MX53_PAD_DISP0_DAT11__USBPHY2_VSTATUS_2 191
-MX53_PAD_DISP0_DAT12__IPU_DISP0_DAT_12 192
-MX53_PAD_DISP0_DAT12__GPIO5_6 193
-MX53_PAD_DISP0_DAT12__USBOH3_USBH2_CLK 194
-MX53_PAD_DISP0_DAT12__SDMA_DEBUG_EVENT_CHANNEL_5 195
-MX53_PAD_DISP0_DAT12__EMI_EMI_DEBUG_17 196
-MX53_PAD_DISP0_DAT12__USBPHY2_VSTATUS_3 197
-MX53_PAD_DISP0_DAT13__IPU_DISP0_DAT_13 198
-MX53_PAD_DISP0_DAT13__GPIO5_7 199
-MX53_PAD_DISP0_DAT13__AUDMUX_AUD5_RXFS 200
-MX53_PAD_DISP0_DAT13__SDMA_DEBUG_EVT_CHN_LINES_0 201
-MX53_PAD_DISP0_DAT13__EMI_EMI_DEBUG_18 202
-MX53_PAD_DISP0_DAT13__USBPHY2_VSTATUS_4 203
-MX53_PAD_DISP0_DAT14__IPU_DISP0_DAT_14 204
-MX53_PAD_DISP0_DAT14__GPIO5_8 205
-MX53_PAD_DISP0_DAT14__AUDMUX_AUD5_RXC 206
-MX53_PAD_DISP0_DAT14__SDMA_DEBUG_EVT_CHN_LINES_1 207
-MX53_PAD_DISP0_DAT14__EMI_EMI_DEBUG_19 208
-MX53_PAD_DISP0_DAT14__USBPHY2_VSTATUS_5 209
-MX53_PAD_DISP0_DAT15__IPU_DISP0_DAT_15 210
-MX53_PAD_DISP0_DAT15__GPIO5_9 211
-MX53_PAD_DISP0_DAT15__ECSPI1_SS1 212
-MX53_PAD_DISP0_DAT15__ECSPI2_SS1 213
-MX53_PAD_DISP0_DAT15__SDMA_DEBUG_EVT_CHN_LINES_2 214
-MX53_PAD_DISP0_DAT15__EMI_EMI_DEBUG_20 215
-MX53_PAD_DISP0_DAT15__USBPHY2_VSTATUS_6 216
-MX53_PAD_DISP0_DAT16__IPU_DISP0_DAT_16 217
-MX53_PAD_DISP0_DAT16__GPIO5_10 218
-MX53_PAD_DISP0_DAT16__ECSPI2_MOSI 219
-MX53_PAD_DISP0_DAT16__AUDMUX_AUD5_TXC 220
-MX53_PAD_DISP0_DAT16__SDMA_EXT_EVENT_0 221
-MX53_PAD_DISP0_DAT16__SDMA_DEBUG_EVT_CHN_LINES_3 222
-MX53_PAD_DISP0_DAT16__EMI_EMI_DEBUG_21 223
-MX53_PAD_DISP0_DAT16__USBPHY2_VSTATUS_7 224
-MX53_PAD_DISP0_DAT17__IPU_DISP0_DAT_17 225
-MX53_PAD_DISP0_DAT17__GPIO5_11 226
-MX53_PAD_DISP0_DAT17__ECSPI2_MISO 227
-MX53_PAD_DISP0_DAT17__AUDMUX_AUD5_TXD 228
-MX53_PAD_DISP0_DAT17__SDMA_EXT_EVENT_1 229
-MX53_PAD_DISP0_DAT17__SDMA_DEBUG_EVT_CHN_LINES_4 230
-MX53_PAD_DISP0_DAT17__EMI_EMI_DEBUG_22 231
-MX53_PAD_DISP0_DAT18__IPU_DISP0_DAT_18 232
-MX53_PAD_DISP0_DAT18__GPIO5_12 233
-MX53_PAD_DISP0_DAT18__ECSPI2_SS0 234
-MX53_PAD_DISP0_DAT18__AUDMUX_AUD5_TXFS 235
-MX53_PAD_DISP0_DAT18__AUDMUX_AUD4_RXFS 236
-MX53_PAD_DISP0_DAT18__SDMA_DEBUG_EVT_CHN_LINES_5 237
-MX53_PAD_DISP0_DAT18__EMI_EMI_DEBUG_23 238
-MX53_PAD_DISP0_DAT18__EMI_WEIM_CS_2 239
-MX53_PAD_DISP0_DAT19__IPU_DISP0_DAT_19 240
-MX53_PAD_DISP0_DAT19__GPIO5_13 241
-MX53_PAD_DISP0_DAT19__ECSPI2_SCLK 242
-MX53_PAD_DISP0_DAT19__AUDMUX_AUD5_RXD 243
-MX53_PAD_DISP0_DAT19__AUDMUX_AUD4_RXC 244
-MX53_PAD_DISP0_DAT19__SDMA_DEBUG_EVT_CHN_LINES_6 245
-MX53_PAD_DISP0_DAT19__EMI_EMI_DEBUG_24 246
-MX53_PAD_DISP0_DAT19__EMI_WEIM_CS_3 247
-MX53_PAD_DISP0_DAT20__IPU_DISP0_DAT_20 248
-MX53_PAD_DISP0_DAT20__GPIO5_14 249
-MX53_PAD_DISP0_DAT20__ECSPI1_SCLK 250
-MX53_PAD_DISP0_DAT20__AUDMUX_AUD4_TXC 251
-MX53_PAD_DISP0_DAT20__SDMA_DEBUG_EVT_CHN_LINES_7 252
-MX53_PAD_DISP0_DAT20__EMI_EMI_DEBUG_25 253
-MX53_PAD_DISP0_DAT20__SATA_PHY_TDI 254
-MX53_PAD_DISP0_DAT21__IPU_DISP0_DAT_21 255
-MX53_PAD_DISP0_DAT21__GPIO5_15 256
-MX53_PAD_DISP0_DAT21__ECSPI1_MOSI 257
-MX53_PAD_DISP0_DAT21__AUDMUX_AUD4_TXD 258
-MX53_PAD_DISP0_DAT21__SDMA_DEBUG_BUS_DEVICE_0 259
-MX53_PAD_DISP0_DAT21__EMI_EMI_DEBUG_26 260
-MX53_PAD_DISP0_DAT21__SATA_PHY_TDO 261
-MX53_PAD_DISP0_DAT22__IPU_DISP0_DAT_22 262
-MX53_PAD_DISP0_DAT22__GPIO5_16 263
-MX53_PAD_DISP0_DAT22__ECSPI1_MISO 264
-MX53_PAD_DISP0_DAT22__AUDMUX_AUD4_TXFS 265
-MX53_PAD_DISP0_DAT22__SDMA_DEBUG_BUS_DEVICE_1 266
-MX53_PAD_DISP0_DAT22__EMI_EMI_DEBUG_27 267
-MX53_PAD_DISP0_DAT22__SATA_PHY_TCK 268
-MX53_PAD_DISP0_DAT23__IPU_DISP0_DAT_23 269
-MX53_PAD_DISP0_DAT23__GPIO5_17 270
-MX53_PAD_DISP0_DAT23__ECSPI1_SS0 271
-MX53_PAD_DISP0_DAT23__AUDMUX_AUD4_RXD 272
-MX53_PAD_DISP0_DAT23__SDMA_DEBUG_BUS_DEVICE_2 273
-MX53_PAD_DISP0_DAT23__EMI_EMI_DEBUG_28 274
-MX53_PAD_DISP0_DAT23__SATA_PHY_TMS 275
-MX53_PAD_CSI0_PIXCLK__IPU_CSI0_PIXCLK 276
-MX53_PAD_CSI0_PIXCLK__GPIO5_18 277
-MX53_PAD_CSI0_PIXCLK__SDMA_DEBUG_PC_0 278
-MX53_PAD_CSI0_PIXCLK__EMI_EMI_DEBUG_29 279
-MX53_PAD_CSI0_MCLK__IPU_CSI0_HSYNC 280
-MX53_PAD_CSI0_MCLK__GPIO5_19 281
-MX53_PAD_CSI0_MCLK__CCM_CSI0_MCLK 282
-MX53_PAD_CSI0_MCLK__SDMA_DEBUG_PC_1 283
-MX53_PAD_CSI0_MCLK__EMI_EMI_DEBUG_30 284
-MX53_PAD_CSI0_MCLK__TPIU_TRCTL 285
-MX53_PAD_CSI0_DATA_EN__IPU_CSI0_DATA_EN 286
-MX53_PAD_CSI0_DATA_EN__GPIO5_20 287
-MX53_PAD_CSI0_DATA_EN__SDMA_DEBUG_PC_2 288
-MX53_PAD_CSI0_DATA_EN__EMI_EMI_DEBUG_31 289
-MX53_PAD_CSI0_DATA_EN__TPIU_TRCLK 290
-MX53_PAD_CSI0_VSYNC__IPU_CSI0_VSYNC 291
-MX53_PAD_CSI0_VSYNC__GPIO5_21 292
-MX53_PAD_CSI0_VSYNC__SDMA_DEBUG_PC_3 293
-MX53_PAD_CSI0_VSYNC__EMI_EMI_DEBUG_32 294
-MX53_PAD_CSI0_VSYNC__TPIU_TRACE_0 295
-MX53_PAD_CSI0_DAT4__IPU_CSI0_D_4 296
-MX53_PAD_CSI0_DAT4__GPIO5_22 297
-MX53_PAD_CSI0_DAT4__KPP_COL_5 298
-MX53_PAD_CSI0_DAT4__ECSPI1_SCLK 299
-MX53_PAD_CSI0_DAT4__USBOH3_USBH3_STP 300
-MX53_PAD_CSI0_DAT4__AUDMUX_AUD3_TXC 301
-MX53_PAD_CSI0_DAT4__EMI_EMI_DEBUG_33 302
-MX53_PAD_CSI0_DAT4__TPIU_TRACE_1 303
-MX53_PAD_CSI0_DAT5__IPU_CSI0_D_5 304
-MX53_PAD_CSI0_DAT5__GPIO5_23 305
-MX53_PAD_CSI0_DAT5__KPP_ROW_5 306
-MX53_PAD_CSI0_DAT5__ECSPI1_MOSI 307
-MX53_PAD_CSI0_DAT5__USBOH3_USBH3_NXT 308
-MX53_PAD_CSI0_DAT5__AUDMUX_AUD3_TXD 309
-MX53_PAD_CSI0_DAT5__EMI_EMI_DEBUG_34 310
-MX53_PAD_CSI0_DAT5__TPIU_TRACE_2 311
-MX53_PAD_CSI0_DAT6__IPU_CSI0_D_6 312
-MX53_PAD_CSI0_DAT6__GPIO5_24 313
-MX53_PAD_CSI0_DAT6__KPP_COL_6 314
-MX53_PAD_CSI0_DAT6__ECSPI1_MISO 315
-MX53_PAD_CSI0_DAT6__USBOH3_USBH3_CLK 316
-MX53_PAD_CSI0_DAT6__AUDMUX_AUD3_TXFS 317
-MX53_PAD_CSI0_DAT6__EMI_EMI_DEBUG_35 318
-MX53_PAD_CSI0_DAT6__TPIU_TRACE_3 319
-MX53_PAD_CSI0_DAT7__IPU_CSI0_D_7 320
-MX53_PAD_CSI0_DAT7__GPIO5_25 321
-MX53_PAD_CSI0_DAT7__KPP_ROW_6 322
-MX53_PAD_CSI0_DAT7__ECSPI1_SS0 323
-MX53_PAD_CSI0_DAT7__USBOH3_USBH3_DIR 324
-MX53_PAD_CSI0_DAT7__AUDMUX_AUD3_RXD 325
-MX53_PAD_CSI0_DAT7__EMI_EMI_DEBUG_36 326
-MX53_PAD_CSI0_DAT7__TPIU_TRACE_4 327
-MX53_PAD_CSI0_DAT8__IPU_CSI0_D_8 328
-MX53_PAD_CSI0_DAT8__GPIO5_26 329
-MX53_PAD_CSI0_DAT8__KPP_COL_7 330
-MX53_PAD_CSI0_DAT8__ECSPI2_SCLK 331
-MX53_PAD_CSI0_DAT8__USBOH3_USBH3_OC 332
-MX53_PAD_CSI0_DAT8__I2C1_SDA 333
-MX53_PAD_CSI0_DAT8__EMI_EMI_DEBUG_37 334
-MX53_PAD_CSI0_DAT8__TPIU_TRACE_5 335
-MX53_PAD_CSI0_DAT9__IPU_CSI0_D_9 336
-MX53_PAD_CSI0_DAT9__GPIO5_27 337
-MX53_PAD_CSI0_DAT9__KPP_ROW_7 338
-MX53_PAD_CSI0_DAT9__ECSPI2_MOSI 339
-MX53_PAD_CSI0_DAT9__USBOH3_USBH3_PWR 340
-MX53_PAD_CSI0_DAT9__I2C1_SCL 341
-MX53_PAD_CSI0_DAT9__EMI_EMI_DEBUG_38 342
-MX53_PAD_CSI0_DAT9__TPIU_TRACE_6 343
-MX53_PAD_CSI0_DAT10__IPU_CSI0_D_10 344
-MX53_PAD_CSI0_DAT10__GPIO5_28 345
-MX53_PAD_CSI0_DAT10__UART1_TXD_MUX 346
-MX53_PAD_CSI0_DAT10__ECSPI2_MISO 347
-MX53_PAD_CSI0_DAT10__AUDMUX_AUD3_RXC 348
-MX53_PAD_CSI0_DAT10__SDMA_DEBUG_PC_4 349
-MX53_PAD_CSI0_DAT10__EMI_EMI_DEBUG_39 350
-MX53_PAD_CSI0_DAT10__TPIU_TRACE_7 351
-MX53_PAD_CSI0_DAT11__IPU_CSI0_D_11 352
-MX53_PAD_CSI0_DAT11__GPIO5_29 353
-MX53_PAD_CSI0_DAT11__UART1_RXD_MUX 354
-MX53_PAD_CSI0_DAT11__ECSPI2_SS0 355
-MX53_PAD_CSI0_DAT11__AUDMUX_AUD3_RXFS 356
-MX53_PAD_CSI0_DAT11__SDMA_DEBUG_PC_5 357
-MX53_PAD_CSI0_DAT11__EMI_EMI_DEBUG_40 358
-MX53_PAD_CSI0_DAT11__TPIU_TRACE_8 359
-MX53_PAD_CSI0_DAT12__IPU_CSI0_D_12 360
-MX53_PAD_CSI0_DAT12__GPIO5_30 361
-MX53_PAD_CSI0_DAT12__UART4_TXD_MUX 362
-MX53_PAD_CSI0_DAT12__USBOH3_USBH3_DATA_0 363
-MX53_PAD_CSI0_DAT12__SDMA_DEBUG_PC_6 364
-MX53_PAD_CSI0_DAT12__EMI_EMI_DEBUG_41 365
-MX53_PAD_CSI0_DAT12__TPIU_TRACE_9 366
-MX53_PAD_CSI0_DAT13__IPU_CSI0_D_13 367
-MX53_PAD_CSI0_DAT13__GPIO5_31 368
-MX53_PAD_CSI0_DAT13__UART4_RXD_MUX 369
-MX53_PAD_CSI0_DAT13__USBOH3_USBH3_DATA_1 370
-MX53_PAD_CSI0_DAT13__SDMA_DEBUG_PC_7 371
-MX53_PAD_CSI0_DAT13__EMI_EMI_DEBUG_42 372
-MX53_PAD_CSI0_DAT13__TPIU_TRACE_10 373
-MX53_PAD_CSI0_DAT14__IPU_CSI0_D_14 374
-MX53_PAD_CSI0_DAT14__GPIO6_0 375
-MX53_PAD_CSI0_DAT14__UART5_TXD_MUX 376
-MX53_PAD_CSI0_DAT14__USBOH3_USBH3_DATA_2 377
-MX53_PAD_CSI0_DAT14__SDMA_DEBUG_PC_8 378
-MX53_PAD_CSI0_DAT14__EMI_EMI_DEBUG_43 379
-MX53_PAD_CSI0_DAT14__TPIU_TRACE_11 380
-MX53_PAD_CSI0_DAT15__IPU_CSI0_D_15 381
-MX53_PAD_CSI0_DAT15__GPIO6_1 382
-MX53_PAD_CSI0_DAT15__UART5_RXD_MUX 383
-MX53_PAD_CSI0_DAT15__USBOH3_USBH3_DATA_3 384
-MX53_PAD_CSI0_DAT15__SDMA_DEBUG_PC_9 385
-MX53_PAD_CSI0_DAT15__EMI_EMI_DEBUG_44 386
-MX53_PAD_CSI0_DAT15__TPIU_TRACE_12 387
-MX53_PAD_CSI0_DAT16__IPU_CSI0_D_16 388
-MX53_PAD_CSI0_DAT16__GPIO6_2 389
-MX53_PAD_CSI0_DAT16__UART4_RTS 390
-MX53_PAD_CSI0_DAT16__USBOH3_USBH3_DATA_4 391
-MX53_PAD_CSI0_DAT16__SDMA_DEBUG_PC_10 392
-MX53_PAD_CSI0_DAT16__EMI_EMI_DEBUG_45 393
-MX53_PAD_CSI0_DAT16__TPIU_TRACE_13 394
-MX53_PAD_CSI0_DAT17__IPU_CSI0_D_17 395
-MX53_PAD_CSI0_DAT17__GPIO6_3 396
-MX53_PAD_CSI0_DAT17__UART4_CTS 397
-MX53_PAD_CSI0_DAT17__USBOH3_USBH3_DATA_5 398
-MX53_PAD_CSI0_DAT17__SDMA_DEBUG_PC_11 399
-MX53_PAD_CSI0_DAT17__EMI_EMI_DEBUG_46 400
-MX53_PAD_CSI0_DAT17__TPIU_TRACE_14 401
-MX53_PAD_CSI0_DAT18__IPU_CSI0_D_18 402
-MX53_PAD_CSI0_DAT18__GPIO6_4 403
-MX53_PAD_CSI0_DAT18__UART5_RTS 404
-MX53_PAD_CSI0_DAT18__USBOH3_USBH3_DATA_6 405
-MX53_PAD_CSI0_DAT18__SDMA_DEBUG_PC_12 406
-MX53_PAD_CSI0_DAT18__EMI_EMI_DEBUG_47 407
-MX53_PAD_CSI0_DAT18__TPIU_TRACE_15 408
-MX53_PAD_CSI0_DAT19__IPU_CSI0_D_19 409
-MX53_PAD_CSI0_DAT19__GPIO6_5 410
-MX53_PAD_CSI0_DAT19__UART5_CTS 411
-MX53_PAD_CSI0_DAT19__USBOH3_USBH3_DATA_7 412
-MX53_PAD_CSI0_DAT19__SDMA_DEBUG_PC_13 413
-MX53_PAD_CSI0_DAT19__EMI_EMI_DEBUG_48 414
-MX53_PAD_CSI0_DAT19__USBPHY2_BISTOK 415
-MX53_PAD_EIM_A25__EMI_WEIM_A_25 416
-MX53_PAD_EIM_A25__GPIO5_2 417
-MX53_PAD_EIM_A25__ECSPI2_RDY 418
-MX53_PAD_EIM_A25__IPU_DI1_PIN12 419
-MX53_PAD_EIM_A25__CSPI_SS1 420
-MX53_PAD_EIM_A25__IPU_DI0_D1_CS 421
-MX53_PAD_EIM_A25__USBPHY1_BISTOK 422
-MX53_PAD_EIM_EB2__EMI_WEIM_EB_2 423
-MX53_PAD_EIM_EB2__GPIO2_30 424
-MX53_PAD_EIM_EB2__CCM_DI1_EXT_CLK 425
-MX53_PAD_EIM_EB2__IPU_SER_DISP1_CS 426
-MX53_PAD_EIM_EB2__ECSPI1_SS0 427
-MX53_PAD_EIM_EB2__I2C2_SCL 428
-MX53_PAD_EIM_D16__EMI_WEIM_D_16 429
-MX53_PAD_EIM_D16__GPIO3_16 430
-MX53_PAD_EIM_D16__IPU_DI0_PIN5 431
-MX53_PAD_EIM_D16__IPU_DISPB1_SER_CLK 432
-MX53_PAD_EIM_D16__ECSPI1_SCLK 433
-MX53_PAD_EIM_D16__I2C2_SDA 434
-MX53_PAD_EIM_D17__EMI_WEIM_D_17 435
-MX53_PAD_EIM_D17__GPIO3_17 436
-MX53_PAD_EIM_D17__IPU_DI0_PIN6 437
-MX53_PAD_EIM_D17__IPU_DISPB1_SER_DIN 438
-MX53_PAD_EIM_D17__ECSPI1_MISO 439
-MX53_PAD_EIM_D17__I2C3_SCL 440
-MX53_PAD_EIM_D18__EMI_WEIM_D_18 441
-MX53_PAD_EIM_D18__GPIO3_18 442
-MX53_PAD_EIM_D18__IPU_DI0_PIN7 443
-MX53_PAD_EIM_D18__IPU_DISPB1_SER_DIO 444
-MX53_PAD_EIM_D18__ECSPI1_MOSI 445
-MX53_PAD_EIM_D18__I2C3_SDA 446
-MX53_PAD_EIM_D18__IPU_DI1_D0_CS 447
-MX53_PAD_EIM_D19__EMI_WEIM_D_19 448
-MX53_PAD_EIM_D19__GPIO3_19 449
-MX53_PAD_EIM_D19__IPU_DI0_PIN8 450
-MX53_PAD_EIM_D19__IPU_DISPB1_SER_RS 451
-MX53_PAD_EIM_D19__ECSPI1_SS1 452
-MX53_PAD_EIM_D19__EPIT1_EPITO 453
-MX53_PAD_EIM_D19__UART1_CTS 454
-MX53_PAD_EIM_D19__USBOH3_USBH2_OC 455
-MX53_PAD_EIM_D20__EMI_WEIM_D_20 456
-MX53_PAD_EIM_D20__GPIO3_20 457
-MX53_PAD_EIM_D20__IPU_DI0_PIN16 458
-MX53_PAD_EIM_D20__IPU_SER_DISP0_CS 459
-MX53_PAD_EIM_D20__CSPI_SS0 460
-MX53_PAD_EIM_D20__EPIT2_EPITO 461
-MX53_PAD_EIM_D20__UART1_RTS 462
-MX53_PAD_EIM_D20__USBOH3_USBH2_PWR 463
-MX53_PAD_EIM_D21__EMI_WEIM_D_21 464
-MX53_PAD_EIM_D21__GPIO3_21 465
-MX53_PAD_EIM_D21__IPU_DI0_PIN17 466
-MX53_PAD_EIM_D21__IPU_DISPB0_SER_CLK 467
-MX53_PAD_EIM_D21__CSPI_SCLK 468
-MX53_PAD_EIM_D21__I2C1_SCL 469
-MX53_PAD_EIM_D21__USBOH3_USBOTG_OC 470
-MX53_PAD_EIM_D22__EMI_WEIM_D_22 471
-MX53_PAD_EIM_D22__GPIO3_22 472
-MX53_PAD_EIM_D22__IPU_DI0_PIN1 473
-MX53_PAD_EIM_D22__IPU_DISPB0_SER_DIN 474
-MX53_PAD_EIM_D22__CSPI_MISO 475
-MX53_PAD_EIM_D22__USBOH3_USBOTG_PWR 476
-MX53_PAD_EIM_D23__EMI_WEIM_D_23 477
-MX53_PAD_EIM_D23__GPIO3_23 478
-MX53_PAD_EIM_D23__UART3_CTS 479
-MX53_PAD_EIM_D23__UART1_DCD 480
-MX53_PAD_EIM_D23__IPU_DI0_D0_CS 481
-MX53_PAD_EIM_D23__IPU_DI1_PIN2 482
-MX53_PAD_EIM_D23__IPU_CSI1_DATA_EN 483
-MX53_PAD_EIM_D23__IPU_DI1_PIN14 484
-MX53_PAD_EIM_EB3__EMI_WEIM_EB_3 485
-MX53_PAD_EIM_EB3__GPIO2_31 486
-MX53_PAD_EIM_EB3__UART3_RTS 487
-MX53_PAD_EIM_EB3__UART1_RI 488
-MX53_PAD_EIM_EB3__IPU_DI1_PIN3 489
-MX53_PAD_EIM_EB3__IPU_CSI1_HSYNC 490
-MX53_PAD_EIM_EB3__IPU_DI1_PIN16 491
-MX53_PAD_EIM_D24__EMI_WEIM_D_24 492
-MX53_PAD_EIM_D24__GPIO3_24 493
-MX53_PAD_EIM_D24__UART3_TXD_MUX 494
-MX53_PAD_EIM_D24__ECSPI1_SS2 495
-MX53_PAD_EIM_D24__CSPI_SS2 496
-MX53_PAD_EIM_D24__AUDMUX_AUD5_RXFS 497
-MX53_PAD_EIM_D24__ECSPI2_SS2 498
-MX53_PAD_EIM_D24__UART1_DTR 499
-MX53_PAD_EIM_D25__EMI_WEIM_D_25 500
-MX53_PAD_EIM_D25__GPIO3_25 501
-MX53_PAD_EIM_D25__UART3_RXD_MUX 502
-MX53_PAD_EIM_D25__ECSPI1_SS3 503
-MX53_PAD_EIM_D25__CSPI_SS3 504
-MX53_PAD_EIM_D25__AUDMUX_AUD5_RXC 505
-MX53_PAD_EIM_D25__ECSPI2_SS3 506
-MX53_PAD_EIM_D25__UART1_DSR 507
-MX53_PAD_EIM_D26__EMI_WEIM_D_26 508
-MX53_PAD_EIM_D26__GPIO3_26 509
-MX53_PAD_EIM_D26__UART2_TXD_MUX 510
-MX53_PAD_EIM_D26__FIRI_RXD 511
-MX53_PAD_EIM_D26__IPU_CSI0_D_1 512
-MX53_PAD_EIM_D26__IPU_DI1_PIN11 513
-MX53_PAD_EIM_D26__IPU_SISG_2 514
-MX53_PAD_EIM_D26__IPU_DISP1_DAT_22 515
-MX53_PAD_EIM_D27__EMI_WEIM_D_27 516
-MX53_PAD_EIM_D27__GPIO3_27 517
-MX53_PAD_EIM_D27__UART2_RXD_MUX 518
-MX53_PAD_EIM_D27__FIRI_TXD 519
-MX53_PAD_EIM_D27__IPU_CSI0_D_0 520
-MX53_PAD_EIM_D27__IPU_DI1_PIN13 521
-MX53_PAD_EIM_D27__IPU_SISG_3 522
-MX53_PAD_EIM_D27__IPU_DISP1_DAT_23 523
-MX53_PAD_EIM_D28__EMI_WEIM_D_28 524
-MX53_PAD_EIM_D28__GPIO3_28 525
-MX53_PAD_EIM_D28__UART2_CTS 526
-MX53_PAD_EIM_D28__IPU_DISPB0_SER_DIO 527
-MX53_PAD_EIM_D28__CSPI_MOSI 528
-MX53_PAD_EIM_D28__I2C1_SDA 529
-MX53_PAD_EIM_D28__IPU_EXT_TRIG 530
-MX53_PAD_EIM_D28__IPU_DI0_PIN13 531
-MX53_PAD_EIM_D29__EMI_WEIM_D_29 532
-MX53_PAD_EIM_D29__GPIO3_29 533
-MX53_PAD_EIM_D29__UART2_RTS 534
-MX53_PAD_EIM_D29__IPU_DISPB0_SER_RS 535
-MX53_PAD_EIM_D29__CSPI_SS0 536
-MX53_PAD_EIM_D29__IPU_DI1_PIN15 537
-MX53_PAD_EIM_D29__IPU_CSI1_VSYNC 538
-MX53_PAD_EIM_D29__IPU_DI0_PIN14 539
-MX53_PAD_EIM_D30__EMI_WEIM_D_30 540
-MX53_PAD_EIM_D30__GPIO3_30 541
-MX53_PAD_EIM_D30__UART3_CTS 542
-MX53_PAD_EIM_D30__IPU_CSI0_D_3 543
-MX53_PAD_EIM_D30__IPU_DI0_PIN11 544
-MX53_PAD_EIM_D30__IPU_DISP1_DAT_21 545
-MX53_PAD_EIM_D30__USBOH3_USBH1_OC 546
-MX53_PAD_EIM_D30__USBOH3_USBH2_OC 547
-MX53_PAD_EIM_D31__EMI_WEIM_D_31 548
-MX53_PAD_EIM_D31__GPIO3_31 549
-MX53_PAD_EIM_D31__UART3_RTS 550
-MX53_PAD_EIM_D31__IPU_CSI0_D_2 551
-MX53_PAD_EIM_D31__IPU_DI0_PIN12 552
-MX53_PAD_EIM_D31__IPU_DISP1_DAT_20 553
-MX53_PAD_EIM_D31__USBOH3_USBH1_PWR 554
-MX53_PAD_EIM_D31__USBOH3_USBH2_PWR 555
-MX53_PAD_EIM_A24__EMI_WEIM_A_24 556
-MX53_PAD_EIM_A24__GPIO5_4 557
-MX53_PAD_EIM_A24__IPU_DISP1_DAT_19 558
-MX53_PAD_EIM_A24__IPU_CSI1_D_19 559
-MX53_PAD_EIM_A24__IPU_SISG_2 560
-MX53_PAD_EIM_A24__USBPHY2_BVALID 561
-MX53_PAD_EIM_A23__EMI_WEIM_A_23 562
-MX53_PAD_EIM_A23__GPIO6_6 563
-MX53_PAD_EIM_A23__IPU_DISP1_DAT_18 564
-MX53_PAD_EIM_A23__IPU_CSI1_D_18 565
-MX53_PAD_EIM_A23__IPU_SISG_3 566
-MX53_PAD_EIM_A23__USBPHY2_ENDSESSION 567
-MX53_PAD_EIM_A22__EMI_WEIM_A_22 568
-MX53_PAD_EIM_A22__GPIO2_16 569
-MX53_PAD_EIM_A22__IPU_DISP1_DAT_17 570
-MX53_PAD_EIM_A22__IPU_CSI1_D_17 571
-MX53_PAD_EIM_A22__SRC_BT_CFG1_7 572
-MX53_PAD_EIM_A21__EMI_WEIM_A_21 573
-MX53_PAD_EIM_A21__GPIO2_17 574
-MX53_PAD_EIM_A21__IPU_DISP1_DAT_16 575
-MX53_PAD_EIM_A21__IPU_CSI1_D_16 576
-MX53_PAD_EIM_A21__SRC_BT_CFG1_6 577
-MX53_PAD_EIM_A20__EMI_WEIM_A_20 578
-MX53_PAD_EIM_A20__GPIO2_18 579
-MX53_PAD_EIM_A20__IPU_DISP1_DAT_15 580
-MX53_PAD_EIM_A20__IPU_CSI1_D_15 581
-MX53_PAD_EIM_A20__SRC_BT_CFG1_5 582
-MX53_PAD_EIM_A19__EMI_WEIM_A_19 583
-MX53_PAD_EIM_A19__GPIO2_19 584
-MX53_PAD_EIM_A19__IPU_DISP1_DAT_14 585
-MX53_PAD_EIM_A19__IPU_CSI1_D_14 586
-MX53_PAD_EIM_A19__SRC_BT_CFG1_4 587
-MX53_PAD_EIM_A18__EMI_WEIM_A_18 588
-MX53_PAD_EIM_A18__GPIO2_20 589
-MX53_PAD_EIM_A18__IPU_DISP1_DAT_13 590
-MX53_PAD_EIM_A18__IPU_CSI1_D_13 591
-MX53_PAD_EIM_A18__SRC_BT_CFG1_3 592
-MX53_PAD_EIM_A17__EMI_WEIM_A_17 593
-MX53_PAD_EIM_A17__GPIO2_21 594
-MX53_PAD_EIM_A17__IPU_DISP1_DAT_12 595
-MX53_PAD_EIM_A17__IPU_CSI1_D_12 596
-MX53_PAD_EIM_A17__SRC_BT_CFG1_2 597
-MX53_PAD_EIM_A16__EMI_WEIM_A_16 598
-MX53_PAD_EIM_A16__GPIO2_22 599
-MX53_PAD_EIM_A16__IPU_DI1_DISP_CLK 600
-MX53_PAD_EIM_A16__IPU_CSI1_PIXCLK 601
-MX53_PAD_EIM_A16__SRC_BT_CFG1_1 602
-MX53_PAD_EIM_CS0__EMI_WEIM_CS_0 603
-MX53_PAD_EIM_CS0__GPIO2_23 604
-MX53_PAD_EIM_CS0__ECSPI2_SCLK 605
-MX53_PAD_EIM_CS0__IPU_DI1_PIN5 606
-MX53_PAD_EIM_CS1__EMI_WEIM_CS_1 607
-MX53_PAD_EIM_CS1__GPIO2_24 608
-MX53_PAD_EIM_CS1__ECSPI2_MOSI 609
-MX53_PAD_EIM_CS1__IPU_DI1_PIN6 610
-MX53_PAD_EIM_OE__EMI_WEIM_OE 611
-MX53_PAD_EIM_OE__GPIO2_25 612
-MX53_PAD_EIM_OE__ECSPI2_MISO 613
-MX53_PAD_EIM_OE__IPU_DI1_PIN7 614
-MX53_PAD_EIM_OE__USBPHY2_IDDIG 615
-MX53_PAD_EIM_RW__EMI_WEIM_RW 616
-MX53_PAD_EIM_RW__GPIO2_26 617
-MX53_PAD_EIM_RW__ECSPI2_SS0 618
-MX53_PAD_EIM_RW__IPU_DI1_PIN8 619
-MX53_PAD_EIM_RW__USBPHY2_HOSTDISCONNECT 620
-MX53_PAD_EIM_LBA__EMI_WEIM_LBA 621
-MX53_PAD_EIM_LBA__GPIO2_27 622
-MX53_PAD_EIM_LBA__ECSPI2_SS1 623
-MX53_PAD_EIM_LBA__IPU_DI1_PIN17 624
-MX53_PAD_EIM_LBA__SRC_BT_CFG1_0 625
-MX53_PAD_EIM_EB0__EMI_WEIM_EB_0 626
-MX53_PAD_EIM_EB0__GPIO2_28 627
-MX53_PAD_EIM_EB0__IPU_DISP1_DAT_11 628
-MX53_PAD_EIM_EB0__IPU_CSI1_D_11 629
-MX53_PAD_EIM_EB0__GPC_PMIC_RDY 630
-MX53_PAD_EIM_EB0__SRC_BT_CFG2_7 631
-MX53_PAD_EIM_EB1__EMI_WEIM_EB_1 632
-MX53_PAD_EIM_EB1__GPIO2_29 633
-MX53_PAD_EIM_EB1__IPU_DISP1_DAT_10 634
-MX53_PAD_EIM_EB1__IPU_CSI1_D_10 635
-MX53_PAD_EIM_EB1__SRC_BT_CFG2_6 636
-MX53_PAD_EIM_DA0__EMI_NAND_WEIM_DA_0 637
-MX53_PAD_EIM_DA0__GPIO3_0 638
-MX53_PAD_EIM_DA0__IPU_DISP1_DAT_9 639
-MX53_PAD_EIM_DA0__IPU_CSI1_D_9 640
-MX53_PAD_EIM_DA0__SRC_BT_CFG2_5 641
-MX53_PAD_EIM_DA1__EMI_NAND_WEIM_DA_1 642
-MX53_PAD_EIM_DA1__GPIO3_1 643
-MX53_PAD_EIM_DA1__IPU_DISP1_DAT_8 644
-MX53_PAD_EIM_DA1__IPU_CSI1_D_8 645
-MX53_PAD_EIM_DA1__SRC_BT_CFG2_4 646
-MX53_PAD_EIM_DA2__EMI_NAND_WEIM_DA_2 647
-MX53_PAD_EIM_DA2__GPIO3_2 648
-MX53_PAD_EIM_DA2__IPU_DISP1_DAT_7 649
-MX53_PAD_EIM_DA2__IPU_CSI1_D_7 650
-MX53_PAD_EIM_DA2__SRC_BT_CFG2_3 651
-MX53_PAD_EIM_DA3__EMI_NAND_WEIM_DA_3 652
-MX53_PAD_EIM_DA3__GPIO3_3 653
-MX53_PAD_EIM_DA3__IPU_DISP1_DAT_6 654
-MX53_PAD_EIM_DA3__IPU_CSI1_D_6 655
-MX53_PAD_EIM_DA3__SRC_BT_CFG2_2 656
-MX53_PAD_EIM_DA4__EMI_NAND_WEIM_DA_4 657
-MX53_PAD_EIM_DA4__GPIO3_4 658
-MX53_PAD_EIM_DA4__IPU_DISP1_DAT_5 659
-MX53_PAD_EIM_DA4__IPU_CSI1_D_5 660
-MX53_PAD_EIM_DA4__SRC_BT_CFG3_7 661
-MX53_PAD_EIM_DA5__EMI_NAND_WEIM_DA_5 662
-MX53_PAD_EIM_DA5__GPIO3_5 663
-MX53_PAD_EIM_DA5__IPU_DISP1_DAT_4 664
-MX53_PAD_EIM_DA5__IPU_CSI1_D_4 665
-MX53_PAD_EIM_DA5__SRC_BT_CFG3_6 666
-MX53_PAD_EIM_DA6__EMI_NAND_WEIM_DA_6 667
-MX53_PAD_EIM_DA6__GPIO3_6 668
-MX53_PAD_EIM_DA6__IPU_DISP1_DAT_3 669
-MX53_PAD_EIM_DA6__IPU_CSI1_D_3 670
-MX53_PAD_EIM_DA6__SRC_BT_CFG3_5 671
-MX53_PAD_EIM_DA7__EMI_NAND_WEIM_DA_7 672
-MX53_PAD_EIM_DA7__GPIO3_7 673
-MX53_PAD_EIM_DA7__IPU_DISP1_DAT_2 674
-MX53_PAD_EIM_DA7__IPU_CSI1_D_2 675
-MX53_PAD_EIM_DA7__SRC_BT_CFG3_4 676
-MX53_PAD_EIM_DA8__EMI_NAND_WEIM_DA_8 677
-MX53_PAD_EIM_DA8__GPIO3_8 678
-MX53_PAD_EIM_DA8__IPU_DISP1_DAT_1 679
-MX53_PAD_EIM_DA8__IPU_CSI1_D_1 680
-MX53_PAD_EIM_DA8__SRC_BT_CFG3_3 681
-MX53_PAD_EIM_DA9__EMI_NAND_WEIM_DA_9 682
-MX53_PAD_EIM_DA9__GPIO3_9 683
-MX53_PAD_EIM_DA9__IPU_DISP1_DAT_0 684
-MX53_PAD_EIM_DA9__IPU_CSI1_D_0 685
-MX53_PAD_EIM_DA9__SRC_BT_CFG3_2 686
-MX53_PAD_EIM_DA10__EMI_NAND_WEIM_DA_10 687
-MX53_PAD_EIM_DA10__GPIO3_10 688
-MX53_PAD_EIM_DA10__IPU_DI1_PIN15 689
-MX53_PAD_EIM_DA10__IPU_CSI1_DATA_EN 690
-MX53_PAD_EIM_DA10__SRC_BT_CFG3_1 691
-MX53_PAD_EIM_DA11__EMI_NAND_WEIM_DA_11 692
-MX53_PAD_EIM_DA11__GPIO3_11 693
-MX53_PAD_EIM_DA11__IPU_DI1_PIN2 694
-MX53_PAD_EIM_DA11__IPU_CSI1_HSYNC 695
-MX53_PAD_EIM_DA12__EMI_NAND_WEIM_DA_12 696
-MX53_PAD_EIM_DA12__GPIO3_12 697
-MX53_PAD_EIM_DA12__IPU_DI1_PIN3 698
-MX53_PAD_EIM_DA12__IPU_CSI1_VSYNC 699
-MX53_PAD_EIM_DA13__EMI_NAND_WEIM_DA_13 700
-MX53_PAD_EIM_DA13__GPIO3_13 701
-MX53_PAD_EIM_DA13__IPU_DI1_D0_CS 702
-MX53_PAD_EIM_DA13__CCM_DI1_EXT_CLK 703
-MX53_PAD_EIM_DA14__EMI_NAND_WEIM_DA_14 704
-MX53_PAD_EIM_DA14__GPIO3_14 705
-MX53_PAD_EIM_DA14__IPU_DI1_D1_CS 706
-MX53_PAD_EIM_DA14__CCM_DI0_EXT_CLK 707
-MX53_PAD_EIM_DA15__EMI_NAND_WEIM_DA_15 708
-MX53_PAD_EIM_DA15__GPIO3_15 709
-MX53_PAD_EIM_DA15__IPU_DI1_PIN1 710
-MX53_PAD_EIM_DA15__IPU_DI1_PIN4 711
-MX53_PAD_NANDF_WE_B__EMI_NANDF_WE_B 712
-MX53_PAD_NANDF_WE_B__GPIO6_12 713
-MX53_PAD_NANDF_RE_B__EMI_NANDF_RE_B 714
-MX53_PAD_NANDF_RE_B__GPIO6_13 715
-MX53_PAD_EIM_WAIT__EMI_WEIM_WAIT 716
-MX53_PAD_EIM_WAIT__GPIO5_0 717
-MX53_PAD_EIM_WAIT__EMI_WEIM_DTACK_B 718
-MX53_PAD_LVDS1_TX3_P__GPIO6_22 719
-MX53_PAD_LVDS1_TX3_P__LDB_LVDS1_TX3 720
-MX53_PAD_LVDS1_TX2_P__GPIO6_24 721
-MX53_PAD_LVDS1_TX2_P__LDB_LVDS1_TX2 722
-MX53_PAD_LVDS1_CLK_P__GPIO6_26 723
-MX53_PAD_LVDS1_CLK_P__LDB_LVDS1_CLK 724
-MX53_PAD_LVDS1_TX1_P__GPIO6_28 725
-MX53_PAD_LVDS1_TX1_P__LDB_LVDS1_TX1 726
-MX53_PAD_LVDS1_TX0_P__GPIO6_30 727
-MX53_PAD_LVDS1_TX0_P__LDB_LVDS1_TX0 728
-MX53_PAD_LVDS0_TX3_P__GPIO7_22 729
-MX53_PAD_LVDS0_TX3_P__LDB_LVDS0_TX3 730
-MX53_PAD_LVDS0_CLK_P__GPIO7_24 731
-MX53_PAD_LVDS0_CLK_P__LDB_LVDS0_CLK 732
-MX53_PAD_LVDS0_TX2_P__GPIO7_26 733
-MX53_PAD_LVDS0_TX2_P__LDB_LVDS0_TX2 734
-MX53_PAD_LVDS0_TX1_P__GPIO7_28 735
-MX53_PAD_LVDS0_TX1_P__LDB_LVDS0_TX1 736
-MX53_PAD_LVDS0_TX0_P__GPIO7_30 737
-MX53_PAD_LVDS0_TX0_P__LDB_LVDS0_TX0 738
-MX53_PAD_GPIO_10__GPIO4_0 739
-MX53_PAD_GPIO_10__OSC32k_32K_OUT 740
-MX53_PAD_GPIO_11__GPIO4_1 741
-MX53_PAD_GPIO_12__GPIO4_2 742
-MX53_PAD_GPIO_13__GPIO4_3 743
-MX53_PAD_GPIO_14__GPIO4_4 744
-MX53_PAD_NANDF_CLE__EMI_NANDF_CLE 745
-MX53_PAD_NANDF_CLE__GPIO6_7 746
-MX53_PAD_NANDF_CLE__USBPHY1_VSTATUS_0 747
-MX53_PAD_NANDF_ALE__EMI_NANDF_ALE 748
-MX53_PAD_NANDF_ALE__GPIO6_8 749
-MX53_PAD_NANDF_ALE__USBPHY1_VSTATUS_1 750
-MX53_PAD_NANDF_WP_B__EMI_NANDF_WP_B 751
-MX53_PAD_NANDF_WP_B__GPIO6_9 752
-MX53_PAD_NANDF_WP_B__USBPHY1_VSTATUS_2 753
-MX53_PAD_NANDF_RB0__EMI_NANDF_RB_0 754
-MX53_PAD_NANDF_RB0__GPIO6_10 755
-MX53_PAD_NANDF_RB0__USBPHY1_VSTATUS_3 756
-MX53_PAD_NANDF_CS0__EMI_NANDF_CS_0 757
-MX53_PAD_NANDF_CS0__GPIO6_11 758
-MX53_PAD_NANDF_CS0__USBPHY1_VSTATUS_4 759
-MX53_PAD_NANDF_CS1__EMI_NANDF_CS_1 760
-MX53_PAD_NANDF_CS1__GPIO6_14 761
-MX53_PAD_NANDF_CS1__MLB_MLBCLK 762
-MX53_PAD_NANDF_CS1__USBPHY1_VSTATUS_5 763
-MX53_PAD_NANDF_CS2__EMI_NANDF_CS_2 764
-MX53_PAD_NANDF_CS2__GPIO6_15 765
-MX53_PAD_NANDF_CS2__IPU_SISG_0 766
-MX53_PAD_NANDF_CS2__ESAI1_TX0 767
-MX53_PAD_NANDF_CS2__EMI_WEIM_CRE 768
-MX53_PAD_NANDF_CS2__CCM_CSI0_MCLK 769
-MX53_PAD_NANDF_CS2__MLB_MLBSIG 770
-MX53_PAD_NANDF_CS2__USBPHY1_VSTATUS_6 771
-MX53_PAD_NANDF_CS3__EMI_NANDF_CS_3 772
-MX53_PAD_NANDF_CS3__GPIO6_16 773
-MX53_PAD_NANDF_CS3__IPU_SISG_1 774
-MX53_PAD_NANDF_CS3__ESAI1_TX1 775
-MX53_PAD_NANDF_CS3__EMI_WEIM_A_26 776
-MX53_PAD_NANDF_CS3__MLB_MLBDAT 777
-MX53_PAD_NANDF_CS3__USBPHY1_VSTATUS_7 778
-MX53_PAD_FEC_MDIO__FEC_MDIO 779
-MX53_PAD_FEC_MDIO__GPIO1_22 780
-MX53_PAD_FEC_MDIO__ESAI1_SCKR 781
-MX53_PAD_FEC_MDIO__FEC_COL 782
-MX53_PAD_FEC_MDIO__RTC_CE_RTC_PS2 783
-MX53_PAD_FEC_MDIO__SDMA_DEBUG_BUS_DEVICE_3 784
-MX53_PAD_FEC_MDIO__EMI_EMI_DEBUG_49 785
-MX53_PAD_FEC_REF_CLK__FEC_TX_CLK 786
-MX53_PAD_FEC_REF_CLK__GPIO1_23 787
-MX53_PAD_FEC_REF_CLK__ESAI1_FSR 788
-MX53_PAD_FEC_REF_CLK__SDMA_DEBUG_BUS_DEVICE_4 789
-MX53_PAD_FEC_REF_CLK__EMI_EMI_DEBUG_50 790
-MX53_PAD_FEC_RX_ER__FEC_RX_ER 791
-MX53_PAD_FEC_RX_ER__GPIO1_24 792
-MX53_PAD_FEC_RX_ER__ESAI1_HCKR 793
-MX53_PAD_FEC_RX_ER__FEC_RX_CLK 794
-MX53_PAD_FEC_RX_ER__RTC_CE_RTC_PS3 795
-MX53_PAD_FEC_CRS_DV__FEC_RX_DV 796
-MX53_PAD_FEC_CRS_DV__GPIO1_25 797
-MX53_PAD_FEC_CRS_DV__ESAI1_SCKT 798
-MX53_PAD_FEC_RXD1__FEC_RDATA_1 799
-MX53_PAD_FEC_RXD1__GPIO1_26 800
-MX53_PAD_FEC_RXD1__ESAI1_FST 801
-MX53_PAD_FEC_RXD1__MLB_MLBSIG 802
-MX53_PAD_FEC_RXD1__RTC_CE_RTC_PS1 803
-MX53_PAD_FEC_RXD0__FEC_RDATA_0 804
-MX53_PAD_FEC_RXD0__GPIO1_27 805
-MX53_PAD_FEC_RXD0__ESAI1_HCKT 806
-MX53_PAD_FEC_RXD0__OSC32k_32K_OUT 807
-MX53_PAD_FEC_TX_EN__FEC_TX_EN 808
-MX53_PAD_FEC_TX_EN__GPIO1_28 809
-MX53_PAD_FEC_TX_EN__ESAI1_TX3_RX2 810
-MX53_PAD_FEC_TXD1__FEC_TDATA_1 811
-MX53_PAD_FEC_TXD1__GPIO1_29 812
-MX53_PAD_FEC_TXD1__ESAI1_TX2_RX3 813
-MX53_PAD_FEC_TXD1__MLB_MLBCLK 814
-MX53_PAD_FEC_TXD1__RTC_CE_RTC_PRSC_CLK 815
-MX53_PAD_FEC_TXD0__FEC_TDATA_0 816
-MX53_PAD_FEC_TXD0__GPIO1_30 817
-MX53_PAD_FEC_TXD0__ESAI1_TX4_RX1 818
-MX53_PAD_FEC_TXD0__USBPHY2_DATAOUT_0 819
-MX53_PAD_FEC_MDC__FEC_MDC 820
-MX53_PAD_FEC_MDC__GPIO1_31 821
-MX53_PAD_FEC_MDC__ESAI1_TX5_RX0 822
-MX53_PAD_FEC_MDC__MLB_MLBDAT 823
-MX53_PAD_FEC_MDC__RTC_CE_RTC_ALARM1_TRIG 824
-MX53_PAD_FEC_MDC__USBPHY2_DATAOUT_1 825
-MX53_PAD_PATA_DIOW__PATA_DIOW 826
-MX53_PAD_PATA_DIOW__GPIO6_17 827
-MX53_PAD_PATA_DIOW__UART1_TXD_MUX 828
-MX53_PAD_PATA_DIOW__USBPHY2_DATAOUT_2 829
-MX53_PAD_PATA_DMACK__PATA_DMACK 830
-MX53_PAD_PATA_DMACK__GPIO6_18 831
-MX53_PAD_PATA_DMACK__UART1_RXD_MUX 832
-MX53_PAD_PATA_DMACK__USBPHY2_DATAOUT_3 833
-MX53_PAD_PATA_DMARQ__PATA_DMARQ 834
-MX53_PAD_PATA_DMARQ__GPIO7_0 835
-MX53_PAD_PATA_DMARQ__UART2_TXD_MUX 836
-MX53_PAD_PATA_DMARQ__CCM_CCM_OUT_0 837
-MX53_PAD_PATA_DMARQ__USBPHY2_DATAOUT_4 838
-MX53_PAD_PATA_BUFFER_EN__PATA_BUFFER_EN 839
-MX53_PAD_PATA_BUFFER_EN__GPIO7_1 840
-MX53_PAD_PATA_BUFFER_EN__UART2_RXD_MUX 841
-MX53_PAD_PATA_BUFFER_EN__CCM_CCM_OUT_1 842
-MX53_PAD_PATA_BUFFER_EN__USBPHY2_DATAOUT_5 843
-MX53_PAD_PATA_INTRQ__PATA_INTRQ 844
-MX53_PAD_PATA_INTRQ__GPIO7_2 845
-MX53_PAD_PATA_INTRQ__UART2_CTS 846
-MX53_PAD_PATA_INTRQ__CAN1_TXCAN 847
-MX53_PAD_PATA_INTRQ__CCM_CCM_OUT_2 848
-MX53_PAD_PATA_INTRQ__USBPHY2_DATAOUT_6 849
-MX53_PAD_PATA_DIOR__PATA_DIOR 850
-MX53_PAD_PATA_DIOR__GPIO7_3 851
-MX53_PAD_PATA_DIOR__UART2_RTS 852
-MX53_PAD_PATA_DIOR__CAN1_RXCAN 853
-MX53_PAD_PATA_DIOR__USBPHY2_DATAOUT_7 854
-MX53_PAD_PATA_RESET_B__PATA_PATA_RESET_B 855
-MX53_PAD_PATA_RESET_B__GPIO7_4 856
-MX53_PAD_PATA_RESET_B__ESDHC3_CMD 857
-MX53_PAD_PATA_RESET_B__UART1_CTS 858
-MX53_PAD_PATA_RESET_B__CAN2_TXCAN 859
-MX53_PAD_PATA_RESET_B__USBPHY1_DATAOUT_0 860
-MX53_PAD_PATA_IORDY__PATA_IORDY 861
-MX53_PAD_PATA_IORDY__GPIO7_5 862
-MX53_PAD_PATA_IORDY__ESDHC3_CLK 863
-MX53_PAD_PATA_IORDY__UART1_RTS 864
-MX53_PAD_PATA_IORDY__CAN2_RXCAN 865
-MX53_PAD_PATA_IORDY__USBPHY1_DATAOUT_1 866
-MX53_PAD_PATA_DA_0__PATA_DA_0 867
-MX53_PAD_PATA_DA_0__GPIO7_6 868
-MX53_PAD_PATA_DA_0__ESDHC3_RST 869
-MX53_PAD_PATA_DA_0__OWIRE_LINE 870
-MX53_PAD_PATA_DA_0__USBPHY1_DATAOUT_2 871
-MX53_PAD_PATA_DA_1__PATA_DA_1 872
-MX53_PAD_PATA_DA_1__GPIO7_7 873
-MX53_PAD_PATA_DA_1__ESDHC4_CMD 874
-MX53_PAD_PATA_DA_1__UART3_CTS 875
-MX53_PAD_PATA_DA_1__USBPHY1_DATAOUT_3 876
-MX53_PAD_PATA_DA_2__PATA_DA_2 877
-MX53_PAD_PATA_DA_2__GPIO7_8 878
-MX53_PAD_PATA_DA_2__ESDHC4_CLK 879
-MX53_PAD_PATA_DA_2__UART3_RTS 880
-MX53_PAD_PATA_DA_2__USBPHY1_DATAOUT_4 881
-MX53_PAD_PATA_CS_0__PATA_CS_0 882
-MX53_PAD_PATA_CS_0__GPIO7_9 883
-MX53_PAD_PATA_CS_0__UART3_TXD_MUX 884
-MX53_PAD_PATA_CS_0__USBPHY1_DATAOUT_5 885
-MX53_PAD_PATA_CS_1__PATA_CS_1 886
-MX53_PAD_PATA_CS_1__GPIO7_10 887
-MX53_PAD_PATA_CS_1__UART3_RXD_MUX 888
-MX53_PAD_PATA_CS_1__USBPHY1_DATAOUT_6 889
-MX53_PAD_PATA_DATA0__PATA_DATA_0 890
-MX53_PAD_PATA_DATA0__GPIO2_0 891
-MX53_PAD_PATA_DATA0__EMI_NANDF_D_0 892
-MX53_PAD_PATA_DATA0__ESDHC3_DAT4 893
-MX53_PAD_PATA_DATA0__GPU3d_GPU_DEBUG_OUT_0 894
-MX53_PAD_PATA_DATA0__IPU_DIAG_BUS_0 895
-MX53_PAD_PATA_DATA0__USBPHY1_DATAOUT_7 896
-MX53_PAD_PATA_DATA1__PATA_DATA_1 897
-MX53_PAD_PATA_DATA1__GPIO2_1 898
-MX53_PAD_PATA_DATA1__EMI_NANDF_D_1 899
-MX53_PAD_PATA_DATA1__ESDHC3_DAT5 900
-MX53_PAD_PATA_DATA1__GPU3d_GPU_DEBUG_OUT_1 901
-MX53_PAD_PATA_DATA1__IPU_DIAG_BUS_1 902
-MX53_PAD_PATA_DATA2__PATA_DATA_2 903
-MX53_PAD_PATA_DATA2__GPIO2_2 904
-MX53_PAD_PATA_DATA2__EMI_NANDF_D_2 905
-MX53_PAD_PATA_DATA2__ESDHC3_DAT6 906
-MX53_PAD_PATA_DATA2__GPU3d_GPU_DEBUG_OUT_2 907
-MX53_PAD_PATA_DATA2__IPU_DIAG_BUS_2 908
-MX53_PAD_PATA_DATA3__PATA_DATA_3 909
-MX53_PAD_PATA_DATA3__GPIO2_3 910
-MX53_PAD_PATA_DATA3__EMI_NANDF_D_3 911
-MX53_PAD_PATA_DATA3__ESDHC3_DAT7 912
-MX53_PAD_PATA_DATA3__GPU3d_GPU_DEBUG_OUT_3 913
-MX53_PAD_PATA_DATA3__IPU_DIAG_BUS_3 914
-MX53_PAD_PATA_DATA4__PATA_DATA_4 915
-MX53_PAD_PATA_DATA4__GPIO2_4 916
-MX53_PAD_PATA_DATA4__EMI_NANDF_D_4 917
-MX53_PAD_PATA_DATA4__ESDHC4_DAT4 918
-MX53_PAD_PATA_DATA4__GPU3d_GPU_DEBUG_OUT_4 919
-MX53_PAD_PATA_DATA4__IPU_DIAG_BUS_4 920
-MX53_PAD_PATA_DATA5__PATA_DATA_5 921
-MX53_PAD_PATA_DATA5__GPIO2_5 922
-MX53_PAD_PATA_DATA5__EMI_NANDF_D_5 923
-MX53_PAD_PATA_DATA5__ESDHC4_DAT5 924
-MX53_PAD_PATA_DATA5__GPU3d_GPU_DEBUG_OUT_5 925
-MX53_PAD_PATA_DATA5__IPU_DIAG_BUS_5 926
-MX53_PAD_PATA_DATA6__PATA_DATA_6 927
-MX53_PAD_PATA_DATA6__GPIO2_6 928
-MX53_PAD_PATA_DATA6__EMI_NANDF_D_6 929
-MX53_PAD_PATA_DATA6__ESDHC4_DAT6 930
-MX53_PAD_PATA_DATA6__GPU3d_GPU_DEBUG_OUT_6 931
-MX53_PAD_PATA_DATA6__IPU_DIAG_BUS_6 932
-MX53_PAD_PATA_DATA7__PATA_DATA_7 933
-MX53_PAD_PATA_DATA7__GPIO2_7 934
-MX53_PAD_PATA_DATA7__EMI_NANDF_D_7 935
-MX53_PAD_PATA_DATA7__ESDHC4_DAT7 936
-MX53_PAD_PATA_DATA7__GPU3d_GPU_DEBUG_OUT_7 937
-MX53_PAD_PATA_DATA7__IPU_DIAG_BUS_7 938
-MX53_PAD_PATA_DATA8__PATA_DATA_8 939
-MX53_PAD_PATA_DATA8__GPIO2_8 940
-MX53_PAD_PATA_DATA8__ESDHC1_DAT4 941
-MX53_PAD_PATA_DATA8__EMI_NANDF_D_8 942
-MX53_PAD_PATA_DATA8__ESDHC3_DAT0 943
-MX53_PAD_PATA_DATA8__GPU3d_GPU_DEBUG_OUT_8 944
-MX53_PAD_PATA_DATA8__IPU_DIAG_BUS_8 945
-MX53_PAD_PATA_DATA9__PATA_DATA_9 946
-MX53_PAD_PATA_DATA9__GPIO2_9 947
-MX53_PAD_PATA_DATA9__ESDHC1_DAT5 948
-MX53_PAD_PATA_DATA9__EMI_NANDF_D_9 949
-MX53_PAD_PATA_DATA9__ESDHC3_DAT1 950
-MX53_PAD_PATA_DATA9__GPU3d_GPU_DEBUG_OUT_9 951
-MX53_PAD_PATA_DATA9__IPU_DIAG_BUS_9 952
-MX53_PAD_PATA_DATA10__PATA_DATA_10 953
-MX53_PAD_PATA_DATA10__GPIO2_10 954
-MX53_PAD_PATA_DATA10__ESDHC1_DAT6 955
-MX53_PAD_PATA_DATA10__EMI_NANDF_D_10 956
-MX53_PAD_PATA_DATA10__ESDHC3_DAT2 957
-MX53_PAD_PATA_DATA10__GPU3d_GPU_DEBUG_OUT_10 958
-MX53_PAD_PATA_DATA10__IPU_DIAG_BUS_10 959
-MX53_PAD_PATA_DATA11__PATA_DATA_11 960
-MX53_PAD_PATA_DATA11__GPIO2_11 961
-MX53_PAD_PATA_DATA11__ESDHC1_DAT7 962
-MX53_PAD_PATA_DATA11__EMI_NANDF_D_11 963
-MX53_PAD_PATA_DATA11__ESDHC3_DAT3 964
-MX53_PAD_PATA_DATA11__GPU3d_GPU_DEBUG_OUT_11 965
-MX53_PAD_PATA_DATA11__IPU_DIAG_BUS_11 966
-MX53_PAD_PATA_DATA12__PATA_DATA_12 967
-MX53_PAD_PATA_DATA12__GPIO2_12 968
-MX53_PAD_PATA_DATA12__ESDHC2_DAT4 969
-MX53_PAD_PATA_DATA12__EMI_NANDF_D_12 970
-MX53_PAD_PATA_DATA12__ESDHC4_DAT0 971
-MX53_PAD_PATA_DATA12__GPU3d_GPU_DEBUG_OUT_12 972
-MX53_PAD_PATA_DATA12__IPU_DIAG_BUS_12 973
-MX53_PAD_PATA_DATA13__PATA_DATA_13 974
-MX53_PAD_PATA_DATA13__GPIO2_13 975
-MX53_PAD_PATA_DATA13__ESDHC2_DAT5 976
-MX53_PAD_PATA_DATA13__EMI_NANDF_D_13 977
-MX53_PAD_PATA_DATA13__ESDHC4_DAT1 978
-MX53_PAD_PATA_DATA13__GPU3d_GPU_DEBUG_OUT_13 979
-MX53_PAD_PATA_DATA13__IPU_DIAG_BUS_13 980
-MX53_PAD_PATA_DATA14__PATA_DATA_14 981
-MX53_PAD_PATA_DATA14__GPIO2_14 982
-MX53_PAD_PATA_DATA14__ESDHC2_DAT6 983
-MX53_PAD_PATA_DATA14__EMI_NANDF_D_14 984
-MX53_PAD_PATA_DATA14__ESDHC4_DAT2 985
-MX53_PAD_PATA_DATA14__GPU3d_GPU_DEBUG_OUT_14 986
-MX53_PAD_PATA_DATA14__IPU_DIAG_BUS_14 987
-MX53_PAD_PATA_DATA15__PATA_DATA_15 988
-MX53_PAD_PATA_DATA15__GPIO2_15 989
-MX53_PAD_PATA_DATA15__ESDHC2_DAT7 990
-MX53_PAD_PATA_DATA15__EMI_NANDF_D_15 991
-MX53_PAD_PATA_DATA15__ESDHC4_DAT3 992
-MX53_PAD_PATA_DATA15__GPU3d_GPU_DEBUG_OUT_15 993
-MX53_PAD_PATA_DATA15__IPU_DIAG_BUS_15 994
-MX53_PAD_SD1_DATA0__ESDHC1_DAT0 995
-MX53_PAD_SD1_DATA0__GPIO1_16 996
-MX53_PAD_SD1_DATA0__GPT_CAPIN1 997
-MX53_PAD_SD1_DATA0__CSPI_MISO 998
-MX53_PAD_SD1_DATA0__CCM_PLL3_BYP 999
-MX53_PAD_SD1_DATA1__ESDHC1_DAT1 1000
-MX53_PAD_SD1_DATA1__GPIO1_17 1001
-MX53_PAD_SD1_DATA1__GPT_CAPIN2 1002
-MX53_PAD_SD1_DATA1__CSPI_SS0 1003
-MX53_PAD_SD1_DATA1__CCM_PLL4_BYP 1004
-MX53_PAD_SD1_CMD__ESDHC1_CMD 1005
-MX53_PAD_SD1_CMD__GPIO1_18 1006
-MX53_PAD_SD1_CMD__GPT_CMPOUT1 1007
-MX53_PAD_SD1_CMD__CSPI_MOSI 1008
-MX53_PAD_SD1_CMD__CCM_PLL1_BYP 1009
-MX53_PAD_SD1_DATA2__ESDHC1_DAT2 1010
-MX53_PAD_SD1_DATA2__GPIO1_19 1011
-MX53_PAD_SD1_DATA2__GPT_CMPOUT2 1012
-MX53_PAD_SD1_DATA2__PWM2_PWMO 1013
-MX53_PAD_SD1_DATA2__WDOG1_WDOG_B 1014
-MX53_PAD_SD1_DATA2__CSPI_SS1 1015
-MX53_PAD_SD1_DATA2__WDOG1_WDOG_RST_B_DEB 1016
-MX53_PAD_SD1_DATA2__CCM_PLL2_BYP 1017
-MX53_PAD_SD1_CLK__ESDHC1_CLK 1018
-MX53_PAD_SD1_CLK__GPIO1_20 1019
-MX53_PAD_SD1_CLK__OSC32k_32K_OUT 1020
-MX53_PAD_SD1_CLK__GPT_CLKIN 1021
-MX53_PAD_SD1_CLK__CSPI_SCLK 1022
-MX53_PAD_SD1_CLK__SATA_PHY_DTB_0 1023
-MX53_PAD_SD1_DATA3__ESDHC1_DAT3 1024
-MX53_PAD_SD1_DATA3__GPIO1_21 1025
-MX53_PAD_SD1_DATA3__GPT_CMPOUT3 1026
-MX53_PAD_SD1_DATA3__PWM1_PWMO 1027
-MX53_PAD_SD1_DATA3__WDOG2_WDOG_B 1028
-MX53_PAD_SD1_DATA3__CSPI_SS2 1029
-MX53_PAD_SD1_DATA3__WDOG2_WDOG_RST_B_DEB 1030
-MX53_PAD_SD1_DATA3__SATA_PHY_DTB_1 1031
-MX53_PAD_SD2_CLK__ESDHC2_CLK 1032
-MX53_PAD_SD2_CLK__GPIO1_10 1033
-MX53_PAD_SD2_CLK__KPP_COL_5 1034
-MX53_PAD_SD2_CLK__AUDMUX_AUD4_RXFS 1035
-MX53_PAD_SD2_CLK__CSPI_SCLK 1036
-MX53_PAD_SD2_CLK__SCC_RANDOM_V 1037
-MX53_PAD_SD2_CMD__ESDHC2_CMD 1038
-MX53_PAD_SD2_CMD__GPIO1_11 1039
-MX53_PAD_SD2_CMD__KPP_ROW_5 1040
-MX53_PAD_SD2_CMD__AUDMUX_AUD4_RXC 1041
-MX53_PAD_SD2_CMD__CSPI_MOSI 1042
-MX53_PAD_SD2_CMD__SCC_RANDOM 1043
-MX53_PAD_SD2_DATA3__ESDHC2_DAT3 1044
-MX53_PAD_SD2_DATA3__GPIO1_12 1045
-MX53_PAD_SD2_DATA3__KPP_COL_6 1046
-MX53_PAD_SD2_DATA3__AUDMUX_AUD4_TXC 1047
-MX53_PAD_SD2_DATA3__CSPI_SS2 1048
-MX53_PAD_SD2_DATA3__SJC_DONE 1049
-MX53_PAD_SD2_DATA2__ESDHC2_DAT2 1050
-MX53_PAD_SD2_DATA2__GPIO1_13 1051
-MX53_PAD_SD2_DATA2__KPP_ROW_6 1052
-MX53_PAD_SD2_DATA2__AUDMUX_AUD4_TXD 1053
-MX53_PAD_SD2_DATA2__CSPI_SS1 1054
-MX53_PAD_SD2_DATA2__SJC_FAIL 1055
-MX53_PAD_SD2_DATA1__ESDHC2_DAT1 1056
-MX53_PAD_SD2_DATA1__GPIO1_14 1057
-MX53_PAD_SD2_DATA1__KPP_COL_7 1058
-MX53_PAD_SD2_DATA1__AUDMUX_AUD4_TXFS 1059
-MX53_PAD_SD2_DATA1__CSPI_SS0 1060
-MX53_PAD_SD2_DATA1__RTIC_SEC_VIO 1061
-MX53_PAD_SD2_DATA0__ESDHC2_DAT0 1062
-MX53_PAD_SD2_DATA0__GPIO1_15 1063
-MX53_PAD_SD2_DATA0__KPP_ROW_7 1064
-MX53_PAD_SD2_DATA0__AUDMUX_AUD4_RXD 1065
-MX53_PAD_SD2_DATA0__CSPI_MISO 1066
-MX53_PAD_SD2_DATA0__RTIC_DONE_INT 1067
-MX53_PAD_GPIO_0__CCM_CLKO 1068
-MX53_PAD_GPIO_0__GPIO1_0 1069
-MX53_PAD_GPIO_0__KPP_COL_5 1070
-MX53_PAD_GPIO_0__CCM_SSI_EXT1_CLK 1071
-MX53_PAD_GPIO_0__EPIT1_EPITO 1072
-MX53_PAD_GPIO_0__SRTC_ALARM_DEB 1073
-MX53_PAD_GPIO_0__USBOH3_USBH1_PWR 1074
-MX53_PAD_GPIO_0__CSU_TD 1075
-MX53_PAD_GPIO_1__ESAI1_SCKR 1076
-MX53_PAD_GPIO_1__GPIO1_1 1077
-MX53_PAD_GPIO_1__KPP_ROW_5 1078
-MX53_PAD_GPIO_1__CCM_SSI_EXT2_CLK 1079
-MX53_PAD_GPIO_1__PWM2_PWMO 1080
-MX53_PAD_GPIO_1__WDOG2_WDOG_B 1081
-MX53_PAD_GPIO_1__ESDHC1_CD 1082
-MX53_PAD_GPIO_1__SRC_TESTER_ACK 1083
-MX53_PAD_GPIO_9__ESAI1_FSR 1084
-MX53_PAD_GPIO_9__GPIO1_9 1085
-MX53_PAD_GPIO_9__KPP_COL_6 1086
-MX53_PAD_GPIO_9__CCM_REF_EN_B 1087
-MX53_PAD_GPIO_9__PWM1_PWMO 1088
-MX53_PAD_GPIO_9__WDOG1_WDOG_B 1089
-MX53_PAD_GPIO_9__ESDHC1_WP 1090
-MX53_PAD_GPIO_9__SCC_FAIL_STATE 1091
-MX53_PAD_GPIO_3__ESAI1_HCKR 1092
-MX53_PAD_GPIO_3__GPIO1_3 1093
-MX53_PAD_GPIO_3__I2C3_SCL 1094
-MX53_PAD_GPIO_3__DPLLIP1_TOG_EN 1095
-MX53_PAD_GPIO_3__CCM_CLKO2 1096
-MX53_PAD_GPIO_3__OBSERVE_MUX_OBSRV_INT_OUT0 1097
-MX53_PAD_GPIO_3__USBOH3_USBH1_OC 1098
-MX53_PAD_GPIO_3__MLB_MLBCLK 1099
-MX53_PAD_GPIO_6__ESAI1_SCKT 1100
-MX53_PAD_GPIO_6__GPIO1_6 1101
-MX53_PAD_GPIO_6__I2C3_SDA 1102
-MX53_PAD_GPIO_6__CCM_CCM_OUT_0 1103
-MX53_PAD_GPIO_6__CSU_CSU_INT_DEB 1104
-MX53_PAD_GPIO_6__OBSERVE_MUX_OBSRV_INT_OUT1 1105
-MX53_PAD_GPIO_6__ESDHC2_LCTL 1106
-MX53_PAD_GPIO_6__MLB_MLBSIG 1107
-MX53_PAD_GPIO_2__ESAI1_FST 1108
-MX53_PAD_GPIO_2__GPIO1_2 1109
-MX53_PAD_GPIO_2__KPP_ROW_6 1110
-MX53_PAD_GPIO_2__CCM_CCM_OUT_1 1111
-MX53_PAD_GPIO_2__CSU_CSU_ALARM_AUT_0 1112
-MX53_PAD_GPIO_2__OBSERVE_MUX_OBSRV_INT_OUT2 1113
-MX53_PAD_GPIO_2__ESDHC2_WP 1114
-MX53_PAD_GPIO_2__MLB_MLBDAT 1115
-MX53_PAD_GPIO_4__ESAI1_HCKT 1116
-MX53_PAD_GPIO_4__GPIO1_4 1117
-MX53_PAD_GPIO_4__KPP_COL_7 1118
-MX53_PAD_GPIO_4__CCM_CCM_OUT_2 1119
-MX53_PAD_GPIO_4__CSU_CSU_ALARM_AUT_1 1120
-MX53_PAD_GPIO_4__OBSERVE_MUX_OBSRV_INT_OUT3 1121
-MX53_PAD_GPIO_4__ESDHC2_CD 1122
-MX53_PAD_GPIO_4__SCC_SEC_STATE 1123
-MX53_PAD_GPIO_5__ESAI1_TX2_RX3 1124
-MX53_PAD_GPIO_5__GPIO1_5 1125
-MX53_PAD_GPIO_5__KPP_ROW_7 1126
-MX53_PAD_GPIO_5__CCM_CLKO 1127
-MX53_PAD_GPIO_5__CSU_CSU_ALARM_AUT_2 1128
-MX53_PAD_GPIO_5__OBSERVE_MUX_OBSRV_INT_OUT4 1129
-MX53_PAD_GPIO_5__I2C3_SCL 1130
-MX53_PAD_GPIO_5__CCM_PLL1_BYP 1131
-MX53_PAD_GPIO_7__ESAI1_TX4_RX1 1132
-MX53_PAD_GPIO_7__GPIO1_7 1133
-MX53_PAD_GPIO_7__EPIT1_EPITO 1134
-MX53_PAD_GPIO_7__CAN1_TXCAN 1135
-MX53_PAD_GPIO_7__UART2_TXD_MUX 1136
-MX53_PAD_GPIO_7__FIRI_RXD 1137
-MX53_PAD_GPIO_7__SPDIF_PLOCK 1138
-MX53_PAD_GPIO_7__CCM_PLL2_BYP 1139
-MX53_PAD_GPIO_8__ESAI1_TX5_RX0 1140
-MX53_PAD_GPIO_8__GPIO1_8 1141
-MX53_PAD_GPIO_8__EPIT2_EPITO 1142
-MX53_PAD_GPIO_8__CAN1_RXCAN 1143
-MX53_PAD_GPIO_8__UART2_RXD_MUX 1144
-MX53_PAD_GPIO_8__FIRI_TXD 1145
-MX53_PAD_GPIO_8__SPDIF_SRCLK 1146
-MX53_PAD_GPIO_8__CCM_PLL3_BYP 1147
-MX53_PAD_GPIO_16__ESAI1_TX3_RX2 1148
-MX53_PAD_GPIO_16__GPIO7_11 1149
-MX53_PAD_GPIO_16__TZIC_PWRFAIL_INT 1150
-MX53_PAD_GPIO_16__RTC_CE_RTC_EXT_TRIG1 1151
-MX53_PAD_GPIO_16__SPDIF_IN1 1152
-MX53_PAD_GPIO_16__I2C3_SDA 1153
-MX53_PAD_GPIO_16__SJC_DE_B 1154
-MX53_PAD_GPIO_17__ESAI1_TX0 1155
-MX53_PAD_GPIO_17__GPIO7_12 1156
-MX53_PAD_GPIO_17__SDMA_EXT_EVENT_0 1157
-MX53_PAD_GPIO_17__GPC_PMIC_RDY 1158
-MX53_PAD_GPIO_17__RTC_CE_RTC_FSV_TRIG 1159
-MX53_PAD_GPIO_17__SPDIF_OUT1 1160
-MX53_PAD_GPIO_17__IPU_SNOOP2 1161
-MX53_PAD_GPIO_17__SJC_JTAG_ACT 1162
-MX53_PAD_GPIO_18__ESAI1_TX1 1163
-MX53_PAD_GPIO_18__GPIO7_13 1164
-MX53_PAD_GPIO_18__SDMA_EXT_EVENT_1 1165
-MX53_PAD_GPIO_18__OWIRE_LINE 1166
-MX53_PAD_GPIO_18__RTC_CE_RTC_ALARM2_TRIG 1167
-MX53_PAD_GPIO_18__CCM_ASRC_EXT_CLK 1168
-MX53_PAD_GPIO_18__ESDHC1_LCTL 1169
-MX53_PAD_GPIO_18__SRC_SYSTEM_RST 1170
+Refer to imx53-pinfunc.h in device tree source folder for all available
+imx53 PIN_FUNC_ID.
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx6dl-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx6dl-pinctrl.txt
new file mode 100644
index 0000000..0ac5bee
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx6dl-pinctrl.txt
@@ -0,0 +1,38 @@
+* Freescale IMX6 DualLite/Solo IOMUX Controller
+
+Please refer to fsl,imx-pinctrl.txt in this directory for common binding part
+and usage.
+
+Required properties:
+- compatible: "fsl,imx6dl-iomuxc"
+- fsl,pins: two integers array, represents a group of pins mux and config
+ setting. The format is fsl,pins = <PIN_FUNC_ID CONFIG>, PIN_FUNC_ID is a
+ pin working on a specific function, CONFIG is the pad setting value like
+ pull-up for this pin. Please refer to imx6dl datasheet for the valid pad
+ config settings.
+
+CONFIG bits definition:
+PAD_CTL_HYS (1 << 16)
+PAD_CTL_PUS_100K_DOWN (0 << 14)
+PAD_CTL_PUS_47K_UP (1 << 14)
+PAD_CTL_PUS_100K_UP (2 << 14)
+PAD_CTL_PUS_22K_UP (3 << 14)
+PAD_CTL_PUE (1 << 13)
+PAD_CTL_PKE (1 << 12)
+PAD_CTL_ODE (1 << 11)
+PAD_CTL_SPEED_LOW (1 << 6)
+PAD_CTL_SPEED_MED (2 << 6)
+PAD_CTL_SPEED_HIGH (3 << 6)
+PAD_CTL_DSE_DISABLE (0 << 3)
+PAD_CTL_DSE_240ohm (1 << 3)
+PAD_CTL_DSE_120ohm (2 << 3)
+PAD_CTL_DSE_80ohm (3 << 3)
+PAD_CTL_DSE_60ohm (4 << 3)
+PAD_CTL_DSE_48ohm (5 << 3)
+PAD_CTL_DSE_40ohm (6 << 3)
+PAD_CTL_DSE_34ohm (7 << 3)
+PAD_CTL_SRE_FAST (1 << 0)
+PAD_CTL_SRE_SLOW (0 << 0)
+
+Refer to imx6dl-pinfunc.h in device tree source folder for all available
+imx6dl PIN_FUNC_ID.
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx6q-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx6q-pinctrl.txt
index a4119f6..546610c 100644
--- a/Documentation/devicetree/bindings/pinctrl/fsl,imx6q-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx6q-pinctrl.txt
@@ -34,1597 +34,5 @@
PAD_CTL_SRE_FAST (1 << 0)
PAD_CTL_SRE_SLOW (0 << 0)
-See below for available PIN_FUNC_ID for imx6q:
-MX6Q_PAD_SD2_DAT1__USDHC2_DAT1 0
-MX6Q_PAD_SD2_DAT1__ECSPI5_SS0 1
-MX6Q_PAD_SD2_DAT1__WEIM_WEIM_CS_2 2
-MX6Q_PAD_SD2_DAT1__AUDMUX_AUD4_TXFS 3
-MX6Q_PAD_SD2_DAT1__KPP_COL_7 4
-MX6Q_PAD_SD2_DAT1__GPIO_1_14 5
-MX6Q_PAD_SD2_DAT1__CCM_WAIT 6
-MX6Q_PAD_SD2_DAT1__ANATOP_TESTO_0 7
-MX6Q_PAD_SD2_DAT2__USDHC2_DAT2 8
-MX6Q_PAD_SD2_DAT2__ECSPI5_SS1 9
-MX6Q_PAD_SD2_DAT2__WEIM_WEIM_CS_3 10
-MX6Q_PAD_SD2_DAT2__AUDMUX_AUD4_TXD 11
-MX6Q_PAD_SD2_DAT2__KPP_ROW_6 12
-MX6Q_PAD_SD2_DAT2__GPIO_1_13 13
-MX6Q_PAD_SD2_DAT2__CCM_STOP 14
-MX6Q_PAD_SD2_DAT2__ANATOP_TESTO_1 15
-MX6Q_PAD_SD2_DAT0__USDHC2_DAT0 16
-MX6Q_PAD_SD2_DAT0__ECSPI5_MISO 17
-MX6Q_PAD_SD2_DAT0__AUDMUX_AUD4_RXD 18
-MX6Q_PAD_SD2_DAT0__KPP_ROW_7 19
-MX6Q_PAD_SD2_DAT0__GPIO_1_15 20
-MX6Q_PAD_SD2_DAT0__DCIC2_DCIC_OUT 21
-MX6Q_PAD_SD2_DAT0__TESTO_2 22
-MX6Q_PAD_RGMII_TXC__USBOH3_H2_DATA 23
-MX6Q_PAD_RGMII_TXC__ENET_RGMII_TXC 24
-MX6Q_PAD_RGMII_TXC__SPDIF_SPDIF_EXTCLK 25
-MX6Q_PAD_RGMII_TXC__GPIO_6_19 26
-MX6Q_PAD_RGMII_TXC__MIPI_CORE_DPHY_IN_0 27
-MX6Q_PAD_RGMII_TXC__ANATOP_24M_OUT 28
-MX6Q_PAD_RGMII_TD0__MIPI_HSI_CRL_TX_RDY 29
-MX6Q_PAD_RGMII_TD0__ENET_RGMII_TD0 30
-MX6Q_PAD_RGMII_TD0__GPIO_6_20 31
-MX6Q_PAD_RGMII_TD0__MIPI_CORE_DPHY_IN_1 32
-MX6Q_PAD_RGMII_TD1__MIPI_HSI_CRL_RX_FLG 33
-MX6Q_PAD_RGMII_TD1__ENET_RGMII_TD1 34
-MX6Q_PAD_RGMII_TD1__GPIO_6_21 35
-MX6Q_PAD_RGMII_TD1__MIPI_CORE_DPHY_IN_2 36
-MX6Q_PAD_RGMII_TD1__CCM_PLL3_BYP 37
-MX6Q_PAD_RGMII_TD2__MIPI_HSI_CRL_RX_DTA 38
-MX6Q_PAD_RGMII_TD2__ENET_RGMII_TD2 39
-MX6Q_PAD_RGMII_TD2__GPIO_6_22 40
-MX6Q_PAD_RGMII_TD2__MIPI_CORE_DPHY_IN_3 41
-MX6Q_PAD_RGMII_TD2__CCM_PLL2_BYP 42
-MX6Q_PAD_RGMII_TD3__MIPI_HSI_CRL_RX_WAK 43
-MX6Q_PAD_RGMII_TD3__ENET_RGMII_TD3 44
-MX6Q_PAD_RGMII_TD3__GPIO_6_23 45
-MX6Q_PAD_RGMII_TD3__MIPI_CORE_DPHY_IN_4 46
-MX6Q_PAD_RGMII_RX_CTL__USBOH3_H3_DATA 47
-MX6Q_PAD_RGMII_RX_CTL__RGMII_RX_CTL 48
-MX6Q_PAD_RGMII_RX_CTL__GPIO_6_24 49
-MX6Q_PAD_RGMII_RX_CTL__MIPI_DPHY_IN_5 50
-MX6Q_PAD_RGMII_RD0__MIPI_HSI_CRL_RX_RDY 51
-MX6Q_PAD_RGMII_RD0__ENET_RGMII_RD0 52
-MX6Q_PAD_RGMII_RD0__GPIO_6_25 53
-MX6Q_PAD_RGMII_RD0__MIPI_CORE_DPHY_IN_6 54
-MX6Q_PAD_RGMII_TX_CTL__USBOH3_H2_STROBE 55
-MX6Q_PAD_RGMII_TX_CTL__RGMII_TX_CTL 56
-MX6Q_PAD_RGMII_TX_CTL__GPIO_6_26 57
-MX6Q_PAD_RGMII_TX_CTL__CORE_DPHY_IN_7 58
-MX6Q_PAD_RGMII_TX_CTL__ANATOP_REF_OUT 59
-MX6Q_PAD_RGMII_RD1__MIPI_HSI_CTRL_TX_FL 60
-MX6Q_PAD_RGMII_RD1__ENET_RGMII_RD1 61
-MX6Q_PAD_RGMII_RD1__GPIO_6_27 62
-MX6Q_PAD_RGMII_RD1__CORE_DPHY_TEST_IN_8 63
-MX6Q_PAD_RGMII_RD1__SJC_FAIL 64
-MX6Q_PAD_RGMII_RD2__MIPI_HSI_CRL_TX_DTA 65
-MX6Q_PAD_RGMII_RD2__ENET_RGMII_RD2 66
-MX6Q_PAD_RGMII_RD2__GPIO_6_28 67
-MX6Q_PAD_RGMII_RD2__MIPI_CORE_DPHY_IN_9 68
-MX6Q_PAD_RGMII_RD3__MIPI_HSI_CRL_TX_WAK 69
-MX6Q_PAD_RGMII_RD3__ENET_RGMII_RD3 70
-MX6Q_PAD_RGMII_RD3__GPIO_6_29 71
-MX6Q_PAD_RGMII_RD3__MIPI_CORE_DPHY_IN10 72
-MX6Q_PAD_RGMII_RXC__USBOH3_H3_STROBE 73
-MX6Q_PAD_RGMII_RXC__ENET_RGMII_RXC 74
-MX6Q_PAD_RGMII_RXC__GPIO_6_30 75
-MX6Q_PAD_RGMII_RXC__MIPI_CORE_DPHY_IN11 76
-MX6Q_PAD_EIM_A25__WEIM_WEIM_A_25 77
-MX6Q_PAD_EIM_A25__ECSPI4_SS1 78
-MX6Q_PAD_EIM_A25__ECSPI2_RDY 79
-MX6Q_PAD_EIM_A25__IPU1_DI1_PIN12 80
-MX6Q_PAD_EIM_A25__IPU1_DI0_D1_CS 81
-MX6Q_PAD_EIM_A25__GPIO_5_2 82
-MX6Q_PAD_EIM_A25__HDMI_TX_CEC_LINE 83
-MX6Q_PAD_EIM_A25__PL301_PER1_HBURST_0 84
-MX6Q_PAD_EIM_EB2__WEIM_WEIM_EB_2 85
-MX6Q_PAD_EIM_EB2__ECSPI1_SS0 86
-MX6Q_PAD_EIM_EB2__CCM_DI1_EXT_CLK 87
-MX6Q_PAD_EIM_EB2__IPU2_CSI1_D_19 88
-MX6Q_PAD_EIM_EB2__HDMI_TX_DDC_SCL 89
-MX6Q_PAD_EIM_EB2__GPIO_2_30 90
-MX6Q_PAD_EIM_EB2__I2C2_SCL 91
-MX6Q_PAD_EIM_EB2__SRC_BT_CFG_30 92
-MX6Q_PAD_EIM_D16__WEIM_WEIM_D_16 93
-MX6Q_PAD_EIM_D16__ECSPI1_SCLK 94
-MX6Q_PAD_EIM_D16__IPU1_DI0_PIN5 95
-MX6Q_PAD_EIM_D16__IPU2_CSI1_D_18 96
-MX6Q_PAD_EIM_D16__HDMI_TX_DDC_SDA 97
-MX6Q_PAD_EIM_D16__GPIO_3_16 98
-MX6Q_PAD_EIM_D16__I2C2_SDA 99
-MX6Q_PAD_EIM_D17__WEIM_WEIM_D_17 100
-MX6Q_PAD_EIM_D17__ECSPI1_MISO 101
-MX6Q_PAD_EIM_D17__IPU1_DI0_PIN6 102
-MX6Q_PAD_EIM_D17__IPU2_CSI1_PIXCLK 103
-MX6Q_PAD_EIM_D17__DCIC1_DCIC_OUT 104
-MX6Q_PAD_EIM_D17__GPIO_3_17 105
-MX6Q_PAD_EIM_D17__I2C3_SCL 106
-MX6Q_PAD_EIM_D17__PL301_PER1_HBURST_1 107
-MX6Q_PAD_EIM_D18__WEIM_WEIM_D_18 108
-MX6Q_PAD_EIM_D18__ECSPI1_MOSI 109
-MX6Q_PAD_EIM_D18__IPU1_DI0_PIN7 110
-MX6Q_PAD_EIM_D18__IPU2_CSI1_D_17 111
-MX6Q_PAD_EIM_D18__IPU1_DI1_D0_CS 112
-MX6Q_PAD_EIM_D18__GPIO_3_18 113
-MX6Q_PAD_EIM_D18__I2C3_SDA 114
-MX6Q_PAD_EIM_D18__PL301_PER1_HBURST_2 115
-MX6Q_PAD_EIM_D19__WEIM_WEIM_D_19 116
-MX6Q_PAD_EIM_D19__ECSPI1_SS1 117
-MX6Q_PAD_EIM_D19__IPU1_DI0_PIN8 118
-MX6Q_PAD_EIM_D19__IPU2_CSI1_D_16 119
-MX6Q_PAD_EIM_D19__UART1_CTS 120
-MX6Q_PAD_EIM_D19__GPIO_3_19 121
-MX6Q_PAD_EIM_D19__EPIT1_EPITO 122
-MX6Q_PAD_EIM_D19__PL301_PER1_HRESP 123
-MX6Q_PAD_EIM_D20__WEIM_WEIM_D_20 124
-MX6Q_PAD_EIM_D20__ECSPI4_SS0 125
-MX6Q_PAD_EIM_D20__IPU1_DI0_PIN16 126
-MX6Q_PAD_EIM_D20__IPU2_CSI1_D_15 127
-MX6Q_PAD_EIM_D20__UART1_RTS 128
-MX6Q_PAD_EIM_D20__GPIO_3_20 129
-MX6Q_PAD_EIM_D20__EPIT2_EPITO 130
-MX6Q_PAD_EIM_D21__WEIM_WEIM_D_21 131
-MX6Q_PAD_EIM_D21__ECSPI4_SCLK 132
-MX6Q_PAD_EIM_D21__IPU1_DI0_PIN17 133
-MX6Q_PAD_EIM_D21__IPU2_CSI1_D_11 134
-MX6Q_PAD_EIM_D21__USBOH3_USBOTG_OC 135
-MX6Q_PAD_EIM_D21__GPIO_3_21 136
-MX6Q_PAD_EIM_D21__I2C1_SCL 137
-MX6Q_PAD_EIM_D21__SPDIF_IN1 138
-MX6Q_PAD_EIM_D22__WEIM_WEIM_D_22 139
-MX6Q_PAD_EIM_D22__ECSPI4_MISO 140
-MX6Q_PAD_EIM_D22__IPU1_DI0_PIN1 141
-MX6Q_PAD_EIM_D22__IPU2_CSI1_D_10 142
-MX6Q_PAD_EIM_D22__USBOH3_USBOTG_PWR 143
-MX6Q_PAD_EIM_D22__GPIO_3_22 144
-MX6Q_PAD_EIM_D22__SPDIF_OUT1 145
-MX6Q_PAD_EIM_D22__PL301_PER1_HWRITE 146
-MX6Q_PAD_EIM_D23__WEIM_WEIM_D_23 147
-MX6Q_PAD_EIM_D23__IPU1_DI0_D0_CS 148
-MX6Q_PAD_EIM_D23__UART3_CTS 149
-MX6Q_PAD_EIM_D23__UART1_DCD 150
-MX6Q_PAD_EIM_D23__IPU2_CSI1_DATA_EN 151
-MX6Q_PAD_EIM_D23__GPIO_3_23 152
-MX6Q_PAD_EIM_D23__IPU1_DI1_PIN2 153
-MX6Q_PAD_EIM_D23__IPU1_DI1_PIN14 154
-MX6Q_PAD_EIM_EB3__WEIM_WEIM_EB_3 155
-MX6Q_PAD_EIM_EB3__ECSPI4_RDY 156
-MX6Q_PAD_EIM_EB3__UART3_RTS 157
-MX6Q_PAD_EIM_EB3__UART1_RI 158
-MX6Q_PAD_EIM_EB3__IPU2_CSI1_HSYNC 159
-MX6Q_PAD_EIM_EB3__GPIO_2_31 160
-MX6Q_PAD_EIM_EB3__IPU1_DI1_PIN3 161
-MX6Q_PAD_EIM_EB3__SRC_BT_CFG_31 162
-MX6Q_PAD_EIM_D24__WEIM_WEIM_D_24 163
-MX6Q_PAD_EIM_D24__ECSPI4_SS2 164
-MX6Q_PAD_EIM_D24__UART3_TXD 165
-MX6Q_PAD_EIM_D24__ECSPI1_SS2 166
-MX6Q_PAD_EIM_D24__ECSPI2_SS2 167
-MX6Q_PAD_EIM_D24__GPIO_3_24 168
-MX6Q_PAD_EIM_D24__AUDMUX_AUD5_RXFS 169
-MX6Q_PAD_EIM_D24__UART1_DTR 170
-MX6Q_PAD_EIM_D25__WEIM_WEIM_D_25 171
-MX6Q_PAD_EIM_D25__ECSPI4_SS3 172
-MX6Q_PAD_EIM_D25__UART3_RXD 173
-MX6Q_PAD_EIM_D25__ECSPI1_SS3 174
-MX6Q_PAD_EIM_D25__ECSPI2_SS3 175
-MX6Q_PAD_EIM_D25__GPIO_3_25 176
-MX6Q_PAD_EIM_D25__AUDMUX_AUD5_RXC 177
-MX6Q_PAD_EIM_D25__UART1_DSR 178
-MX6Q_PAD_EIM_D26__WEIM_WEIM_D_26 179
-MX6Q_PAD_EIM_D26__IPU1_DI1_PIN11 180
-MX6Q_PAD_EIM_D26__IPU1_CSI0_D_1 181
-MX6Q_PAD_EIM_D26__IPU2_CSI1_D_14 182
-MX6Q_PAD_EIM_D26__UART2_TXD 183
-MX6Q_PAD_EIM_D26__GPIO_3_26 184
-MX6Q_PAD_EIM_D26__IPU1_SISG_2 185
-MX6Q_PAD_EIM_D26__IPU1_DISP1_DAT_22 186
-MX6Q_PAD_EIM_D27__WEIM_WEIM_D_27 187
-MX6Q_PAD_EIM_D27__IPU1_DI1_PIN13 188
-MX6Q_PAD_EIM_D27__IPU1_CSI0_D_0 189
-MX6Q_PAD_EIM_D27__IPU2_CSI1_D_13 190
-MX6Q_PAD_EIM_D27__UART2_RXD 191
-MX6Q_PAD_EIM_D27__GPIO_3_27 192
-MX6Q_PAD_EIM_D27__IPU1_SISG_3 193
-MX6Q_PAD_EIM_D27__IPU1_DISP1_DAT_23 194
-MX6Q_PAD_EIM_D28__WEIM_WEIM_D_28 195
-MX6Q_PAD_EIM_D28__I2C1_SDA 196
-MX6Q_PAD_EIM_D28__ECSPI4_MOSI 197
-MX6Q_PAD_EIM_D28__IPU2_CSI1_D_12 198
-MX6Q_PAD_EIM_D28__UART2_CTS 199
-MX6Q_PAD_EIM_D28__GPIO_3_28 200
-MX6Q_PAD_EIM_D28__IPU1_EXT_TRIG 201
-MX6Q_PAD_EIM_D28__IPU1_DI0_PIN13 202
-MX6Q_PAD_EIM_D29__WEIM_WEIM_D_29 203
-MX6Q_PAD_EIM_D29__IPU1_DI1_PIN15 204
-MX6Q_PAD_EIM_D29__ECSPI4_SS0 205
-MX6Q_PAD_EIM_D29__UART2_RTS 206
-MX6Q_PAD_EIM_D29__GPIO_3_29 207
-MX6Q_PAD_EIM_D29__IPU2_CSI1_VSYNC 208
-MX6Q_PAD_EIM_D29__IPU1_DI0_PIN14 209
-MX6Q_PAD_EIM_D30__WEIM_WEIM_D_30 210
-MX6Q_PAD_EIM_D30__IPU1_DISP1_DAT_21 211
-MX6Q_PAD_EIM_D30__IPU1_DI0_PIN11 212
-MX6Q_PAD_EIM_D30__IPU1_CSI0_D_3 213
-MX6Q_PAD_EIM_D30__UART3_CTS 214
-MX6Q_PAD_EIM_D30__GPIO_3_30 215
-MX6Q_PAD_EIM_D30__USBOH3_USBH1_OC 216
-MX6Q_PAD_EIM_D30__PL301_PER1_HPROT_0 217
-MX6Q_PAD_EIM_D31__WEIM_WEIM_D_31 218
-MX6Q_PAD_EIM_D31__IPU1_DISP1_DAT_20 219
-MX6Q_PAD_EIM_D31__IPU1_DI0_PIN12 220
-MX6Q_PAD_EIM_D31__IPU1_CSI0_D_2 221
-MX6Q_PAD_EIM_D31__UART3_RTS 222
-MX6Q_PAD_EIM_D31__GPIO_3_31 223
-MX6Q_PAD_EIM_D31__USBOH3_USBH1_PWR 224
-MX6Q_PAD_EIM_D31__PL301_PER1_HPROT_1 225
-MX6Q_PAD_EIM_A24__WEIM_WEIM_A_24 226
-MX6Q_PAD_EIM_A24__IPU1_DISP1_DAT_19 227
-MX6Q_PAD_EIM_A24__IPU2_CSI1_D_19 228
-MX6Q_PAD_EIM_A24__IPU2_SISG_2 229
-MX6Q_PAD_EIM_A24__IPU1_SISG_2 230
-MX6Q_PAD_EIM_A24__GPIO_5_4 231
-MX6Q_PAD_EIM_A24__PL301_PER1_HPROT_2 232
-MX6Q_PAD_EIM_A24__SRC_BT_CFG_24 233
-MX6Q_PAD_EIM_A23__WEIM_WEIM_A_23 234
-MX6Q_PAD_EIM_A23__IPU1_DISP1_DAT_18 235
-MX6Q_PAD_EIM_A23__IPU2_CSI1_D_18 236
-MX6Q_PAD_EIM_A23__IPU2_SISG_3 237
-MX6Q_PAD_EIM_A23__IPU1_SISG_3 238
-MX6Q_PAD_EIM_A23__GPIO_6_6 239
-MX6Q_PAD_EIM_A23__PL301_PER1_HPROT_3 240
-MX6Q_PAD_EIM_A23__SRC_BT_CFG_23 241
-MX6Q_PAD_EIM_A22__WEIM_WEIM_A_22 242
-MX6Q_PAD_EIM_A22__IPU1_DISP1_DAT_17 243
-MX6Q_PAD_EIM_A22__IPU2_CSI1_D_17 244
-MX6Q_PAD_EIM_A22__GPIO_2_16 245
-MX6Q_PAD_EIM_A22__TPSMP_HDATA_0 246
-MX6Q_PAD_EIM_A22__SRC_BT_CFG_22 247
-MX6Q_PAD_EIM_A21__WEIM_WEIM_A_21 248
-MX6Q_PAD_EIM_A21__IPU1_DISP1_DAT_16 249
-MX6Q_PAD_EIM_A21__IPU2_CSI1_D_16 250
-MX6Q_PAD_EIM_A21__RESERVED_RESERVED 251
-MX6Q_PAD_EIM_A21__MIPI_CORE_DPHY_OUT_18 252
-MX6Q_PAD_EIM_A21__GPIO_2_17 253
-MX6Q_PAD_EIM_A21__TPSMP_HDATA_1 254
-MX6Q_PAD_EIM_A21__SRC_BT_CFG_21 255
-MX6Q_PAD_EIM_A20__WEIM_WEIM_A_20 256
-MX6Q_PAD_EIM_A20__IPU1_DISP1_DAT_15 257
-MX6Q_PAD_EIM_A20__IPU2_CSI1_D_15 258
-MX6Q_PAD_EIM_A20__RESERVED_RESERVED 259
-MX6Q_PAD_EIM_A20__MIPI_CORE_DPHY_OUT_19 260
-MX6Q_PAD_EIM_A20__GPIO_2_18 261
-MX6Q_PAD_EIM_A20__TPSMP_HDATA_2 262
-MX6Q_PAD_EIM_A20__SRC_BT_CFG_20 263
-MX6Q_PAD_EIM_A19__WEIM_WEIM_A_19 264
-MX6Q_PAD_EIM_A19__IPU1_DISP1_DAT_14 265
-MX6Q_PAD_EIM_A19__IPU2_CSI1_D_14 266
-MX6Q_PAD_EIM_A19__RESERVED_RESERVED 267
-MX6Q_PAD_EIM_A19__MIPI_CORE_DPHY_OUT_20 268
-MX6Q_PAD_EIM_A19__GPIO_2_19 269
-MX6Q_PAD_EIM_A19__TPSMP_HDATA_3 270
-MX6Q_PAD_EIM_A19__SRC_BT_CFG_19 271
-MX6Q_PAD_EIM_A18__WEIM_WEIM_A_18 272
-MX6Q_PAD_EIM_A18__IPU1_DISP1_DAT_13 273
-MX6Q_PAD_EIM_A18__IPU2_CSI1_D_13 274
-MX6Q_PAD_EIM_A18__RESERVED_RESERVED 275
-MX6Q_PAD_EIM_A18__MIPI_CORE_DPHY_OUT_21 276
-MX6Q_PAD_EIM_A18__GPIO_2_20 277
-MX6Q_PAD_EIM_A18__TPSMP_HDATA_4 278
-MX6Q_PAD_EIM_A18__SRC_BT_CFG_18 279
-MX6Q_PAD_EIM_A17__WEIM_WEIM_A_17 280
-MX6Q_PAD_EIM_A17__IPU1_DISP1_DAT_12 281
-MX6Q_PAD_EIM_A17__IPU2_CSI1_D_12 282
-MX6Q_PAD_EIM_A17__RESERVED_RESERVED 283
-MX6Q_PAD_EIM_A17__MIPI_CORE_DPHY_OUT_22 284
-MX6Q_PAD_EIM_A17__GPIO_2_21 285
-MX6Q_PAD_EIM_A17__TPSMP_HDATA_5 286
-MX6Q_PAD_EIM_A17__SRC_BT_CFG_17 287
-MX6Q_PAD_EIM_A16__WEIM_WEIM_A_16 288
-MX6Q_PAD_EIM_A16__IPU1_DI1_DISP_CLK 289
-MX6Q_PAD_EIM_A16__IPU2_CSI1_PIXCLK 290
-MX6Q_PAD_EIM_A16__MIPI_CORE_DPHY_OUT_23 291
-MX6Q_PAD_EIM_A16__GPIO_2_22 292
-MX6Q_PAD_EIM_A16__TPSMP_HDATA_6 293
-MX6Q_PAD_EIM_A16__SRC_BT_CFG_16 294
-MX6Q_PAD_EIM_CS0__WEIM_WEIM_CS_0 295
-MX6Q_PAD_EIM_CS0__IPU1_DI1_PIN5 296
-MX6Q_PAD_EIM_CS0__ECSPI2_SCLK 297
-MX6Q_PAD_EIM_CS0__MIPI_CORE_DPHY_OUT_24 298
-MX6Q_PAD_EIM_CS0__GPIO_2_23 299
-MX6Q_PAD_EIM_CS0__TPSMP_HDATA_7 300
-MX6Q_PAD_EIM_CS1__WEIM_WEIM_CS_1 301
-MX6Q_PAD_EIM_CS1__IPU1_DI1_PIN6 302
-MX6Q_PAD_EIM_CS1__ECSPI2_MOSI 303
-MX6Q_PAD_EIM_CS1__MIPI_CORE_DPHY_OUT_25 304
-MX6Q_PAD_EIM_CS1__GPIO_2_24 305
-MX6Q_PAD_EIM_CS1__TPSMP_HDATA_8 306
-MX6Q_PAD_EIM_OE__WEIM_WEIM_OE 307
-MX6Q_PAD_EIM_OE__IPU1_DI1_PIN7 308
-MX6Q_PAD_EIM_OE__ECSPI2_MISO 309
-MX6Q_PAD_EIM_OE__MIPI_CORE_DPHY_OUT_26 310
-MX6Q_PAD_EIM_OE__GPIO_2_25 311
-MX6Q_PAD_EIM_OE__TPSMP_HDATA_9 312
-MX6Q_PAD_EIM_RW__WEIM_WEIM_RW 313
-MX6Q_PAD_EIM_RW__IPU1_DI1_PIN8 314
-MX6Q_PAD_EIM_RW__ECSPI2_SS0 315
-MX6Q_PAD_EIM_RW__MIPI_CORE_DPHY_OUT_27 316
-MX6Q_PAD_EIM_RW__GPIO_2_26 317
-MX6Q_PAD_EIM_RW__TPSMP_HDATA_10 318
-MX6Q_PAD_EIM_RW__SRC_BT_CFG_29 319
-MX6Q_PAD_EIM_LBA__WEIM_WEIM_LBA 320
-MX6Q_PAD_EIM_LBA__IPU1_DI1_PIN17 321
-MX6Q_PAD_EIM_LBA__ECSPI2_SS1 322
-MX6Q_PAD_EIM_LBA__GPIO_2_27 323
-MX6Q_PAD_EIM_LBA__TPSMP_HDATA_11 324
-MX6Q_PAD_EIM_LBA__SRC_BT_CFG_26 325
-MX6Q_PAD_EIM_EB0__WEIM_WEIM_EB_0 326
-MX6Q_PAD_EIM_EB0__IPU1_DISP1_DAT_11 327
-MX6Q_PAD_EIM_EB0__IPU2_CSI1_D_11 328
-MX6Q_PAD_EIM_EB0__MIPI_CORE_DPHY_OUT_0 329
-MX6Q_PAD_EIM_EB0__CCM_PMIC_RDY 330
-MX6Q_PAD_EIM_EB0__GPIO_2_28 331
-MX6Q_PAD_EIM_EB0__TPSMP_HDATA_12 332
-MX6Q_PAD_EIM_EB0__SRC_BT_CFG_27 333
-MX6Q_PAD_EIM_EB1__WEIM_WEIM_EB_1 334
-MX6Q_PAD_EIM_EB1__IPU1_DISP1_DAT_10 335
-MX6Q_PAD_EIM_EB1__IPU2_CSI1_D_10 336
-MX6Q_PAD_EIM_EB1__MIPI_CORE_DPHY__OUT_1 337
-MX6Q_PAD_EIM_EB1__GPIO_2_29 338
-MX6Q_PAD_EIM_EB1__TPSMP_HDATA_13 339
-MX6Q_PAD_EIM_EB1__SRC_BT_CFG_28 340
-MX6Q_PAD_EIM_DA0__WEIM_WEIM_DA_A_0 341
-MX6Q_PAD_EIM_DA0__IPU1_DISP1_DAT_9 342
-MX6Q_PAD_EIM_DA0__IPU2_CSI1_D_9 343
-MX6Q_PAD_EIM_DA0__MIPI_CORE_DPHY__OUT_2 344
-MX6Q_PAD_EIM_DA0__GPIO_3_0 345
-MX6Q_PAD_EIM_DA0__TPSMP_HDATA_14 346
-MX6Q_PAD_EIM_DA0__SRC_BT_CFG_0 347
-MX6Q_PAD_EIM_DA1__WEIM_WEIM_DA_A_1 348
-MX6Q_PAD_EIM_DA1__IPU1_DISP1_DAT_8 349
-MX6Q_PAD_EIM_DA1__IPU2_CSI1_D_8 350
-MX6Q_PAD_EIM_DA1__MIPI_CORE_DPHY_OUT_3 351
-MX6Q_PAD_EIM_DA1__USBPHY1_TX_LS_MODE 352
-MX6Q_PAD_EIM_DA1__GPIO_3_1 353
-MX6Q_PAD_EIM_DA1__TPSMP_HDATA_15 354
-MX6Q_PAD_EIM_DA1__SRC_BT_CFG_1 355
-MX6Q_PAD_EIM_DA2__WEIM_WEIM_DA_A_2 356
-MX6Q_PAD_EIM_DA2__IPU1_DISP1_DAT_7 357
-MX6Q_PAD_EIM_DA2__IPU2_CSI1_D_7 358
-MX6Q_PAD_EIM_DA2__MIPI_CORE_DPHY_OUT_4 359
-MX6Q_PAD_EIM_DA2__USBPHY1_TX_HS_MODE 360
-MX6Q_PAD_EIM_DA2__GPIO_3_2 361
-MX6Q_PAD_EIM_DA2__TPSMP_HDATA_16 362
-MX6Q_PAD_EIM_DA2__SRC_BT_CFG_2 363
-MX6Q_PAD_EIM_DA3__WEIM_WEIM_DA_A_3 364
-MX6Q_PAD_EIM_DA3__IPU1_DISP1_DAT_6 365
-MX6Q_PAD_EIM_DA3__IPU2_CSI1_D_6 366
-MX6Q_PAD_EIM_DA3__MIPI_CORE_DPHY_OUT_5 367
-MX6Q_PAD_EIM_DA3__USBPHY1_TX_HIZ 368
-MX6Q_PAD_EIM_DA3__GPIO_3_3 369
-MX6Q_PAD_EIM_DA3__TPSMP_HDATA_17 370
-MX6Q_PAD_EIM_DA3__SRC_BT_CFG_3 371
-MX6Q_PAD_EIM_DA4__WEIM_WEIM_DA_A_4 372
-MX6Q_PAD_EIM_DA4__IPU1_DISP1_DAT_5 373
-MX6Q_PAD_EIM_DA4__IPU2_CSI1_D_5 374
-MX6Q_PAD_EIM_DA4__MIPI_CORE_DPHY_OUT_6 375
-MX6Q_PAD_EIM_DA4__ANATOP_USBPHY1_TX_EN 376
-MX6Q_PAD_EIM_DA4__GPIO_3_4 377
-MX6Q_PAD_EIM_DA4__TPSMP_HDATA_18 378
-MX6Q_PAD_EIM_DA4__SRC_BT_CFG_4 379
-MX6Q_PAD_EIM_DA5__WEIM_WEIM_DA_A_5 380
-MX6Q_PAD_EIM_DA5__IPU1_DISP1_DAT_4 381
-MX6Q_PAD_EIM_DA5__IPU2_CSI1_D_4 382
-MX6Q_PAD_EIM_DA5__MIPI_CORE_DPHY_OUT_7 383
-MX6Q_PAD_EIM_DA5__ANATOP_USBPHY1_TX_DP 384
-MX6Q_PAD_EIM_DA5__GPIO_3_5 385
-MX6Q_PAD_EIM_DA5__TPSMP_HDATA_19 386
-MX6Q_PAD_EIM_DA5__SRC_BT_CFG_5 387
-MX6Q_PAD_EIM_DA6__WEIM_WEIM_DA_A_6 388
-MX6Q_PAD_EIM_DA6__IPU1_DISP1_DAT_3 389
-MX6Q_PAD_EIM_DA6__IPU2_CSI1_D_3 390
-MX6Q_PAD_EIM_DA6__MIPI_CORE_DPHY_OUT_8 391
-MX6Q_PAD_EIM_DA6__ANATOP_USBPHY1_TX_DN 392
-MX6Q_PAD_EIM_DA6__GPIO_3_6 393
-MX6Q_PAD_EIM_DA6__TPSMP_HDATA_20 394
-MX6Q_PAD_EIM_DA6__SRC_BT_CFG_6 395
-MX6Q_PAD_EIM_DA7__WEIM_WEIM_DA_A_7 396
-MX6Q_PAD_EIM_DA7__IPU1_DISP1_DAT_2 397
-MX6Q_PAD_EIM_DA7__IPU2_CSI1_D_2 398
-MX6Q_PAD_EIM_DA7__MIPI_CORE_DPHY_OUT_9 399
-MX6Q_PAD_EIM_DA7__GPIO_3_7 400
-MX6Q_PAD_EIM_DA7__TPSMP_HDATA_21 401
-MX6Q_PAD_EIM_DA7__SRC_BT_CFG_7 402
-MX6Q_PAD_EIM_DA8__WEIM_WEIM_DA_A_8 403
-MX6Q_PAD_EIM_DA8__IPU1_DISP1_DAT_1 404
-MX6Q_PAD_EIM_DA8__IPU2_CSI1_D_1 405
-MX6Q_PAD_EIM_DA8__MIPI_CORE_DPHY_OUT_10 406
-MX6Q_PAD_EIM_DA8__GPIO_3_8 407
-MX6Q_PAD_EIM_DA8__TPSMP_HDATA_22 408
-MX6Q_PAD_EIM_DA8__SRC_BT_CFG_8 409
-MX6Q_PAD_EIM_DA9__WEIM_WEIM_DA_A_9 410
-MX6Q_PAD_EIM_DA9__IPU1_DISP1_DAT_0 411
-MX6Q_PAD_EIM_DA9__IPU2_CSI1_D_0 412
-MX6Q_PAD_EIM_DA9__MIPI_CORE_DPHY_OUT_11 413
-MX6Q_PAD_EIM_DA9__GPIO_3_9 414
-MX6Q_PAD_EIM_DA9__TPSMP_HDATA_23 415
-MX6Q_PAD_EIM_DA9__SRC_BT_CFG_9 416
-MX6Q_PAD_EIM_DA10__WEIM_WEIM_DA_A_10 417
-MX6Q_PAD_EIM_DA10__IPU1_DI1_PIN15 418
-MX6Q_PAD_EIM_DA10__IPU2_CSI1_DATA_EN 419
-MX6Q_PAD_EIM_DA10__MIPI_CORE_DPHY_OUT12 420
-MX6Q_PAD_EIM_DA10__GPIO_3_10 421
-MX6Q_PAD_EIM_DA10__TPSMP_HDATA_24 422
-MX6Q_PAD_EIM_DA10__SRC_BT_CFG_10 423
-MX6Q_PAD_EIM_DA11__WEIM_WEIM_DA_A_11 424
-MX6Q_PAD_EIM_DA11__IPU1_DI1_PIN2 425
-MX6Q_PAD_EIM_DA11__IPU2_CSI1_HSYNC 426
-MX6Q_PAD_EIM_DA11__MIPI_CORE_DPHY_OUT13 427
-MX6Q_PAD_EIM_DA11__SDMA_DBG_EVT_CHN_6 428
-MX6Q_PAD_EIM_DA11__GPIO_3_11 429
-MX6Q_PAD_EIM_DA11__TPSMP_HDATA_25 430
-MX6Q_PAD_EIM_DA11__SRC_BT_CFG_11 431
-MX6Q_PAD_EIM_DA12__WEIM_WEIM_DA_A_12 432
-MX6Q_PAD_EIM_DA12__IPU1_DI1_PIN3 433
-MX6Q_PAD_EIM_DA12__IPU2_CSI1_VSYNC 434
-MX6Q_PAD_EIM_DA12__MIPI_CORE_DPHY_OUT14 435
-MX6Q_PAD_EIM_DA12__SDMA_DEBUG_EVT_CHN_3 436
-MX6Q_PAD_EIM_DA12__GPIO_3_12 437
-MX6Q_PAD_EIM_DA12__TPSMP_HDATA_26 438
-MX6Q_PAD_EIM_DA12__SRC_BT_CFG_12 439
-MX6Q_PAD_EIM_DA13__WEIM_WEIM_DA_A_13 440
-MX6Q_PAD_EIM_DA13__IPU1_DI1_D0_CS 441
-MX6Q_PAD_EIM_DA13__CCM_DI1_EXT_CLK 442
-MX6Q_PAD_EIM_DA13__MIPI_CORE_DPHY_OUT15 443
-MX6Q_PAD_EIM_DA13__SDMA_DEBUG_EVT_CHN_4 444
-MX6Q_PAD_EIM_DA13__GPIO_3_13 445
-MX6Q_PAD_EIM_DA13__TPSMP_HDATA_27 446
-MX6Q_PAD_EIM_DA13__SRC_BT_CFG_13 447
-MX6Q_PAD_EIM_DA14__WEIM_WEIM_DA_A_14 448
-MX6Q_PAD_EIM_DA14__IPU1_DI1_D1_CS 449
-MX6Q_PAD_EIM_DA14__CCM_DI0_EXT_CLK 450
-MX6Q_PAD_EIM_DA14__MIPI_CORE_DPHY_OUT16 451
-MX6Q_PAD_EIM_DA14__SDMA_DEBUG_EVT_CHN_5 452
-MX6Q_PAD_EIM_DA14__GPIO_3_14 453
-MX6Q_PAD_EIM_DA14__TPSMP_HDATA_28 454
-MX6Q_PAD_EIM_DA14__SRC_BT_CFG_14 455
-MX6Q_PAD_EIM_DA15__WEIM_WEIM_DA_A_15 456
-MX6Q_PAD_EIM_DA15__IPU1_DI1_PIN1 457
-MX6Q_PAD_EIM_DA15__IPU1_DI1_PIN4 458
-MX6Q_PAD_EIM_DA15__MIPI_CORE_DPHY_OUT17 459
-MX6Q_PAD_EIM_DA15__GPIO_3_15 460
-MX6Q_PAD_EIM_DA15__TPSMP_HDATA_29 461
-MX6Q_PAD_EIM_DA15__SRC_BT_CFG_15 462
-MX6Q_PAD_EIM_WAIT__WEIM_WEIM_WAIT 463
-MX6Q_PAD_EIM_WAIT__WEIM_WEIM_DTACK_B 464
-MX6Q_PAD_EIM_WAIT__GPIO_5_0 465
-MX6Q_PAD_EIM_WAIT__TPSMP_HDATA_30 466
-MX6Q_PAD_EIM_WAIT__SRC_BT_CFG_25 467
-MX6Q_PAD_EIM_BCLK__WEIM_WEIM_BCLK 468
-MX6Q_PAD_EIM_BCLK__IPU1_DI1_PIN16 469
-MX6Q_PAD_EIM_BCLK__GPIO_6_31 470
-MX6Q_PAD_EIM_BCLK__TPSMP_HDATA_31 471
-MX6Q_PAD_DI0_DISP_CLK__IPU1_DI0_DSP_CLK 472
-MX6Q_PAD_DI0_DISP_CLK__IPU2_DI0_DSP_CLK 473
-MX6Q_PAD_DI0_DISP_CLK__MIPI_CR_DPY_OT28 474
-MX6Q_PAD_DI0_DISP_CLK__SDMA_DBG_CR_STA0 475
-MX6Q_PAD_DI0_DISP_CLK__GPIO_4_16 476
-MX6Q_PAD_DI0_DISP_CLK__MMDC_DEBUG_0 477
-MX6Q_PAD_DI0_PIN15__IPU1_DI0_PIN15 478
-MX6Q_PAD_DI0_PIN15__IPU2_DI0_PIN15 479
-MX6Q_PAD_DI0_PIN15__AUDMUX_AUD6_TXC 480
-MX6Q_PAD_DI0_PIN15__MIPI_CR_DPHY_OUT_29 481
-MX6Q_PAD_DI0_PIN15__SDMA_DBG_CORE_STA_1 482
-MX6Q_PAD_DI0_PIN15__GPIO_4_17 483
-MX6Q_PAD_DI0_PIN15__MMDC_MMDC_DEBUG_1 484
-MX6Q_PAD_DI0_PIN2__IPU1_DI0_PIN2 485
-MX6Q_PAD_DI0_PIN2__IPU2_DI0_PIN2 486
-MX6Q_PAD_DI0_PIN2__AUDMUX_AUD6_TXD 487
-MX6Q_PAD_DI0_PIN2__MIPI_CR_DPHY_OUT_30 488
-MX6Q_PAD_DI0_PIN2__SDMA_DBG_CORE_STA_2 489
-MX6Q_PAD_DI0_PIN2__GPIO_4_18 490
-MX6Q_PAD_DI0_PIN2__MMDC_DEBUG_2 491
-MX6Q_PAD_DI0_PIN2__PL301_PER1_HADDR_9 492
-MX6Q_PAD_DI0_PIN3__IPU1_DI0_PIN3 493
-MX6Q_PAD_DI0_PIN3__IPU2_DI0_PIN3 494
-MX6Q_PAD_DI0_PIN3__AUDMUX_AUD6_TXFS 495
-MX6Q_PAD_DI0_PIN3__MIPI_CORE_DPHY_OUT31 496
-MX6Q_PAD_DI0_PIN3__SDMA_DBG_CORE_STA_3 497
-MX6Q_PAD_DI0_PIN3__GPIO_4_19 498
-MX6Q_PAD_DI0_PIN3__MMDC_MMDC_DEBUG_3 499
-MX6Q_PAD_DI0_PIN3__PL301_PER1_HADDR_10 500
-MX6Q_PAD_DI0_PIN4__IPU1_DI0_PIN4 501
-MX6Q_PAD_DI0_PIN4__IPU2_DI0_PIN4 502
-MX6Q_PAD_DI0_PIN4__AUDMUX_AUD6_RXD 503
-MX6Q_PAD_DI0_PIN4__USDHC1_WP 504
-MX6Q_PAD_DI0_PIN4__SDMA_DEBUG_YIELD 505
-MX6Q_PAD_DI0_PIN4__GPIO_4_20 506
-MX6Q_PAD_DI0_PIN4__MMDC_MMDC_DEBUG_4 507
-MX6Q_PAD_DI0_PIN4__PL301_PER1_HADDR_11 508
-MX6Q_PAD_DISP0_DAT0__IPU1_DISP0_DAT_0 509
-MX6Q_PAD_DISP0_DAT0__IPU2_DISP0_DAT_0 510
-MX6Q_PAD_DISP0_DAT0__ECSPI3_SCLK 511
-MX6Q_PAD_DISP0_DAT0__USDHC1_USDHC_DBG_0 512
-MX6Q_PAD_DISP0_DAT0__SDMA_DBG_CORE_RUN 513
-MX6Q_PAD_DISP0_DAT0__GPIO_4_21 514
-MX6Q_PAD_DISP0_DAT0__MMDC_MMDC_DEBUG_5 515
-MX6Q_PAD_DISP0_DAT1__IPU1_DISP0_DAT_1 516
-MX6Q_PAD_DISP0_DAT1__IPU2_DISP0_DAT_1 517
-MX6Q_PAD_DISP0_DAT1__ECSPI3_MOSI 518
-MX6Q_PAD_DISP0_DAT1__USDHC1_USDHC_DBG_1 519
-MX6Q_PAD_DISP0_DAT1__SDMA_DBG_EVT_CHNSL 520
-MX6Q_PAD_DISP0_DAT1__GPIO_4_22 521
-MX6Q_PAD_DISP0_DAT1__MMDC_DEBUG_6 522
-MX6Q_PAD_DISP0_DAT1__PL301_PER1_HADR_12 523
-MX6Q_PAD_DISP0_DAT2__IPU1_DISP0_DAT_2 524
-MX6Q_PAD_DISP0_DAT2__IPU2_DISP0_DAT_2 525
-MX6Q_PAD_DISP0_DAT2__ECSPI3_MISO 526
-MX6Q_PAD_DISP0_DAT2__USDHC1_USDHC_DBG_2 527
-MX6Q_PAD_DISP0_DAT2__SDMA_DEBUG_MODE 528
-MX6Q_PAD_DISP0_DAT2__GPIO_4_23 529
-MX6Q_PAD_DISP0_DAT2__MMDC_DEBUG_7 530
-MX6Q_PAD_DISP0_DAT2__PL301_PER1_HADR_13 531
-MX6Q_PAD_DISP0_DAT3__IPU1_DISP0_DAT_3 532
-MX6Q_PAD_DISP0_DAT3__IPU2_DISP0_DAT_3 533
-MX6Q_PAD_DISP0_DAT3__ECSPI3_SS0 534
-MX6Q_PAD_DISP0_DAT3__USDHC1_USDHC_DBG_3 535
-MX6Q_PAD_DISP0_DAT3__SDMA_DBG_BUS_ERROR 536
-MX6Q_PAD_DISP0_DAT3__GPIO_4_24 537
-MX6Q_PAD_DISP0_DAT3__MMDC_MMDC_DBG_8 538
-MX6Q_PAD_DISP0_DAT3__PL301_PER1_HADR_14 539
-MX6Q_PAD_DISP0_DAT4__IPU1_DISP0_DAT_4 540
-MX6Q_PAD_DISP0_DAT4__IPU2_DISP0_DAT_4 541
-MX6Q_PAD_DISP0_DAT4__ECSPI3_SS1 542
-MX6Q_PAD_DISP0_DAT4__USDHC1_USDHC_DBG_4 543
-MX6Q_PAD_DISP0_DAT4__SDMA_DEBUG_BUS_RWB 544
-MX6Q_PAD_DISP0_DAT4__GPIO_4_25 545
-MX6Q_PAD_DISP0_DAT4__MMDC_MMDC_DEBUG_9 546
-MX6Q_PAD_DISP0_DAT4__PL301_PER1_HADR_15 547
-MX6Q_PAD_DISP0_DAT5__IPU1_DISP0_DAT_5 548
-MX6Q_PAD_DISP0_DAT5__IPU2_DISP0_DAT_5 549
-MX6Q_PAD_DISP0_DAT5__ECSPI3_SS2 550
-MX6Q_PAD_DISP0_DAT5__AUDMUX_AUD6_RXFS 551
-MX6Q_PAD_DISP0_DAT5__SDMA_DBG_MCH_DMBUS 552
-MX6Q_PAD_DISP0_DAT5__GPIO_4_26 553
-MX6Q_PAD_DISP0_DAT5__MMDC_DEBUG_10 554
-MX6Q_PAD_DISP0_DAT5__PL301_PER1_HADR_16 555
-MX6Q_PAD_DISP0_DAT6__IPU1_DISP0_DAT_6 556
-MX6Q_PAD_DISP0_DAT6__IPU2_DISP0_DAT_6 557
-MX6Q_PAD_DISP0_DAT6__ECSPI3_SS3 558
-MX6Q_PAD_DISP0_DAT6__AUDMUX_AUD6_RXC 559
-MX6Q_PAD_DISP0_DAT6__SDMA_DBG_RTBUF_WRT 560
-MX6Q_PAD_DISP0_DAT6__GPIO_4_27 561
-MX6Q_PAD_DISP0_DAT6__MMDC_DEBUG_11 562
-MX6Q_PAD_DISP0_DAT6__PL301_PER1_HADR_17 563
-MX6Q_PAD_DISP0_DAT7__IPU1_DISP0_DAT_7 564
-MX6Q_PAD_DISP0_DAT7__IPU2_DISP0_DAT_7 565
-MX6Q_PAD_DISP0_DAT7__ECSPI3_RDY 566
-MX6Q_PAD_DISP0_DAT7__USDHC1_USDHC_DBG_5 567
-MX6Q_PAD_DISP0_DAT7__SDMA_DBG_EVT_CHN_0 568
-MX6Q_PAD_DISP0_DAT7__GPIO_4_28 569
-MX6Q_PAD_DISP0_DAT7__MMDC_DEBUG_12 570
-MX6Q_PAD_DISP0_DAT7__PL301_PER1_HADR_18 571
-MX6Q_PAD_DISP0_DAT8__IPU1_DISP0_DAT_8 572
-MX6Q_PAD_DISP0_DAT8__IPU2_DISP0_DAT_8 573
-MX6Q_PAD_DISP0_DAT8__PWM1_PWMO 574
-MX6Q_PAD_DISP0_DAT8__WDOG1_WDOG_B 575
-MX6Q_PAD_DISP0_DAT8__SDMA_DBG_EVT_CHN_1 576
-MX6Q_PAD_DISP0_DAT8__GPIO_4_29 577
-MX6Q_PAD_DISP0_DAT8__MMDC_DEBUG_13 578
-MX6Q_PAD_DISP0_DAT8__PL301_PER1_HADR_19 579
-MX6Q_PAD_DISP0_DAT9__IPU1_DISP0_DAT_9 580
-MX6Q_PAD_DISP0_DAT9__IPU2_DISP0_DAT_9 581
-MX6Q_PAD_DISP0_DAT9__PWM2_PWMO 582
-MX6Q_PAD_DISP0_DAT9__WDOG2_WDOG_B 583
-MX6Q_PAD_DISP0_DAT9__SDMA_DBG_EVT_CHN_2 584
-MX6Q_PAD_DISP0_DAT9__GPIO_4_30 585
-MX6Q_PAD_DISP0_DAT9__MMDC_DEBUG_14 586
-MX6Q_PAD_DISP0_DAT9__PL301_PER1_HADR_20 587
-MX6Q_PAD_DISP0_DAT10__IPU1_DISP0_DAT_10 588
-MX6Q_PAD_DISP0_DAT10__IPU2_DISP0_DAT_10 589
-MX6Q_PAD_DISP0_DAT10__USDHC1_DBG_6 590
-MX6Q_PAD_DISP0_DAT10__SDMA_DBG_EVT_CHN3 591
-MX6Q_PAD_DISP0_DAT10__GPIO_4_31 592
-MX6Q_PAD_DISP0_DAT10__MMDC_DEBUG_15 593
-MX6Q_PAD_DISP0_DAT10__PL301_PER1_HADR21 594
-MX6Q_PAD_DISP0_DAT11__IPU1_DISP0_DAT_11 595
-MX6Q_PAD_DISP0_DAT11__IPU2_DISP0_DAT_11 596
-MX6Q_PAD_DISP0_DAT11__USDHC1_USDHC_DBG7 597
-MX6Q_PAD_DISP0_DAT11__SDMA_DBG_EVT_CHN4 598
-MX6Q_PAD_DISP0_DAT11__GPIO_5_5 599
-MX6Q_PAD_DISP0_DAT11__MMDC_DEBUG_16 600
-MX6Q_PAD_DISP0_DAT11__PL301_PER1_HADR22 601
-MX6Q_PAD_DISP0_DAT12__IPU1_DISP0_DAT_12 602
-MX6Q_PAD_DISP0_DAT12__IPU2_DISP0_DAT_12 603
-MX6Q_PAD_DISP0_DAT12__RESERVED_RESERVED 604
-MX6Q_PAD_DISP0_DAT12__SDMA_DBG_EVT_CHN5 605
-MX6Q_PAD_DISP0_DAT12__GPIO_5_6 606
-MX6Q_PAD_DISP0_DAT12__MMDC_DEBUG_17 607
-MX6Q_PAD_DISP0_DAT12__PL301_PER1_HADR23 608
-MX6Q_PAD_DISP0_DAT13__IPU1_DISP0_DAT_13 609
-MX6Q_PAD_DISP0_DAT13__IPU2_DISP0_DAT_13 610
-MX6Q_PAD_DISP0_DAT13__AUDMUX_AUD5_RXFS 611
-MX6Q_PAD_DISP0_DAT13__SDMA_DBG_EVT_CHN0 612
-MX6Q_PAD_DISP0_DAT13__GPIO_5_7 613
-MX6Q_PAD_DISP0_DAT13__MMDC_DEBUG_18 614
-MX6Q_PAD_DISP0_DAT13__PL301_PER1_HADR24 615
-MX6Q_PAD_DISP0_DAT14__IPU1_DISP0_DAT_14 616
-MX6Q_PAD_DISP0_DAT14__IPU2_DISP0_DAT_14 617
-MX6Q_PAD_DISP0_DAT14__AUDMUX_AUD5_RXC 618
-MX6Q_PAD_DISP0_DAT14__SDMA_DBG_EVT_CHN1 619
-MX6Q_PAD_DISP0_DAT14__GPIO_5_8 620
-MX6Q_PAD_DISP0_DAT14__MMDC_DEBUG_19 621
-MX6Q_PAD_DISP0_DAT15__IPU1_DISP0_DAT_15 622
-MX6Q_PAD_DISP0_DAT15__IPU2_DISP0_DAT_15 623
-MX6Q_PAD_DISP0_DAT15__ECSPI1_SS1 624
-MX6Q_PAD_DISP0_DAT15__ECSPI2_SS1 625
-MX6Q_PAD_DISP0_DAT15__SDMA_DBG_EVT_CHN2 626
-MX6Q_PAD_DISP0_DAT15__GPIO_5_9 627
-MX6Q_PAD_DISP0_DAT15__MMDC_DEBUG_20 628
-MX6Q_PAD_DISP0_DAT15__PL301_PER1_HADR25 629
-MX6Q_PAD_DISP0_DAT16__IPU1_DISP0_DAT_16 630
-MX6Q_PAD_DISP0_DAT16__IPU2_DISP0_DAT_16 631
-MX6Q_PAD_DISP0_DAT16__ECSPI2_MOSI 632
-MX6Q_PAD_DISP0_DAT16__AUDMUX_AUD5_TXC 633
-MX6Q_PAD_DISP0_DAT16__SDMA_EXT_EVENT_0 634
-MX6Q_PAD_DISP0_DAT16__GPIO_5_10 635
-MX6Q_PAD_DISP0_DAT16__MMDC_DEBUG_21 636
-MX6Q_PAD_DISP0_DAT16__PL301_PER1_HADR26 637
-MX6Q_PAD_DISP0_DAT17__IPU1_DISP0_DAT_17 638
-MX6Q_PAD_DISP0_DAT17__IPU2_DISP0_DAT_17 639
-MX6Q_PAD_DISP0_DAT17__ECSPI2_MISO 640
-MX6Q_PAD_DISP0_DAT17__AUDMUX_AUD5_TXD 641
-MX6Q_PAD_DISP0_DAT17__SDMA_EXT_EVENT_1 642
-MX6Q_PAD_DISP0_DAT17__GPIO_5_11 643
-MX6Q_PAD_DISP0_DAT17__MMDC_DEBUG_22 644
-MX6Q_PAD_DISP0_DAT17__PL301_PER1_HADR27 645
-MX6Q_PAD_DISP0_DAT18__IPU1_DISP0_DAT_18 646
-MX6Q_PAD_DISP0_DAT18__IPU2_DISP0_DAT_18 647
-MX6Q_PAD_DISP0_DAT18__ECSPI2_SS0 648
-MX6Q_PAD_DISP0_DAT18__AUDMUX_AUD5_TXFS 649
-MX6Q_PAD_DISP0_DAT18__AUDMUX_AUD4_RXFS 650
-MX6Q_PAD_DISP0_DAT18__GPIO_5_12 651
-MX6Q_PAD_DISP0_DAT18__MMDC_DEBUG_23 652
-MX6Q_PAD_DISP0_DAT18__WEIM_WEIM_CS_2 653
-MX6Q_PAD_DISP0_DAT19__IPU1_DISP0_DAT_19 654
-MX6Q_PAD_DISP0_DAT19__IPU2_DISP0_DAT_19 655
-MX6Q_PAD_DISP0_DAT19__ECSPI2_SCLK 656
-MX6Q_PAD_DISP0_DAT19__AUDMUX_AUD5_RXD 657
-MX6Q_PAD_DISP0_DAT19__AUDMUX_AUD4_RXC 658
-MX6Q_PAD_DISP0_DAT19__GPIO_5_13 659
-MX6Q_PAD_DISP0_DAT19__MMDC_DEBUG_24 660
-MX6Q_PAD_DISP0_DAT19__WEIM_WEIM_CS_3 661
-MX6Q_PAD_DISP0_DAT20__IPU1_DISP0_DAT_20 662
-MX6Q_PAD_DISP0_DAT20__IPU2_DISP0_DAT_20 663
-MX6Q_PAD_DISP0_DAT20__ECSPI1_SCLK 664
-MX6Q_PAD_DISP0_DAT20__AUDMUX_AUD4_TXC 665
-MX6Q_PAD_DISP0_DAT20__SDMA_DBG_EVT_CHN7 666
-MX6Q_PAD_DISP0_DAT20__GPIO_5_14 667
-MX6Q_PAD_DISP0_DAT20__MMDC_DEBUG_25 668
-MX6Q_PAD_DISP0_DAT20__PL301_PER1_HADR28 669
-MX6Q_PAD_DISP0_DAT21__IPU1_DISP0_DAT_21 670
-MX6Q_PAD_DISP0_DAT21__IPU2_DISP0_DAT_21 671
-MX6Q_PAD_DISP0_DAT21__ECSPI1_MOSI 672
-MX6Q_PAD_DISP0_DAT21__AUDMUX_AUD4_TXD 673
-MX6Q_PAD_DISP0_DAT21__SDMA_DBG_BUS_DEV0 674
-MX6Q_PAD_DISP0_DAT21__GPIO_5_15 675
-MX6Q_PAD_DISP0_DAT21__MMDC_DEBUG_26 676
-MX6Q_PAD_DISP0_DAT21__PL301_PER1_HADR29 677
-MX6Q_PAD_DISP0_DAT22__IPU1_DISP0_DAT_22 678
-MX6Q_PAD_DISP0_DAT22__IPU2_DISP0_DAT_22 679
-MX6Q_PAD_DISP0_DAT22__ECSPI1_MISO 680
-MX6Q_PAD_DISP0_DAT22__AUDMUX_AUD4_TXFS 681
-MX6Q_PAD_DISP0_DAT22__SDMA_DBG_BUS_DEV1 682
-MX6Q_PAD_DISP0_DAT22__GPIO_5_16 683
-MX6Q_PAD_DISP0_DAT22__MMDC_DEBUG_27 684
-MX6Q_PAD_DISP0_DAT22__PL301_PER1_HADR30 685
-MX6Q_PAD_DISP0_DAT23__IPU1_DISP0_DAT_23 686
-MX6Q_PAD_DISP0_DAT23__IPU2_DISP0_DAT_23 687
-MX6Q_PAD_DISP0_DAT23__ECSPI1_SS0 688
-MX6Q_PAD_DISP0_DAT23__AUDMUX_AUD4_RXD 689
-MX6Q_PAD_DISP0_DAT23__SDMA_DBG_BUS_DEV2 690
-MX6Q_PAD_DISP0_DAT23__GPIO_5_17 691
-MX6Q_PAD_DISP0_DAT23__MMDC_DEBUG_28 692
-MX6Q_PAD_DISP0_DAT23__PL301_PER1_HADR31 693
-MX6Q_PAD_ENET_MDIO__RESERVED_RESERVED 694
-MX6Q_PAD_ENET_MDIO__ENET_MDIO 695
-MX6Q_PAD_ENET_MDIO__ESAI1_SCKR 696
-MX6Q_PAD_ENET_MDIO__SDMA_DEBUG_BUS_DEV3 697
-MX6Q_PAD_ENET_MDIO__ENET_1588_EVT1_OUT 698
-MX6Q_PAD_ENET_MDIO__GPIO_1_22 699
-MX6Q_PAD_ENET_MDIO__SPDIF_PLOCK 700
-MX6Q_PAD_ENET_REF_CLK__RESERVED_RSRVED 701
-MX6Q_PAD_ENET_REF_CLK__ENET_TX_CLK 702
-MX6Q_PAD_ENET_REF_CLK__ESAI1_FSR 703
-MX6Q_PAD_ENET_REF_CLK__SDMA_DBGBUS_DEV4 704
-MX6Q_PAD_ENET_REF_CLK__GPIO_1_23 705
-MX6Q_PAD_ENET_REF_CLK__SPDIF_SRCLK 706
-MX6Q_PAD_ENET_REF_CLK__USBPHY1_RX_SQH 707
-MX6Q_PAD_ENET_RX_ER__ENET_RX_ER 708
-MX6Q_PAD_ENET_RX_ER__ESAI1_HCKR 709
-MX6Q_PAD_ENET_RX_ER__SPDIF_IN1 710
-MX6Q_PAD_ENET_RX_ER__ENET_1588_EVT2_OUT 711
-MX6Q_PAD_ENET_RX_ER__GPIO_1_24 712
-MX6Q_PAD_ENET_RX_ER__PHY_TDI 713
-MX6Q_PAD_ENET_RX_ER__USBPHY1_RX_HS_RXD 714
-MX6Q_PAD_ENET_CRS_DV__RESERVED_RSRVED 715
-MX6Q_PAD_ENET_CRS_DV__ENET_RX_EN 716
-MX6Q_PAD_ENET_CRS_DV__ESAI1_SCKT 717
-MX6Q_PAD_ENET_CRS_DV__SPDIF_EXTCLK 718
-MX6Q_PAD_ENET_CRS_DV__GPIO_1_25 719
-MX6Q_PAD_ENET_CRS_DV__PHY_TDO 720
-MX6Q_PAD_ENET_CRS_DV__USBPHY1_RX_FS_RXD 721
-MX6Q_PAD_ENET_RXD1__MLB_MLBSIG 722
-MX6Q_PAD_ENET_RXD1__ENET_RDATA_1 723
-MX6Q_PAD_ENET_RXD1__ESAI1_FST 724
-MX6Q_PAD_ENET_RXD1__ENET_1588_EVT3_OUT 725
-MX6Q_PAD_ENET_RXD1__GPIO_1_26 726
-MX6Q_PAD_ENET_RXD1__PHY_TCK 727
-MX6Q_PAD_ENET_RXD1__USBPHY1_RX_DISCON 728
-MX6Q_PAD_ENET_RXD0__OSC32K_32K_OUT 729
-MX6Q_PAD_ENET_RXD0__ENET_RDATA_0 730
-MX6Q_PAD_ENET_RXD0__ESAI1_HCKT 731
-MX6Q_PAD_ENET_RXD0__SPDIF_OUT1 732
-MX6Q_PAD_ENET_RXD0__GPIO_1_27 733
-MX6Q_PAD_ENET_RXD0__PHY_TMS 734
-MX6Q_PAD_ENET_RXD0__USBPHY1_PLL_CK20DIV 735
-MX6Q_PAD_ENET_TX_EN__RESERVED_RSRVED 736
-MX6Q_PAD_ENET_TX_EN__ENET_TX_EN 737
-MX6Q_PAD_ENET_TX_EN__ESAI1_TX3_RX2 738
-MX6Q_PAD_ENET_TX_EN__GPIO_1_28 739
-MX6Q_PAD_ENET_TX_EN__SATA_PHY_TDI 740
-MX6Q_PAD_ENET_TX_EN__USBPHY2_RX_SQH 741
-MX6Q_PAD_ENET_TXD1__MLB_MLBCLK 742
-MX6Q_PAD_ENET_TXD1__ENET_TDATA_1 743
-MX6Q_PAD_ENET_TXD1__ESAI1_TX2_RX3 744
-MX6Q_PAD_ENET_TXD1__ENET_1588_EVENT0_IN 745
-MX6Q_PAD_ENET_TXD1__GPIO_1_29 746
-MX6Q_PAD_ENET_TXD1__SATA_PHY_TDO 747
-MX6Q_PAD_ENET_TXD1__USBPHY2_RX_HS_RXD 748
-MX6Q_PAD_ENET_TXD0__RESERVED_RSRVED 749
-MX6Q_PAD_ENET_TXD0__ENET_TDATA_0 750
-MX6Q_PAD_ENET_TXD0__ESAI1_TX4_RX1 751
-MX6Q_PAD_ENET_TXD0__GPIO_1_30 752
-MX6Q_PAD_ENET_TXD0__SATA_PHY_TCK 753
-MX6Q_PAD_ENET_TXD0__USBPHY2_RX_FS_RXD 754
-MX6Q_PAD_ENET_MDC__MLB_MLBDAT 755
-MX6Q_PAD_ENET_MDC__ENET_MDC 756
-MX6Q_PAD_ENET_MDC__ESAI1_TX5_RX0 757
-MX6Q_PAD_ENET_MDC__ENET_1588_EVENT1_IN 758
-MX6Q_PAD_ENET_MDC__GPIO_1_31 759
-MX6Q_PAD_ENET_MDC__SATA_PHY_TMS 760
-MX6Q_PAD_ENET_MDC__USBPHY2_RX_DISCON 761
-MX6Q_PAD_DRAM_D40__MMDC_DRAM_D_40 762
-MX6Q_PAD_DRAM_D41__MMDC_DRAM_D_41 763
-MX6Q_PAD_DRAM_D42__MMDC_DRAM_D_42 764
-MX6Q_PAD_DRAM_D43__MMDC_DRAM_D_43 765
-MX6Q_PAD_DRAM_D44__MMDC_DRAM_D_44 766
-MX6Q_PAD_DRAM_D45__MMDC_DRAM_D_45 767
-MX6Q_PAD_DRAM_D46__MMDC_DRAM_D_46 768
-MX6Q_PAD_DRAM_D47__MMDC_DRAM_D_47 769
-MX6Q_PAD_DRAM_SDQS5__MMDC_DRAM_SDQS_5 770
-MX6Q_PAD_DRAM_DQM5__MMDC_DRAM_DQM_5 771
-MX6Q_PAD_DRAM_D32__MMDC_DRAM_D_32 772
-MX6Q_PAD_DRAM_D33__MMDC_DRAM_D_33 773
-MX6Q_PAD_DRAM_D34__MMDC_DRAM_D_34 774
-MX6Q_PAD_DRAM_D35__MMDC_DRAM_D_35 775
-MX6Q_PAD_DRAM_D36__MMDC_DRAM_D_36 776
-MX6Q_PAD_DRAM_D37__MMDC_DRAM_D_37 777
-MX6Q_PAD_DRAM_D38__MMDC_DRAM_D_38 778
-MX6Q_PAD_DRAM_D39__MMDC_DRAM_D_39 779
-MX6Q_PAD_DRAM_DQM4__MMDC_DRAM_DQM_4 780
-MX6Q_PAD_DRAM_SDQS4__MMDC_DRAM_SDQS_4 781
-MX6Q_PAD_DRAM_D24__MMDC_DRAM_D_24 782
-MX6Q_PAD_DRAM_D25__MMDC_DRAM_D_25 783
-MX6Q_PAD_DRAM_D26__MMDC_DRAM_D_26 784
-MX6Q_PAD_DRAM_D27__MMDC_DRAM_D_27 785
-MX6Q_PAD_DRAM_D28__MMDC_DRAM_D_28 786
-MX6Q_PAD_DRAM_D29__MMDC_DRAM_D_29 787
-MX6Q_PAD_DRAM_SDQS3__MMDC_DRAM_SDQS_3 788
-MX6Q_PAD_DRAM_D30__MMDC_DRAM_D_30 789
-MX6Q_PAD_DRAM_D31__MMDC_DRAM_D_31 790
-MX6Q_PAD_DRAM_DQM3__MMDC_DRAM_DQM_3 791
-MX6Q_PAD_DRAM_D16__MMDC_DRAM_D_16 792
-MX6Q_PAD_DRAM_D17__MMDC_DRAM_D_17 793
-MX6Q_PAD_DRAM_D18__MMDC_DRAM_D_18 794
-MX6Q_PAD_DRAM_D19__MMDC_DRAM_D_19 795
-MX6Q_PAD_DRAM_D20__MMDC_DRAM_D_20 796
-MX6Q_PAD_DRAM_D21__MMDC_DRAM_D_21 797
-MX6Q_PAD_DRAM_D22__MMDC_DRAM_D_22 798
-MX6Q_PAD_DRAM_SDQS2__MMDC_DRAM_SDQS_2 799
-MX6Q_PAD_DRAM_D23__MMDC_DRAM_D_23 800
-MX6Q_PAD_DRAM_DQM2__MMDC_DRAM_DQM_2 801
-MX6Q_PAD_DRAM_A0__MMDC_DRAM_A_0 802
-MX6Q_PAD_DRAM_A1__MMDC_DRAM_A_1 803
-MX6Q_PAD_DRAM_A2__MMDC_DRAM_A_2 804
-MX6Q_PAD_DRAM_A3__MMDC_DRAM_A_3 805
-MX6Q_PAD_DRAM_A4__MMDC_DRAM_A_4 806
-MX6Q_PAD_DRAM_A5__MMDC_DRAM_A_5 807
-MX6Q_PAD_DRAM_A6__MMDC_DRAM_A_6 808
-MX6Q_PAD_DRAM_A7__MMDC_DRAM_A_7 809
-MX6Q_PAD_DRAM_A8__MMDC_DRAM_A_8 810
-MX6Q_PAD_DRAM_A9__MMDC_DRAM_A_9 811
-MX6Q_PAD_DRAM_A10__MMDC_DRAM_A_10 812
-MX6Q_PAD_DRAM_A11__MMDC_DRAM_A_11 813
-MX6Q_PAD_DRAM_A12__MMDC_DRAM_A_12 814
-MX6Q_PAD_DRAM_A13__MMDC_DRAM_A_13 815
-MX6Q_PAD_DRAM_A14__MMDC_DRAM_A_14 816
-MX6Q_PAD_DRAM_A15__MMDC_DRAM_A_15 817
-MX6Q_PAD_DRAM_CAS__MMDC_DRAM_CAS 818
-MX6Q_PAD_DRAM_CS0__MMDC_DRAM_CS_0 819
-MX6Q_PAD_DRAM_CS1__MMDC_DRAM_CS_1 820
-MX6Q_PAD_DRAM_RAS__MMDC_DRAM_RAS 821
-MX6Q_PAD_DRAM_RESET__MMDC_DRAM_RESET 822
-MX6Q_PAD_DRAM_SDBA0__MMDC_DRAM_SDBA_0 823
-MX6Q_PAD_DRAM_SDBA1__MMDC_DRAM_SDBA_1 824
-MX6Q_PAD_DRAM_SDCLK_0__MMDC_DRAM_SDCLK0 825
-MX6Q_PAD_DRAM_SDBA2__MMDC_DRAM_SDBA_2 826
-MX6Q_PAD_DRAM_SDCKE0__MMDC_DRAM_SDCKE_0 827
-MX6Q_PAD_DRAM_SDCLK_1__MMDC_DRAM_SDCLK1 828
-MX6Q_PAD_DRAM_SDCKE1__MMDC_DRAM_SDCKE_1 829
-MX6Q_PAD_DRAM_SDODT0__MMDC_DRAM_ODT_0 830
-MX6Q_PAD_DRAM_SDODT1__MMDC_DRAM_ODT_1 831
-MX6Q_PAD_DRAM_SDWE__MMDC_DRAM_SDWE 832
-MX6Q_PAD_DRAM_D0__MMDC_DRAM_D_0 833
-MX6Q_PAD_DRAM_D1__MMDC_DRAM_D_1 834
-MX6Q_PAD_DRAM_D2__MMDC_DRAM_D_2 835
-MX6Q_PAD_DRAM_D3__MMDC_DRAM_D_3 836
-MX6Q_PAD_DRAM_D4__MMDC_DRAM_D_4 837
-MX6Q_PAD_DRAM_D5__MMDC_DRAM_D_5 838
-MX6Q_PAD_DRAM_SDQS0__MMDC_DRAM_SDQS_0 839
-MX6Q_PAD_DRAM_D6__MMDC_DRAM_D_6 840
-MX6Q_PAD_DRAM_D7__MMDC_DRAM_D_7 841
-MX6Q_PAD_DRAM_DQM0__MMDC_DRAM_DQM_0 842
-MX6Q_PAD_DRAM_D8__MMDC_DRAM_D_8 843
-MX6Q_PAD_DRAM_D9__MMDC_DRAM_D_9 844
-MX6Q_PAD_DRAM_D10__MMDC_DRAM_D_10 845
-MX6Q_PAD_DRAM_D11__MMDC_DRAM_D_11 846
-MX6Q_PAD_DRAM_D12__MMDC_DRAM_D_12 847
-MX6Q_PAD_DRAM_D13__MMDC_DRAM_D_13 848
-MX6Q_PAD_DRAM_D14__MMDC_DRAM_D_14 849
-MX6Q_PAD_DRAM_SDQS1__MMDC_DRAM_SDQS_1 850
-MX6Q_PAD_DRAM_D15__MMDC_DRAM_D_15 851
-MX6Q_PAD_DRAM_DQM1__MMDC_DRAM_DQM_1 852
-MX6Q_PAD_DRAM_D48__MMDC_DRAM_D_48 853
-MX6Q_PAD_DRAM_D49__MMDC_DRAM_D_49 854
-MX6Q_PAD_DRAM_D50__MMDC_DRAM_D_50 855
-MX6Q_PAD_DRAM_D51__MMDC_DRAM_D_51 856
-MX6Q_PAD_DRAM_D52__MMDC_DRAM_D_52 857
-MX6Q_PAD_DRAM_D53__MMDC_DRAM_D_53 858
-MX6Q_PAD_DRAM_D54__MMDC_DRAM_D_54 859
-MX6Q_PAD_DRAM_D55__MMDC_DRAM_D_55 860
-MX6Q_PAD_DRAM_SDQS6__MMDC_DRAM_SDQS_6 861
-MX6Q_PAD_DRAM_DQM6__MMDC_DRAM_DQM_6 862
-MX6Q_PAD_DRAM_D56__MMDC_DRAM_D_56 863
-MX6Q_PAD_DRAM_SDQS7__MMDC_DRAM_SDQS_7 864
-MX6Q_PAD_DRAM_D57__MMDC_DRAM_D_57 865
-MX6Q_PAD_DRAM_D58__MMDC_DRAM_D_58 866
-MX6Q_PAD_DRAM_D59__MMDC_DRAM_D_59 867
-MX6Q_PAD_DRAM_D60__MMDC_DRAM_D_60 868
-MX6Q_PAD_DRAM_DQM7__MMDC_DRAM_DQM_7 869
-MX6Q_PAD_DRAM_D61__MMDC_DRAM_D_61 870
-MX6Q_PAD_DRAM_D62__MMDC_DRAM_D_62 871
-MX6Q_PAD_DRAM_D63__MMDC_DRAM_D_63 872
-MX6Q_PAD_KEY_COL0__ECSPI1_SCLK 873
-MX6Q_PAD_KEY_COL0__ENET_RDATA_3 874
-MX6Q_PAD_KEY_COL0__AUDMUX_AUD5_TXC 875
-MX6Q_PAD_KEY_COL0__KPP_COL_0 876
-MX6Q_PAD_KEY_COL0__UART4_TXD 877
-MX6Q_PAD_KEY_COL0__GPIO_4_6 878
-MX6Q_PAD_KEY_COL0__DCIC1_DCIC_OUT 879
-MX6Q_PAD_KEY_COL0__SRC_ANY_PU_RST 880
-MX6Q_PAD_KEY_ROW0__ECSPI1_MOSI 881
-MX6Q_PAD_KEY_ROW0__ENET_TDATA_3 882
-MX6Q_PAD_KEY_ROW0__AUDMUX_AUD5_TXD 883
-MX6Q_PAD_KEY_ROW0__KPP_ROW_0 884
-MX6Q_PAD_KEY_ROW0__UART4_RXD 885
-MX6Q_PAD_KEY_ROW0__GPIO_4_7 886
-MX6Q_PAD_KEY_ROW0__DCIC2_DCIC_OUT 887
-MX6Q_PAD_KEY_ROW0__PL301_PER1_HADR_0 888
-MX6Q_PAD_KEY_COL1__ECSPI1_MISO 889
-MX6Q_PAD_KEY_COL1__ENET_MDIO 890
-MX6Q_PAD_KEY_COL1__AUDMUX_AUD5_TXFS 891
-MX6Q_PAD_KEY_COL1__KPP_COL_1 892
-MX6Q_PAD_KEY_COL1__UART5_TXD 893
-MX6Q_PAD_KEY_COL1__GPIO_4_8 894
-MX6Q_PAD_KEY_COL1__USDHC1_VSELECT 895
-MX6Q_PAD_KEY_COL1__PL301MX_PER1_HADR_1 896
-MX6Q_PAD_KEY_ROW1__ECSPI1_SS0 897
-MX6Q_PAD_KEY_ROW1__ENET_COL 898
-MX6Q_PAD_KEY_ROW1__AUDMUX_AUD5_RXD 899
-MX6Q_PAD_KEY_ROW1__KPP_ROW_1 900
-MX6Q_PAD_KEY_ROW1__UART5_RXD 901
-MX6Q_PAD_KEY_ROW1__GPIO_4_9 902
-MX6Q_PAD_KEY_ROW1__USDHC2_VSELECT 903
-MX6Q_PAD_KEY_ROW1__PL301_PER1_HADDR_2 904
-MX6Q_PAD_KEY_COL2__ECSPI1_SS1 905
-MX6Q_PAD_KEY_COL2__ENET_RDATA_2 906
-MX6Q_PAD_KEY_COL2__CAN1_TXCAN 907
-MX6Q_PAD_KEY_COL2__KPP_COL_2 908
-MX6Q_PAD_KEY_COL2__ENET_MDC 909
-MX6Q_PAD_KEY_COL2__GPIO_4_10 910
-MX6Q_PAD_KEY_COL2__USBOH3_H1_PWRCTL_WKP 911
-MX6Q_PAD_KEY_COL2__PL301_PER1_HADDR_3 912
-MX6Q_PAD_KEY_ROW2__ECSPI1_SS2 913
-MX6Q_PAD_KEY_ROW2__ENET_TDATA_2 914
-MX6Q_PAD_KEY_ROW2__CAN1_RXCAN 915
-MX6Q_PAD_KEY_ROW2__KPP_ROW_2 916
-MX6Q_PAD_KEY_ROW2__USDHC2_VSELECT 917
-MX6Q_PAD_KEY_ROW2__GPIO_4_11 918
-MX6Q_PAD_KEY_ROW2__HDMI_TX_CEC_LINE 919
-MX6Q_PAD_KEY_ROW2__PL301_PER1_HADR_4 920
-MX6Q_PAD_KEY_COL3__ECSPI1_SS3 921
-MX6Q_PAD_KEY_COL3__ENET_CRS 922
-MX6Q_PAD_KEY_COL3__HDMI_TX_DDC_SCL 923
-MX6Q_PAD_KEY_COL3__KPP_COL_3 924
-MX6Q_PAD_KEY_COL3__I2C2_SCL 925
-MX6Q_PAD_KEY_COL3__GPIO_4_12 926
-MX6Q_PAD_KEY_COL3__SPDIF_IN1 927
-MX6Q_PAD_KEY_COL3__PL301_PER1_HADR_5 928
-MX6Q_PAD_KEY_ROW3__OSC32K_32K_OUT 929
-MX6Q_PAD_KEY_ROW3__ASRC_ASRC_EXT_CLK 930
-MX6Q_PAD_KEY_ROW3__HDMI_TX_DDC_SDA 931
-MX6Q_PAD_KEY_ROW3__KPP_ROW_3 932
-MX6Q_PAD_KEY_ROW3__I2C2_SDA 933
-MX6Q_PAD_KEY_ROW3__GPIO_4_13 934
-MX6Q_PAD_KEY_ROW3__USDHC1_VSELECT 935
-MX6Q_PAD_KEY_ROW3__PL301_PER1_HADR_6 936
-MX6Q_PAD_KEY_COL4__CAN2_TXCAN 937
-MX6Q_PAD_KEY_COL4__IPU1_SISG_4 938
-MX6Q_PAD_KEY_COL4__USBOH3_USBOTG_OC 939
-MX6Q_PAD_KEY_COL4__KPP_COL_4 940
-MX6Q_PAD_KEY_COL4__UART5_RTS 941
-MX6Q_PAD_KEY_COL4__GPIO_4_14 942
-MX6Q_PAD_KEY_COL4__MMDC_DEBUG_49 943
-MX6Q_PAD_KEY_COL4__PL301_PER1_HADDR_7 944
-MX6Q_PAD_KEY_ROW4__CAN2_RXCAN 945
-MX6Q_PAD_KEY_ROW4__IPU1_SISG_5 946
-MX6Q_PAD_KEY_ROW4__USBOH3_USBOTG_PWR 947
-MX6Q_PAD_KEY_ROW4__KPP_ROW_4 948
-MX6Q_PAD_KEY_ROW4__UART5_CTS 949
-MX6Q_PAD_KEY_ROW4__GPIO_4_15 950
-MX6Q_PAD_KEY_ROW4__MMDC_DEBUG_50 951
-MX6Q_PAD_KEY_ROW4__PL301_PER1_HADR_8 952
-MX6Q_PAD_GPIO_0__CCM_CLKO 953
-MX6Q_PAD_GPIO_0__KPP_COL_5 954
-MX6Q_PAD_GPIO_0__ASRC_ASRC_EXT_CLK 955
-MX6Q_PAD_GPIO_0__EPIT1_EPITO 956
-MX6Q_PAD_GPIO_0__GPIO_1_0 957
-MX6Q_PAD_GPIO_0__USBOH3_USBH1_PWR 958
-MX6Q_PAD_GPIO_0__SNVS_HP_WRAP_SNVS_VIO5 959
-MX6Q_PAD_GPIO_1__ESAI1_SCKR 960
-MX6Q_PAD_GPIO_1__WDOG2_WDOG_B 961
-MX6Q_PAD_GPIO_1__KPP_ROW_5 962
-MX6Q_PAD_GPIO_1__PWM2_PWMO 963
-MX6Q_PAD_GPIO_1__GPIO_1_1 964
-MX6Q_PAD_GPIO_1__USDHC1_CD 965
-MX6Q_PAD_GPIO_1__SRC_TESTER_ACK 966
-MX6Q_PAD_GPIO_9__ESAI1_FSR 967
-MX6Q_PAD_GPIO_9__WDOG1_WDOG_B 968
-MX6Q_PAD_GPIO_9__KPP_COL_6 969
-MX6Q_PAD_GPIO_9__CCM_REF_EN_B 970
-MX6Q_PAD_GPIO_9__PWM1_PWMO 971
-MX6Q_PAD_GPIO_9__GPIO_1_9 972
-MX6Q_PAD_GPIO_9__USDHC1_WP 973
-MX6Q_PAD_GPIO_9__SRC_EARLY_RST 974
-MX6Q_PAD_GPIO_3__ESAI1_HCKR 975
-MX6Q_PAD_GPIO_3__OBSERVE_MUX_INT_OUT0 976
-MX6Q_PAD_GPIO_3__I2C3_SCL 977
-MX6Q_PAD_GPIO_3__ANATOP_24M_OUT 978
-MX6Q_PAD_GPIO_3__CCM_CLKO2 979
-MX6Q_PAD_GPIO_3__GPIO_1_3 980
-MX6Q_PAD_GPIO_3__USBOH3_USBH1_OC 981
-MX6Q_PAD_GPIO_3__MLB_MLBCLK 982
-MX6Q_PAD_GPIO_6__ESAI1_SCKT 983
-MX6Q_PAD_GPIO_6__OBSERVE_MUX_INT_OUT1 984
-MX6Q_PAD_GPIO_6__I2C3_SDA 985
-MX6Q_PAD_GPIO_6__CCM_CCM_OUT_0 986
-MX6Q_PAD_GPIO_6__CSU_CSU_INT_DEB 987
-MX6Q_PAD_GPIO_6__GPIO_1_6 988
-MX6Q_PAD_GPIO_6__USDHC2_LCTL 989
-MX6Q_PAD_GPIO_6__MLB_MLBSIG 990
-MX6Q_PAD_GPIO_2__ESAI1_FST 991
-MX6Q_PAD_GPIO_2__OBSERVE_MUX_INT_OUT2 992
-MX6Q_PAD_GPIO_2__KPP_ROW_6 993
-MX6Q_PAD_GPIO_2__CCM_CCM_OUT_1 994
-MX6Q_PAD_GPIO_2__CSU_CSU_ALARM_AUT_0 995
-MX6Q_PAD_GPIO_2__GPIO_1_2 996
-MX6Q_PAD_GPIO_2__USDHC2_WP 997
-MX6Q_PAD_GPIO_2__MLB_MLBDAT 998
-MX6Q_PAD_GPIO_4__ESAI1_HCKT 999
-MX6Q_PAD_GPIO_4__OBSERVE_MUX_INT_OUT3 1000
-MX6Q_PAD_GPIO_4__KPP_COL_7 1001
-MX6Q_PAD_GPIO_4__CCM_CCM_OUT_2 1002
-MX6Q_PAD_GPIO_4__CSU_CSU_ALARM_AUT_1 1003
-MX6Q_PAD_GPIO_4__GPIO_1_4 1004
-MX6Q_PAD_GPIO_4__USDHC2_CD 1005
-MX6Q_PAD_GPIO_4__OCOTP_CRL_WRAR_FUSE_LA 1006
-MX6Q_PAD_GPIO_5__ESAI1_TX2_RX3 1007
-MX6Q_PAD_GPIO_5__OBSERVE_MUX_INT_OUT4 1008
-MX6Q_PAD_GPIO_5__KPP_ROW_7 1009
-MX6Q_PAD_GPIO_5__CCM_CLKO 1010
-MX6Q_PAD_GPIO_5__CSU_CSU_ALARM_AUT_2 1011
-MX6Q_PAD_GPIO_5__GPIO_1_5 1012
-MX6Q_PAD_GPIO_5__I2C3_SCL 1013
-MX6Q_PAD_GPIO_5__CHEETAH_EVENTI 1014
-MX6Q_PAD_GPIO_7__ESAI1_TX4_RX1 1015
-MX6Q_PAD_GPIO_7__ECSPI5_RDY 1016
-MX6Q_PAD_GPIO_7__EPIT1_EPITO 1017
-MX6Q_PAD_GPIO_7__CAN1_TXCAN 1018
-MX6Q_PAD_GPIO_7__UART2_TXD 1019
-MX6Q_PAD_GPIO_7__GPIO_1_7 1020
-MX6Q_PAD_GPIO_7__SPDIF_PLOCK 1021
-MX6Q_PAD_GPIO_7__USBOH3_OTGUSB_HST_MODE 1022
-MX6Q_PAD_GPIO_8__ESAI1_TX5_RX0 1023
-MX6Q_PAD_GPIO_8__ANATOP_ANATOP_32K_OUT 1024
-MX6Q_PAD_GPIO_8__EPIT2_EPITO 1025
-MX6Q_PAD_GPIO_8__CAN1_RXCAN 1026
-MX6Q_PAD_GPIO_8__UART2_RXD 1027
-MX6Q_PAD_GPIO_8__GPIO_1_8 1028
-MX6Q_PAD_GPIO_8__SPDIF_SRCLK 1029
-MX6Q_PAD_GPIO_8__USBOH3_OTG_PWRCTL_WAK 1030
-MX6Q_PAD_GPIO_16__ESAI1_TX3_RX2 1031
-MX6Q_PAD_GPIO_16__ENET_1588_EVENT2_IN 1032
-MX6Q_PAD_GPIO_16__ENET_ETHERNET_REF_OUT 1033
-MX6Q_PAD_GPIO_16__USDHC1_LCTL 1034
-MX6Q_PAD_GPIO_16__SPDIF_IN1 1035
-MX6Q_PAD_GPIO_16__GPIO_7_11 1036
-MX6Q_PAD_GPIO_16__I2C3_SDA 1037
-MX6Q_PAD_GPIO_16__SJC_DE_B 1038
-MX6Q_PAD_GPIO_17__ESAI1_TX0 1039
-MX6Q_PAD_GPIO_17__ENET_1588_EVENT3_IN 1040
-MX6Q_PAD_GPIO_17__CCM_PMIC_RDY 1041
-MX6Q_PAD_GPIO_17__SDMA_SDMA_EXT_EVENT_0 1042
-MX6Q_PAD_GPIO_17__SPDIF_OUT1 1043
-MX6Q_PAD_GPIO_17__GPIO_7_12 1044
-MX6Q_PAD_GPIO_17__SJC_JTAG_ACT 1045
-MX6Q_PAD_GPIO_18__ESAI1_TX1 1046
-MX6Q_PAD_GPIO_18__ENET_RX_CLK 1047
-MX6Q_PAD_GPIO_18__USDHC3_VSELECT 1048
-MX6Q_PAD_GPIO_18__SDMA_SDMA_EXT_EVENT_1 1049
-MX6Q_PAD_GPIO_18__ASRC_ASRC_EXT_CLK 1050
-MX6Q_PAD_GPIO_18__GPIO_7_13 1051
-MX6Q_PAD_GPIO_18__SNVS_HP_WRA_SNVS_VIO5 1052
-MX6Q_PAD_GPIO_18__SRC_SYSTEM_RST 1053
-MX6Q_PAD_GPIO_19__KPP_COL_5 1054
-MX6Q_PAD_GPIO_19__ENET_1588_EVENT0_OUT 1055
-MX6Q_PAD_GPIO_19__SPDIF_OUT1 1056
-MX6Q_PAD_GPIO_19__CCM_CLKO 1057
-MX6Q_PAD_GPIO_19__ECSPI1_RDY 1058
-MX6Q_PAD_GPIO_19__GPIO_4_5 1059
-MX6Q_PAD_GPIO_19__ENET_TX_ER 1060
-MX6Q_PAD_GPIO_19__SRC_INT_BOOT 1061
-MX6Q_PAD_CSI0_PIXCLK__IPU1_CSI0_PIXCLK 1062
-MX6Q_PAD_CSI0_PIXCLK__PCIE_CTRL_MUX_12 1063
-MX6Q_PAD_CSI0_PIXCLK__SDMA_DEBUG_PC_0 1064
-MX6Q_PAD_CSI0_PIXCLK__GPIO_5_18 1065
-MX6Q_PAD_CSI0_PIXCLK___MMDC_DEBUG_29 1066
-MX6Q_PAD_CSI0_PIXCLK__CHEETAH_EVENTO 1067
-MX6Q_PAD_CSI0_MCLK__IPU1_CSI0_HSYNC 1068
-MX6Q_PAD_CSI0_MCLK__PCIE_CTRL_MUX_13 1069
-MX6Q_PAD_CSI0_MCLK__CCM_CLKO 1070
-MX6Q_PAD_CSI0_MCLK__SDMA_DEBUG_PC_1 1071
-MX6Q_PAD_CSI0_MCLK__GPIO_5_19 1072
-MX6Q_PAD_CSI0_MCLK__MMDC_MMDC_DEBUG_30 1073
-MX6Q_PAD_CSI0_MCLK__CHEETAH_TRCTL 1074
-MX6Q_PAD_CSI0_DATA_EN__IPU1_CSI0_DA_EN 1075
-MX6Q_PAD_CSI0_DATA_EN__WEIM_WEIM_D_0 1076
-MX6Q_PAD_CSI0_DATA_EN__PCIE_CTRL_MUX_14 1077
-MX6Q_PAD_CSI0_DATA_EN__SDMA_DEBUG_PC_2 1078
-MX6Q_PAD_CSI0_DATA_EN__GPIO_5_20 1079
-MX6Q_PAD_CSI0_DATA_EN__MMDC_DEBUG_31 1080
-MX6Q_PAD_CSI0_DATA_EN__CHEETAH_TRCLK 1081
-MX6Q_PAD_CSI0_VSYNC__IPU1_CSI0_VSYNC 1082
-MX6Q_PAD_CSI0_VSYNC__WEIM_WEIM_D_1 1083
-MX6Q_PAD_CSI0_VSYNC__PCIE_CTRL_MUX_15 1084
-MX6Q_PAD_CSI0_VSYNC__SDMA_DEBUG_PC_3 1085
-MX6Q_PAD_CSI0_VSYNC__GPIO_5_21 1086
-MX6Q_PAD_CSI0_VSYNC__MMDC_DEBUG_32 1087
-MX6Q_PAD_CSI0_VSYNC__CHEETAH_TRACE_0 1088
-MX6Q_PAD_CSI0_DAT4__IPU1_CSI0_D_4 1089
-MX6Q_PAD_CSI0_DAT4__WEIM_WEIM_D_2 1090
-MX6Q_PAD_CSI0_DAT4__ECSPI1_SCLK 1091
-MX6Q_PAD_CSI0_DAT4__KPP_COL_5 1092
-MX6Q_PAD_CSI0_DAT4__AUDMUX_AUD3_TXC 1093
-MX6Q_PAD_CSI0_DAT4__GPIO_5_22 1094
-MX6Q_PAD_CSI0_DAT4__MMDC_DEBUG_43 1095
-MX6Q_PAD_CSI0_DAT4__CHEETAH_TRACE_1 1096
-MX6Q_PAD_CSI0_DAT5__IPU1_CSI0_D_5 1097
-MX6Q_PAD_CSI0_DAT5__WEIM_WEIM_D_3 1098
-MX6Q_PAD_CSI0_DAT5__ECSPI1_MOSI 1099
-MX6Q_PAD_CSI0_DAT5__KPP_ROW_5 1100
-MX6Q_PAD_CSI0_DAT5__AUDMUX_AUD3_TXD 1101
-MX6Q_PAD_CSI0_DAT5__GPIO_5_23 1102
-MX6Q_PAD_CSI0_DAT5__MMDC_MMDC_DEBUG_44 1103
-MX6Q_PAD_CSI0_DAT5__CHEETAH_TRACE_2 1104
-MX6Q_PAD_CSI0_DAT6__IPU1_CSI0_D_6 1105
-MX6Q_PAD_CSI0_DAT6__WEIM_WEIM_D_4 1106
-MX6Q_PAD_CSI0_DAT6__ECSPI1_MISO 1107
-MX6Q_PAD_CSI0_DAT6__KPP_COL_6 1108
-MX6Q_PAD_CSI0_DAT6__AUDMUX_AUD3_TXFS 1109
-MX6Q_PAD_CSI0_DAT6__GPIO_5_24 1110
-MX6Q_PAD_CSI0_DAT6__MMDC_MMDC_DEBUG_45 1111
-MX6Q_PAD_CSI0_DAT6__CHEETAH_TRACE_3 1112
-MX6Q_PAD_CSI0_DAT7__IPU1_CSI0_D_7 1113
-MX6Q_PAD_CSI0_DAT7__WEIM_WEIM_D_5 1114
-MX6Q_PAD_CSI0_DAT7__ECSPI1_SS0 1115
-MX6Q_PAD_CSI0_DAT7__KPP_ROW_6 1116
-MX6Q_PAD_CSI0_DAT7__AUDMUX_AUD3_RXD 1117
-MX6Q_PAD_CSI0_DAT7__GPIO_5_25 1118
-MX6Q_PAD_CSI0_DAT7__MMDC_MMDC_DEBUG_46 1119
-MX6Q_PAD_CSI0_DAT7__CHEETAH_TRACE_4 1120
-MX6Q_PAD_CSI0_DAT8__IPU1_CSI0_D_8 1121
-MX6Q_PAD_CSI0_DAT8__WEIM_WEIM_D_6 1122
-MX6Q_PAD_CSI0_DAT8__ECSPI2_SCLK 1123
-MX6Q_PAD_CSI0_DAT8__KPP_COL_7 1124
-MX6Q_PAD_CSI0_DAT8__I2C1_SDA 1125
-MX6Q_PAD_CSI0_DAT8__GPIO_5_26 1126
-MX6Q_PAD_CSI0_DAT8__MMDC_MMDC_DEBUG_47 1127
-MX6Q_PAD_CSI0_DAT8__CHEETAH_TRACE_5 1128
-MX6Q_PAD_CSI0_DAT9__IPU1_CSI0_D_9 1129
-MX6Q_PAD_CSI0_DAT9__WEIM_WEIM_D_7 1130
-MX6Q_PAD_CSI0_DAT9__ECSPI2_MOSI 1131
-MX6Q_PAD_CSI0_DAT9__KPP_ROW_7 1132
-MX6Q_PAD_CSI0_DAT9__I2C1_SCL 1133
-MX6Q_PAD_CSI0_DAT9__GPIO_5_27 1134
-MX6Q_PAD_CSI0_DAT9__MMDC_MMDC_DEBUG_48 1135
-MX6Q_PAD_CSI0_DAT9__CHEETAH_TRACE_6 1136
-MX6Q_PAD_CSI0_DAT10__IPU1_CSI0_D_10 1137
-MX6Q_PAD_CSI0_DAT10__AUDMUX_AUD3_RXC 1138
-MX6Q_PAD_CSI0_DAT10__ECSPI2_MISO 1139
-MX6Q_PAD_CSI0_DAT10__UART1_TXD 1140
-MX6Q_PAD_CSI0_DAT10__SDMA_DEBUG_PC_4 1141
-MX6Q_PAD_CSI0_DAT10__GPIO_5_28 1142
-MX6Q_PAD_CSI0_DAT10__MMDC_MMDC_DEBUG_33 1143
-MX6Q_PAD_CSI0_DAT10__CHEETAH_TRACE_7 1144
-MX6Q_PAD_CSI0_DAT11__IPU1_CSI0_D_11 1145
-MX6Q_PAD_CSI0_DAT11__AUDMUX_AUD3_RXFS 1146
-MX6Q_PAD_CSI0_DAT11__ECSPI2_SS0 1147
-MX6Q_PAD_CSI0_DAT11__UART1_RXD 1148
-MX6Q_PAD_CSI0_DAT11__SDMA_DEBUG_PC_5 1149
-MX6Q_PAD_CSI0_DAT11__GPIO_5_29 1150
-MX6Q_PAD_CSI0_DAT11__MMDC_MMDC_DEBUG_34 1151
-MX6Q_PAD_CSI0_DAT11__CHEETAH_TRACE_8 1152
-MX6Q_PAD_CSI0_DAT12__IPU1_CSI0_D_12 1153
-MX6Q_PAD_CSI0_DAT12__WEIM_WEIM_D_8 1154
-MX6Q_PAD_CSI0_DAT12__PCIE_CTRL_MUX_16 1155
-MX6Q_PAD_CSI0_DAT12__UART4_TXD 1156
-MX6Q_PAD_CSI0_DAT12__SDMA_DEBUG_PC_6 1157
-MX6Q_PAD_CSI0_DAT12__GPIO_5_30 1158
-MX6Q_PAD_CSI0_DAT12__MMDC_MMDC_DEBUG_35 1159
-MX6Q_PAD_CSI0_DAT12__CHEETAH_TRACE_9 1160
-MX6Q_PAD_CSI0_DAT13__IPU1_CSI0_D_13 1161
-MX6Q_PAD_CSI0_DAT13__WEIM_WEIM_D_9 1162
-MX6Q_PAD_CSI0_DAT13__PCIE_CTRL_MUX_17 1163
-MX6Q_PAD_CSI0_DAT13__UART4_RXD 1164
-MX6Q_PAD_CSI0_DAT13__SDMA_DEBUG_PC_7 1165
-MX6Q_PAD_CSI0_DAT13__GPIO_5_31 1166
-MX6Q_PAD_CSI0_DAT13__MMDC_MMDC_DEBUG_36 1167
-MX6Q_PAD_CSI0_DAT13__CHEETAH_TRACE_10 1168
-MX6Q_PAD_CSI0_DAT14__IPU1_CSI0_D_14 1169
-MX6Q_PAD_CSI0_DAT14__WEIM_WEIM_D_10 1170
-MX6Q_PAD_CSI0_DAT14__PCIE_CTRL_MUX_18 1171
-MX6Q_PAD_CSI0_DAT14__UART5_TXD 1172
-MX6Q_PAD_CSI0_DAT14__SDMA_DEBUG_PC_8 1173
-MX6Q_PAD_CSI0_DAT14__GPIO_6_0 1174
-MX6Q_PAD_CSI0_DAT14__MMDC_MMDC_DEBUG_37 1175
-MX6Q_PAD_CSI0_DAT14__CHEETAH_TRACE_11 1176
-MX6Q_PAD_CSI0_DAT15__IPU1_CSI0_D_15 1177
-MX6Q_PAD_CSI0_DAT15__WEIM_WEIM_D_11 1178
-MX6Q_PAD_CSI0_DAT15__PCIE_CTRL_MUX_19 1179
-MX6Q_PAD_CSI0_DAT15__UART5_RXD 1180
-MX6Q_PAD_CSI0_DAT15__SDMA_DEBUG_PC_9 1181
-MX6Q_PAD_CSI0_DAT15__GPIO_6_1 1182
-MX6Q_PAD_CSI0_DAT15__MMDC_MMDC_DEBUG_38 1183
-MX6Q_PAD_CSI0_DAT15__CHEETAH_TRACE_12 1184
-MX6Q_PAD_CSI0_DAT16__IPU1_CSI0_D_16 1185
-MX6Q_PAD_CSI0_DAT16__WEIM_WEIM_D_12 1186
-MX6Q_PAD_CSI0_DAT16__PCIE_CTRL_MUX_20 1187
-MX6Q_PAD_CSI0_DAT16__UART4_RTS 1188
-MX6Q_PAD_CSI0_DAT16__SDMA_DEBUG_PC_10 1189
-MX6Q_PAD_CSI0_DAT16__GPIO_6_2 1190
-MX6Q_PAD_CSI0_DAT16__MMDC_MMDC_DEBUG_39 1191
-MX6Q_PAD_CSI0_DAT16__CHEETAH_TRACE_13 1192
-MX6Q_PAD_CSI0_DAT17__IPU1_CSI0_D_17 1193
-MX6Q_PAD_CSI0_DAT17__WEIM_WEIM_D_13 1194
-MX6Q_PAD_CSI0_DAT17__PCIE_CTRL_MUX_21 1195
-MX6Q_PAD_CSI0_DAT17__UART4_CTS 1196
-MX6Q_PAD_CSI0_DAT17__SDMA_DEBUG_PC_11 1197
-MX6Q_PAD_CSI0_DAT17__GPIO_6_3 1198
-MX6Q_PAD_CSI0_DAT17__MMDC_MMDC_DEBUG_40 1199
-MX6Q_PAD_CSI0_DAT17__CHEETAH_TRACE_14 1200
-MX6Q_PAD_CSI0_DAT18__IPU1_CSI0_D_18 1201
-MX6Q_PAD_CSI0_DAT18__WEIM_WEIM_D_14 1202
-MX6Q_PAD_CSI0_DAT18__PCIE_CTRL_MUX_22 1203
-MX6Q_PAD_CSI0_DAT18__UART5_RTS 1204
-MX6Q_PAD_CSI0_DAT18__SDMA_DEBUG_PC_12 1205
-MX6Q_PAD_CSI0_DAT18__GPIO_6_4 1206
-MX6Q_PAD_CSI0_DAT18__MMDC_MMDC_DEBUG_41 1207
-MX6Q_PAD_CSI0_DAT18__CHEETAH_TRACE_15 1208
-MX6Q_PAD_CSI0_DAT19__IPU1_CSI0_D_19 1209
-MX6Q_PAD_CSI0_DAT19__WEIM_WEIM_D_15 1210
-MX6Q_PAD_CSI0_DAT19__PCIE_CTRL_MUX_23 1211
-MX6Q_PAD_CSI0_DAT19__UART5_CTS 1212
-MX6Q_PAD_CSI0_DAT19__SDMA_DEBUG_PC_13 1213
-MX6Q_PAD_CSI0_DAT19__GPIO_6_5 1214
-MX6Q_PAD_CSI0_DAT19__MMDC_MMDC_DEBUG_42 1215
-MX6Q_PAD_CSI0_DAT19__ANATOP_TESTO_9 1216
-MX6Q_PAD_JTAG_TMS__SJC_TMS 1217
-MX6Q_PAD_JTAG_MOD__SJC_MOD 1218
-MX6Q_PAD_JTAG_TRSTB__SJC_TRSTB 1219
-MX6Q_PAD_JTAG_TDI__SJC_TDI 1220
-MX6Q_PAD_JTAG_TCK__SJC_TCK 1221
-MX6Q_PAD_JTAG_TDO__SJC_TDO 1222
-MX6Q_PAD_LVDS1_TX3_P__LDB_LVDS1_TX3 1223
-MX6Q_PAD_LVDS1_TX2_P__LDB_LVDS1_TX2 1224
-MX6Q_PAD_LVDS1_CLK_P__LDB_LVDS1_CLK 1225
-MX6Q_PAD_LVDS1_TX1_P__LDB_LVDS1_TX1 1226
-MX6Q_PAD_LVDS1_TX0_P__LDB_LVDS1_TX0 1227
-MX6Q_PAD_LVDS0_TX3_P__LDB_LVDS0_TX3 1228
-MX6Q_PAD_LVDS0_CLK_P__LDB_LVDS0_CLK 1229
-MX6Q_PAD_LVDS0_TX2_P__LDB_LVDS0_TX2 1230
-MX6Q_PAD_LVDS0_TX1_P__LDB_LVDS0_TX1 1231
-MX6Q_PAD_LVDS0_TX0_P__LDB_LVDS0_TX0 1232
-MX6Q_PAD_TAMPER__SNVS_LP_WRAP_SNVS_TD1 1233
-MX6Q_PAD_PMIC_ON_REQ__SNVS_LPWRAP_WKALM 1234
-MX6Q_PAD_PMIC_STBY_REQ__CCM_PMIC_STBYRQ 1235
-MX6Q_PAD_POR_B__SRC_POR_B 1236
-MX6Q_PAD_BOOT_MODE1__SRC_BOOT_MODE_1 1237
-MX6Q_PAD_RESET_IN_B__SRC_RESET_B 1238
-MX6Q_PAD_BOOT_MODE0__SRC_BOOT_MODE_0 1239
-MX6Q_PAD_TEST_MODE__TCU_TEST_MODE 1240
-MX6Q_PAD_SD3_DAT7__USDHC3_DAT7 1241
-MX6Q_PAD_SD3_DAT7__UART1_TXD 1242
-MX6Q_PAD_SD3_DAT7__PCIE_CTRL_MUX_24 1243
-MX6Q_PAD_SD3_DAT7__USBOH3_UH3_DFD_OUT_0 1244
-MX6Q_PAD_SD3_DAT7__USBOH3_UH2_DFD_OUT_0 1245
-MX6Q_PAD_SD3_DAT7__GPIO_6_17 1246
-MX6Q_PAD_SD3_DAT7__MIPI_CORE_DPHY_IN_12 1247
-MX6Q_PAD_SD3_DAT7__USBPHY2_CLK20DIV 1248
-MX6Q_PAD_SD3_DAT6__USDHC3_DAT6 1249
-MX6Q_PAD_SD3_DAT6__UART1_RXD 1250
-MX6Q_PAD_SD3_DAT6__PCIE_CTRL_MUX_25 1251
-MX6Q_PAD_SD3_DAT6__USBOH3_UH3_DFD_OUT_1 1252
-MX6Q_PAD_SD3_DAT6__USBOH3_UH2_DFD_OUT_1 1253
-MX6Q_PAD_SD3_DAT6__GPIO_6_18 1254
-MX6Q_PAD_SD3_DAT6__MIPI_CORE_DPHY_IN_13 1255
-MX6Q_PAD_SD3_DAT6__ANATOP_TESTO_10 1256
-MX6Q_PAD_SD3_DAT5__USDHC3_DAT5 1257
-MX6Q_PAD_SD3_DAT5__UART2_TXD 1258
-MX6Q_PAD_SD3_DAT5__PCIE_CTRL_MUX_26 1259
-MX6Q_PAD_SD3_DAT5__USBOH3_UH3_DFD_OUT_2 1260
-MX6Q_PAD_SD3_DAT5__USBOH3_UH2_DFD_OUT_2 1261
-MX6Q_PAD_SD3_DAT5__GPIO_7_0 1262
-MX6Q_PAD_SD3_DAT5__MIPI_CORE_DPHY_IN_14 1263
-MX6Q_PAD_SD3_DAT5__ANATOP_TESTO_11 1264
-MX6Q_PAD_SD3_DAT4__USDHC3_DAT4 1265
-MX6Q_PAD_SD3_DAT4__UART2_RXD 1266
-MX6Q_PAD_SD3_DAT4__PCIE_CTRL_MUX_27 1267
-MX6Q_PAD_SD3_DAT4__USBOH3_UH3_DFD_OUT_3 1268
-MX6Q_PAD_SD3_DAT4__USBOH3_UH2_DFD_OUT_3 1269
-MX6Q_PAD_SD3_DAT4__GPIO_7_1 1270
-MX6Q_PAD_SD3_DAT4__MIPI_CORE_DPHY_IN_15 1271
-MX6Q_PAD_SD3_DAT4__ANATOP_TESTO_12 1272
-MX6Q_PAD_SD3_CMD__USDHC3_CMD 1273
-MX6Q_PAD_SD3_CMD__UART2_CTS 1274
-MX6Q_PAD_SD3_CMD__CAN1_TXCAN 1275
-MX6Q_PAD_SD3_CMD__USBOH3_UH3_DFD_OUT_4 1276
-MX6Q_PAD_SD3_CMD__USBOH3_UH2_DFD_OUT_4 1277
-MX6Q_PAD_SD3_CMD__GPIO_7_2 1278
-MX6Q_PAD_SD3_CMD__MIPI_CORE_DPHY_IN_16 1279
-MX6Q_PAD_SD3_CMD__ANATOP_TESTO_13 1280
-MX6Q_PAD_SD3_CLK__USDHC3_CLK 1281
-MX6Q_PAD_SD3_CLK__UART2_RTS 1282
-MX6Q_PAD_SD3_CLK__CAN1_RXCAN 1283
-MX6Q_PAD_SD3_CLK__USBOH3_UH3_DFD_OUT_5 1284
-MX6Q_PAD_SD3_CLK__USBOH3_UH2_DFD_OUT_5 1285
-MX6Q_PAD_SD3_CLK__GPIO_7_3 1286
-MX6Q_PAD_SD3_CLK__MIPI_CORE_DPHY_IN_17 1287
-MX6Q_PAD_SD3_CLK__ANATOP_TESTO_14 1288
-MX6Q_PAD_SD3_DAT0__USDHC3_DAT0 1289
-MX6Q_PAD_SD3_DAT0__UART1_CTS 1290
-MX6Q_PAD_SD3_DAT0__CAN2_TXCAN 1291
-MX6Q_PAD_SD3_DAT0__USBOH3_UH3_DFD_OUT_6 1292
-MX6Q_PAD_SD3_DAT0__USBOH3_UH2_DFD_OUT_6 1293
-MX6Q_PAD_SD3_DAT0__GPIO_7_4 1294
-MX6Q_PAD_SD3_DAT0__MIPI_CORE_DPHY_IN_18 1295
-MX6Q_PAD_SD3_DAT0__ANATOP_TESTO_15 1296
-MX6Q_PAD_SD3_DAT1__USDHC3_DAT1 1297
-MX6Q_PAD_SD3_DAT1__UART1_RTS 1298
-MX6Q_PAD_SD3_DAT1__CAN2_RXCAN 1299
-MX6Q_PAD_SD3_DAT1__USBOH3_UH3_DFD_OUT_7 1300
-MX6Q_PAD_SD3_DAT1__USBOH3_UH2_DFD_OUT_7 1301
-MX6Q_PAD_SD3_DAT1__GPIO_7_5 1302
-MX6Q_PAD_SD3_DAT1__MIPI_CORE_DPHY_IN_19 1303
-MX6Q_PAD_SD3_DAT1__ANATOP_TESTI_0 1304
-MX6Q_PAD_SD3_DAT2__USDHC3_DAT2 1305
-MX6Q_PAD_SD3_DAT2__PCIE_CTRL_MUX_28 1306
-MX6Q_PAD_SD3_DAT2__USBOH3_UH3_DFD_OUT_8 1307
-MX6Q_PAD_SD3_DAT2__USBOH3_UH2_DFD_OUT_8 1308
-MX6Q_PAD_SD3_DAT2__GPIO_7_6 1309
-MX6Q_PAD_SD3_DAT2__MIPI_CORE_DPHY_IN_20 1310
-MX6Q_PAD_SD3_DAT2__ANATOP_TESTI_1 1311
-MX6Q_PAD_SD3_DAT3__USDHC3_DAT3 1312
-MX6Q_PAD_SD3_DAT3__UART3_CTS 1313
-MX6Q_PAD_SD3_DAT3__PCIE_CTRL_MUX_29 1314
-MX6Q_PAD_SD3_DAT3__USBOH3_UH3_DFD_OUT_9 1315
-MX6Q_PAD_SD3_DAT3__USBOH3_UH2_DFD_OUT_9 1316
-MX6Q_PAD_SD3_DAT3__GPIO_7_7 1317
-MX6Q_PAD_SD3_DAT3__MIPI_CORE_DPHY_IN_21 1318
-MX6Q_PAD_SD3_DAT3__ANATOP_TESTI_2 1319
-MX6Q_PAD_SD3_RST__USDHC3_RST 1320
-MX6Q_PAD_SD3_RST__UART3_RTS 1321
-MX6Q_PAD_SD3_RST__PCIE_CTRL_MUX_30 1322
-MX6Q_PAD_SD3_RST__USBOH3_UH3_DFD_OUT_10 1323
-MX6Q_PAD_SD3_RST__USBOH3_UH2_DFD_OUT_10 1324
-MX6Q_PAD_SD3_RST__GPIO_7_8 1325
-MX6Q_PAD_SD3_RST__MIPI_CORE_DPHY_IN_22 1326
-MX6Q_PAD_SD3_RST__ANATOP_ANATOP_TESTI_3 1327
-MX6Q_PAD_NANDF_CLE__RAWNAND_CLE 1328
-MX6Q_PAD_NANDF_CLE__IPU2_SISG_4 1329
-MX6Q_PAD_NANDF_CLE__PCIE_CTRL_MUX_31 1330
-MX6Q_PAD_NANDF_CLE__USBOH3_UH3_DFD_OT11 1331
-MX6Q_PAD_NANDF_CLE__USBOH3_UH2_DFD_OT11 1332
-MX6Q_PAD_NANDF_CLE__GPIO_6_7 1333
-MX6Q_PAD_NANDF_CLE__MIPI_CORE_DPHY_IN23 1334
-MX6Q_PAD_NANDF_CLE__TPSMP_HTRANS_0 1335
-MX6Q_PAD_NANDF_ALE__RAWNAND_ALE 1336
-MX6Q_PAD_NANDF_ALE__USDHC4_RST 1337
-MX6Q_PAD_NANDF_ALE__PCIE_CTRL_MUX_0 1338
-MX6Q_PAD_NANDF_ALE__USBOH3_UH3_DFD_OT12 1339
-MX6Q_PAD_NANDF_ALE__USBOH3_UH2_DFD_OT12 1340
-MX6Q_PAD_NANDF_ALE__GPIO_6_8 1341
-MX6Q_PAD_NANDF_ALE__MIPI_CR_DPHY_IN_24 1342
-MX6Q_PAD_NANDF_ALE__TPSMP_HTRANS_1 1343
-MX6Q_PAD_NANDF_WP_B__RAWNAND_RESETN 1344
-MX6Q_PAD_NANDF_WP_B__IPU2_SISG_5 1345
-MX6Q_PAD_NANDF_WP_B__PCIE_CTRL__MUX_1 1346
-MX6Q_PAD_NANDF_WP_B__USBOH3_UH3_DFDOT13 1347
-MX6Q_PAD_NANDF_WP_B__USBOH3_UH2_DFDOT13 1348
-MX6Q_PAD_NANDF_WP_B__GPIO_6_9 1349
-MX6Q_PAD_NANDF_WP_B__MIPI_CR_DPHY_OUT32 1350
-MX6Q_PAD_NANDF_WP_B__PL301_PER1_HSIZE_0 1351
-MX6Q_PAD_NANDF_RB0__RAWNAND_READY0 1352
-MX6Q_PAD_NANDF_RB0__IPU2_DI0_PIN1 1353
-MX6Q_PAD_NANDF_RB0__PCIE_CTRL_MUX_2 1354
-MX6Q_PAD_NANDF_RB0__USBOH3_UH3_DFD_OT14 1355
-MX6Q_PAD_NANDF_RB0__USBOH3_UH2_DFD_OT14 1356
-MX6Q_PAD_NANDF_RB0__GPIO_6_10 1357
-MX6Q_PAD_NANDF_RB0__MIPI_CR_DPHY_OUT_33 1358
-MX6Q_PAD_NANDF_RB0__PL301_PER1_HSIZE_1 1359
-MX6Q_PAD_NANDF_CS0__RAWNAND_CE0N 1360
-MX6Q_PAD_NANDF_CS0__USBOH3_UH3_DFD_OT15 1361
-MX6Q_PAD_NANDF_CS0__USBOH3_UH2_DFD_OT15 1362
-MX6Q_PAD_NANDF_CS0__GPIO_6_11 1363
-MX6Q_PAD_NANDF_CS0__PL301_PER1_HSIZE_2 1364
-MX6Q_PAD_NANDF_CS1__RAWNAND_CE1N 1365
-MX6Q_PAD_NANDF_CS1__USDHC4_VSELECT 1366
-MX6Q_PAD_NANDF_CS1__USDHC3_VSELECT 1367
-MX6Q_PAD_NANDF_CS1__PCIE_CTRL_MUX_3 1368
-MX6Q_PAD_NANDF_CS1__GPIO_6_14 1369
-MX6Q_PAD_NANDF_CS1__PL301_PER1_HRDYOUT 1370
-MX6Q_PAD_NANDF_CS2__RAWNAND_CE2N 1371
-MX6Q_PAD_NANDF_CS2__IPU1_SISG_0 1372
-MX6Q_PAD_NANDF_CS2__ESAI1_TX0 1373
-MX6Q_PAD_NANDF_CS2__WEIM_WEIM_CRE 1374
-MX6Q_PAD_NANDF_CS2__CCM_CLKO2 1375
-MX6Q_PAD_NANDF_CS2__GPIO_6_15 1376
-MX6Q_PAD_NANDF_CS2__IPU2_SISG_0 1377
-MX6Q_PAD_NANDF_CS3__RAWNAND_CE3N 1378
-MX6Q_PAD_NANDF_CS3__IPU1_SISG_1 1379
-MX6Q_PAD_NANDF_CS3__ESAI1_TX1 1380
-MX6Q_PAD_NANDF_CS3__WEIM_WEIM_A_26 1381
-MX6Q_PAD_NANDF_CS3__PCIE_CTRL_MUX_4 1382
-MX6Q_PAD_NANDF_CS3__GPIO_6_16 1383
-MX6Q_PAD_NANDF_CS3__IPU2_SISG_1 1384
-MX6Q_PAD_NANDF_CS3__TPSMP_CLK 1385
-MX6Q_PAD_SD4_CMD__USDHC4_CMD 1386
-MX6Q_PAD_SD4_CMD__RAWNAND_RDN 1387
-MX6Q_PAD_SD4_CMD__UART3_TXD 1388
-MX6Q_PAD_SD4_CMD__PCIE_CTRL_MUX_5 1389
-MX6Q_PAD_SD4_CMD__GPIO_7_9 1390
-MX6Q_PAD_SD4_CMD__TPSMP_HDATA_DIR 1391
-MX6Q_PAD_SD4_CLK__USDHC4_CLK 1392
-MX6Q_PAD_SD4_CLK__RAWNAND_WRN 1393
-MX6Q_PAD_SD4_CLK__UART3_RXD 1394
-MX6Q_PAD_SD4_CLK__PCIE_CTRL_MUX_6 1395
-MX6Q_PAD_SD4_CLK__GPIO_7_10 1396
-MX6Q_PAD_NANDF_D0__RAWNAND_D0 1397
-MX6Q_PAD_NANDF_D0__USDHC1_DAT4 1398
-MX6Q_PAD_NANDF_D0__GPU3D_GPU_DBG_OUT_0 1399
-MX6Q_PAD_NANDF_D0__USBOH3_UH2_DFD_OUT16 1400
-MX6Q_PAD_NANDF_D0__USBOH3_UH3_DFD_OUT16 1401
-MX6Q_PAD_NANDF_D0__GPIO_2_0 1402
-MX6Q_PAD_NANDF_D0__IPU1_IPU_DIAG_BUS_0 1403
-MX6Q_PAD_NANDF_D0__IPU2_IPU_DIAG_BUS_0 1404
-MX6Q_PAD_NANDF_D1__RAWNAND_D1 1405
-MX6Q_PAD_NANDF_D1__USDHC1_DAT5 1406
-MX6Q_PAD_NANDF_D1__GPU3D_GPU_DEBUG_OUT1 1407
-MX6Q_PAD_NANDF_D1__USBOH3_UH2_DFD_OUT17 1408
-MX6Q_PAD_NANDF_D1__USBOH3_UH3_DFD_OUT17 1409
-MX6Q_PAD_NANDF_D1__GPIO_2_1 1410
-MX6Q_PAD_NANDF_D1__IPU1_IPU_DIAG_BUS_1 1411
-MX6Q_PAD_NANDF_D1__IPU2_IPU_DIAG_BUS_1 1412
-MX6Q_PAD_NANDF_D2__RAWNAND_D2 1413
-MX6Q_PAD_NANDF_D2__USDHC1_DAT6 1414
-MX6Q_PAD_NANDF_D2__GPU3D_GPU_DBG_OUT_2 1415
-MX6Q_PAD_NANDF_D2__USBOH3_UH2_DFD_OUT18 1416
-MX6Q_PAD_NANDF_D2__USBOH3_UH3_DFD_OUT18 1417
-MX6Q_PAD_NANDF_D2__GPIO_2_2 1418
-MX6Q_PAD_NANDF_D2__IPU1_IPU_DIAG_BUS_2 1419
-MX6Q_PAD_NANDF_D2__IPU2_IPU_DIAG_BUS_2 1420
-MX6Q_PAD_NANDF_D3__RAWNAND_D3 1421
-MX6Q_PAD_NANDF_D3__USDHC1_DAT7 1422
-MX6Q_PAD_NANDF_D3__GPU3D_GPU_DBG_OUT_3 1423
-MX6Q_PAD_NANDF_D3__USBOH3_UH2_DFD_OUT19 1424
-MX6Q_PAD_NANDF_D3__USBOH3_UH3_DFD_OUT19 1425
-MX6Q_PAD_NANDF_D3__GPIO_2_3 1426
-MX6Q_PAD_NANDF_D3__IPU1_IPU_DIAG_BUS_3 1427
-MX6Q_PAD_NANDF_D3__IPU2_IPU_DIAG_BUS_3 1428
-MX6Q_PAD_NANDF_D4__RAWNAND_D4 1429
-MX6Q_PAD_NANDF_D4__USDHC2_DAT4 1430
-MX6Q_PAD_NANDF_D4__GPU3D_GPU_DBG_OUT_4 1431
-MX6Q_PAD_NANDF_D4__USBOH3_UH2_DFD_OUT20 1432
-MX6Q_PAD_NANDF_D4__USBOH3_UH3_DFD_OUT20 1433
-MX6Q_PAD_NANDF_D4__GPIO_2_4 1434
-MX6Q_PAD_NANDF_D4__IPU1_IPU_DIAG_BUS_4 1435
-MX6Q_PAD_NANDF_D4__IPU2_IPU_DIAG_BUS_4 1436
-MX6Q_PAD_NANDF_D5__RAWNAND_D5 1437
-MX6Q_PAD_NANDF_D5__USDHC2_DAT5 1438
-MX6Q_PAD_NANDF_D5__GPU3D_GPU_DBG_OUT_5 1439
-MX6Q_PAD_NANDF_D5__USBOH3_UH2_DFD_OUT21 1440
-MX6Q_PAD_NANDF_D5__USBOH3_UH3_DFD_OUT21 1441
-MX6Q_PAD_NANDF_D5__GPIO_2_5 1442
-MX6Q_PAD_NANDF_D5__IPU1_IPU_DIAG_BUS_5 1443
-MX6Q_PAD_NANDF_D5__IPU2_IPU_DIAG_BUS_5 1444
-MX6Q_PAD_NANDF_D6__RAWNAND_D6 1445
-MX6Q_PAD_NANDF_D6__USDHC2_DAT6 1446
-MX6Q_PAD_NANDF_D6__GPU3D_GPU_DBG_OUT_6 1447
-MX6Q_PAD_NANDF_D6__USBOH3_UH2_DFD_OUT22 1448
-MX6Q_PAD_NANDF_D6__USBOH3_UH3_DFD_OUT22 1449
-MX6Q_PAD_NANDF_D6__GPIO_2_6 1450
-MX6Q_PAD_NANDF_D6__IPU1_IPU_DIAG_BUS_6 1451
-MX6Q_PAD_NANDF_D6__IPU2_IPU_DIAG_BUS_6 1452
-MX6Q_PAD_NANDF_D7__RAWNAND_D7 1453
-MX6Q_PAD_NANDF_D7__USDHC2_DAT7 1454
-MX6Q_PAD_NANDF_D7__GPU3D_GPU_DBG_OUT_7 1455
-MX6Q_PAD_NANDF_D7__USBOH3_UH2_DFD_OUT23 1456
-MX6Q_PAD_NANDF_D7__USBOH3_UH3_DFD_OUT23 1457
-MX6Q_PAD_NANDF_D7__GPIO_2_7 1458
-MX6Q_PAD_NANDF_D7__IPU1_IPU_DIAG_BUS_7 1459
-MX6Q_PAD_NANDF_D7__IPU2_IPU_DIAG_BUS_7 1460
-MX6Q_PAD_SD4_DAT0__RAWNAND_D8 1461
-MX6Q_PAD_SD4_DAT0__USDHC4_DAT0 1462
-MX6Q_PAD_SD4_DAT0__RAWNAND_DQS 1463
-MX6Q_PAD_SD4_DAT0__USBOH3_UH2_DFD_OUT24 1464
-MX6Q_PAD_SD4_DAT0__USBOH3_UH3_DFD_OUT24 1465
-MX6Q_PAD_SD4_DAT0__GPIO_2_8 1466
-MX6Q_PAD_SD4_DAT0__IPU1_IPU_DIAG_BUS_8 1467
-MX6Q_PAD_SD4_DAT0__IPU2_IPU_DIAG_BUS_8 1468
-MX6Q_PAD_SD4_DAT1__RAWNAND_D9 1469
-MX6Q_PAD_SD4_DAT1__USDHC4_DAT1 1470
-MX6Q_PAD_SD4_DAT1__PWM3_PWMO 1471
-MX6Q_PAD_SD4_DAT1__USBOH3_UH2_DFD_OUT25 1472
-MX6Q_PAD_SD4_DAT1__USBOH3_UH3_DFD_OUT25 1473
-MX6Q_PAD_SD4_DAT1__GPIO_2_9 1474
-MX6Q_PAD_SD4_DAT1__IPU1_IPU_DIAG_BUS_9 1475
-MX6Q_PAD_SD4_DAT1__IPU2_IPU_DIAG_BUS_9 1476
-MX6Q_PAD_SD4_DAT2__RAWNAND_D10 1477
-MX6Q_PAD_SD4_DAT2__USDHC4_DAT2 1478
-MX6Q_PAD_SD4_DAT2__PWM4_PWMO 1479
-MX6Q_PAD_SD4_DAT2__USBOH3_UH2_DFD_OUT26 1480
-MX6Q_PAD_SD4_DAT2__USBOH3_UH3_DFD_OUT26 1481
-MX6Q_PAD_SD4_DAT2__GPIO_2_10 1482
-MX6Q_PAD_SD4_DAT2__IPU1_IPU_DIAG_BUS_10 1483
-MX6Q_PAD_SD4_DAT2__IPU2_IPU_DIAG_BUS_10 1484
-MX6Q_PAD_SD4_DAT3__RAWNAND_D11 1485
-MX6Q_PAD_SD4_DAT3__USDHC4_DAT3 1486
-MX6Q_PAD_SD4_DAT3__USBOH3_UH2_DFD_OUT27 1487
-MX6Q_PAD_SD4_DAT3__USBOH3_UH3_DFD_OUT27 1488
-MX6Q_PAD_SD4_DAT3__GPIO_2_11 1489
-MX6Q_PAD_SD4_DAT3__IPU1_IPU_DIAG_BUS_11 1490
-MX6Q_PAD_SD4_DAT3__IPU2_IPU_DIAG_BUS_11 1491
-MX6Q_PAD_SD4_DAT4__RAWNAND_D12 1492
-MX6Q_PAD_SD4_DAT4__USDHC4_DAT4 1493
-MX6Q_PAD_SD4_DAT4__UART2_RXD 1494
-MX6Q_PAD_SD4_DAT4__USBOH3_UH2_DFD_OUT28 1495
-MX6Q_PAD_SD4_DAT4__USBOH3_UH3_DFD_OUT28 1496
-MX6Q_PAD_SD4_DAT4__GPIO_2_12 1497
-MX6Q_PAD_SD4_DAT4__IPU1_IPU_DIAG_BUS_12 1498
-MX6Q_PAD_SD4_DAT4__IPU2_IPU_DIAG_BUS_12 1499
-MX6Q_PAD_SD4_DAT5__RAWNAND_D13 1500
-MX6Q_PAD_SD4_DAT5__USDHC4_DAT5 1501
-MX6Q_PAD_SD4_DAT5__UART2_RTS 1502
-MX6Q_PAD_SD4_DAT5__USBOH3_UH2_DFD_OUT29 1503
-MX6Q_PAD_SD4_DAT5__USBOH3_UH3_DFD_OUT29 1504
-MX6Q_PAD_SD4_DAT5__GPIO_2_13 1505
-MX6Q_PAD_SD4_DAT5__IPU1_IPU_DIAG_BUS_13 1506
-MX6Q_PAD_SD4_DAT5__IPU2_IPU_DIAG_BUS_13 1507
-MX6Q_PAD_SD4_DAT6__RAWNAND_D14 1508
-MX6Q_PAD_SD4_DAT6__USDHC4_DAT6 1509
-MX6Q_PAD_SD4_DAT6__UART2_CTS 1510
-MX6Q_PAD_SD4_DAT6__USBOH3_UH2_DFD_OUT30 1511
-MX6Q_PAD_SD4_DAT6__USBOH3_UH3_DFD_OUT30 1512
-MX6Q_PAD_SD4_DAT6__GPIO_2_14 1513
-MX6Q_PAD_SD4_DAT6__IPU1_IPU_DIAG_BUS_14 1514
-MX6Q_PAD_SD4_DAT6__IPU2_IPU_DIAG_BUS_14 1515
-MX6Q_PAD_SD4_DAT7__RAWNAND_D15 1516
-MX6Q_PAD_SD4_DAT7__USDHC4_DAT7 1517
-MX6Q_PAD_SD4_DAT7__UART2_TXD 1518
-MX6Q_PAD_SD4_DAT7__USBOH3_UH2_DFD_OUT31 1519
-MX6Q_PAD_SD4_DAT7__USBOH3_UH3_DFD_OUT31 1520
-MX6Q_PAD_SD4_DAT7__GPIO_2_15 1521
-MX6Q_PAD_SD4_DAT7__IPU1_IPU_DIAG_BUS_15 1522
-MX6Q_PAD_SD4_DAT7__IPU2_IPU_DIAG_BUS_15 1523
-MX6Q_PAD_SD1_DAT1__USDHC1_DAT1 1524
-MX6Q_PAD_SD1_DAT1__ECSPI5_SS0 1525
-MX6Q_PAD_SD1_DAT1__PWM3_PWMO 1526
-MX6Q_PAD_SD1_DAT1__GPT_CAPIN2 1527
-MX6Q_PAD_SD1_DAT1__PCIE_CTRL_MUX_7 1528
-MX6Q_PAD_SD1_DAT1__GPIO_1_17 1529
-MX6Q_PAD_SD1_DAT1__HDMI_TX_OPHYDTB_0 1530
-MX6Q_PAD_SD1_DAT1__ANATOP_TESTO_8 1531
-MX6Q_PAD_SD1_DAT0__USDHC1_DAT0 1532
-MX6Q_PAD_SD1_DAT0__ECSPI5_MISO 1533
-MX6Q_PAD_SD1_DAT0__CAAM_WRAP_RNG_OSCOBS 1534
-MX6Q_PAD_SD1_DAT0__GPT_CAPIN1 1535
-MX6Q_PAD_SD1_DAT0__PCIE_CTRL_MUX_8 1536
-MX6Q_PAD_SD1_DAT0__GPIO_1_16 1537
-MX6Q_PAD_SD1_DAT0__HDMI_TX_OPHYDTB_1 1538
-MX6Q_PAD_SD1_DAT0__ANATOP_TESTO_7 1539
-MX6Q_PAD_SD1_DAT3__USDHC1_DAT3 1540
-MX6Q_PAD_SD1_DAT3__ECSPI5_SS2 1541
-MX6Q_PAD_SD1_DAT3__GPT_CMPOUT3 1542
-MX6Q_PAD_SD1_DAT3__PWM1_PWMO 1543
-MX6Q_PAD_SD1_DAT3__WDOG2_WDOG_B 1544
-MX6Q_PAD_SD1_DAT3__GPIO_1_21 1545
-MX6Q_PAD_SD1_DAT3__WDOG2_WDOG_RST_B_DEB 1546
-MX6Q_PAD_SD1_DAT3__ANATOP_TESTO_6 1547
-MX6Q_PAD_SD1_CMD__USDHC1_CMD 1548
-MX6Q_PAD_SD1_CMD__ECSPI5_MOSI 1549
-MX6Q_PAD_SD1_CMD__PWM4_PWMO 1550
-MX6Q_PAD_SD1_CMD__GPT_CMPOUT1 1551
-MX6Q_PAD_SD1_CMD__GPIO_1_18 1552
-MX6Q_PAD_SD1_CMD__ANATOP_TESTO_5 1553
-MX6Q_PAD_SD1_DAT2__USDHC1_DAT2 1554
-MX6Q_PAD_SD1_DAT2__ECSPI5_SS1 1555
-MX6Q_PAD_SD1_DAT2__GPT_CMPOUT2 1556
-MX6Q_PAD_SD1_DAT2__PWM2_PWMO 1557
-MX6Q_PAD_SD1_DAT2__WDOG1_WDOG_B 1558
-MX6Q_PAD_SD1_DAT2__GPIO_1_19 1559
-MX6Q_PAD_SD1_DAT2__WDOG1_WDOG_RST_B_DEB 1560
-MX6Q_PAD_SD1_DAT2__ANATOP_TESTO_4 1561
-MX6Q_PAD_SD1_CLK__USDHC1_CLK 1562
-MX6Q_PAD_SD1_CLK__ECSPI5_SCLK 1563
-MX6Q_PAD_SD1_CLK__OSC32K_32K_OUT 1564
-MX6Q_PAD_SD1_CLK__GPT_CLKIN 1565
-MX6Q_PAD_SD1_CLK__GPIO_1_20 1566
-MX6Q_PAD_SD1_CLK__PHY_DTB_0 1567
-MX6Q_PAD_SD1_CLK__SATA_PHY_DTB_0 1568
-MX6Q_PAD_SD2_CLK__USDHC2_CLK 1569
-MX6Q_PAD_SD2_CLK__ECSPI5_SCLK 1570
-MX6Q_PAD_SD2_CLK__KPP_COL_5 1571
-MX6Q_PAD_SD2_CLK__AUDMUX_AUD4_RXFS 1572
-MX6Q_PAD_SD2_CLK__PCIE_CTRL_MUX_9 1573
-MX6Q_PAD_SD2_CLK__GPIO_1_10 1574
-MX6Q_PAD_SD2_CLK__PHY_DTB_1 1575
-MX6Q_PAD_SD2_CLK__SATA_PHY_DTB_1 1576
-MX6Q_PAD_SD2_CMD__USDHC2_CMD 1577
-MX6Q_PAD_SD2_CMD__ECSPI5_MOSI 1578
-MX6Q_PAD_SD2_CMD__KPP_ROW_5 1579
-MX6Q_PAD_SD2_CMD__AUDMUX_AUD4_RXC 1580
-MX6Q_PAD_SD2_CMD__PCIE_CTRL_MUX_10 1581
-MX6Q_PAD_SD2_CMD__GPIO_1_11 1582
-MX6Q_PAD_SD2_DAT3__USDHC2_DAT3 1583
-MX6Q_PAD_SD2_DAT3__ECSPI5_SS3 1584
-MX6Q_PAD_SD2_DAT3__KPP_COL_6 1585
-MX6Q_PAD_SD2_DAT3__AUDMUX_AUD4_TXC 1586
-MX6Q_PAD_SD2_DAT3__PCIE_CTRL_MUX_11 1587
-MX6Q_PAD_SD2_DAT3__GPIO_1_12 1588
-MX6Q_PAD_SD2_DAT3__SJC_DONE 1589
-MX6Q_PAD_SD2_DAT3__ANATOP_TESTO_3 1590
-MX6Q_PAD_ENET_RX_ER__ANATOP_USBOTG_ID 1591
-MX6Q_PAD_GPIO_1__ANATOP_USBOTG_ID 1592
+Refer to imx6q-pinfunc.h in device tree source folder for all available
+imx6q PIN_FUNC_ID.
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx6sl-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx6sl-pinctrl.txt
new file mode 100644
index 0000000..e5f6d1f
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx6sl-pinctrl.txt
@@ -0,0 +1,39 @@
+* Freescale IMX6 SoloLite IOMUX Controller
+
+Please refer to fsl,imx-pinctrl.txt in this directory for common binding part
+and usage.
+
+Required properties:
+- compatible: "fsl,imx6sl-iomuxc"
+- fsl,pins: two integers array, represents a group of pins mux and config
+ setting. The format is fsl,pins = <PIN_FUNC_ID CONFIG>, PIN_FUNC_ID is a
+ pin working on a specific function, CONFIG is the pad setting value like
+ pull-up for this pin. Please refer to imx6sl datasheet for the valid pad
+ config settings.
+
+CONFIG bits definition:
+PAD_CTL_LVE (1 << 22)
+PAD_CTL_HYS (1 << 16)
+PAD_CTL_PUS_100K_DOWN (0 << 14)
+PAD_CTL_PUS_47K_UP (1 << 14)
+PAD_CTL_PUS_100K_UP (2 << 14)
+PAD_CTL_PUS_22K_UP (3 << 14)
+PAD_CTL_PUE (1 << 13)
+PAD_CTL_PKE (1 << 12)
+PAD_CTL_ODE (1 << 11)
+PAD_CTL_SPEED_LOW (1 << 6)
+PAD_CTL_SPEED_MED (2 << 6)
+PAD_CTL_SPEED_HIGH (3 << 6)
+PAD_CTL_DSE_DISABLE (0 << 3)
+PAD_CTL_DSE_240ohm (1 << 3)
+PAD_CTL_DSE_120ohm (2 << 3)
+PAD_CTL_DSE_80ohm (3 << 3)
+PAD_CTL_DSE_60ohm (4 << 3)
+PAD_CTL_DSE_48ohm (5 << 3)
+PAD_CTL_DSE_40ohm (6 << 3)
+PAD_CTL_DSE_34ohm (7 << 3)
+PAD_CTL_SRE_FAST (1 << 0)
+PAD_CTL_SRE_SLOW (0 << 0)
+
+Refer to imx6sl-pinfunc.h in device tree source folder for all available
+imx6sl PIN_FUNC_ID.
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,mxs-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,mxs-pinctrl.txt
index f7e8e8f..3077370 100644
--- a/Documentation/devicetree/bindings/pinctrl/fsl,mxs-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/fsl,mxs-pinctrl.txt
@@ -70,6 +70,10 @@
0: Disable the internal pull-up
1: Enable the internal pull-up
+Note that when enabling the pull-up, the internal pad keeper gets disabled.
+Also, some pins doesn't have a pull up, in that case, setting the fsl,pull-up
+will only disable the internal pad keeper.
+
Examples:
pinctrl@80018000 {
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,vf610-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,vf610-pinctrl.txt
new file mode 100644
index 0000000..ddcdeb6
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/fsl,vf610-pinctrl.txt
@@ -0,0 +1,41 @@
+Freescale Vybrid VF610 IOMUX Controller
+
+Please refer to fsl,imx-pinctrl.txt in this directory for common binding part
+and usage.
+
+Required properties:
+- compatible: "fsl,vf610-iomuxc"
+- fsl,pins: two integers array, represents a group of pins mux and config
+ setting. The format is fsl,pins = <PIN_FUNC_ID CONFIG>, PIN_FUNC_ID is
+ a pin working on a specific function, CONFIG is the pad setting value
+ such as pull-up, speed, ode for this pin. Please refer to Vybrid VF610
+ datasheet for the valid pad config settings.
+
+CONFIG bits definition:
+PAD_CTL_SPEED_LOW (1 << 12)
+PAD_CTL_SPEED_MED (2 << 12)
+PAD_CTL_SPEED_HIGH (3 << 12)
+PAD_CTL_SRE_FAST (1 << 11)
+PAD_CTL_SRE_SLOW (0 << 11)
+PAD_CTL_ODE (1 << 10)
+PAD_CTL_HYS (1 << 9)
+PAD_CTL_DSE_DISABLE (0 << 6)
+PAD_CTL_DSE_150ohm (1 << 6)
+PAD_CTL_DSE_75ohm (2 << 6)
+PAD_CTL_DSE_50ohm (3 << 6)
+PAD_CTL_DSE_37ohm (4 << 6)
+PAD_CTL_DSE_30ohm (5 << 6)
+PAD_CTL_DSE_25ohm (6 << 6)
+PAD_CTL_DSE_20ohm (7 << 6)
+PAD_CTL_PUS_100K_DOWN (0 << 4)
+PAD_CTL_PUS_47K_UP (1 << 4)
+PAD_CTL_PUS_100K_UP (2 << 4)
+PAD_CTL_PUS_22K_UP (3 << 4)
+PAD_CTL_PKE (1 << 3)
+PAD_CTL_PUE (1 << 2)
+PAD_CTL_OBE_ENABLE (1 << 1)
+PAD_CTL_IBE_ENABLE (1 << 0)
+PAD_CTL_OBE_IBE_ENABLE (3 << 0)
+
+Please refer to vf610-pinfunc.h in device tree source folder
+for all available PIN_FUNC_ID for Vybrid VF610.
diff --git a/Documentation/devicetree/bindings/pinctrl/img,tz1090-pdc-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/img,tz1090-pdc-pinctrl.txt
new file mode 100644
index 0000000..a186181
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/img,tz1090-pdc-pinctrl.txt
@@ -0,0 +1,127 @@
+ImgTec TZ1090 PDC pin controller
+
+Required properties:
+- compatible: "img,tz1090-pdc-pinctrl"
+- reg: Should contain the register physical address and length of the
+ SOC_GPIO_CONTROL registers in the PDC register region.
+
+Please refer to pinctrl-bindings.txt in this directory for details of the
+common pinctrl bindings used by client devices, including the meaning of the
+phrase "pin configuration node".
+
+TZ1090-PDC's pin configuration nodes act as a container for an abitrary number
+of subnodes. Each of these subnodes represents some desired configuration for a
+pin, a group, or a list of pins or groups. This configuration can include the
+mux function to select on those pin(s)/group(s), and various pin configuration
+parameters, such as pull-up, drive strength, etc.
+
+The name of each subnode is not important; all subnodes should be enumerated
+and processed purely based on their content.
+
+Each subnode only affects those parameters that are explicitly listed. In
+other words, a subnode that lists a mux function but no pin configuration
+parameters implies no information about any pin configuration parameters.
+Similarly, a pin subnode that describes a pullup parameter implies no
+information about e.g. the mux function. For this reason, even seemingly boolean
+values are actually tristates in this binding: unspecified, off, or on.
+Unspecified is represented as an absent property, and off/on are represented as
+integer values 0 and 1.
+
+Required subnode-properties:
+- tz1090,pins : An array of strings. Each string contains the name of a pin or
+ group. Valid values for these names are listed below.
+
+Optional subnode-properties:
+- tz1090,function: A string containing the name of the function to mux to the
+ pin or group. Valid values for function names are listed below, including
+ which pingroups can be muxed to them.
+- supported generic pinconfig properties (for further details see
+ Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt):
+ - bias-disable
+ - bias-high-impedance
+ - bias-bus-hold
+ - bias-pull-up
+ - bias-pull-down
+ - input-schmitt-enable
+ - input-schmitt-disable
+ - drive-strength: Integer, control drive strength of pins in mA.
+ 2: 2mA
+ 4: 4mA
+ 8: 8mA
+ 12: 12mA
+ - low-power-enable: Flag, power-on-start weak pull-down for invalid power.
+ - low-power-disable: Flag, power-on-start weak pull-down disabled.
+
+Note that many of these properties are only valid for certain specific pins
+or groups. See the TZ1090 TRM for complete details regarding which groups
+support which functionality. The Linux pinctrl driver may also be a useful
+reference.
+
+Valid values for pin and group names are:
+
+ pins:
+
+ These all support bias-high-impediance, bias-pull-up, bias-pull-down, and
+ bias-bus-hold (which can also be provided to any of the groups below to set
+ it for all gpio pins in that group).
+
+ gpio0, gpio1, sys_wake0, sys_wake1, sys_wake2, ir_data, ext_power.
+
+ mux groups:
+
+ These all support function.
+
+ gpio0
+ pins: gpio0.
+ function: ir_mod_stable_out.
+ gpio1
+ pins: gpio1.
+ function: ir_mod_power_out.
+
+ drive groups:
+
+ These support input-schmitt-enable, input-schmitt-disable,
+ drive-strength, low-power-enable, and low-power-disable.
+
+ pdc
+ pins: gpio0, gpio1, sys_wake0, sys_wake1, sys_wake2, ir_data,
+ ext_power.
+
+Example:
+
+ pinctrl_pdc: pinctrl@02006500 {
+ #gpio-range-cells = <3>;
+ compatible = "img,tz1090-pdc-pinctrl";
+ reg = <0x02006500 0x100>;
+ };
+
+Example board file extracts:
+
+ &pinctrl_pdc {
+ pinctrl-names = "default";
+ pinctrl-0 = <&syswake_default>;
+
+ syswake_default: syswakes {
+ syswake_cfg {
+ tz1090,pins = "sys_wake0",
+ "sys_wake1",
+ "sys_wake2";
+ pull-up;
+ };
+ };
+ irmod_default: irmod {
+ gpio0_cfg {
+ tz1090,pins = "gpio0";
+ tz1090,function = "ir_mod_stable_out";
+ };
+ gpio1_cfg {
+ tz1090,pins = "gpio1";
+ tz1090,function = "ir_mod_power_out";
+ };
+ };
+ };
+
+ ir: ir@02006200 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&irmod_default>;
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/img,tz1090-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/img,tz1090-pinctrl.txt
new file mode 100644
index 0000000..4b27c99
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/img,tz1090-pinctrl.txt
@@ -0,0 +1,227 @@
+ImgTec TZ1090 pin controller
+
+Required properties:
+- compatible: "img,tz1090-pinctrl"
+- reg: Should contain the register physical address and length of the pad
+ configuration registers (CR_PADS_* and CR_IF_CTL0).
+
+Please refer to pinctrl-bindings.txt in this directory for details of the
+common pinctrl bindings used by client devices, including the meaning of the
+phrase "pin configuration node".
+
+TZ1090's pin configuration nodes act as a container for an abitrary number of
+subnodes. Each of these subnodes represents some desired configuration for a
+pin, a group, or a list of pins or groups. This configuration can include the
+mux function to select on those pin(s)/group(s), and various pin configuration
+parameters, such as pull-up, drive strength, etc.
+
+The name of each subnode is not important; all subnodes should be enumerated
+and processed purely based on their content.
+
+Each subnode only affects those parameters that are explicitly listed. In
+other words, a subnode that lists a mux function but no pin configuration
+parameters implies no information about any pin configuration parameters.
+Similarly, a pin subnode that describes a pullup parameter implies no
+information about e.g. the mux function. For this reason, even seemingly boolean
+values are actually tristates in this binding: unspecified, off, or on.
+Unspecified is represented as an absent property, and off/on are represented as
+integer values 0 and 1.
+
+Required subnode-properties:
+- tz1090,pins : An array of strings. Each string contains the name of a pin or
+ group. Valid values for these names are listed below.
+
+Optional subnode-properties:
+- tz1090,function: A string containing the name of the function to mux to the
+ pin or group. Valid values for function names are listed below, including
+ which pingroups can be muxed to them.
+- supported generic pinconfig properties (for further details see
+ Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt):
+ - bias-disable
+ - bias-high-impedance
+ - bias-bus-hold
+ - bias-pull-up
+ - bias-pull-down
+ - input-schmitt-enable
+ - input-schmitt-disable
+ - drive-strength: Integer, control drive strength of pins in mA.
+ 2: 2mA
+ 4: 4mA
+ 8: 8mA
+ 12: 12mA
+
+
+Note that many of these properties are only valid for certain specific pins
+or groups. See the TZ1090 TRM for complete details regarding which groups
+support which functionality. The Linux pinctrl driver may also be a useful
+reference.
+
+Valid values for pin and group names are:
+
+ gpio pins:
+
+ These all support bias-high-impediance, bias-pull-up, bias-pull-down, and
+ bias-bus-hold (which can also be provided to any of the groups below to set
+ it for all pins in that group).
+
+ They also all support the some form of muxing. Any pins which are contained
+ in one of the mux groups (see below) can be muxed only to the functions
+ supported by the mux group. All other pins can be muxed to the "perip"
+ function which which enables them with their intended peripheral.
+
+ Different pins in the same mux group cannot be muxed to different functions,
+ however it is possible to mux only a subset of the pins in a mux group to a
+ particular function and leave the remaining pins unmuxed. This is useful if
+ the board connects certain pins in a group to other devices to be controlled
+ by GPIO, and you don't want the usual peripheral to have any control of the
+ pin.
+
+ ant_sel0, ant_sel1, gain0, gain1, gain2, gain3, gain4, gain5, gain6, gain7,
+ i2s_bclk_out, i2s_din, i2s_dout0, i2s_dout1, i2s_dout2, i2s_lrclk_out,
+ i2s_mclk, pa_on, pdm_a, pdm_b, pdm_c, pdm_d, pll_on, rx_hp, rx_on,
+ scb0_sclk, scb0_sdat, scb1_sclk, scb1_sdat, scb2_sclk, scb2_sdat, sdh_cd,
+ sdh_clk_in, sdh_wp, sdio_clk, sdio_cmd, sdio_d0, sdio_d1, sdio_d2, sdio_d3,
+ spi0_cs0, spi0_cs1, spi0_cs2, spi0_din, spi0_dout, spi0_mclk, spi1_cs0,
+ spi1_cs1, spi1_cs2, spi1_din, spi1_dout, spi1_mclk, tft_blank_ls, tft_blue0,
+ tft_blue1, tft_blue2, tft_blue3, tft_blue4, tft_blue5, tft_blue6, tft_blue7,
+ tft_green0, tft_green1, tft_green2, tft_green3, tft_green4, tft_green5,
+ tft_green6, tft_green7, tft_hsync_nr, tft_panelclk, tft_pwrsave, tft_red0,
+ tft_red1, tft_red2, tft_red3, tft_red4, tft_red5, tft_red6, tft_red7,
+ tft_vd12acb, tft_vdden_gd, tft_vsync_ns, tx_on, uart0_cts, uart0_rts,
+ uart0_rxd, uart0_txd, uart1_rxd, uart1_txd.
+
+ bias-high-impediance: supported.
+ bias-pull-up: supported.
+ bias-pull-down: supported.
+ bias-bus-hold: supported.
+ function: perip or those supported by pin's mux group.
+
+ other pins:
+
+ These other pins are part of various pin groups below, but can't be
+ controlled as GPIOs. They do however support bias-high-impediance,
+ bias-pull-up, bias-pull-down, and bias-bus-hold (which can also be provided
+ to any of the groups below to set it for all pins in that group).
+
+ clk_out0, clk_out1, tck, tdi, tdo, tms, trst.
+
+ bias-high-impediance: supported.
+ bias-pull-up: supported.
+ bias-pull-down: supported.
+ bias-bus-hold: supported.
+
+ mux groups:
+
+ These all support function, and some support drive configs.
+
+ afe
+ pins: tx_on, rx_on, pll_on, pa_on, rx_hp, ant_sel0,
+ ant_sel1, gain0, gain1, gain2, gain3, gain4,
+ gain5, gain6, gain7.
+ function: afe, ts_out_0.
+ input-schmitt-enable: supported.
+ input-schmitt-disable: supported.
+ drive-strength: supported.
+ pdm_d
+ pins: pdm_d.
+ function: pdm_dac, usb_vbus.
+ sdh
+ pins: sdh_cd, sdh_wp, sdh_clk_in.
+ function: sdh, sdio.
+ sdio
+ pins: sdio_clk, sdio_cmd, sdio_d0, sdio_d1, sdio_d2,
+ sdio_d3.
+ function: sdio, sdh.
+ spi1_cs2
+ pins: spi1_cs2.
+ function: spi1_cs2, usb_vbus.
+ tft
+ pins: tft_red0, tft_red1, tft_red2, tft_red3,
+ tft_red4, tft_red5, tft_red6, tft_red7,
+ tft_green0, tft_green1, tft_green2, tft_green3,
+ tft_green4, tft_green5, tft_green6, tft_green7,
+ tft_blue0, tft_blue1, tft_blue2, tft_blue3,
+ tft_blue4, tft_blue5, tft_blue6, tft_blue7,
+ tft_vdden_gd, tft_panelclk, tft_blank_ls,
+ tft_vsync_ns, tft_hsync_nr, tft_vd12acb,
+ tft_pwrsave.
+ function: tft, ext_dac, not_iqadc_stb, iqdac_stb, ts_out_1,
+ lcd_trace, phy_ringosc.
+ input-schmitt-enable: supported.
+ input-schmitt-disable: supported.
+ drive-strength: supported.
+
+ drive groups:
+
+ These all support input-schmitt-enable, input-schmitt-disable,
+ and drive-strength.
+
+ jtag
+ pins: tck, trst, tdi, tdo, tms.
+ scb1
+ pins: scb1_sdat, scb1_sclk.
+ scb2
+ pins: scb2_sdat, scb2_sclk.
+ spi0
+ pins: spi0_mclk, spi0_cs0, spi0_cs1, spi0_cs2, spi0_dout, spi0_din.
+ spi1
+ pins: spi1_mclk, spi1_cs0, spi1_cs1, spi1_cs2, spi1_dout, spi1_din.
+ uart
+ pins: uart0_txd, uart0_rxd, uart0_rts, uart0_cts,
+ uart1_txd, uart1_rxd.
+ drive_i2s
+ pins: clk_out1, i2s_din, i2s_dout0, i2s_dout1, i2s_dout2,
+ i2s_lrclk_out, i2s_bclk_out, i2s_mclk.
+ drive_pdm
+ pins: clk_out0, pdm_b, pdm_a.
+ drive_scb0
+ pins: scb0_sclk, scb0_sdat, pdm_d, pdm_c.
+ drive_sdio
+ pins: sdio_clk, sdio_cmd, sdio_d0, sdio_d1, sdio_d2, sdio_d3,
+ sdh_wp, sdh_cd, sdh_clk_in.
+
+ convenience groups:
+
+ These are just convenient groupings of pins and don't support any drive
+ configs.
+
+ uart0
+ pins: uart0_cts, uart0_rts, uart0_rxd, uart0_txd.
+ uart1
+ pins: uart1_rxd, uart1_txd.
+ scb0
+ pins: scb0_sclk, scb0_sdat.
+ i2s
+ pins: i2s_bclk_out, i2s_din, i2s_dout0, i2s_dout1, i2s_dout2,
+ i2s_lrclk_out, i2s_mclk.
+
+Example:
+
+ pinctrl: pinctrl@02005800 {
+ #gpio-range-cells = <3>;
+ compatible = "img,tz1090-pinctrl";
+ reg = <0x02005800 0xe4>;
+ };
+
+Example board file extract:
+
+ &pinctrl {
+ uart0_default: uart0 {
+ uart0_cfg {
+ tz1090,pins = "uart0_rxd",
+ "uart0_txd";
+ tz1090,function = "perip";
+ };
+ };
+ tft_default: tft {
+ tft_cfg {
+ tz1090,pins = "tft";
+ tz1090,function = "tft";
+ };
+ };
+ };
+
+ uart@02004b00 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_default>;
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/marvell,dove-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/marvell,dove-pinctrl.txt
index a648aaa..50ec351 100644
--- a/Documentation/devicetree/bindings/pinctrl/marvell,dove-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/marvell,dove-pinctrl.txt
@@ -10,29 +10,31 @@
Available mpp pins/groups and functions:
Note: brackets (x) are not part of the mpp name for marvell,function and given
only for more detailed description in this document.
+Note: pmu* also allows for Power Management functions listed below
name pins functions
================================================================================
-mpp0 0 gpio, pmu, uart2(rts), sdio0(cd), lcd0(pwm)
-mpp1 1 gpio, pmu, uart2(cts), sdio0(wp), lcd1(pwm)
+mpp0 0 gpio, pmu, uart2(rts), sdio0(cd), lcd0(pwm), pmu*
+mpp1 1 gpio, pmu, uart2(cts), sdio0(wp), lcd1(pwm), pmu*
mpp2 2 gpio, pmu, uart2(txd), sdio0(buspwr), sata(prsnt),
- uart1(rts)
+ uart1(rts), pmu*
mpp3 3 gpio, pmu, uart2(rxd), sdio0(ledctrl), sata(act),
- uart1(cts), lcd-spi(cs1)
-mpp4 4 gpio, pmu, uart3(rts), sdio1(cd), spi1(miso)
-mpp5 5 gpio, pmu, uart3(cts), sdio1(wp), spi1(cs)
-mpp6 6 gpio, pmu, uart3(txd), sdio1(buspwr), spi1(mosi)
-mpp7 7 gpio, pmu, uart3(rxd), sdio1(ledctrl), spi1(sck)
-mpp8 8 gpio, pmu, watchdog(rstout)
-mpp9 9 gpio, pmu, pex1(clkreq)
-mpp10 10 gpio, pmu, ssp(sclk)
+ uart1(cts), lcd-spi(cs1), pmu*
+mpp4 4 gpio, pmu, uart3(rts), sdio1(cd), spi1(miso), pmu*
+mpp5 5 gpio, pmu, uart3(cts), sdio1(wp), spi1(cs), pmu*
+mpp6 6 gpio, pmu, uart3(txd), sdio1(buspwr), spi1(mosi), pmu*
+mpp7 7 gpio, pmu, uart3(rxd), sdio1(ledctrl), spi1(sck), pmu*
+mpp8 8 gpio, pmu, watchdog(rstout), pmu*
+mpp9 9 gpio, pmu, pex1(clkreq), pmu*
+mpp10 10 gpio, pmu, ssp(sclk), pmu*
mpp11 11 gpio, pmu, sata(prsnt), sata-1(act), sdio0(ledctrl),
- sdio1(ledctrl), pex0(clkreq)
-mpp12 12 gpio, pmu, uart2(rts), audio0(extclk), sdio1(cd), sata(act)
+ sdio1(ledctrl), pex0(clkreq), pmu*
+mpp12 12 gpio, pmu, uart2(rts), audio0(extclk), sdio1(cd),
+ sata(act), pmu*
mpp13 13 gpio, pmu, uart2(cts), audio1(extclk), sdio1(wp),
- ssp(extclk)
-mpp14 14 gpio, pmu, uart2(txd), sdio1(buspwr), ssp(rxd)
-mpp15 15 gpio, pmu, uart2(rxd), sdio1(ledctrl), ssp(sfrm)
+ ssp(extclk), pmu*
+mpp14 14 gpio, pmu, uart2(txd), sdio1(buspwr), ssp(rxd), pmu*
+mpp15 15 gpio, pmu, uart2(rxd), sdio1(ledctrl), ssp(sfrm), pmu*
mpp16 16 gpio, uart3(rts), sdio0(cd), ac97(sdi1), lcd-spi(cs1)
mpp17 17 gpio, uart3(cts), sdio0(wp), ac97(sdi2), twsi(sda),
ac97-1(sysclko)
@@ -57,6 +59,21 @@
audio0 - i2s, ac97
twsi - none, opt1, opt2, opt3
+Power Management functions (pmu*):
+pmu-nc Pin not driven by any PM function
+pmu-low Pin driven low (0)
+pmu-high Pin driven high (1)
+pmic(sdi) Pin is used for PMIC SDI
+cpu-pwr-down Pin is used for CPU_PWRDWN
+standby-pwr-down Pin is used for STBY_PWRDWN
+core-pwr-good Pin is used for CORE_PWR_GOOD (Pins 0-7 only)
+cpu-pwr-good Pin is used for CPU_PWR_GOOD (Pins 8-15 only)
+bat-fault Pin is used for BATTERY_FAULT
+ext0-wakeup Pin is used for EXT0_WU
+ext1-wakeup Pin is used for EXT0_WU
+ext2-wakeup Pin is used for EXT0_WU
+pmu-blink Pin is used for blink function
+
Notes:
* group "mpp_audio1" allows the following functions and gpio pins:
- gpio : gpio on pins 52-57
diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra114-pinmux.txt b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra114-pinmux.txt
new file mode 100644
index 0000000..e204d00
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra114-pinmux.txt
@@ -0,0 +1,120 @@
+NVIDIA Tegra114 pinmux controller
+
+The Tegra114 pinctrl binding is very similar to the Tegra20 and Tegra30
+pinctrl binding, as described in nvidia,tegra20-pinmux.txt and
+nvidia,tegra30-pinmux.txt. In fact, this document assumes that binding as
+a baseline, and only documents the differences between the two bindings.
+
+Required properties:
+- compatible: "nvidia,tegra114-pinmux"
+- reg: Should contain the register physical address and length for each of
+ the pad control and mux registers. The first bank of address must be the
+ driver strength pad control register address and second bank address must
+ be pinmux register address.
+
+Tegra114 adds the following optional properties for pin configuration subnodes:
+- nvidia,enable-input: Integer. Enable the pin's input path. 0: no, 1: yes.
+- nvidia,open-drain: Integer. Enable open drain mode. 0: no, 1: yes.
+- nvidia,lock: Integer. Lock the pin configuration against further changes
+ until reset. 0: no, 1: yes.
+- nvidia,io-reset: Integer. Reset the IO path. 0: no, 1: yes.
+- nvidia,rcv-sel: Integer. Select VIL/VIH receivers. 0: normal, 1: high.
+- nvidia,drive-type: Integer. Valid range 0...3.
+
+As with Tegra20 and Terga30, see the Tegra TRM for complete details regarding
+which groups support which functionality.
+
+Valid values for pin and group names are:
+
+ per-pin mux groups:
+
+ These all support nvidia,function, nvidia,tristate, nvidia,pull,
+ nvidia,enable-input, nvidia,lock. Some support nvidia,open-drain,
+ nvidia,io-reset and nvidia,rcv-sel.
+
+ ulpi_data0_po1, ulpi_data1_po2, ulpi_data2_po3, ulpi_data3_po4,
+ ulpi_data4_po5, ulpi_data5_po6, ulpi_data6_po7, ulpi_data7_po0,
+ ulpi_clk_py0, ulpi_dir_py1, ulpi_nxt_py2, ulpi_stp_py3, dap3_fs_pp0,
+ dap3_din_pp1, dap3_dout_pp2, dap3_sclk_pp3, pv0, pv1, sdmmc1_clk_pz0,
+ sdmmc1_cmd_pz1, sdmmc1_dat3_py4, sdmmc1_dat2_py5, sdmmc1_dat1_py6,
+ sdmmc1_dat0_py7, clk2_out_pw5, clk2_req_pcc5, hdmi_int_pn7, ddc_scl_pv4,
+ ddc_sda_pv5, uart2_rxd_pc3, uart2_txd_pc2, uart2_rts_n_pj6,
+ uart2_cts_n_pj5, uart3_txd_pw6, uart3_rxd_pw7, uart3_cts_n_pa1,
+ uart3_rts_n_pc0, pu0, pu1, pu2, pu3, pu4, pu5, pu6, gen1_i2c_sda_pc5,
+ gen1_i2c_scl_pc4, dap4_fs_pp4, dap4_din_pp5, dap4_dout_pp6, dap4_sclk_pp7,
+ clk3_out_pee0, clk3_req_pee1, gmi_wp_n_pc7, gmi_iordy_pi5, gmi_wait_pi7,
+ gmi_adv_n_pk0, gmi_clk_pk1, gmi_cs0_n_pj0, gmi_cs1_n_pj2, gmi_cs2_n_pk3,
+ gmi_cs3_n_pk4, gmi_cs4_n_pk2, gmi_cs6_n_pi3, gmi_cs7_n_pi6, gmi_ad0_pg0,
+ gmi_ad1_pg1, gmi_ad2_pg2, gmi_ad3_pg3, gmi_ad4_pg4, gmi_ad5_pg5,
+ gmi_ad6_pg6, gmi_ad7_pg7, gmi_ad8_ph0, gmi_ad9_ph1, gmi_ad10_ph2,
+ gmi_ad11_ph3, gmi_ad12_ph4, gmi_ad13_ph5, gmi_ad14_ph6, gmi_ad15_ph7,
+ gmi_a16_pj7, gmi_a17_pb0, gmi_a18_pb1, gmi_a19_pk7, gmi_wr_n_pi0,
+ gmi_oe_n_pi1, gmi_dqs_p_pj3, gmi_rst_n_pi4, gen2_i2c_scl_pt5,
+ gen2_i2c_sda_pt6, sdmmc4_clk_pcc4, sdmmc4_cmd_pt7, sdmmc4_dat0_paa0,
+ sdmmc4_dat1_paa1, sdmmc4_dat2_paa2, sdmmc4_dat3_paa3, sdmmc4_dat4_paa4,
+ sdmmc4_dat5_paa5, sdmmc4_dat6_paa6, sdmmc4_dat7_paa7, cam_mclk_pcc0,
+ pcc1, pbb0, cam_i2c_scl_pbb1, cam_i2c_sda_pbb2, pbb3, pbb4, pbb5, pbb6,
+ pbb7, pcc2, pwr_i2c_scl_pz6, pwr_i2c_sda_pz7, kb_row0_pr0, kb_row1_pr1,
+ kb_row2_pr2, kb_row3_pr3, kb_row4_pr4, kb_row5_pr5, kb_row6_pr6,
+ kb_row7_pr7, kb_row8_ps0, kb_row9_ps1, kb_row10_ps2, kb_col0_pq0,
+ kb_col1_pq1, kb_col2_pq2, kb_col3_pq3, kb_col4_pq4, kb_col5_pq5,
+ kb_col6_pq6, kb_col7_pq7, clk_32k_out_pa0, sys_clk_req_pz5, core_pwr_req,
+ cpu_pwr_req, pwr_int_n, owr, dap1_fs_pn0, dap1_din_pn1, dap1_dout_pn2,
+ dap1_sclk_pn3, clk1_req_pee2, clk1_out_pw4, spdif_in_pk6, spdif_out_pk5,
+ dap2_fs_pa2, dap2_din_pa4, dap2_dout_pa5, dap2_sclk_pa3, dvfs_pwm_px0,
+ gpio_x1_aud_px1, gpio_x3_aud_px3, dvfs_clk_px2, gpio_x4_aud_px4,
+ gpio_x5_aud_px5, gpio_x6_aud_px6, gpio_x7_aud_px7, sdmmc3_clk_pa6,
+ sdmmc3_cmd_pa7, sdmmc3_dat0_pb7, sdmmc3_dat1_pb6, sdmmc3_dat2_pb5,
+ sdmmc3_dat3_pb4, hdmi_cec_pee3, sdmmc1_wp_n_pv3, sdmmc3_cd_n_pv2,
+ gpio_w2_aud_pw2, gpio_w3_aud_pw3, usb_vbus_en0_pn4, usb_vbus_en1_pn5,
+ sdmmc3_clk_lb_in_pee5, sdmmc3_clk_lb_out_pee4, reset_out_n.
+
+ drive groups:
+
+ These all support nvidia,pull-down-strength, nvidia,pull-up-strength,
+ nvidia,slew-rate-rising, nvidia,slew-rate-falling. Most but not all
+ support nvidia,high-speed-mode, nvidia,schmitt, nvidia,low-power-mode
+ and nvidia,drive-type.
+
+ ao1, ao2, at1, at2, at3, at4, at5, cdev1, cdev2, dap1, dap2, dap3, dap4,
+ dbg, sdio3, spi, uaa, uab, uart2, uart3, sdio1, ddc, gma, gme, gmf, gmg,
+ gmh, owr, uda.
+
+Example:
+
+ pinmux: pinmux {
+ compatible = "nvidia,tegra114-pinmux";
+ reg = <0x70000868 0x148 /* Pad control registers */
+ 0x70003000 0x40c>; /* PinMux registers */
+ };
+
+Example board file extract:
+
+ pinctrl {
+ sdmmc4_default: pinmux {
+ sdmmc4_clk_pcc4 {
+ nvidia,pins = "sdmmc4_clk_pcc4",
+ nvidia,function = "sdmmc4";
+ nvidia,pull = <0>;
+ nvidia,tristate = <0>;
+ };
+ sdmmc4_dat0_paa0 {
+ nvidia,pins = "sdmmc4_dat0_paa0",
+ "sdmmc4_dat1_paa1",
+ "sdmmc4_dat2_paa2",
+ "sdmmc4_dat3_paa3",
+ "sdmmc4_dat4_paa4",
+ "sdmmc4_dat5_paa5",
+ "sdmmc4_dat6_paa6",
+ "sdmmc4_dat7_paa7";
+ nvidia,function = "sdmmc4";
+ nvidia,pull = <2>;
+ nvidia,tristate = <0>;
+ };
+ };
+ };
+
+ sdhci@78000400 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&sdmmc4_default>;
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
index c95ea82..aeb3c99 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
@@ -126,3 +126,51 @@
whether there is any interaction between the child and intermediate parent
nodes, is again defined entirely by the binding for the individual pin
controller device.
+
+== Using generic pinconfig options ==
+
+Generic pinconfig parameters can be used by defining a separate node containing
+the applicable parameters (and optional values), like:
+
+pcfg_pull_up: pcfg_pull_up {
+ bias-pull-up;
+ drive-strength = <20>;
+};
+
+This node should then be referenced in the appropriate pinctrl node as a phandle
+and parsed in the driver using the pinconf_generic_parse_dt_config function.
+
+Supported configuration parameters are:
+
+bias-disable - disable any pin bias
+bias-high-impedance - high impedance mode ("third-state", "floating")
+bias-bus-hold - latch weakly
+bias-pull-up - pull up the pin
+bias-pull-down - pull down the pin
+bias-pull-pin-default - use pin-default pull state
+drive-push-pull - drive actively high and low
+drive-open-drain - drive with open drain
+drive-open-source - drive with open source
+drive-strength - sink or source at most X mA
+input-schmitt-enable - enable schmitt-trigger mode
+input-schmitt-disable - disable schmitt-trigger mode
+input-debounce - debounce mode with debound time X
+low-power-enable - enable low power mode
+low-power-disable - disable low power mode
+output-low - set the pin to output mode with low level
+output-high - set the pin to output mode with high level
+
+Arguments for parameters:
+
+- bias-pull-up, -down and -pin-default take as optional argument on hardware
+ supporting it the pull strength in Ohm. bias-disable will disable the pull.
+
+- drive-strength takes as argument the target strength in mA.
+
+- input-debounce takes the debounce time in usec as argument
+ or 0 to disable debouncing
+
+All parameters not listed here, do not take an argument.
+
+More in-depth documentation on these parameters can be found in
+<include/linux/pinctrl/pinconfig-generic.h>
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
index 2c81e45..5a02e30 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
@@ -1,7 +1,9 @@
One-register-per-pin type device tree based pinctrl driver
Required properties:
-- compatible : "pinctrl-single"
+- compatible : "pinctrl-single" or "pinconf-single".
+ "pinctrl-single" means that pinconf isn't supported.
+ "pinconf-single" means that generic pinconf is supported.
- reg : offset and length of the register set for the mux registers
@@ -14,8 +16,61 @@
- pinctrl-single,function-off : function off mode for disabled state if
available and same for all registers; if not specified, disabling of
pin functions is ignored
+
- pinctrl-single,bit-per-mux : boolean to indicate that one register controls
- more than one pin
+ more than one pin, for which "pinctrl-single,function-mask" property specifies
+ position mask of pin.
+
+- pinctrl-single,drive-strength : array of value that are used to configure
+ drive strength in the pinmux register. They're value of drive strength
+ current and drive strength mask.
+
+ /* drive strength current, mask */
+ pinctrl-single,power-source = <0x30 0xf0>;
+
+- pinctrl-single,bias-pullup : array of value that are used to configure the
+ input bias pullup in the pinmux register.
+
+ /* input, enabled pullup bits, disabled pullup bits, mask */
+ pinctrl-single,bias-pullup = <0 1 0 1>;
+
+- pinctrl-single,bias-pulldown : array of value that are used to configure the
+ input bias pulldown in the pinmux register.
+
+ /* input, enabled pulldown bits, disabled pulldown bits, mask */
+ pinctrl-single,bias-pulldown = <2 2 0 2>;
+
+ * Two bits to control input bias pullup and pulldown: User should use
+ pinctrl-single,bias-pullup & pinctrl-single,bias-pulldown. One bit means
+ pullup, and the other one bit means pulldown.
+ * Three bits to control input bias enable, pullup and pulldown. User should
+ use pinctrl-single,bias-pullup & pinctrl-single,bias-pulldown. Input bias
+ enable bit should be included in pullup or pulldown bits.
+ * Although driver could set PIN_CONFIG_BIAS_DISABLE, there's no property as
+ pinctrl-single,bias-disable. Because pinctrl single driver could implement
+ it by calling pulldown, pullup disabled.
+
+- pinctrl-single,input-schmitt : array of value that are used to configure
+ input schmitt in the pinmux register. In some silicons, there're two input
+ schmitt value (rising-edge & falling-edge) in the pinmux register.
+
+ /* input schmitt value, mask */
+ pinctrl-single,input-schmitt = <0x30 0x70>;
+
+- pinctrl-single,input-schmitt-enable : array of value that are used to
+ configure input schmitt enable or disable in the pinmux register.
+
+ /* input, enable bits, disable bits, mask */
+ pinctrl-single,input-schmitt-enable = <0x30 0x40 0 0x70>;
+
+- pinctrl-single,gpio-range : list of value that are used to configure a GPIO
+ range. They're value of subnode phandle, pin base in pinctrl device, pin
+ number in this range, GPIO function value of this GPIO range.
+ The number of parameters is depend on #pinctrl-single,gpio-range-cells
+ property.
+
+ /* pin base, nr pins & gpio function */
+ pinctrl-single,gpio-range = <&range 0 3 0 &range 3 9 1>;
This driver assumes that there is only one register for each pin (unless the
pinctrl-single,bit-per-mux is set), and uses the common pinctrl bindings as
@@ -42,6 +97,20 @@
device pinctrl register, 0x18 is the desired value, and 0xff is the sub mask to
be used when applying this change to the register.
+
+Optional sub-node: In case some pins could be configured as GPIO in the pinmux
+register, those pins could be defined as a GPIO range. This sub-node is required
+by pinctrl-single,gpio-range property.
+
+Required properties in sub-node:
+- #pinctrl-single,gpio-range-cells : the number of parameters after phandle in
+ pinctrl-single,gpio-range property.
+
+ range: gpio-range {
+ #pinctrl-single,gpio-range-cells = <3>;
+ };
+
+
Example:
/* SoC common file */
@@ -58,7 +127,7 @@
/* second controller instance for pins in wkup domain */
pmx_wkup: pinmux@4a31e040 {
- compatible = "pinctrl-single;
+ compatible = "pinctrl-single";
reg = <0x4a31e040 0x0038>;
#address-cells = <1>;
#size-cells = <0>;
@@ -76,6 +145,29 @@
pinctrl-single,function-mask = <0x5F>;
};
+/* third controller instance for pins in gpio domain */
+pmx_gpio: pinmux@d401e000 {
+ compatible = "pinconf-single";
+ reg = <0xd401e000 0x0330>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ pinctrl-single,register-width = <32>;
+ pinctrl-single,function-mask = <7>;
+
+ /* sparse GPIO range could be supported */
+ pinctrl-single,gpio-range = <&range 0 3 0 &range 3 9 1
+ &range 12 1 0 &range 13 29 1
+ &range 43 1 0 &range 44 49 1
+ &range 94 1 1 &range 96 2 1>;
+
+ range: gpio-range {
+ #pinctrl-single,gpio-range-cells = <3>;
+ };
+};
+
+
/* board specific .dts file */
&pmx_core {
@@ -96,6 +188,15 @@
>;
};
+ uart0_pins: pinmux_uart0_pins {
+ pinctrl-single,pins = <
+ 0x208 0 /* UART0_RXD (IOCFG138) */
+ 0x20c 0 /* UART0_TXD (IOCFG139) */
+ >;
+ pinctrl-single,bias-pulldown = <0 2 2>;
+ pinctrl-single,bias-pullup = <0 1 1>;
+ };
+
/* map uart2 pins */
uart2_pins: pinmux_uart2_pins {
pinctrl-single,pins = <
@@ -122,6 +223,11 @@
};
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_pins>;
+};
+
&uart2 {
pinctrl-names = "default";
pinctrl-0 = <&uart2_pins>;
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-sirf.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-sirf.txt
new file mode 100644
index 0000000..c596a6a
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-sirf.txt
@@ -0,0 +1,47 @@
+CSR SiRFprimaII pinmux controller
+
+Required properties:
+- compatible : "sirf,prima2-pinctrl"
+- reg : Address range of the pinctrl registers
+- interrupts : Interrupts used by every GPIO group
+- gpio-controller : Indicates this device is a GPIO controller
+- interrupt-controller : Marks the device node as an interrupt controller
+Optional properties:
+- sirf,pullups : if n-th bit of m-th bank is set, set a pullup on GPIO-n of bank m
+- sirf,pulldowns : if n-th bit of m-th bank is set, set a pulldown on GPIO-n of bank m
+
+Please refer to pinctrl-bindings.txt in this directory for details of the common
+pinctrl bindings used by client devices.
+
+SiRFprimaII's pinmux nodes act as a container for an abitrary number of subnodes.
+Each of these subnodes represents some desired configuration for a group of pins.
+
+Required subnode-properties:
+- sirf,pins : An array of strings. Each string contains the name of a group.
+- sirf,function: A string containing the name of the function to mux to the
+ group.
+
+ Valid values for group and function names can be found from looking at the
+ group and function arrays in driver files:
+ drivers/pinctrl/pinctrl-sirf.c
+
+For example, pinctrl might have subnodes like the following:
+ uart2_pins_a: uart2@0 {
+ uart {
+ sirf,pins = "uart2grp";
+ sirf,function = "uart2";
+ };
+ };
+ uart2_noflow_pins_a: uart2@1 {
+ uart {
+ sirf,pins = "uart2_nostreamctrlgrp";
+ sirf,function = "uart2_nostreamctrl";
+ };
+ };
+
+For a specific board, if it wants to use uart2 without hardware flow control,
+it can add the following to its board-specific .dts file.
+uart2: uart@0xb0070000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart2_noflow_pins_a>;
+}
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-st.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-st.txt
new file mode 100644
index 0000000..05bf82a
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-st.txt
@@ -0,0 +1,110 @@
+*ST pin controller.
+
+Each multi-function pin is controlled, driven and routed through the
+PIO multiplexing block. Each pin supports GPIO functionality (ALT0)
+and multiple alternate functions(ALT1 - ALTx) that directly connect
+the pin to different hardware blocks.
+
+When a pin is in GPIO mode, Output Enable (OE), Open Drain(OD), and
+Pull Up (PU) are driven by the related PIO block.
+
+ST pinctrl driver controls PIO multiplexing block and also interacts with
+gpio driver to configure a pin.
+
+Required properties: (PIO multiplexing block)
+- compatible : should be "st,<SOC>-<pio-block>-pinctrl"
+ like st,stih415-sbc-pinctrl, st,stih415-front-pinctrl and so on.
+- gpio-controller : Indicates this device is a GPIO controller
+- #gpio-cells : Should be one. The first cell is the pin number.
+- st,retime-pin-mask : Should be mask to specify which pins can be retimed.
+ If the property is not present, it is assumed that all the pins in the
+ bank are capable of retiming. Retiming is mainly used to improve the
+ IO timing margins of external synchronous interfaces.
+- st,bank-name : Should be a name string for this bank as
+ specified in datasheet.
+- st,syscfg : Should be a phandle of the syscfg node.
+
+Example:
+ pin-controller-sbc {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "st,stih415-sbc-pinctrl";
+ st,syscfg = <&syscfg_sbc>;
+ ranges = <0 0xfe610000 0x5000>;
+ PIO0: gpio@fe610000 {
+ gpio-controller;
+ #gpio-cells = <1>;
+ reg = <0 0x100>;
+ st,bank-name = "PIO0";
+ };
+ ...
+ pin-functions nodes follow...
+ };
+
+
+Contents of function subnode node:
+----------------------
+Required properties for pin configuration node:
+- st,pins : Child node with list of pins with configuration.
+
+Below is the format of how each pin conf should look like.
+
+<bank offset mux mode rt_type rt_delay rt_clk>
+
+Every PIO is represented with 4-7 parameters depending on retime configuration.
+Each parameter is explained as below.
+
+-bank : Should be bank phandle to which this PIO belongs.
+-offset : Offset in the PIO bank.
+-mux : Should be alternate function number associated this pin.
+ Use same numbers from datasheet.
+-mode :pin configuration is selected from one of the below values.
+ IN
+ IN_PU
+ OUT
+ BIDIR
+ BIDIR_PU
+
+-rt_type Retiming Configuration for the pin.
+ Possible retime configuration are:
+
+ ------- -------------
+ value args
+ ------- -------------
+ NICLK <delay> <clk>
+ ICLK_IO <delay> <clk>
+ BYPASS <delay>
+ DE_IO <delay> <clk>
+ SE_ICLK_IO <delay> <clk>
+ SE_NICLK_IO <delay> <clk>
+
+- delay is retime delay in pico seconds as mentioned in data sheet.
+
+- rt_clk :clk to be use for retime.
+ Possible values are:
+ CLK_A
+ CLK_B
+ CLK_C
+ CLK_D
+
+Example of mmcclk pin which is a bi-direction pull pu with retime config
+as non inverted clock retimed with CLK_B and delay of 0 pico seconds:
+
+pin-controller {
+ ...
+ mmc0 {
+ pinctrl_mmc: mmc {
+ st,pins {
+ mmcclk = <&PIO13 4 ALT4 BIDIR_PU NICLK 0 CLK_B>;
+ ...
+ };
+ };
+ ...
+ };
+};
+
+sdhci0:sdhci@fe810000{
+ ...
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_mmc>;
+};
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-vt8500.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-vt8500.txt
new file mode 100644
index 0000000..b3aa90f
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-vt8500.txt
@@ -0,0 +1,57 @@
+VIA VT8500 and Wondermedia WM8xxx-series pinmux/gpio controller
+
+These SoCs contain a combined Pinmux/GPIO module. Each pin may operate as
+either a GPIO in, GPIO out or as an alternate function (I2C, SPI etc).
+
+Required properties:
+- compatible: "via,vt8500-pinctrl", "wm,wm8505-pinctrl", "wm,wm8650-pinctrl",
+ "wm8750-pinctrl" or "wm,wm8850-pinctrl"
+- reg: Should contain the physical address of the module's registers.
+- interrupt-controller: Marks the device node as an interrupt controller.
+- #interrupt-cells: Should be two.
+- gpio-controller: Marks the device node as a GPIO controller.
+- #gpio-cells : Should be two. The first cell is the pin number and the
+ second cell is used to specify optional parameters.
+ bit 0 - active low
+
+Please refer to ../gpio/gpio.txt for a general description of GPIO bindings.
+
+Please refer to pinctrl-bindings.txt in this directory for details of the
+common pinctrl bindings used by client devices, including the meaning of the
+phrase "pin configuration node".
+
+Each pin configuration node lists the pin(s) to which it applies, and one or
+more of the mux functions to select on those pin(s), and pull-up/down
+configuration. Each subnode only affects those parameters that are explicitly
+listed. In other words, a subnode that lists only a mux function implies no
+information about any pull configuration. Similarly, a subnode that lists only
+a pull parameter implies no information about the mux function.
+
+Required subnode-properties:
+- wm,pins: An array of cells. Each cell contains the ID of a pin.
+
+Optional subnode-properties:
+- wm,function: Integer, containing the function to mux to the pin(s):
+ 0: GPIO in
+ 1: GPIO out
+ 2: alternate
+
+- wm,pull: Integer, representing the pull-down/up to apply to the pin(s):
+ 0: none
+ 1: down
+ 2: up
+
+Each of wm,function and wm,pull may contain either a single value which
+will be applied to all pins in wm,pins, or one value for each entry in
+wm,pins.
+
+Example:
+
+ pinctrl: pinctrl {
+ compatible = "wm,wm8505-pinctrl";
+ reg = <0xD8110000 0x10000>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt
new file mode 100644
index 0000000..d5dac7b
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt
@@ -0,0 +1,153 @@
+* Renesas Pin Function Controller (GPIO and Pin Mux/Config)
+
+The Pin Function Controller (PFC) is a Pin Mux/Config controller. On SH7372,
+SH73A0, R8A73A4 and R8A7740 it also acts as a GPIO controller.
+
+
+Pin Control
+-----------
+
+Required Properties:
+
+ - compatible: should be one of the following.
+ - "renesas,pfc-r8a73a4": for R8A73A4 (R-Mobile APE6) compatible pin-controller.
+ - "renesas,pfc-r8a7740": for R8A7740 (R-Mobile A1) compatible pin-controller.
+ - "renesas,pfc-r8a7778": for R8A7778 (R-Mobile M1) compatible pin-controller.
+ - "renesas,pfc-r8a7779": for R8A7779 (R-Car H1) compatible pin-controller.
+ - "renesas,pfc-r8a7790": for R8A7790 (R-Car H2) compatible pin-controller.
+ - "renesas,pfc-sh7372": for SH7372 (SH-Mobile AP4) compatible pin-controller.
+ - "renesas,pfc-sh73a0": for SH73A0 (SH-Mobile AG5) compatible pin-controller.
+
+ - reg: Base address and length of each memory resource used by the pin
+ controller hardware module.
+
+Optional properties:
+
+ - #gpio-range-cells: Mandatory when the PFC doesn't handle GPIO, forbidden
+ otherwise. Should be 3.
+
+The PFC node also acts as a container for pin configuration nodes. Please refer
+to pinctrl-bindings.txt in this directory for the definition of the term "pin
+configuration node" and for the common pinctrl bindings used by client devices.
+
+Each pin configuration node represents a desired configuration for a pin, a
+pin group, or a list of pins or pin groups. The configuration can include the
+function to select on those pin(s) and pin configuration parameters (such as
+pull-up and pull-down).
+
+Pin configuration nodes contain pin configuration properties, either directly
+or grouped in child subnodes. Both pin muxing and configuration parameters can
+be grouped in that way and referenced as a single pin configuration node by
+client devices.
+
+A configuration node or subnode must reference at least one pin (through the
+pins or pin groups properties) and contain at least a function or one
+configuration parameter. When the function is present only pin groups can be
+used to reference pins.
+
+All pin configuration nodes and subnodes names are ignored. All of those nodes
+are parsed through phandles and processed purely based on their content.
+
+Pin Configuration Node Properties:
+
+- renesas,pins : An array of strings, each string containing the name of a pin.
+- renesas,groups : An array of strings, each string containing the name of a pin
+ group.
+
+- renesas,function: A string containing the name of the function to mux to the
+ pin group(s) specified by the renesas,groups property
+
+ Valid values for pin, group and function names can be found in the group and
+ function arrays of the PFC data file corresponding to the SoC
+ (drivers/pinctrl/sh-pfc/pfc-*.c)
+
+The pin configuration parameters use the generic pinconf bindings defined in
+pinctrl-bindings.txt in this directory. The supported parameters are
+bias-disable, bias-pull-up and bias-pull-down.
+
+
+GPIO
+----
+
+On SH7372, SH73A0, R8A73A4 and R8A7740 the PFC node is also a GPIO controller
+node.
+
+Required Properties:
+
+ - gpio-controller: Marks the device node as a gpio controller.
+
+ - #gpio-cells: Should be 2. The first cell is the GPIO number and the second
+ cell specifies GPIO flags, as defined in <dt-bindings/gpio/gpio.h>. Only the
+ GPIO_ACTIVE_HIGH and GPIO_ACTIVE_LOW flags are supported.
+
+The syntax of the gpio specifier used by client nodes should be the following
+with values derived from the SoC user manual.
+
+ <[phandle of the gpio controller node]
+ [pin number within the gpio controller]
+ [flags]>
+
+On other mach-shmobile platforms GPIO is handled by the gpio-rcar driver.
+Please refer to Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt
+for documentation of the GPIO device tree bindings on those platforms.
+
+
+Examples
+--------
+
+Example 1: SH73A0 (SH-Mobile AG5) pin controller node
+
+ pfc: pfc@e6050000 {
+ compatible = "renesas,pfc-sh73a0";
+ reg = <0xe6050000 0x8000>,
+ <0xe605801c 0x1c>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+Example 2: A GPIO LED node that references a GPIO
+
+ #include <dt-bindings/gpio/gpio.h>
+
+ leds {
+ compatible = "gpio-leds";
+ led1 {
+ gpios = <&pfc 20 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+Example 3: KZM-A9-GT (SH-Mobile AG5) default pin state hog and pin control maps
+ for the MMCIF and SCIFA4 devices
+
+ &pfc {
+ pinctrl-0 = <&scifa4_pins>;
+ pinctrl-names = "default";
+
+ mmcif_pins: mmcif {
+ mux {
+ renesas,groups = "mmc0_data8_0", "mmc0_ctrl_0";
+ renesas,function = "mmc0";
+ };
+ cfg {
+ renesas,groups = "mmc0_data8_0";
+ renesas,pins = "PORT279";
+ bias-pull-up;
+ };
+ };
+
+ scifa4_pins: scifa4 {
+ renesas,groups = "scifa4_data", "scifa4_ctrl";
+ renesas,function = "scifa4";
+ };
+ };
+
+Example 4: KZM-A9-GT (SH-Mobile AG5) default pin state for the MMCIF device
+
+ &mmcif {
+ pinctrl-0 = <&mmcif_pins>;
+ pinctrl-names = "default";
+
+ bus-width = <8>;
+ vmmc-supply = <®_1p8v>;
+ status = "okay";
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt
new file mode 100644
index 0000000..b0fb101
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt
@@ -0,0 +1,97 @@
+* Rockchip Pinmux Controller
+
+The Rockchip Pinmux Controller, enables the IC
+to share one PAD to several functional blocks. The sharing is done by
+multiplexing the PAD input/output signals. For each PAD there are up to
+4 muxing options with option 0 being the use as a GPIO.
+
+Please refer to pinctrl-bindings.txt in this directory for details of the
+common pinctrl bindings used by client devices, including the meaning of the
+phrase "pin configuration node".
+
+The Rockchip pin configuration node is a node of a group of pins which can be
+used for a specific device or function. This node represents both mux and
+config of the pins in that group. The 'pins' selects the function mode(also
+named pin mode) this pin can work on and the 'config' configures various pad
+settings such as pull-up, etc.
+
+The pins are grouped into up to 5 individual pin banks which need to be
+defined as gpio sub-nodes of the pinmux controller.
+
+Required properties for iomux controller:
+ - compatible: one of "rockchip,rk2928-pinctrl", "rockchip,rk3066a-pinctrl"
+ "rockchip,rk3066b-pinctrl", "rockchip,rk3188-pinctrl"
+
+Required properties for gpio sub nodes:
+ - compatible: "rockchip,gpio-bank"
+ - reg: register of the gpio bank (different than the iomux registerset)
+ - interrupts: base interrupt of the gpio bank in the interrupt controller
+ - clocks: clock that drives this bank
+ - gpio-controller: identifies the node as a gpio controller and pin bank.
+ - #gpio-cells: number of cells in GPIO specifier. Since the generic GPIO
+ binding is used, the amount of cells must be specified as 2. See generic
+ GPIO binding documentation for description of particular cells.
+ - interrupt-controller: identifies the controller node as interrupt-parent.
+ - #interrupt-cells: the value of this property should be 2 and the interrupt
+ cells should use the standard two-cell scheme described in
+ bindings/interrupt-controller/interrupts.txt
+
+Required properties for pin configuration node:
+ - rockchip,pins: 3 integers array, represents a group of pins mux and config
+ setting. The format is rockchip,pins = <PIN_BANK PIN_BANK_IDX MUX &phandle>.
+ The MUX 0 means gpio and MUX 1 to 3 mean the specific device function.
+ The phandle of a node containing the generic pinconfig options
+ to use, as described in pinctrl-bindings.txt in this directory.
+
+Examples:
+
+#include <dt-bindings/pinctrl/rockchip.h>
+
+...
+
+pinctrl@20008000 {
+ compatible = "rockchip,rk3066a-pinctrl";
+ reg = <0x20008000 0x150>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ gpio0: gpio0@20034000 {
+ compatible = "rockchip,gpio-bank";
+ reg = <0x20034000 0x100>;
+ interrupts = <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk_gates8 9>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ ...
+
+ pcfg_pull_default: pcfg_pull_default {
+ bias-pull-pin-default
+ };
+
+ uart2 {
+ uart2_xfer: uart2-xfer {
+ rockchip,pins = <RK_GPIO1 8 1 &pcfg_pull_default>,
+ <RK_GPIO1 9 1 &pcfg_pull_default>;
+ };
+ };
+};
+
+uart2: serial@20064000 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x20064000 0x400>;
+ interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
+ reg-shift = <2>;
+ reg-io-width = <1>;
+ clocks = <&mux_uart2>;
+ status = "okay";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart2_xfer>;
+};
diff --git a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
index e97a278..36281e7 100644
--- a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
@@ -7,9 +7,15 @@
Required Properties:
- compatible: should be one of the following.
- - "samsung,pinctrl-exynos4210": for Exynos4210 compatible pin-controller.
- - "samsung,pinctrl-exynos4x12": for Exynos4x12 compatible pin-controller.
- - "samsung,pinctrl-exynos5250": for Exynos5250 compatible pin-controller.
+ - "samsung,s3c2412-pinctrl": for S3C2412-compatible pin-controller,
+ - "samsung,s3c2416-pinctrl": for S3C2416-compatible pin-controller,
+ - "samsung,s3c2440-pinctrl": for S3C2440-compatible pin-controller,
+ - "samsung,s3c2450-pinctrl": for S3C2450-compatible pin-controller,
+ - "samsung,s3c64xx-pinctrl": for S3C64xx-compatible pin-controller,
+ - "samsung,exynos4210-pinctrl": for Exynos4210 compatible pin-controller.
+ - "samsung,exynos4x12-pinctrl": for Exynos4x12 compatible pin-controller.
+ - "samsung,exynos5250-pinctrl": for Exynos5250 compatible pin-controller.
+ - "samsung,exynos5420-pinctrl": for Exynos5420 compatible pin-controller.
- reg: Base address of the pin controller hardware module and length of
the address space it occupies.
@@ -20,8 +26,18 @@
- gpio-controller: identifies the node as a gpio controller and pin bank.
- #gpio-cells: number of cells in GPIO specifier. Since the generic GPIO
- binding is used, the amount of cells must be specified as 2. See generic
- GPIO binding documentation for description of particular cells.
+ binding is used, the amount of cells must be specified as 2. See the below
+ mentioned gpio binding representation for description of particular cells.
+
+ Eg: <&gpx2 6 0>
+ <[phandle of the gpio controller node]
+ [pin number within the gpio controller]
+ [flags]>
+
+ Values for gpio specifier:
+ - Pin number: is a value between 0 to 7.
+ - Flags: 0 - Active High
+ 1 - Active Low
- Pin mux/config groups as child nodes: The pin mux (selecting pin function
mode) and pin config (pull up/down, driver strength) settings are represented
@@ -105,6 +121,12 @@
- compatible: identifies the type of the external wakeup interrupt controller
The possible values are:
+ - samsung,s3c2410-wakeup-eint: represents wakeup interrupt controller
+ found on Samsung S3C24xx SoCs except S3C2412 and S3C2413,
+ - samsung,s3c2412-wakeup-eint: represents wakeup interrupt controller
+ found on Samsung S3C2412 and S3C2413 SoCs,
+ - samsung,s3c64xx-wakeup-eint: represents wakeup interrupt controller
+ found on Samsung S3C64xx SoCs,
- samsung,exynos4210-wakeup-eint: represents wakeup interrupt controller
found on Samsung Exynos4210 SoC.
- interrupt-parent: phandle of the interrupt parent to which the external
@@ -142,7 +164,7 @@
Example: A pin-controller node with pin banks:
pinctrl_0: pinctrl@11400000 {
- compatible = "samsung,pinctrl-exynos4210";
+ compatible = "samsung,exynos4210-pinctrl";
reg = <0x11400000 0x1000>;
interrupts = <0 47 0>;
@@ -185,7 +207,7 @@
Example 1: A pin-controller node with pin groups.
pinctrl_0: pinctrl@11400000 {
- compatible = "samsung,pinctrl-exynos4210";
+ compatible = "samsung,exynos4210-pinctrl";
reg = <0x11400000 0x1000>;
interrupts = <0 47 0>;
@@ -230,7 +252,7 @@
Example 2: A pin-controller node with external wakeup interrupt controller node.
pinctrl_1: pinctrl@11000000 {
- compatible = "samsung,pinctrl-exynos4210";
+ compatible = "samsung,exynos4210-pinctrl";
reg = <0x11000000 0x1000>;
interrupts = <0 46 0>
@@ -263,3 +285,33 @@
pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
}
+
+Example 5: A display port client node that supports 'default' pinctrl state
+ and gpio binding.
+
+ display-port-controller {
+ /* ... */
+
+ samsung,hpd-gpio = <&gpx2 6 0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&dp_hpd>;
+ };
+
+Example 6: Request the gpio for display port controller
+
+ static int exynos_dp_probe(struct platform_device *pdev)
+ {
+ int hpd_gpio, ret;
+ struct device *dev = &pdev->dev;
+ struct device_node *dp_node = dev->of_node;
+
+ /* ... */
+
+ hpd_gpio = of_get_named_gpio(dp_node, "samsung,hpd-gpio", 0);
+
+ /* ... */
+
+ ret = devm_gpio_request_one(&pdev->dev, hpd_gpio, GPIOF_IN,
+ "hpd_gpio");
+ /* ... */
+ }
diff --git a/Documentation/devicetree/bindings/pinctrl/ste,abx500.txt b/Documentation/devicetree/bindings/pinctrl/ste,abx500.txt
new file mode 100644
index 0000000..e3865e1
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/ste,abx500.txt
@@ -0,0 +1,352 @@
+ST Ericsson abx500 pinmux controller
+
+Required properties:
+- compatible: "stericsson,ab8500-gpio", "stericsson,ab8540-gpio",
+ "stericsson,ab8505-gpio", "stericsson,ab9540-gpio",
+
+Please refer to pinctrl-bindings.txt in this directory for details of the
+common pinctrl bindings used by client devices, including the meaning of the
+phrase "pin configuration node".
+
+ST Ericsson's pin configuration nodes act as a container for an arbitrary number of
+subnodes. Each of these subnodes represents some desired configuration for a
+pin, a group, or a list of pins or groups. This configuration can include the
+mux function to select on those pin(s)/group(s), and various pin configuration
+parameters, such as input, output, pull up, pull down...
+
+The name of each subnode is not important; all subnodes should be enumerated
+and processed purely based on their content.
+
+Required subnode-properties:
+- ste,pins : An array of strings. Each string contains the name of a pin or
+ group.
+
+Optional subnode-properties:
+- ste,function: A string containing the name of the function to mux to the
+ pin or group.
+
+- generic pin configuration option to use. Example :
+
+ default_cfg {
+ ste,pins = "GPIO1";
+ bias-disable;
+ };
+
+- ste,config: Handle of pin configuration node containing the generic
+ pinconfig options to use, as described in pinctrl-bindings.txt in
+ this directory. Example :
+
+ pcfg_bias_disable: pcfg_bias_disable {
+ bias-disable;
+ };
+
+ default_cfg {
+ ste,pins = "GPIO1";
+ ste.config = <&pcfg_bias_disable>;
+ };
+
+Example board file extract:
+
+&pinctrl_abx500 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&sysclkreq2_default_mode>, <&sysclkreq3_default_mode>, <&gpio3_default_mode>, <&sysclkreq6_default_mode>, <&pwmout1_default_mode>, <&pwmout2_default_mode>, <&pwmout3_default_mode>, <&adi1_default_mode>, <&dmic12_default_mode>, <&dmic34_default_mode>, <&dmic56_default_mode>, <&sysclkreq5_default_mode>, <&batremn_default_mode>, <&service_default_mode>, <&pwrctrl0_default_mode>, <&pwrctrl1_default_mode>, <&pwmextvibra1_default_mode>, <&pwmextvibra2_default_mode>, <&gpio51_default_mode>, <&gpio52_default_mode>, <&gpio53_default_mode>, <&gpio54_default_mode>, <&pdmclkdat_default_mode>;
+
+ sysclkreq2 {
+ sysclkreq2_default_mode: sysclkreq2_default {
+ default_mux {
+ ste,function = "sysclkreq";
+ ste,pins = "sysclkreq2_d_1";
+ };
+ default_cfg {
+ ste,pins = "GPIO1";
+ bias-disable;
+ };
+ };
+ };
+ sysclkreq3 {
+ sysclkreq3_default_mode: sysclkreq3_default {
+ default_mux {
+ ste,function = "sysclkreq";
+ ste,pins = "sysclkreq3_d_1";
+ };
+ default_cfg {
+ ste,pins = "GPIO2";
+ output-low;
+ };
+ };
+ };
+ gpio3 {
+ gpio3_default_mode: gpio3_default {
+ default_mux {
+ ste,function = "gpio";
+ ste,pins = "gpio3_a_1";
+ };
+ default_cfg {
+ ste,pins = "GPIO3";
+ output-low;
+ };
+ };
+ };
+ sysclkreq6 {
+ sysclkreq6_default_mode: sysclkreq6_default {
+ default_mux {
+ ste,function = "sysclkreq";
+ ste,pins = "sysclkreq6_d_1";
+ };
+ default_cfg {
+ ste,pins = "GPIO4";
+ bias-disable;
+ };
+ };
+ };
+ pwmout1 {
+ pwmout1_default_mode: pwmout1_default {
+ default_mux {
+ ste,function = "pwmout";
+ ste,pins = "pwmout1_d_1";
+ };
+ default_cfg {
+ ste,pins = "GPIO14";
+ output-low;
+ };
+ };
+ };
+ pwmout2 {
+ pwmout2_default_mode: pwmout2_default {
+ pwmout2_default_mux {
+ ste,function = "pwmout";
+ ste,pins = "pwmout2_d_1";
+ };
+ pwmout2_default_cfg {
+ ste,pins = "GPIO15";
+ output-low;
+ };
+ };
+ };
+ pwmout3 {
+ pwmout3_default_mode: pwmout3_default {
+ pwmout3_default_mux {
+ ste,function = "pwmout";
+ ste,pins = "pwmout3_d_1";
+ };
+ pwmout3_default_cfg {
+ ste,pins = "GPIO16";
+ output-low;
+ };
+ };
+ };
+ adi1 {
+
+ adi1_default_mode: adi1_default {
+ adi1_default_mux {
+ ste,function = "adi1";
+ ste,pins = "adi1_d_1";
+ };
+ adi1_default_cfg1 {
+ ste,pins = "GPIO17","GPIO19","GPIO20";
+ bias-disable;
+ };
+ adi1_default_cfg2 {
+ ste,pins = "GPIO18";
+ output-low;
+ };
+ };
+ };
+ dmic12 {
+ dmic12_default_mode: dmic12_default {
+ dmic12_default_mux {
+ ste,function = "dmic";
+ ste,pins = "dmic12_d_1";
+ };
+ dmic12_default_cfg1 {
+ ste,pins = "GPIO27";
+ output-low;
+ };
+ dmic12_default_cfg2 {
+ ste,pins = "GPIO28";
+ bias-disable;
+ };
+ };
+ };
+ dmic34 {
+ dmic34_default_mode: dmic34_default {
+ dmic34_default_mux {
+ ste,function = "dmic";
+ ste,pins = "dmic34_d_1";
+ };
+ dmic34_default_cfg1 {
+ ste,pins = "GPIO29";
+ output-low;
+ };
+ dmic34_default_cfg2 {
+ ste,pins = "GPIO30";
+ bias-disable;{
+
+ };
+ };
+ };
+ dmic56 {
+ dmic56_default_mode: dmic56_default {
+ dmic56_default_mux {
+ ste,function = "dmic";
+ ste,pins = "dmic56_d_1";
+ };
+ dmic56_default_cfg1 {
+ ste,pins = "GPIO31";
+ output-low;
+ };
+ dmic56_default_cfg2 {
+ ste,pins = "GPIO32";
+ bias-disable;
+ };
+ };
+ };
+ sysclkreq5 {
+ sysclkreq5_default_mode: sysclkreq5_default {
+ sysclkreq5_default_mux {
+ ste,function = "sysclkreq";
+ ste,pins = "sysclkreq5_d_1";
+ };
+ sysclkreq5_default_cfg {
+ ste,pins = "GPIO42";
+ output-low;
+ };
+ };
+ };
+ batremn {
+ batremn_default_mode: batremn_default {
+ batremn_default_mux {
+ ste,function = "batremn";
+ ste,pins = "batremn_d_1";
+ };
+ batremn_default_cfg {
+ ste,pins = "GPIO43";
+ bias-disable;
+ };
+ };
+ };
+ service {
+ service_default_mode: service_default {
+ service_default_mux {
+ ste,function = "service";
+ ste,pins = "service_d_1";
+ };
+ service_default_cfg {
+ ste,pins = "GPIO44";
+ bias-disable;
+ };
+ };
+ };
+ pwrctrl0 {
+ pwrctrl0_default_mux: pwrctrl0_mux {
+ pwrctrl0_default_mux {
+ ste,function = "pwrctrl";
+ ste,pins = "pwrctrl0_d_1";
+ };
+ };
+ pwrctrl0_default_mode: pwrctrl0_default {
+ pwrctrl0_default_cfg {
+ ste,pins = "GPIO45";
+ bias-disable;
+ };
+ };
+ };
+ pwrctrl1 {
+ pwrctrl1_default_mux: pwrctrl1_mux {
+ pwrctrl1_default_mux {
+ ste,function = "pwrctrl";
+ ste,pins = "pwrctrl1_d_1";
+ };
+ };
+ pwrctrl1_default_mode: pwrctrl1_default {
+ pwrctrl1_default_cfg {
+ ste,pins = "GPIO46";
+ bias-disable;
+ };
+ };
+ };
+ pwmextvibra1 {
+ pwmextvibra1_default_mode: pwmextvibra1_default {
+ pwmextvibra1_default_mux {
+ ste,function = "pwmextvibra";
+ ste,pins = "pwmextvibra1_d_1";
+ };
+ pwmextvibra1_default_cfg {
+ ste,pins = "GPIO47";
+ bias-disable;
+ };
+ };
+ };
+ pwmextvibra2 {
+ pwmextvibra2_default_mode: pwmextvibra2_default {
+ pwmextvibra2_default_mux {
+ ste,function = "pwmextvibra";
+ ste,pins = "pwmextvibra2_d_1";
+ };
+ pwmextvibra1_default_cfg {
+ ste,pins = "GPIO48";
+ bias-disable;
+ };
+ };
+ };
+ gpio51 {
+ gpio51_default_mode: gpio51_default {
+ gpio51_default_mux {
+ ste,function = "gpio";
+ ste,pins = "gpio51_a_1";
+ };
+ gpio51_default_cfg {
+ ste,pins = "GPIO51";
+ output-low;
+ };
+ };
+ };
+ gpio52 {
+ gpio52_default_mode: gpio52_default {
+ gpio52_default_mux {
+ ste,function = "gpio";
+ ste,pins = "gpio52_a_1";
+ };
+ gpio52_default_cfg {
+ ste,pins = "GPIO52";
+ bias-pull-down;
+ };
+ };
+ };
+ gpio53 {
+ gpio53_default_mode: gpio53_default {
+ gpio53_default_mux {
+ ste,function = "gpio";
+ ste,pins = "gpio53_a_1";
+ };
+ gpio53_default_cfg {
+ ste,pins = "GPIO53";
+ bias-pull-down;
+ };
+ };
+ };
+ gpio54 {
+ gpio54_default_mode: gpio54_default {
+ gpio54_default_mux {
+ ste,function = "gpio";
+ ste,pins = "gpio54_a_1";
+ };
+ gpio54_default_cfg {
+ ste,pins = "GPIO54";
+ output-low;
+ };
+ };
+ };
+ pdmclkdat {
+ pdmclkdat_default_mode: pdmclkdat_default {
+ pdmclkdat_default_mux {
+ ste,function = "pdm";
+ ste,pins = "pdmclkdat_d_1";
+ };
+ pdmclkdat_default_cfg {
+ ste,pins = "GPIO55", "GPIO56";
+ bias-disable;
+ };
+ };
+ };
+};
diff --git a/Documentation/devicetree/bindings/pinctrl/ste,nomadik.txt b/Documentation/devicetree/bindings/pinctrl/ste,nomadik.txt
new file mode 100644
index 0000000..9a2f3f4
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/ste,nomadik.txt
@@ -0,0 +1,140 @@
+ST Ericsson Nomadik pinmux controller
+
+Required properties:
+- compatible: "stericsson,nmk-pinctrl", "stericsson,nmk-pinctrl-db8540",
+ "stericsson,nmk-pinctrl-stn8815"
+- reg: Should contain the register physical address and length of the PRCMU.
+
+Please refer to pinctrl-bindings.txt in this directory for details of the
+common pinctrl bindings used by client devices, including the meaning of the
+phrase "pin configuration node".
+
+ST Ericsson's pin configuration nodes act as a container for an arbitrary number of
+subnodes. Each of these subnodes represents some desired configuration for a
+pin, a group, or a list of pins or groups. This configuration can include the
+mux function to select on those pin(s)/group(s), and various pin configuration
+parameters, such as input, output, pull up, pull down...
+
+The name of each subnode is not important; all subnodes should be enumerated
+and processed purely based on their content.
+
+Required subnode-properties:
+- ste,pins : An array of strings. Each string contains the name of a pin or
+ group.
+
+Optional subnode-properties:
+- ste,function: A string containing the name of the function to mux to the
+ pin or group.
+
+- ste,config: Handle of pin configuration node (e.g. ste,config = <&slpm_in_wkup_pdis>)
+
+- ste,input : <0/1/2>
+ 0: input with no pull
+ 1: input with pull up,
+ 2: input with pull down,
+
+- ste,output: <0/1/2>
+ 0: output low,
+ 1: output high,
+ 2: output (value is not specified).
+
+- ste,sleep: <0/1>
+ 0: sleep mode disable,
+ 1: sleep mode enable.
+
+- ste,sleep-input: <0/1/2/3>
+ 0: sleep input with no pull,
+ 1: sleep input with pull up,
+ 2: sleep input with pull down.
+ 3: sleep input and keep last input configuration (no pull, pull up or pull down).
+
+- ste,sleep-output: <0/1/2>
+ 0: sleep output low,
+ 1: sleep output high,
+ 2: sleep output (value is not specified).
+
+- ste,sleep-gpio: <0/1>
+ 0: disable sleep gpio mode,
+ 1: enable sleep gpio mode.
+
+- ste,sleep-wakeup: <0/1>
+ 0: wake-up detection enabled,
+ 1: wake-up detection disabled.
+
+- ste,sleep-pull-disable: <0/1>
+ 0: GPIO pull-up or pull-down resistor is enabled, when pin is an input,
+ 1: GPIO pull-up and pull-down resistor are disabled.
+
+Example board file extract:
+
+ pinctrl@80157000 {
+ compatible = "stericsson,nmk-pinctrl";
+ reg = <0x80157000 0x2000>;
+
+ pinctrl-names = "default";
+
+ slpm_in_wkup_pdis: slpm_in_wkup_pdis {
+ ste,sleep = <1>;
+ ste,sleep-input = <3>;
+ ste,sleep-wakeup = <1>;
+ ste,sleep-pull-disable = <0>;
+ };
+
+ slpm_out_hi_wkup_pdis: slpm_out_hi_wkup_pdis {
+ ste,sleep = <1>;
+ ste,sleep-output = <1>;
+ ste,sleep-wakeup = <1>;
+ ste,sleep-pull-disable = <0>;
+ };
+
+ slpm_out_wkup_pdis: slpm_out_wkup_pdis {
+ ste,sleep = <1>;
+ ste,sleep-output = <2>;
+ ste,sleep-wakeup = <1>;
+ ste,sleep-pull-disable = <0>;
+ };
+
+ uart0 {
+ uart0_default_mux: uart0_mux {
+ u0_default_mux {
+ ste,function = "u0";
+ ste,pins = "u0_a_1";
+ };
+ };
+ uart0_default_mode: uart0_default {
+ uart0_default_cfg1 {
+ ste,pins = "GPIO0", "GPIO2";
+ ste,input = <1>;
+ };
+
+ uart0_default_cfg2 {
+ ste,pins = "GPIO1", "GPIO3";
+ ste,output = <1>;
+ };
+ };
+ uart0_sleep_mode: uart0_sleep {
+ uart0_sleep_cfg1 {
+ ste,pins = "GPIO0", "GPIO2";
+ ste,config = <&slpm_in_wkup_pdis>;
+ };
+ uart0_sleep_cfg2 {
+ ste,pins = "GPIO1";
+ ste,config = <&slpm_out_hi_wkup_pdis>;
+ };
+ uart0_sleep_cfg3 {
+ ste,pins = "GPIO3";
+ ste,config = <&slpm_out_wkup_pdis>;
+ };
+ };
+ };
+ };
+
+ uart@80120000 {
+ compatible = "arm,pl011", "arm,primecell";
+ reg = <0x80120000 0x1000>;
+ interrupts = <0 11 0x4>;
+
+ pinctrl-names = "default","sleep";
+ pinctrl-0 = <&uart0_default_mux>, <&uart0_default_mode>;
+ pinctrl-1 = <&uart0_sleep_mode>;
+ };
diff --git a/Documentation/devicetree/bindings/power_supply/lp8727_charger.txt b/Documentation/devicetree/bindings/power_supply/lp8727_charger.txt
new file mode 100644
index 0000000..2246bc5
--- /dev/null
+++ b/Documentation/devicetree/bindings/power_supply/lp8727_charger.txt
@@ -0,0 +1,44 @@
+Binding for TI/National Semiconductor LP8727 Charger
+
+Required properties:
+- compatible: "ti,lp8727"
+- reg: I2C slave address 27h
+
+Optional properties:
+- interrupt-parent: interrupt controller node (see interrupt binding[0])
+- interrupts: interrupt specifier (see interrupt binding[0])
+- debounce-ms: interrupt debounce time. (u32)
+
+AC and USB charging parameters
+- charger-type: "ac" or "usb" (string)
+- eoc-level: value of 'enum lp8727_eoc_level' (u8)
+- charging-current: value of 'enum lp8727_ichg' (u8)
+
+[0]: Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
+
+Example)
+
+lp8727@27 {
+ compatible = "ti,lp8727";
+ reg = <0x27>;
+
+ /* GPIO 134 is used for LP8728 interrupt pin */
+ interrupt-parent = <&gpio5>; /* base = 128 */
+ interrupts = <6 0x2>; /* offset = 6, falling edge type */
+
+ debounce-ms = <300>;
+
+ /* AC charger: 5% EOC and 500mA charging current */
+ ac {
+ charger-type = "ac";
+ eoc-level = /bits/ 8 <0>;
+ charging-current = /bits/ 8 <4>;
+ };
+
+ /* USB charger: 10% EOC and 400mA charging current */
+ usb {
+ charger-type = "usb";
+ eoc-level = /bits/ 8 <1>;
+ charging-current = /bits/ 8 <2>;
+ };
+};
diff --git a/Documentation/devicetree/bindings/power_supply/max8925_batter.txt b/Documentation/devicetree/bindings/power_supply/max8925_batter.txt
new file mode 100644
index 0000000..d7e3e0c
--- /dev/null
+++ b/Documentation/devicetree/bindings/power_supply/max8925_batter.txt
@@ -0,0 +1,18 @@
+max8925-battery bindings
+~~~~~~~~~~~~~~~~
+
+Optional properties :
+ - batt-detect: whether support battery detect
+ - topoff-threshold: set charging current in topoff mode
+ - fast-charge: set charging current in fast mode
+ - no-temp-support: whether support temperature protection detect
+ - no-insert-detect: whether support insert detect
+
+Example:
+ charger {
+ batt-detect = <0>;
+ topoff-threshold = <1>;
+ fast-charge = <7>;
+ no-temp-support = <0>;
+ no-insert-detect = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/power_supply/power_supply.txt b/Documentation/devicetree/bindings/power_supply/power_supply.txt
new file mode 100644
index 0000000..8391bfa
--- /dev/null
+++ b/Documentation/devicetree/bindings/power_supply/power_supply.txt
@@ -0,0 +1,23 @@
+Power Supply Core Support
+
+Optional Properties:
+ - power-supplies : This property is added to a supply in order to list the
+ devices which supply it power, referenced by their phandles.
+
+Example:
+
+ usb-charger: power@e {
+ compatible = "some,usb-charger";
+ ...
+ };
+
+ ac-charger: power@c {
+ compatible = "some,ac-charger";
+ ...
+ };
+
+ battery@b {
+ compatible = "some,battery";
+ ...
+ power-supplies = <&usb-charger>, <&ac-charger>;
+ };
diff --git a/Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt b/Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt
new file mode 100644
index 0000000..0347d83
--- /dev/null
+++ b/Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt
@@ -0,0 +1,13 @@
+* QNAP Power Off
+
+QNAP NAS devices have a microcontroller controlling the main power
+supply. This microcontroller is connected to UART1 of the Kirkwood and
+Orion5x SoCs. Sending the character 'A', at 19200 baud, tells the
+microcontroller to turn the power off. This driver adds a handler to
+pm_power_off which is called to turn the power off.
+
+Required Properties:
+- compatible: Should be "qnap,power-off"
+
+- reg: Address and length of the register set for UART1
+- clocks: tclk clock
diff --git a/Documentation/devicetree/bindings/power_supply/restart-poweroff.txt b/Documentation/devicetree/bindings/power_supply/restart-poweroff.txt
new file mode 100644
index 0000000..5776e68
--- /dev/null
+++ b/Documentation/devicetree/bindings/power_supply/restart-poweroff.txt
@@ -0,0 +1,8 @@
+* Restart Power Off
+
+Buffalo Linkstation LS-XHL and LS-CHLv2, and other devices power off
+by restarting and letting u-boot keep hold of the machine until the
+user presses a button.
+
+Required Properties:
+- compatible: Should be "restart-poweroff"
diff --git a/Documentation/devicetree/bindings/power_supply/tps65090.txt b/Documentation/devicetree/bindings/power_supply/tps65090.txt
new file mode 100644
index 0000000..8e5e0d3
--- /dev/null
+++ b/Documentation/devicetree/bindings/power_supply/tps65090.txt
@@ -0,0 +1,17 @@
+TPS65090 Frontend PMU with Switchmode Charger
+
+Required Properties:
+-compatible: "ti,tps65090-charger"
+
+Optional Properties:
+-ti,enable-low-current-chrg: Enables charging when a low current is detected
+ while the default logic is to stop charging.
+
+This node is a subnode of the tps65090 PMIC.
+
+Example:
+
+ tps65090-charger {
+ compatible = "ti,tps65090-charger";
+ ti,enable-low-current-chrg;
+ };
diff --git a/Documentation/devicetree/bindings/powerpc/4xx/emac.txt b/Documentation/devicetree/bindings/powerpc/4xx/emac.txt
index 2161334a..712baf6 100644
--- a/Documentation/devicetree/bindings/powerpc/4xx/emac.txt
+++ b/Documentation/devicetree/bindings/powerpc/4xx/emac.txt
@@ -1,7 +1,7 @@
4xx/Axon EMAC ethernet nodes
The EMAC ethernet controller in IBM and AMCC 4xx chips, and also
- the Axon bridge. To operate this needs to interact with a ths
+ the Axon bridge. To operate this needs to interact with a this
special McMAL DMA controller, and sometimes an RGMII or ZMII
interface. In addition to the nodes and properties described
below, the node for the OPB bus on which the EMAC sits must have a
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/cpus.txt b/Documentation/devicetree/bindings/powerpc/fsl/cpus.txt
new file mode 100644
index 0000000..922c30a
--- /dev/null
+++ b/Documentation/devicetree/bindings/powerpc/fsl/cpus.txt
@@ -0,0 +1,22 @@
+===================================================================
+Power Architecture CPU Binding
+Copyright 2013 Freescale Semiconductor Inc.
+
+Power Architecture CPUs in Freescale SOCs are represented in device trees as
+per the definition in ePAPR.
+
+In addition to the ePAPR definitions, the properties defined below may be
+present on CPU nodes.
+
+PROPERTIES
+
+ - fsl,eref-*
+ Usage: optional
+ Value type: <empty>
+ Definition: The EREF (EREF: A Programmer.s Reference Manual for
+ Freescale Power Architecture) defines the architecture for Freescale
+ Power CPUs. The EREF defines some architecture categories not defined
+ by the Power ISA. For these EREF-specific categories, the existence of
+ a property named fsl,eref-[CAT], where [CAT] is the abbreviated category
+ name with all uppercase letters converted to lowercase, indicates that
+ the category is supported by the implementation.
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/guts.txt b/Documentation/devicetree/bindings/powerpc/fsl/guts.txt
index 9e7a241..7f150b5 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/guts.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/guts.txt
@@ -17,9 +17,20 @@
contains a functioning "reset control register" (i.e. the board
is wired to reset upon setting the HRESET_REQ bit in this register).
-Example:
+ - fsl,liodn-bits : Indicates the number of defined bits in the LIODN
+ registers, for those SOCs that have a PAMU device.
+
+Examples:
global-utilities@e0000 { /* global utilities block */
compatible = "fsl,mpc8548-guts";
reg = <e0000 1000>;
fsl,has-rstcr;
};
+
+ guts: global-utilities@e0000 {
+ compatible = "fsl,qoriq-device-config-1.0";
+ reg = <0xe0000 0xe00>;
+ fsl,has-rstcr;
+ #sleep-cells = <1>;
+ fsl,liodn-bits = <12>;
+ };
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/interlaken-lac.txt b/Documentation/devicetree/bindings/powerpc/fsl/interlaken-lac.txt
new file mode 100644
index 0000000..641bc13
--- /dev/null
+++ b/Documentation/devicetree/bindings/powerpc/fsl/interlaken-lac.txt
@@ -0,0 +1,309 @@
+===============================================================================
+Freescale Interlaken Look-Aside Controller Device Bindings
+Copyright 2012 Freescale Semiconductor Inc.
+
+CONTENTS
+ - Interlaken Look-Aside Controller (LAC) Node
+ - Example LAC Node
+ - Interlaken Look-Aside Controller (LAC) Software Portal Node
+ - Interlaken Look-Aside Controller (LAC) Software Portal Child Nodes
+ - Example LAC SWP Node with Child Nodes
+
+==============================================================================
+Interlaken Look-Aside Controller (LAC) Node
+
+DESCRIPTION
+
+The Interlaken is a narrow, high speed channelized chip-to-chip interface. To
+facilitate interoperability between a data path device and a look-aside
+co-processor, the Interlaken Look-Aside protocol is defined for short
+transaction-related transfers. Although based on the Interlaken protocol,
+Interlaken Look-Aside is not directly compatible with Interlaken and can be
+considered a different operation mode.
+
+The Interlaken LA controller connects internal platform to Interlaken serial
+interface. It accepts LA command through software portals, which are system
+memory mapped 4KB spaces. The LA commands are then translated into the
+Interlaken control words and data words, which are sent on TX side to TCAM
+through SerDes lanes.
+
+There are two 4KiB spaces defined within the LAC global register memory map.
+There is a full register set at 0x0000-0x0FFF (also known as the "hypervisor"
+version), and a subset at 0x1000-0x1FFF. The former is a superset of the
+latter, and includes certain registers that should not be accessible to
+partitioned software. Separate nodes are used for each region, with a phandle
+linking the hypervisor node to the normal operating node.
+
+PROPERTIES
+
+ - compatible
+ Usage: required
+ Value type: <string>
+ Definition: Must include "fsl,interlaken-lac". This represents only
+ those LAC CCSR registers not protected in partitioned
+ software. The version of the device is determined by the LAC
+ IP Block Revision Register (IPBRR0) at offset 0x0BF8.
+
+ Table of correspondences between IPBRR0 values and example
+ chips:
+ Value Device
+ ----------- -------
+ 0x02000100 T4240
+
+ The Hypervisor node has a different compatible. It must include
+ "fsl,interlaken-lac-hv". This node represents the protected
+ LAC register space and is required except inside a partition
+ where access to the hypervisor node is to be denied.
+
+ - fsl,non-hv-node
+ Usage: required in "fsl,interlaken-lac-hv"
+ Value type: <phandle>
+ Definition: Points to the non-protected LAC CCSR mapped register space
+ node.
+
+ - reg
+ Usage: required
+ Value type: <prop-encoded-array>
+ Definition: A standard property. The first resource represents the
+ Interlaken LAC configuration registers.
+
+ - interrupts:
+ Usage: required in non-hv node only
+ Value type: <prop-encoded-array>
+ Definition: Interrupt mapping for Interlaken LAC error IRQ.
+
+EXAMPLE
+ lac: lac@229000 {
+ compatible = "fsl,interlaken-lac"
+ reg = <0x229000 0x1000>;
+ interrupts = <16 2 1 18>;
+ };
+
+ lac-hv@228000 {
+ compatible = "fsl,interlaken-lac-hv"
+ reg = <0x228000 0x1000>;
+ fsl,non-hv-node = <&lac>;
+ };
+
+===============================================================================
+Interlaken Look-Aside Controller (LAC) Software Portal Container Node
+
+DESCRIPTION
+The Interlaken Look-Aside Controller (LAC) utilizes Software Portals to accept
+Interlaken Look-Aside (ILA) commands. The Interlaken LAC software portal
+memory map occupies 128KB of memory space. The software portal memory space is
+intended to be cache-enabled. WIMG for each software space is required to be
+0010 if stashing is enabled; otherwise, WIMG can be 0000 or 0010.
+
+PROPERTIES
+
+ - #address-cells
+ Usage: required
+ Value type: <u32>
+ Definition: A standard property. Must have a value of 1.
+
+ - #size-cells
+ Usage: required
+ Value type: <u32>
+ Definition: A standard property. Must have a value of 1.
+
+ - compatible
+ Usage: required
+ Value type: <string>
+ Definition: Must include "fsl,interlaken-lac-portals"
+
+ - ranges
+ Usage: required
+ Value type: <prop-encoded-array>
+ Definition: A standard property. Specifies the address and length
+ of the LAC portal memory space.
+
+===============================================================================
+Interlaken Look-Aside Controller (LAC) Software Portals Child Nodes
+
+DESCRIPTION
+There are up to 24 available software portals with each software portal
+requiring 4KB of consecutive memory within the software portal memory mapped
+space.
+
+PROPERTIES
+
+ - compatible
+ Usage: required
+ Value type: <string>
+ Definition: Must include "fsl,interlaken-lac-portal-vX.Y" where X is
+ the Major version (IP_MJ) found in the LAC IP Block Revision
+ Register (IPBRR0), at offset 0x0BF8, and Y is the Minor version
+ (IP_MN).
+
+ Table of correspondences between version values and example chips:
+ Value Device
+ ------ -------
+ 1.0 T4240
+
+ - reg
+ Usage: required
+ Value type: <prop-encoded-array>
+ Definition: A standard property. The first resource represents the
+ Interlaken LAC software portal registers.
+
+ - fsl,liodn
+ Value type: <u32>
+ Definition: The logical I/O device number (LIODN) for this device. The
+ LIODN is a number expressed by this device and used to perform
+ look-ups in the IOMMU (PAMU) address table when performing
+ DMAs. This property is automatically added by u-boot.
+
+===============================================================================
+EXAMPLE
+
+lac-portals {
+ #address-cells = <0x1>;
+ #size-cells = <0x1>;
+ compatible = "fsl,interlaken-lac-portals";
+ ranges = <0x0 0xf 0xf4400000 0x20000>;
+
+ lportal0: lac-portal@0 {
+ compatible = "fsl,interlaken-lac-portal-v1.0";
+ fsl,liodn = <0x204>;
+ reg = <0x0 0x1000>;
+ };
+
+ lportal1: lac-portal@1000 {
+ compatible = "fsl,interlaken-lac-portal-v1.0";
+ fsl,liodn = <0x205>;
+ reg = <0x1000 0x1000>;
+ };
+
+ lportal2: lac-portal@2000 {
+ compatible = "fsl,interlaken-lac-portal-v1.0";
+ fsl,liodn = <0x206>;
+ reg = <0x2000 0x1000>;
+ };
+
+ lportal3: lac-portal@3000 {
+ compatible = "fsl,interlaken-lac-portal-v1.0";
+ fsl,liodn = <0x207>;
+ reg = <0x3000 0x1000>;
+ };
+
+ lportal4: lac-portal@4000 {
+ compatible = "fsl,interlaken-lac-portal-v1.0";
+ fsl,liodn = <0x208>;
+ reg = <0x4000 0x1000>;
+ };
+
+ lportal5: lac-portal@5000 {
+ compatible = "fsl,interlaken-lac-portal-v1.0";
+ fsl,liodn = <0x209>;
+ reg = <0x5000 0x1000>;
+ };
+
+ lportal6: lac-portal@6000 {
+ compatible = "fsl,interlaken-lac-portal-v1.0";
+ fsl,liodn = <0x20A>;
+ reg = <0x6000 0x1000>;
+ };
+
+ lportal7: lac-portal@7000 {
+ compatible = "fsl,interlaken-lac-portal-v1.0";
+ fsl,liodn = <0x20B>;
+ reg = <0x7000 0x1000>;
+ };
+
+ lportal8: lac-portal@8000 {
+ compatible = "fsl,interlaken-lac-portal-v1.0";
+ fsl,liodn = <0x20C>;
+ reg = <0x8000 0x1000>;
+ };
+
+ lportal9: lac-portal@9000 {
+ compatible = "fsl,interlaken-lac-portal-v1.0";
+ fsl,liodn = <0x20D>;
+ reg = <0x9000 0x1000>;
+ };
+
+ lportal10: lac-portal@A000 {
+ compatible = "fsl,interlaken-lac-portal-v1.0";
+ fsl,liodn = <0x20E>;
+ reg = <0xA000 0x1000>;
+ };
+
+ lportal11: lac-portal@B000 {
+ compatible = "fsl,interlaken-lac-portal-v1.0";
+ fsl,liodn = <0x20F>;
+ reg = <0xB000 0x1000>;
+ };
+
+ lportal12: lac-portal@C000 {
+ compatible = "fsl,interlaken-lac-portal-v1.0";
+ fsl,liodn = <0x210>;
+ reg = <0xC000 0x1000>;
+ };
+
+ lportal13: lac-portal@D000 {
+ compatible = "fsl,interlaken-lac-portal-v1.0";
+ fsl,liodn = <0x211>;
+ reg = <0xD000 0x1000>;
+ };
+
+ lportal14: lac-portal@E000 {
+ compatible = "fsl,interlaken-lac-portal-v1.0";
+ fsl,liodn = <0x212>;
+ reg = <0xE000 0x1000>;
+ };
+
+ lportal15: lac-portal@F000 {
+ compatible = "fsl,interlaken-lac-portal-v1.0";
+ fsl,liodn = <0x213>;
+ reg = <0xF000 0x1000>;
+ };
+
+ lportal16: lac-portal@10000 {
+ compatible = "fsl,interlaken-lac-portal-v1.0";
+ fsl,liodn = <0x214>;
+ reg = <0x10000 0x1000>;
+ };
+
+ lportal17: lac-portal@11000 {
+ compatible = "fsl,interlaken-lac-portal-v1.0";
+ fsl,liodn = <0x215>;
+ reg = <0x11000 0x1000>;
+ };
+
+ lportal8: lac-portal@1200 {
+ compatible = "fsl,interlaken-lac-portal-v1.0";
+ fsl,liodn = <0x216>;
+ reg = <0x12000 0x1000>;
+ };
+
+ lportal19: lac-portal@13000 {
+ compatible = "fsl,interlaken-lac-portal-v1.0";
+ fsl,liodn = <0x217>;
+ reg = <0x13000 0x1000>;
+ };
+
+ lportal20: lac-portal@14000 {
+ compatible = "fsl,interlaken-lac-portal-v1.0";
+ fsl,liodn = <0x218>;
+ reg = <0x14000 0x1000>;
+ };
+
+ lportal21: lac-portal@15000 {
+ compatible = "fsl,interlaken-lac-portal-v1.0";
+ fsl,liodn = <0x219>;
+ reg = <0x15000 0x1000>;
+ };
+
+ lportal22: lac-portal@16000 {
+ compatible = "fsl,interlaken-lac-portal-v1.0";
+ fsl,liodn = <0x21A>;
+ reg = <0x16000 0x1000>;
+ };
+
+ lportal23: lac-portal@17000 {
+ compatible = "fsl,interlaken-lac-portal-v1.0";
+ fsl,liodn = <0x21B>;
+ reg = <0x17000 0x1000>;
+ };
+};
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/pamu.txt b/Documentation/devicetree/bindings/powerpc/fsl/pamu.txt
new file mode 100644
index 0000000..1f5e329
--- /dev/null
+++ b/Documentation/devicetree/bindings/powerpc/fsl/pamu.txt
@@ -0,0 +1,140 @@
+Freescale Peripheral Management Access Unit (PAMU) Device Tree Binding
+
+DESCRIPTION
+
+The PAMU is an I/O MMU that provides device-to-memory access control and
+address translation capabilities.
+
+Required properties:
+
+- compatible : <string>
+ First entry is a version-specific string, such as
+ "fsl,pamu-v1.0". The second is "fsl,pamu".
+- ranges : <prop-encoded-array>
+ A standard property. Utilized to describe the memory mapped
+ I/O space utilized by the controller. The size should
+ be set to the total size of the register space of all
+ physically present PAMU controllers. For example, for
+ PAMU v1.0, on an SOC that has five PAMU devices, the size
+ is 0x5000.
+- interrupts : <prop-encoded-array>
+ Interrupt mappings. The first tuple is the normal PAMU
+ interrupt, used for reporting access violations. The second
+ is for PAMU hardware errors, such as PAMU operation errors
+ and ECC errors.
+- #address-cells: <u32>
+ A standard property.
+- #size-cells : <u32>
+ A standard property.
+
+Optional properties:
+- reg : <prop-encoded-array>
+ A standard property. It represents the CCSR registers of
+ all child PAMUs combined. Include it to provide support
+ for legacy drivers.
+- interrupt-parent : <phandle>
+ Phandle to interrupt controller
+
+Child nodes:
+
+Each child node represents one PAMU controller. Each SOC device that is
+connected to a specific PAMU device should have a "fsl,pamu-phandle" property
+that links to the corresponding specific child PAMU controller.
+
+- reg : <prop-encoded-array>
+ A standard property. Specifies the physical address and
+ length (relative to the parent 'ranges' property) of this
+ PAMU controller's configuration registers. The size should
+ be set to the size of this PAMU controllers's register space.
+ For PAMU v1.0, this size is 0x1000.
+- fsl,primary-cache-geometry
+ : <prop-encoded-array>
+ Two cells that specify the geometry of the primary PAMU
+ cache. The first is the number of cache lines, and the
+ second is the number of "ways". For direct-mapped caches,
+ specify a value of 1.
+- fsl,secondary-cache-geometry
+ : <prop-encoded-array>
+ Two cells that specify the geometry of the secondary PAMU
+ cache. The first is the number of cache lines, and the
+ second is the number of "ways". For direct-mapped caches,
+ specify a value of 1.
+
+Device nodes:
+
+Devices that have LIODNs need to specify links to the parent PAMU controller
+(the actual PAMU controller that this device is connected to) and a pointer to
+the LIODN register, if applicable.
+
+- fsl,iommu-parent
+ : <phandle>
+ Phandle to the single, specific PAMU controller node to which
+ this device is connect. The PAMU topology is represented in
+ the device tree to assist code that dynamically determines the
+ best LIODN values to minimize PAMU cache thrashing.
+
+- fsl,liodn-reg : <prop-encoded-array>
+ Two cells that specify the location of the LIODN register
+ for this device. Required for devices that have a single
+ LIODN. The first cell is a phandle to a node that contains
+ the registers where the LIODN is to be set. The second is
+ the offset from the first "reg" resource of the node where
+ the specific LIODN register is located.
+
+
+Example:
+
+ iommu@20000 {
+ compatible = "fsl,pamu-v1.0", "fsl,pamu";
+ reg = <0x20000 0x5000>;
+ ranges = <0 0x20000 0x5000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ interrupts = <
+ 24 2 0 0
+ 16 2 1 30>;
+
+ pamu0: pamu@0 {
+ reg = <0 0x1000>;
+ fsl,primary-cache-geometry = <32 1>;
+ fsl,secondary-cache-geometry = <128 2>;
+ };
+
+ pamu1: pamu@1000 {
+ reg = <0x1000 0x1000>;
+ fsl,primary-cache-geometry = <32 1>;
+ fsl,secondary-cache-geometry = <128 2>;
+ };
+
+ pamu2: pamu@2000 {
+ reg = <0x2000 0x1000>;
+ fsl,primary-cache-geometry = <32 1>;
+ fsl,secondary-cache-geometry = <128 2>;
+ };
+
+ pamu3: pamu@3000 {
+ reg = <0x3000 0x1000>;
+ fsl,primary-cache-geometry = <32 1>;
+ fsl,secondary-cache-geometry = <128 2>;
+ };
+
+ pamu4: pamu@4000 {
+ reg = <0x4000 0x1000>;
+ fsl,primary-cache-geometry = <32 1>;
+ fsl,secondary-cache-geometry = <128 2>;
+ };
+ };
+
+ guts: global-utilities@e0000 {
+ compatible = "fsl,qoriq-device-config-1.0";
+ reg = <0xe0000 0xe00>;
+ fsl,has-rstcr;
+ #sleep-cells = <1>;
+ fsl,liodn-bits = <12>;
+ };
+
+/include/ "qoriq-dma-0.dtsi"
+ dma@100300 {
+ fsl,iommu-parent = <&pamu0>;
+ fsl,liodn-reg = <&guts 0x584>; /* DMA2LIODNR */
+ };
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/srio.txt b/Documentation/devicetree/bindings/powerpc/fsl/srio.txt
index b039bcb..07abf0f 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/srio.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/srio.txt
@@ -8,9 +8,9 @@
Definition: Must include "fsl,srio" for IP blocks with IP Block
Revision Register (SRIO IPBRR1) Major ID equal to 0x01c0.
- Optionally, a compatiable string of "fsl,srio-vX.Y" where X is Major
+ Optionally, a compatible string of "fsl,srio-vX.Y" where X is Major
version in IP Block Revision Register and Y is Minor version. If this
- compatiable is provided it should be ordered before "fsl,srio".
+ compatible is provided it should be ordered before "fsl,srio".
- reg
Usage: required
diff --git a/Documentation/devicetree/bindings/pps/pps-gpio.txt b/Documentation/devicetree/bindings/pps/pps-gpio.txt
new file mode 100644
index 0000000..40bf9c3
--- /dev/null
+++ b/Documentation/devicetree/bindings/pps/pps-gpio.txt
@@ -0,0 +1,20 @@
+Device-Tree Bindings for a PPS Signal on GPIO
+
+These properties describe a PPS (pulse-per-second) signal connected to
+a GPIO pin.
+
+Required properties:
+- compatible: should be "pps-gpio"
+- gpios: one PPS GPIO in the format described by ../gpio/gpio.txt
+
+Optional properties:
+- assert-falling-edge: when present, assert is indicated by a falling edge
+ (instead of by a rising edge)
+
+Example:
+ pps {
+ compatible = "pps-gpio";
+ gpios = <&gpio2 6 0>;
+
+ assert-falling-edge;
+ };
diff --git a/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt b/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt
new file mode 100644
index 0000000..de0eaed
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt
@@ -0,0 +1,18 @@
+Atmel TCB PWM controller
+
+Required properties:
+- compatible: should be "atmel,tcb-pwm"
+- #pwm-cells: Should be 3. The first cell specifies the per-chip index
+ of the PWM to use, the second cell is the period in nanoseconds and
+ bit 0 in the third cell is used to encode the polarity of PWM output.
+ Set bit 0 of the third cell in PWM specifier to 1 for inverse polarity &
+ set to 0 for normal polarity.
+- tc-block: The Timer Counter block to use as a PWM chip.
+
+Example:
+
+pwm {
+ compatible = "atmel,tcb-pwm";
+ #pwm-cells = <3>;
+ tc-block = <1>;
+};
diff --git a/Documentation/devicetree/bindings/pwm/nxp,pca9685-pwm.txt b/Documentation/devicetree/bindings/pwm/nxp,pca9685-pwm.txt
new file mode 100644
index 0000000..1e3dfe7
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/nxp,pca9685-pwm.txt
@@ -0,0 +1,27 @@
+NXP PCA9685 16-channel 12-bit PWM LED controller
+================================================
+
+Required properties:
+ - compatible: "nxp,pca9685-pwm"
+ - #pwm-cells: should be 2. The first cell specifies the per-chip index
+ of the PWM to use and the second cell is the period in nanoseconds.
+ The index 16 is the ALLCALL channel, that sets all PWM channels at the same
+ time.
+
+Optional properties:
+ - invert (bool): boolean to enable inverted logic
+ - open-drain (bool): boolean to configure outputs with open-drain structure;
+ if omitted use totem-pole structure
+
+Example:
+
+For LEDs that are directly connected to the PCA, the following setting is
+applicable:
+
+pca: pca@41 {
+ compatible = "nxp,pca9685-pwm";
+ #pwm-cells = <2>;
+ reg = <0x41>;
+ invert;
+ open-drain;
+};
diff --git a/Documentation/devicetree/bindings/pwm/pwm-samsung.txt b/Documentation/devicetree/bindings/pwm/pwm-samsung.txt
new file mode 100644
index 0000000..ac67c68
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/pwm-samsung.txt
@@ -0,0 +1,43 @@
+* Samsung PWM timers
+
+Samsung SoCs contain PWM timer blocks which can be used for system clock source
+and clock event timers, as well as to drive SoC outputs with PWM signal. Each
+PWM timer block provides 5 PWM channels (not all of them can drive physical
+outputs - see SoC and board manual).
+
+Be aware that the clocksource driver supports only uniprocessor systems.
+
+Required properties:
+- compatible : should be one of following:
+ samsung,s3c2410-pwm - for 16-bit timers present on S3C24xx SoCs
+ samsung,s3c6400-pwm - for 32-bit timers present on S3C64xx SoCs
+ samsung,s5p6440-pwm - for 32-bit timers present on S5P64x0 SoCs
+ samsung,s5pc100-pwm - for 32-bit timers present on S5PC100, S5PV210,
+ Exynos4210 rev0 SoCs
+ samsung,exynos4210-pwm - for 32-bit timers present on Exynos4210,
+ Exynos4x12 and Exynos5250 SoCs
+- reg: base address and size of register area
+- interrupts: list of timer interrupts (one interrupt per timer, starting at
+ timer 0)
+- #pwm-cells: number of cells used for PWM specifier - must be 3
+ the specifier format is as follows:
+ - phandle to PWM controller node
+ - index of PWM channel (from 0 to 4)
+ - PWM signal period in nanoseconds
+ - bitmask of optional PWM flags:
+ 0x1 - invert PWM signal
+
+Optional properties:
+- samsung,pwm-outputs: list of PWM channels used as PWM outputs on particular
+ platform - an array of up to 5 elements being indices of PWM channels
+ (from 0 to 4), the order does not matter.
+
+Example:
+ pwm@7f006000 {
+ compatible = "samsung,s3c6400-pwm";
+ reg = <0x7f006000 0x1000>;
+ interrupt-parent = <&vic0>;
+ interrupts = <23>, <24>, <25>, <27>, <28>;
+ samsung,pwm-outputs = <0>, <1>;
+ #pwm-cells = <3>;
+ }
diff --git a/Documentation/devicetree/bindings/pwm/pwm-tiecap.txt b/Documentation/devicetree/bindings/pwm/pwm-tiecap.txt
index 131e8c11..681afad 100644
--- a/Documentation/devicetree/bindings/pwm/pwm-tiecap.txt
+++ b/Documentation/devicetree/bindings/pwm/pwm-tiecap.txt
@@ -1,7 +1,9 @@
TI SOC ECAP based APWM controller
Required properties:
-- compatible: Must be "ti,am33xx-ecap"
+- compatible: Must be "ti,<soc>-ecap".
+ for am33xx - compatible = "ti,am33xx-ecap";
+ for da850 - compatible = "ti,da850-ecap", "ti,am33xx-ecap";
- #pwm-cells: Should be 3. Number of cells being used to specify PWM property.
First cell specifies the per-chip index of the PWM to use, the second
cell is the period in nanoseconds and bit 0 in the third cell is used to
@@ -15,9 +17,15 @@
Example:
-ecap0: ecap@0 {
+ecap0: ecap@0 { /* ECAP on am33xx */
compatible = "ti,am33xx-ecap";
#pwm-cells = <3>;
reg = <0x48300100 0x80>;
ti,hwmods = "ecap0";
};
+
+ecap0: ecap@0 { /* ECAP on da850 */
+ compatible = "ti,da850-ecap", "ti,am33xx-ecap";
+ #pwm-cells = <3>;
+ reg = <0x306000 0x80>;
+};
diff --git a/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt b/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt
index 4fc7079..337c6fc 100644
--- a/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt
+++ b/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt
@@ -1,7 +1,9 @@
TI SOC EHRPWM based PWM controller
Required properties:
-- compatible : Must be "ti,am33xx-ehrpwm"
+- compatible: Must be "ti,<soc>-ehrpwm".
+ for am33xx - compatible = "ti,am33xx-ehrpwm";
+ for da850 - compatible = "ti,da850-ehrpwm", "ti,am33xx-ehrpwm";
- #pwm-cells: Should be 3. Number of cells being used to specify PWM property.
First cell specifies the per-chip index of the PWM to use, the second
cell is the period in nanoseconds and bit 0 in the third cell is used to
@@ -15,9 +17,15 @@
Example:
-ehrpwm0: ehrpwm@0 {
+ehrpwm0: ehrpwm@0 { /* EHRPWM on am33xx */
compatible = "ti,am33xx-ehrpwm";
#pwm-cells = <3>;
reg = <0x48300200 0x100>;
ti,hwmods = "ehrpwm0";
};
+
+ehrpwm0: ehrpwm@0 { /* EHRPWM on da850 */
+ compatible = "ti,da850-ehrpwm", "ti,am33xx-ehrpwm";
+ #pwm-cells = <3>;
+ reg = <0x300000 0x2000>;
+};
diff --git a/Documentation/devicetree/bindings/pwm/vt8500-pwm.txt b/Documentation/devicetree/bindings/pwm/vt8500-pwm.txt
index bcc6367..d21d82d 100644
--- a/Documentation/devicetree/bindings/pwm/vt8500-pwm.txt
+++ b/Documentation/devicetree/bindings/pwm/vt8500-pwm.txt
@@ -3,14 +3,17 @@
Required properties:
- compatible: should be "via,vt8500-pwm"
- reg: physical base address and length of the controller's registers
-- #pwm-cells: should be 2. The first cell specifies the per-chip index
- of the PWM to use and the second cell is the period in nanoseconds.
+- #pwm-cells: Should be 3. Number of cells being used to specify PWM property.
+ First cell specifies the per-chip index of the PWM to use, the second
+ cell is the period in nanoseconds and bit 0 in the third cell is used to
+ encode the polarity of PWM output. Set bit 0 of the third in PWM specifier
+ to 1 for inverse polarity & set to 0 for normal polarity.
- clocks: phandle to the PWM source clock
Example:
pwm1: pwm@d8220000 {
- #pwm-cells = <2>;
+ #pwm-cells = <3>;
compatible = "via,vt8500-pwm";
reg = <0xd8220000 0x1000>;
clocks = <&clkpwm>;
diff --git a/Documentation/devicetree/bindings/regulator/anatop-regulator.txt b/Documentation/devicetree/bindings/regulator/anatop-regulator.txt
index 357758c..758eae2 100644
--- a/Documentation/devicetree/bindings/regulator/anatop-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/anatop-regulator.txt
@@ -9,6 +9,11 @@
- anatop-min-voltage: Minimum voltage of this regulator
- anatop-max-voltage: Maximum voltage of this regulator
+Optional properties:
+- anatop-delay-reg-offset: Anatop MFD step time register offset
+- anatop-delay-bit-shift: Bit shift for the step time register
+- anatop-delay-bit-width: Number of bits used in the step time register
+
Any property defined as part of the core regulator
binding, defined in regulator.txt, can also be used.
@@ -23,6 +28,9 @@
anatop-reg-offset = <0x140>;
anatop-vol-bit-shift = <9>;
anatop-vol-bit-width = <5>;
+ anatop-delay-reg-offset = <0x170>;
+ anatop-delay-bit-shift = <24>;
+ anatop-delay-bit-width = <2>;
anatop-min-bit-val = <1>;
anatop-min-voltage = <725000>;
anatop-max-voltage = <1300000>;
diff --git a/Documentation/devicetree/bindings/regulator/lp872x.txt b/Documentation/devicetree/bindings/regulator/lp872x.txt
new file mode 100644
index 0000000..7818318
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/lp872x.txt
@@ -0,0 +1,160 @@
+Binding for TI/National Semiconductor LP872x Driver
+
+Required properties:
+ - compatible: "ti,lp8720" or "ti,lp8725"
+ - reg: I2C slave address. 0x7d = LP8720, 0x7a = LP8725
+
+Optional properties:
+ - ti,general-config: the value of LP872X_GENERAL_CFG register (u8)
+ (LP8720)
+ bit[2]: BUCK output voltage control by external DVS pin or register
+ 1 = external pin, 0 = bit7 of register 08h
+ bit[1]: sleep control by external DVS pin or register
+ 1 = external pin, 0 = bit6 of register 08h
+ bit[0]: time step unit(usec). 1 = 25, 0 = 50
+
+ (LP8725)
+ bit[7:6]: time step unit(usec). 00 = 32, 01 = 64, 10 = 128, 11 = 256
+ bit[4]: BUCK2 enable control. 1 = enable, 0 = disable
+ bit[3]: BUCK2 output voltage register address. 1 = 0Ah, 0 = 0Bh
+ bit[2]: BUCK1 output voltage control by external DVS pin or register
+ 1 = register 08h, 0 = DVS
+ bit[1]: LDO sleep control. 1 = sleep mode, 0 = normal
+ bit[0]: BUCK1 enable control, 1 = enable, 0 = disable
+
+ For more details, please see the datasheet.
+
+ - ti,update-config: define it when LP872X_GENERAL_CFG register should be set
+ - ti,dvs-gpio: GPIO specifier for external DVS pin control of LP872x devices.
+ - ti,dvs-vsel: DVS selector. 0 = SEL_V1, 1 = SEL_V2.
+ - ti,dvs-state: initial DVS pin state. 0 = DVS_LOW, 1 = DVS_HIGH.
+
+ Sub nodes for regulator_init_data
+ LP8720 has maximum 6 nodes. (child name: ldo1 ~ 5 and buck)
+ LP8725 has maximum 9 nodes. (child name: ldo1 ~ 5, lilo1,2 and buck1,2)
+ For more details, please see the following binding document.
+ (Documentation/devicetree/bindings/regulator/regulator.txt)
+
+Datasheet
+ - LP8720: http://www.ti.com/lit/ds/symlink/lp8720.pdf
+ - LP8725: http://www.ti.com/lit/ds/symlink/lp8725.pdf
+
+Example 1) LP8720
+
+lp8720@7d {
+ compatible = "ti,lp8720";
+ reg = <0x7d>;
+
+ /* external DVS pin used, timestep is 25usec */
+ ti,general-config = /bits/ 8 <0x03>;
+ ti,update-config;
+
+ /*
+ * The dvs-gpio depends on the processor environment.
+ * For example, following GPIO specifier means GPIO134 in OMAP4.
+ */
+ ti,dvs-gpio = <&gpio5 6 0>;
+ ti,dvs-vsel = /bits/ 8 <1>; /* SEL_V2 */
+ ti,dvs-state = /bits/ 8 <1>; /* DVS_HIGH */
+
+ vaf: ldo1 {
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ vmmc: ldo2 {
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ vcam_io: ldo3 {
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ };
+
+ vcam_core: ldo4 {
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <2850000>;
+ regulator-boot-on;
+ };
+
+ vcam: ldo5 {
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ vcc: buck {
+ regulator-name = "VBUCK";
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <2300000>;
+ };
+};
+
+Example 2) LP8725
+
+lp8725@7a {
+ compatible = "ti,lp8725";
+ reg = <0x7a>;
+
+ /* Enable BUCK1,2, no DVS, normal LDO mode, timestep is 256usec */
+ ti,general-config = /bits/ 8 <0xdd>;
+ ti,update-config;
+
+ vcam_io: ldo1 {
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ vcam_core: ldo2 {
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ vcam: ldo3 {
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ vcmmb_io: ldo4 {
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ };
+
+ vcmmb_core: ldo5 {
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ };
+
+ vaux1: lilo1 {
+ regulator-name = "VAUX1";
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ vaux2: lilo2 {
+ regulator-name = "VAUX2";
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ vcc1: buck1 {
+ regulator-name = "VBUCK1";
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-min-microamp = <460000>;
+ regulator-max-microamp = <1370000>;
+ regulator-boot-on;
+ };
+
+ vcc2: buck2 {
+ regulator-name = "VBUCK2";
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-min-microamp = <460000>;
+ regulator-max-microamp = <1370000>;
+ regulator-boot-on;
+ };
+};
diff --git a/Documentation/devicetree/bindings/regulator/max8952.txt b/Documentation/devicetree/bindings/regulator/max8952.txt
new file mode 100644
index 0000000..866fcdd
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/max8952.txt
@@ -0,0 +1,52 @@
+Maxim MAX8952 voltage regulator
+
+Required properties:
+- compatible: must be equal to "maxim,max8952"
+- reg: I2C slave address, usually 0x60
+- max8952,dvs-mode-microvolt: array of 4 integer values defining DVS voltages
+ in microvolts. All values must be from range <770000, 1400000>
+- any required generic properties defined in regulator.txt
+
+Optional properties:
+- max8952,vid-gpios: array of two GPIO pins used for DVS voltage selection
+- max8952,en-gpio: GPIO used to control enable status of regulator
+- max8952,default-mode: index of default DVS voltage, from <0, 3> range
+- max8952,sync-freq: sync frequency, must be one of following values:
+ - 0: 26 MHz
+ - 1: 13 MHz
+ - 2: 19.2 MHz
+ Defaults to 26 MHz if not specified.
+- max8952,ramp-speed: voltage ramp speed, must be one of following values:
+ - 0: 32mV/us
+ - 1: 16mV/us
+ - 2: 8mV/us
+ - 3: 4mV/us
+ - 4: 2mV/us
+ - 5: 1mV/us
+ - 6: 0.5mV/us
+ - 7: 0.25mV/us
+ Defaults to 32mV/us if not specified.
+- any available generic properties defined in regulator.txt
+
+Example:
+
+ vdd_arm_reg: pmic@60 {
+ compatible = "maxim,max8952";
+ reg = <0x60>;
+
+ /* max8952-specific properties */
+ max8952,vid-gpios = <&gpx0 3 0>, <&gpx0 4 0>;
+ max8952,en-gpio = <&gpx0 1 0>;
+ max8952,default-mode = <0>;
+ max8952,dvs-mode-microvolt = <1250000>, <1200000>,
+ <1050000>, <950000>;
+ max8952,sync-freq = <0>;
+ max8952,ramp-speed = <0>;
+
+ /* generic regulator properties */
+ regulator-name = "vdd_arm";
+ regulator-min-microvolt = <770000>;
+ regulator-max-microvolt = <1400000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
diff --git a/Documentation/devicetree/bindings/regulator/max8973-regulator.txt b/Documentation/devicetree/bindings/regulator/max8973-regulator.txt
new file mode 100644
index 0000000..4f15d8a
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/max8973-regulator.txt
@@ -0,0 +1,21 @@
+* Maxim MAX8973 Voltage Regulator
+
+Required properties:
+
+- compatible: must be "maxim,max8973"
+- reg: the i2c slave address of the regulator. It should be 0x1b.
+
+Any standard regulator properties can be used to configure the single max8973
+DCDC.
+
+Example:
+
+ max8973@1b {
+ compatible = "maxim,max8973";
+ reg = <0x1b>;
+
+ regulator-min-microvolt = <935000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
diff --git a/Documentation/devicetree/bindings/regulator/max8997-regulator.txt b/Documentation/devicetree/bindings/regulator/max8997-regulator.txt
index 9fd69a1..5c186a7 100644
--- a/Documentation/devicetree/bindings/regulator/max8997-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/max8997-regulator.txt
@@ -1,6 +1,6 @@
* Maxim MAX8997 Voltage and Current Regulator
-The Maxim MAX8997 is a multi-function device which includes volatage and
+The Maxim MAX8997 is a multi-function device which includes voltage and
current regulators, rtc, charger controller and other sub-blocks. It is
interfaced to the host controller using a i2c interface. Each sub-block is
addressed by the host system using different i2c slave address. This document
@@ -28,7 +28,7 @@
safe operating voltage).
If either of the 'max8997,pmic-buck[1/2/5]-uses-gpio-dvs' optional
- property is specified, then all the eigth voltage values for the
+ property is specified, then all the eight voltage values for the
'max8997,pmic-buck[1/2/5]-dvs-voltage' should be specified.
Optional properties:
diff --git a/Documentation/devicetree/bindings/regulator/palmas-pmic.txt b/Documentation/devicetree/bindings/regulator/palmas-pmic.txt
new file mode 100644
index 0000000..d5a3086
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/palmas-pmic.txt
@@ -0,0 +1,72 @@
+* palmas regulator IP block devicetree bindings
+
+Required properties:
+- compatible : Should be from the list
+ ti,twl6035-pmic
+ ti,twl6036-pmic
+ ti,twl6037-pmic
+ ti,tps65913-pmic
+ ti,tps65914-pmic
+and also the generic series names
+ ti,palmas-pmic
+- interrupt-parent : The parent interrupt controller which is palmas.
+- interrupts : The interrupt number and the type which can be looked up here:
+ arch/arm/boot/dts/include/dt-bindings/interrupt-controller/irq.h
+- interrupts-name: The names of the individual interrupts.
+
+Optional properties:
+- ti,ldo6-vibrator : ldo6 is in vibrator mode
+
+Optional nodes:
+- regulators : Must contain a sub-node per regulator from the list below.
+ Each sub-node should contain the constraints and initialization
+ information for that regulator. See regulator.txt for a
+ description of standard properties for these sub-nodes.
+ Additional custom properties are listed below.
+
+ For ti,palmas-pmic - smps12, smps123, smps3 depending on OTP,
+ smps45, smps457, smps7 depending on variant, smps6, smps[8-10],
+ ldo[1-9], ldoln, ldousb.
+
+ Optional sub-node properties:
+ ti,warm-reset - maintain voltage during warm reset(boolean)
+ ti,roof-floor - control voltage selection by pin(boolean)
+ ti,sleep-mode - mode to adopt in pmic sleep 0 - off, 1 - auto,
+ 2 - eco, 3 - forced pwm
+ ti,tstep - slope control 0 - Jump, 1 10mV/us, 2 5mV/us, 3 2.5mV/us
+ ti,smps-range - OTP has the wrong range set for the hardware so override
+ 0 - low range, 1 - high range.
+
+Example:
+
+#include <dt-bindings/interrupt-controller/irq.h>
+
+pmic {
+ compatible = "ti,twl6035-pmic", "ti,palmas-pmic";
+ interrupt-parent = <&palmas>;
+ interrupts = <14 IRQ_TYPE_NONE>;
+ interrupts-name = "short-irq";
+
+ ti,ldo6-vibrator;
+
+ regulators {
+ smps12_reg : smps12 {
+ regulator-name = "smps12";
+ regulator-min-microvolt = < 600000>;
+ regulator-max-microvolt = <1500000>;
+ regulator-always-on;
+ regulator-boot-on;
+ ti,warm-reset;
+ ti,roof-floor;
+ ti,mode-sleep = <0>;
+ ti,tstep = <0>;
+ ti,smps-range = <1>;
+ };
+
+ ldo1_reg: ldo1 {
+ regulator-name = "ldo1";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ };
+ };
+};
diff --git a/Documentation/devicetree/bindings/regulator/regulator.txt b/Documentation/devicetree/bindings/regulator/regulator.txt
index ecfc6cc..48a3b8e 100644
--- a/Documentation/devicetree/bindings/regulator/regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/regulator.txt
@@ -9,6 +9,7 @@
- regulator-max-microamp: largest current consumers may set
- regulator-always-on: boolean, regulator should never be disabled
- regulator-boot-on: bootloader/firmware enabled regulator
+- regulator-allow-bypass: allow the regulator to go into bypass mode
- <name>-supply: phandle to the parent supply/regulator node
- regulator-ramp-delay: ramp delay for regulator(in uV/uS)
diff --git a/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt b/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt
new file mode 100644
index 0000000..d1660a9
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt
@@ -0,0 +1,152 @@
+* Samsung S5M8767 Voltage and Current Regulator
+
+The Samsung S5M8767 is a multi-function device which includes voltage and
+current regulators, rtc, charger controller and other sub-blocks. It is
+interfaced to the host controller using a i2c interface. Each sub-block is
+addressed by the host system using different i2c slave address. This document
+describes the bindings for 'pmic' sub-block of s5m8767.
+
+Required properties:
+- compatible: Should be "samsung,s5m8767-pmic".
+- reg: Specifies the i2c slave address of the pmic block. It should be 0x66.
+
+- s5m8767,pmic-buck2-dvs-voltage: A set of 8 voltage values in micro-volt (uV)
+ units for buck2 when changing voltage using gpio dvs. Refer to [1] below
+ for additional information.
+
+- s5m8767,pmic-buck3-dvs-voltage: A set of 8 voltage values in micro-volt (uV)
+ units for buck3 when changing voltage using gpio dvs. Refer to [1] below
+ for additional information.
+
+- s5m8767,pmic-buck4-dvs-voltage: A set of 8 voltage values in micro-volt (uV)
+ units for buck4 when changing voltage using gpio dvs. Refer to [1] below
+ for additional information.
+
+- s5m8767,pmic-buck-ds-gpios: GPIO specifiers for three host gpio's used
+ for selecting GPIO DVS lines. It is one-to-one mapped to dvs gpio lines.
+
+[1] If none of the 's5m8767,pmic-buck[2/3/4]-uses-gpio-dvs' optional
+ property is specified, the 's5m8767,pmic-buck[2/3/4]-dvs-voltage'
+ property should specify atleast one voltage level (which would be a
+ safe operating voltage).
+
+ If either of the 's5m8767,pmic-buck[2/3/4]-uses-gpio-dvs' optional
+ property is specified, then all the eight voltage values for the
+ 's5m8767,pmic-buck[2/3/4]-dvs-voltage' should be specified.
+
+Optional properties:
+- interrupt-parent: Specifies the phandle of the interrupt controller to which
+ the interrupts from s5m8767 are delivered to.
+- interrupts: Interrupt specifiers for two interrupt sources.
+ - First interrupt specifier is for 'irq1' interrupt.
+ - Second interrupt specifier is for 'alert' interrupt.
+- s5m8767,pmic-buck2-uses-gpio-dvs: 'buck2' can be controlled by gpio dvs.
+- s5m8767,pmic-buck3-uses-gpio-dvs: 'buck3' can be controlled by gpio dvs.
+- s5m8767,pmic-buck4-uses-gpio-dvs: 'buck4' can be controlled by gpio dvs.
+
+Additional properties required if either of the optional properties are used:
+
+- s5m8767,pmic-buck234-default-dvs-idx: Default voltage setting selected from
+ the possible 8 options selectable by the dvs gpios. The value of this
+ property should be between 0 and 7. If not specified or if out of range, the
+ default value of this property is set to 0.
+
+- s5m8767,pmic-buck-dvs-gpios: GPIO specifiers for three host gpio's used
+ for dvs. The format of the gpio specifier depends in the gpio controller.
+
+Regulators: The regulators of s5m8767 that have to be instantiated should be
+included in a sub-node named 'regulators'. Regulator nodes included in this
+sub-node should be of the format as listed below.
+
+ regulator_name {
+ ldo1_reg: LDO1 {
+ regulator-name = "VDD_ALIVE_1.0V";
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1100000>;
+ regulator-always-on;
+ regulator-boot-on;
+ op_mode = <1>; /* Normal Mode */
+ };
+ };
+The above regulator entries are defined in regulator bindings documentation
+except op_mode description.
+ - op_mode: describes the different operating modes of the LDO's with
+ power mode change in SOC. The different possible values are,
+ 0 - always off mode
+ 1 - on in normal mode
+ 2 - low power mode
+ 3 - suspend mode
+
+The following are the names of the regulators that the s5m8767 pmic block
+supports. Note: The 'n' in LDOn and BUCKn represents the LDO or BUCK number
+as per the datasheet of s5m8767.
+
+ - LDOn
+ - valid values for n are 1 to 28
+ - Example: LDO0, LD01, LDO28
+ - BUCKn
+ - valid values for n are 1 to 9.
+ - Example: BUCK1, BUCK2, BUCK9
+
+The bindings inside the regulator nodes use the standard regulator bindings
+which are documented elsewhere.
+
+Example:
+
+ s5m8767_pmic@66 {
+ compatible = "samsung,s5m8767-pmic";
+ reg = <0x66>;
+
+ s5m8767,pmic-buck2-uses-gpio-dvs;
+ s5m8767,pmic-buck3-uses-gpio-dvs;
+ s5m8767,pmic-buck4-uses-gpio-dvs;
+
+ s5m8767,pmic-buck-default-dvs-idx = <0>;
+
+ s5m8767,pmic-buck-dvs-gpios = <&gpx0 0 0>, /* DVS1 */
+ <&gpx0 1 0>, /* DVS2 */
+ <&gpx0 2 0>; /* DVS3 */
+
+ s5m8767,pmic-buck-ds-gpios = <&gpx2 3 0>, /* SET1 */
+ <&gpx2 4 0>, /* SET2 */
+ <&gpx2 5 0>; /* SET3 */
+
+ s5m8767,pmic-buck2-dvs-voltage = <1350000>, <1300000>,
+ <1250000>, <1200000>,
+ <1150000>, <1100000>,
+ <1000000>, <950000>;
+
+ s5m8767,pmic-buck3-dvs-voltage = <1100000>, <1100000>,
+ <1100000>, <1100000>,
+ <1000000>, <1000000>,
+ <1000000>, <1000000>;
+
+ s5m8767,pmic-buck4-dvs-voltage = <1200000>, <1200000>,
+ <1200000>, <1200000>,
+ <1200000>, <1200000>,
+ <1200000>, <1200000>;
+
+ regulators {
+ ldo1_reg: LDO1 {
+ regulator-name = "VDD_ABB_3.3V";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ op_mode = <1>; /* Normal Mode */
+ };
+
+ ldo2_reg: LDO2 {
+ regulator-name = "VDD_ALIVE_1.1V";
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1100000>;
+ regulator-always-on;
+ };
+
+ buck1_reg: BUCK1 {
+ regulator-name = "VDD_MIF_1.2V";
+ regulator-min-microvolt = <950000>;
+ regulator-max-microvolt = <1350000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/regulator/ti-abb-regulator.txt b/Documentation/devicetree/bindings/regulator/ti-abb-regulator.txt
new file mode 100644
index 0000000..2e57a33e9
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/ti-abb-regulator.txt
@@ -0,0 +1,128 @@
+Adaptive Body Bias(ABB) SoC internal LDO regulator for Texas Instruments SoCs
+
+Required Properties:
+- compatible: Should be one of:
+ - "ti,abb-v1" for older SoCs like OMAP3
+ - "ti,abb-v2" for newer SoCs like OMAP4, OMAP5
+- reg: Address and length of the register set for the device. It contains
+ the information of registers in the same order as described by reg-names
+- reg-names: Should contain the reg names
+ - "base-address" - contains base address of ABB module
+ - "int-address" - contains address of interrupt register for ABB module
+ (also see Optional properties)
+- #address-cell: should be 0
+- #size-cell: should be 0
+- clocks: should point to the clock node used by ABB module
+- ti,settling-time: Settling time in uSecs from SoC documentation for ABB module
+ to settle down(target time for SR2_WTCNT_VALUE).
+- ti,clock-cycles: SoC specific data about count of system ti,clock-cycles used for
+ computing settling time from SoC Documentation for ABB module(clock
+ cycles for SR2_WTCNT_VALUE).
+- ti,tranxdone-status-mask: Mask to the int-register to write-to-clear mask
+ indicating LDO tranxdone (operation complete).
+- ti,abb_info: An array of 6-tuples u32 items providing information about ABB
+ configuration needed per operational voltage of the device.
+ Each item consists of the following in the same order:
+ volt: voltage in uV - Only used to index ABB information.
+ ABB mode: one of the following:
+ 0-bypass
+ 1-Forward Body Bias(FBB)
+ 3-Reverse Body Bias(RBB)
+ efuse: (see Optional properties)
+ RBB enable efuse Mask: (See Optional properties)
+ FBB enable efuse Mask: (See Optional properties)
+ Vset value efuse Mask: (See Optional properties)
+
+ NOTE: If more than 1 entry is present, then regulator is setup to change
+ voltage, allowing for various modes to be selected indexed off
+ the regulator. Further, ABB LDOs are considered always-on by
+ default.
+
+Optional Properties:
+- reg-names: In addition to the required properties, the following are optional
+ - "efuse-address" - Contains efuse base address used to pick up ABB info.
+ - "ldo-address" - Contains address of ABB LDO overide register address.
+ "efuse-address" is required for this.
+- ti,ldovbb-vset-mask - Required if ldo-address is set, mask for LDO override
+ register to provide override vset value.
+- ti,ldovbb-override-mask - Required if ldo-address is set, mask for LDO
+ override register to enable override vset value.
+- ti,abb_opp_sel: Addendum to the description in required properties
+ efuse: Mandatory if 'efuse-address' register is defined. Provides offset
+ from efuse-address to pick up ABB characteristics. Set to 0 if
+ 'efuse-address' is not defined.
+ RBB enable efuse Mask: Optional if 'efuse-address' register is defined.
+ 'ABB mode' is force set to RBB mode if value at "efuse-address"
+ + efuse maps to RBB mask. Set to 0 to ignore this.
+ FBB enable efuse Mask: Optional if 'efuse-address' register is defined.
+ 'ABB mode' is force set to FBB mode if value at "efuse-address"
+ + efuse maps to FBB mask (valid only if RBB mask does not match)
+ Set to 0 to ignore this.
+ Vset value efuse Mask: Mandatory if ldo-address is set. Picks up from
+ efuse the value to set in 'ti,ldovbb-vset-mask' at ldo-address.
+
+Example #1: Simplest configuration (no efuse data, hard coded ABB table):
+abb_x: regulator-abb-x {
+ compatible = "ti,abb-v1";
+ regulator-name = "abb_x";
+ #address-cell = <0>;
+ #size-cells = <0>;
+ reg = <0x483072f0 0x8>, <0x48306818 0x4>;
+ reg-names = "base-address", "int-address";
+ ti,tranxdone-status-mask = <0x4000000>;
+ clocks = <&sysclk>;
+ ti,settling-time = <30>;
+ ti,clock-cycles = <8>;
+ ti,abb_info = <
+ /* uV ABB efuse rbb_m fbb_m vset_m */
+ 1012500 0 0 0 0 0 /* Bypass */
+ 1200000 3 0 0 0 0 /* RBB mandatory */
+ 1320000 1 0 0 0 0 /* FBB mandatory */
+ >;
+};
+
+Example #2: Efuse bits contain ABB mode setting (no LDO override capability)
+abb_y: regulator-abb-y {
+ compatible = "ti,abb-v2";
+ regulator-name = "abb_y";
+ #address-cell = <0>;
+ #size-cells = <0>;
+ reg = <0x4a307bd0 0x8>, <0x4a306014 0x4>, <0x4A002268 0x8>;
+ reg-names = "base-address", "int-address", "efuse-address";
+ ti,tranxdone-status-mask = <0x4000000>;
+ clocks = <&sysclk>;
+ ti,settling-time = <50>;
+ ti,clock-cycles = <16>;
+ ti,abb_info = <
+ /* uV ABB efuse rbb_m fbb_m vset_m */
+ 975000 0 0 0 0 0 /* Bypass */
+ 1012500 0 0 0x40000 0 0 /* RBB optional */
+ 1200000 0 0x4 0 0x40000 0 /* FBB optional */
+ 1320000 1 0 0 0 0 /* FBB mandatory */
+ >;
+};
+
+Example #3: Efuse bits contain ABB mode setting and LDO override capability
+abb_z: regulator-abb-z {
+ compatible = "ti,abb-v2";
+ regulator-name = "abb_z";
+ #address-cell = <0>;
+ #size-cells = <0>;
+ reg = <0x4ae07ce4 0x8>, <0x4ae06010 0x4>,
+ <0x4a002194 0x8>, <0x4ae0C314 0x4>;
+ reg-names = "base-address", "int-address",
+ "efuse-address", "ldo-address";
+ ti,tranxdone-status-mask = <0x8000000>;
+ /* LDOVBBMM_MUX_CTRL */
+ ti,ldovbb-override-mask = <0x400>;
+ /* LDOVBBMM_VSET_OUT */
+ ti,ldovbb-vset-mask = <0x1F>;
+ clocks = <&sysclk>;
+ ti,settling-time = <50>;
+ ti,clock-cycles = <16>;
+ ti,abb_info = <
+ /* uV ABB efuse rbb_m fbb_m vset_m */
+ 975000 0 0 0 0 0 /* Bypass */
+ 1200000 0 0x4 0 0x40000 0x1f00 /* FBB optional, vset */
+ >;
+};
diff --git a/Documentation/devicetree/bindings/regulator/tps51632-regulator.txt b/Documentation/devicetree/bindings/regulator/tps51632-regulator.txt
new file mode 100644
index 0000000..2f7e44a
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/tps51632-regulator.txt
@@ -0,0 +1,27 @@
+TPS51632 Voltage regulators
+
+Required properties:
+- compatible: Must be "ti,tps51632"
+- reg: I2C slave address
+
+Optional properties:
+- ti,enable-pwm-dvfs: Enable the DVFS voltage control through the PWM interface.
+- ti,dvfs-step-20mV: The 20mV step voltage when PWM DVFS enabled. Missing this
+ will set 10mV step voltage in PWM DVFS mode. In normal mode, the voltage
+ step is 10mV as per datasheet.
+
+Any property defined as part of the core regulator binding, defined in
+regulator.txt, can also be used.
+
+Example:
+
+ tps51632 {
+ compatible = "ti,tps51632";
+ reg = <0x43>;
+ regulator-name = "tps51632-vout";
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <1500000>;
+ regulator-boot-on;
+ ti,enable-pwm-dvfs;
+ ti,dvfs-step-20mV;
+ };
diff --git a/Documentation/devicetree/bindings/regulator/tps62360-regulator.txt b/Documentation/devicetree/bindings/regulator/tps62360-regulator.txt
index c8ca6b8..1b20c3d 100644
--- a/Documentation/devicetree/bindings/regulator/tps62360-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/tps62360-regulator.txt
@@ -17,9 +17,9 @@
- ti,vsel1-gpio: Gpio for controlling VSEL1 line.
If this property is missing, then assume that there is no GPIO
for vsel1 control.
-- ti,vsel0-state-high: Inital state of vsel0 input is high.
+- ti,vsel0-state-high: Initial state of vsel0 input is high.
If this property is missing, then assume the state as low (0).
-- ti,vsel1-state-high: Inital state of vsel1 input is high.
+- ti,vsel1-state-high: Initial state of vsel1 input is high.
If this property is missing, then assume the state as low (0).
Any property defined as part of the core regulator binding, defined in
diff --git a/Documentation/devicetree/bindings/regulator/tps65090.txt b/Documentation/devicetree/bindings/regulator/tps65090.txt
new file mode 100644
index 0000000..313a60b
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/tps65090.txt
@@ -0,0 +1,122 @@
+TPS65090 regulators
+
+Required properties:
+- compatible: "ti,tps65090"
+- reg: I2C slave address
+- interrupts: the interrupt outputs of the controller
+- regulators: A node that houses a sub-node for each regulator within the
+ device. Each sub-node is identified using the node's name, with valid
+ values listed below. The content of each sub-node is defined by the
+ standard binding for regulators; see regulator.txt.
+ dcdc[1-3], fet[1-7] and ldo[1-2] respectively.
+- vsys[1-3]-supply: The input supply for DCDC[1-3] respectively.
+- infet[1-7]-supply: The input supply for FET[1-7] respectively.
+- vsys-l[1-2]-supply: The input supply for LDO[1-2] respectively.
+
+Optional properties:
+- ti,enable-ext-control: This is applicable for DCDC1, DCDC2 and DCDC3.
+ If DCDCs are externally controlled then this property should be there.
+- "dcdc-ext-control-gpios: This is applicable for DCDC1, DCDC2 and DCDC3.
+ If DCDCs are externally controlled and if it is from GPIO then GPIO
+ number should be provided. If it is externally controlled and no GPIO
+ entry then driver will just configure this rails as external control
+ and will not provide any enable/disable APIs.
+
+Each regulator is defined using the standard binding for regulators.
+
+Example:
+
+ tps65090@48 {
+ compatible = "ti,tps65090";
+ reg = <0x48>;
+ interrupts = <0 88 0x4>;
+
+ vsys1-supply = <&some_reg>;
+ vsys2-supply = <&some_reg>;
+ vsys3-supply = <&some_reg>;
+ infet1-supply = <&some_reg>;
+ infet2-supply = <&some_reg>;
+ infet3-supply = <&some_reg>;
+ infet4-supply = <&some_reg>;
+ infet5-supply = <&some_reg>;
+ infet6-supply = <&some_reg>;
+ infet7-supply = <&some_reg>;
+ vsys_l1-supply = <&some_reg>;
+ vsys_l2-supply = <&some_reg>;
+
+ regulators {
+ dcdc1 {
+ regulator-name = "dcdc1";
+ regulator-boot-on;
+ regulator-always-on;
+ ti,enable-ext-control;
+ dcdc-ext-control-gpios = <&gpio 10 0>;
+ };
+
+ dcdc2 {
+ regulator-name = "dcdc2";
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ dcdc3 {
+ regulator-name = "dcdc3";
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ fet1 {
+ regulator-name = "fet1";
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ fet2 {
+ regulator-name = "fet2";
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ fet3 {
+ regulator-name = "fet3";
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ fet4 {
+ regulator-name = "fet4";
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ fet5 {
+ regulator-name = "fet5";
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ fet6 {
+ regulator-name = "fet6";
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ fet7 {
+ regulator-name = "fet7";
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo1 {
+ regulator-name = "ldo1";
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo2 {
+ regulator-name = "ldo2";
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/regulator/twl-regulator.txt b/Documentation/devicetree/bindings/regulator/twl-regulator.txt
index 658749b..75b0c16 100644
--- a/Documentation/devicetree/bindings/regulator/twl-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/twl-regulator.txt
@@ -18,20 +18,20 @@
- "ti,twl6030-vdd1" for VDD1 SMPS
- "ti,twl6030-vdd2" for VDD2 SMPS
- "ti,twl6030-vdd3" for VDD3 SMPS
-For twl6025 regulators/LDOs
+For twl6032 regulators/LDOs
- compatible:
- - "ti,twl6025-ldo1" for LDO1 LDO
- - "ti,twl6025-ldo2" for LDO2 LDO
- - "ti,twl6025-ldo3" for LDO3 LDO
- - "ti,twl6025-ldo4" for LDO4 LDO
- - "ti,twl6025-ldo5" for LDO5 LDO
- - "ti,twl6025-ldo6" for LDO6 LDO
- - "ti,twl6025-ldo7" for LDO7 LDO
- - "ti,twl6025-ldoln" for LDOLN LDO
- - "ti,twl6025-ldousb" for LDOUSB LDO
- - "ti,twl6025-smps3" for SMPS3 SMPS
- - "ti,twl6025-smps4" for SMPS4 SMPS
- - "ti,twl6025-vio" for VIO SMPS
+ - "ti,twl6032-ldo1" for LDO1 LDO
+ - "ti,twl6032-ldo2" for LDO2 LDO
+ - "ti,twl6032-ldo3" for LDO3 LDO
+ - "ti,twl6032-ldo4" for LDO4 LDO
+ - "ti,twl6032-ldo5" for LDO5 LDO
+ - "ti,twl6032-ldo6" for LDO6 LDO
+ - "ti,twl6032-ldo7" for LDO7 LDO
+ - "ti,twl6032-ldoln" for LDOLN LDO
+ - "ti,twl6032-ldousb" for LDOUSB LDO
+ - "ti,twl6032-smps3" for SMPS3 SMPS
+ - "ti,twl6032-smps4" for SMPS4 SMPS
+ - "ti,twl6032-vio" for VIO SMPS
For twl4030 regulators/LDOs
- compatible:
- "ti,twl4030-vaux1" for VAUX1 LDO
diff --git a/Documentation/devicetree/bindings/reset/fsl,imx-src.txt b/Documentation/devicetree/bindings/reset/fsl,imx-src.txt
new file mode 100644
index 0000000..1330177
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/fsl,imx-src.txt
@@ -0,0 +1,49 @@
+Freescale i.MX System Reset Controller
+======================================
+
+Please also refer to reset.txt in this directory for common reset
+controller binding usage.
+
+Required properties:
+- compatible: Should be "fsl,<chip>-src"
+- reg: should be register base and length as documented in the
+ datasheet
+- interrupts: Should contain SRC interrupt and CPU WDOG interrupt,
+ in this order.
+- #reset-cells: 1, see below
+
+example:
+
+src: src@020d8000 {
+ compatible = "fsl,imx6q-src";
+ reg = <0x020d8000 0x4000>;
+ interrupts = <0 91 0x04 0 96 0x04>;
+ #reset-cells = <1>;
+};
+
+Specifying reset lines connected to IP modules
+==============================================
+
+The system reset controller can be used to reset the GPU, VPU,
+IPU, and OpenVG IP modules on i.MX5 and i.MX6 ICs. Those device
+nodes should specify the reset line on the SRC in their resets
+property, containing a phandle to the SRC device node and a
+RESET_INDEX specifying which module to reset, as described in
+reset.txt
+
+example:
+
+ ipu1: ipu@02400000 {
+ resets = <&src 2>;
+ };
+ ipu2: ipu@02800000 {
+ resets = <&src 4>;
+ };
+
+The following RESET_INDEX values are valid for i.MX5:
+GPU_RESET 0
+VPU_RESET 1
+IPU1_RESET 2
+OPEN_VG_RESET 3
+The following additional RESET_INDEX value is valid for i.MX6:
+IPU2_RESET 4
diff --git a/Documentation/devicetree/bindings/reset/reset.txt b/Documentation/devicetree/bindings/reset/reset.txt
new file mode 100644
index 0000000..31db6ff
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/reset.txt
@@ -0,0 +1,75 @@
+= Reset Signal Device Tree Bindings =
+
+This binding is intended to represent the hardware reset signals present
+internally in most IC (SoC, FPGA, ...) designs. Reset signals for whole
+standalone chips are most likely better represented as GPIOs, although there
+are likely to be exceptions to this rule.
+
+Hardware blocks typically receive a reset signal. This signal is generated by
+a reset provider (e.g. power management or clock module) and received by a
+reset consumer (the module being reset, or a module managing when a sub-
+ordinate module is reset). This binding exists to represent the provider and
+consumer, and provide a way to couple the two together.
+
+A reset signal is represented by the phandle of the provider, plus a reset
+specifier - a list of DT cells that represents the reset signal within the
+provider. The length (number of cells) and semantics of the reset specifier
+are dictated by the binding of the reset provider, although common schemes
+are described below.
+
+A word on where to place reset signal consumers in device tree: It is possible
+in hardware for a reset signal to affect multiple logically separate HW blocks
+at once. In this case, it would be unwise to represent this reset signal in
+the DT node of each affected HW block, since if activated, an unrelated block
+may be reset. Instead, reset signals should be represented in the DT node
+where it makes most sense to control it; this may be a bus node if all
+children of the bus are affected by the reset signal, or an individual HW
+block node for dedicated reset signals. The intent of this binding is to give
+appropriate software access to the reset signals in order to manage the HW,
+rather than to slavishly enumerate the reset signal that affects each HW
+block.
+
+= Reset providers =
+
+Required properties:
+#reset-cells: Number of cells in a reset specifier; Typically 0 for nodes
+ with a single reset output and 1 for nodes with multiple
+ reset outputs.
+
+For example:
+
+ rst: reset-controller {
+ #reset-cells = <1>;
+ };
+
+= Reset consumers =
+
+Required properties:
+resets: List of phandle and reset specifier pairs, one pair
+ for each reset signal that affects the device, or that the
+ device manages. Note: if the reset provider specifies '0' for
+ #reset-cells, then only the phandle portion of the pair will
+ appear.
+
+Optional properties:
+reset-names: List of reset signal name strings sorted in the same order as
+ the resets property. Consumers drivers will use reset-names to
+ match reset signal names with reset specifiers.
+
+For example:
+
+ device {
+ resets = <&rst 20>;
+ reset-names = "reset";
+ };
+
+This represents a device with a single reset signal named "reset".
+
+ bus {
+ resets = <&rst 10> <&rst 11> <&rst 12> <&rst 11>;
+ reset-names = "i2s1", "i2s2", "dma", "mixer";
+ };
+
+This represents a bus that controls the reset signal of each of four sub-
+ordinate devices. Consider for example a bus that fails to operate unless no
+child device has reset asserted.
diff --git a/Documentation/devicetree/bindings/rng/brcm,bcm2835.txt b/Documentation/devicetree/bindings/rng/brcm,bcm2835.txt
new file mode 100644
index 0000000..07ccdaa
--- /dev/null
+++ b/Documentation/devicetree/bindings/rng/brcm,bcm2835.txt
@@ -0,0 +1,13 @@
+BCM2835 Random number generator
+
+Required properties:
+
+- compatible : should be "brcm,bcm2835-rng"
+- reg : Specifies base physical address and size of the registers.
+
+Example:
+
+rng {
+ compatible = "brcm,bcm2835-rng";
+ reg = <0x7e104000 0x10>;
+};
diff --git a/Documentation/devicetree/bindings/rtc/atmel,at91rm9200-rtc.txt b/Documentation/devicetree/bindings/rtc/atmel,at91rm9200-rtc.txt
new file mode 100644
index 0000000..34c1505
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/atmel,at91rm9200-rtc.txt
@@ -0,0 +1,15 @@
+Atmel AT91RM9200 Real Time Clock
+
+Required properties:
+- compatible: should be: "atmel,at91rm9200-rtc" or "atmel,at91sam9x5-rtc"
+- reg: physical base address of the controller and length of memory mapped
+ region.
+- interrupts: rtc alarm/event interrupt
+
+Example:
+
+rtc@fffffe00 {
+ compatible = "atmel,at91rm9200-rtc";
+ reg = <0xfffffe00 0x100>;
+ interrupts = <1 4 7>;
+};
diff --git a/Documentation/devicetree/bindings/rtc/dw-apb.txt b/Documentation/devicetree/bindings/rtc/dw-apb.txt
index 93e2b0f..eb2327b 100644
--- a/Documentation/devicetree/bindings/rtc/dw-apb.txt
+++ b/Documentation/devicetree/bindings/rtc/dw-apb.txt
@@ -5,9 +5,20 @@
- reg: physical base address of the controller and length of memory mapped
region.
- interrupts: IRQ line for the timer.
+- either clocks+clock-names or clock-frequency properties
+
+Optional properties:
+- clocks : list of clock specifiers, corresponding to entries in
+ the clock-names property;
+- clock-names : should contain "timer" and "pclk" entries, matching entries
+ in the clocks property.
- clock-frequency: The frequency in HZ of the timer.
- clock-freq: For backwards compatibility with picoxcell
+If using the clock specifiers, the pclk clock is optional, as not all
+systems may use one.
+
+
Example:
timer1: timer@ffc09000 {
@@ -23,3 +34,11 @@
clock-frequency = <200000000>;
reg = <0xffd00000 0x1000>;
};
+
+ timer3: timer@ffe00000 {
+ compatible = "snps,dw-apb-timer-osc";
+ interrupts = <0 170 4>;
+ reg = <0xffe00000 0x1000>;
+ clocks = <&timer_clk>, <&timer_pclk>;
+ clock-names = "timer", "pclk";
+ };
diff --git a/Documentation/devicetree/bindings/rtc/s3c-rtc.txt b/Documentation/devicetree/bindings/rtc/s3c-rtc.txt
index 90ec45f..7ac7259 100644
--- a/Documentation/devicetree/bindings/rtc/s3c-rtc.txt
+++ b/Documentation/devicetree/bindings/rtc/s3c-rtc.txt
@@ -7,7 +7,7 @@
- reg: physical base address of the controller and length of memory mapped
region.
- interrupts: Two interrupt numbers to the cpu should be specified. First
- interrupt number is the rtc alarm interupt and second interrupt number
+ interrupt number is the rtc alarm interrupt and second interrupt number
is the rtc tick interrupt. The number of cells representing a interrupt
depends on the parent interrupt controller.
diff --git a/Documentation/devicetree/bindings/serial/lantiq_asc.txt b/Documentation/devicetree/bindings/serial/lantiq_asc.txt
new file mode 100644
index 0000000..5b78591
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/lantiq_asc.txt
@@ -0,0 +1,16 @@
+Lantiq SoC ASC serial controller
+
+Required properties:
+- compatible : Should be "lantiq,asc"
+- reg : Address and length of the register set for the device
+- interrupts: the 3 (tx rx err) interrupt numbers. The interrupt specifier
+ depends on the interrupt-parent interrupt controller.
+
+Example:
+
+asc1: serial@E100C00 {
+ compatible = "lantiq,asc";
+ reg = <0xE100C00 0x400>;
+ interrupt-parent = <&icu0>;
+ interrupts = <112 113 114>;
+};
diff --git a/Documentation/devicetree/bindings/serial/nvidia,tegra20-hsuart.txt b/Documentation/devicetree/bindings/serial/nvidia,tegra20-hsuart.txt
new file mode 100644
index 0000000..392a449
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/nvidia,tegra20-hsuart.txt
@@ -0,0 +1,24 @@
+NVIDIA Tegra20/Tegra30 high speed (DMA based) UART controller driver.
+
+Required properties:
+- compatible : should be "nvidia,tegra30-hsuart", "nvidia,tegra20-hsuart".
+- reg: Should contain UART controller registers location and length.
+- interrupts: Should contain UART controller interrupts.
+- nvidia,dma-request-selector : The Tegra DMA controller's phandle and
+ request selector for this UART controller.
+
+Optional properties:
+- nvidia,enable-modem-interrupt: Enable modem interrupts. Should be enable
+ only if all 8 lines of UART controller are pinmuxed.
+
+Example:
+
+serial@70006000 {
+ compatible = "nvidia,tegra30-hsuart", "nvidia,tegra20-hsuart";
+ reg = <0x70006000 0x40>;
+ reg-shift = <2>;
+ interrupts = <0 36 0x04>;
+ nvidia,dma-request-selector = <&apbdma 8>;
+ nvidia,enable-modem-interrupt;
+ status = "disabled";
+};
diff --git a/Documentation/devicetree/bindings/serial/pl011.txt b/Documentation/devicetree/bindings/serial/pl011.txt
new file mode 100644
index 0000000..5d2e840
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/pl011.txt
@@ -0,0 +1,17 @@
+* ARM AMBA Primecell PL011 serial UART
+
+Required properties:
+- compatible: must be "arm,primecell", "arm,pl011"
+- reg: exactly one register range with length 0x1000
+- interrupts: exactly one interrupt specifier
+
+Optional properties:
+- pinctrl: When present, must have one state named "sleep"
+ and one state named "default"
+- clocks: When present, must refer to exactly one clock named
+ "apb_pclk"
+- dmas: When present, may have one or two dma channels.
+ The first one must be named "rx", the second one
+ must be named "tx".
+
+See also bindings/arm/primecell.txt
diff --git a/Documentation/devicetree/bindings/serio/olpc,ap-sp.txt b/Documentation/devicetree/bindings/serio/olpc,ap-sp.txt
new file mode 100644
index 0000000..0e72183
--- /dev/null
+++ b/Documentation/devicetree/bindings/serio/olpc,ap-sp.txt
@@ -0,0 +1,13 @@
+OLPC AP-SP serio interface
+
+Required properties:
+- compatible : "olpc,ap-sp"
+- reg : base address and length of SoC's WTM registers
+- interrupts : SP-AP interrupt
+
+Example:
+ ap-sp@d4290000 {
+ compatible = "olpc,ap-sp";
+ reg = <0xd4290000 0x1000>;
+ interrupts = <40>;
+ }
diff --git a/Documentation/devicetree/bindings/serio/snps-arc_ps2.txt b/Documentation/devicetree/bindings/serio/snps-arc_ps2.txt
new file mode 100644
index 0000000..38c2f21
--- /dev/null
+++ b/Documentation/devicetree/bindings/serio/snps-arc_ps2.txt
@@ -0,0 +1,16 @@
+* ARC PS/2 driver: PS/2 block used in some ARC FPGA's & nSIM OSCI model
+
+Required properties:
+- compatible : "snps,arc_ps2"
+- reg : offset and length (always 0x14) of registers
+- interrupts : interrupt
+- interrupt-names : name of interrupt, must be "arc_ps2_irq"
+
+Example:
+
+serio@c9000400 {
+ compatible = "snps,arc_ps2";
+ reg = <0xc9000400 0x14>;
+ interrupts = <13>;
+ interrupt-names = "arc_ps2_irq";
+}
diff --git a/Documentation/devicetree/bindings/sound/adi,adau1701.txt b/Documentation/devicetree/bindings/sound/adi,adau1701.txt
new file mode 100644
index 0000000..547a49b
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/adi,adau1701.txt
@@ -0,0 +1,35 @@
+Analog Devices ADAU1701
+
+Required properties:
+
+ - compatible: Should contain "adi,adau1701"
+ - reg: The i2c address. Value depends on the state of ADDR0
+ and ADDR1, as wired in hardware.
+
+Optional properties:
+
+ - reset-gpio: A GPIO spec to define which pin is connected to the
+ chip's !RESET pin. If specified, the driver will
+ assert a hardware reset at probe time.
+ - adi,pll-mode-gpios: An array of two GPIO specs to describe the GPIOs
+ the ADAU's PLL config pins are connected to.
+ The state of the pins are set according to the
+ configured clock divider on ASoC side before the
+ firmware is loaded.
+ - adi,pin-config: An array of 12 numerical values selecting one of the
+ pin configurations as described in the datasheet,
+ table 53. Note that the value of this property has
+ to be prefixed with '/bits/ 8'.
+
+Examples:
+
+ i2c_bus {
+ adau1701@34 {
+ compatible = "adi,adau1701";
+ reg = <0x34>;
+ reset-gpio = <&gpio 23 0>;
+ adi,pll-mode-gpios = <&gpio 24 0 &gpio 25 0>;
+ adi,pin-config = /bits/ 8 <0x4 0x7 0x5 0x5 0x4 0x4
+ 0x4 0x4 0x4 0x4 0x4 0x4>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/ak4642.txt b/Documentation/devicetree/bindings/sound/ak4642.txt
new file mode 100644
index 0000000..623d4e7
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/ak4642.txt
@@ -0,0 +1,17 @@
+AK4642 I2C transmitter
+
+This device supports I2C mode only.
+
+Required properties:
+
+ - compatible : "asahi-kasei,ak4642" or "asahi-kasei,ak4643" or "asahi-kasei,ak4648"
+ - reg : The chip select number on the I2C bus
+
+Example:
+
+&i2c {
+ ak4648: ak4648@0x12 {
+ compatible = "asahi-kasei,ak4642";
+ reg = <0x12>;
+ };
+};
diff --git a/Documentation/devicetree/bindings/sound/ak5386.txt b/Documentation/devicetree/bindings/sound/ak5386.txt
new file mode 100644
index 0000000..dc3914f
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/ak5386.txt
@@ -0,0 +1,19 @@
+AK5386 Single-ended 24-Bit 192kHz delta-sigma ADC
+
+This device has no control interface.
+
+Required properties:
+
+ - compatible : "asahi-kasei,ak5386"
+
+Optional properties:
+
+ - reset-gpio : a GPIO spec for the reset/power down pin.
+ If specified, it will be deasserted at probe time.
+
+Example:
+
+spdif: ak5386@0 {
+ compatible = "asahi-kasei,ak5386";
+ reset-gpio = <&gpio0 23>;
+};
diff --git a/Documentation/devicetree/bindings/sound/cs4271.txt b/Documentation/devicetree/bindings/sound/cs4271.txt
index a850fb9..e2cd1d7 100644
--- a/Documentation/devicetree/bindings/sound/cs4271.txt
+++ b/Documentation/devicetree/bindings/sound/cs4271.txt
@@ -20,6 +20,18 @@
!RESET pin
- cirrus,amuteb-eq-bmutec: When given, the Codec's AMUTEB=BMUTEC flag
is enabled.
+ - cirrus,enable-soft-reset:
+ The CS4271 requires its LRCLK and MCLK to be stable before its RESET
+ line is de-asserted. That also means that clocks cannot be changed
+ without putting the chip back into hardware reset, which also requires
+ a complete re-initialization of all registers.
+
+ One (undocumented) workaround is to assert and de-assert the PDN bit
+ in the MODE2 register. This workaround can be enabled with this DT
+ property.
+
+ Note that this is not needed in case the clocks are stable
+ throughout the entire runtime of the codec.
Examples:
diff --git a/Documentation/devicetree/bindings/sound/imx-audio-wm8962.txt b/Documentation/devicetree/bindings/sound/imx-audio-wm8962.txt
new file mode 100644
index 0000000..f49450a
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/imx-audio-wm8962.txt
@@ -0,0 +1,46 @@
+Freescale i.MX audio complex with WM8962 codec
+
+Required properties:
+- compatible : "fsl,imx-audio-wm8962"
+- model : The user-visible name of this sound complex
+- ssi-controller : The phandle of the i.MX SSI controller
+- audio-codec : The phandle of the WM8962 audio codec
+- audio-routing : A list of the connections between audio components.
+ Each entry is a pair of strings, the first being the connection's sink,
+ the second being the connection's source. Valid names could be power
+ supplies, WM8962 pins, and the jacks on the board:
+
+ Power supplies:
+ * Mic Bias
+
+ Board connectors:
+ * Mic Jack
+ * Headphone Jack
+ * Ext Spk
+
+- mux-int-port : The internal port of the i.MX audio muxer (AUDMUX)
+- mux-ext-port : The external port of the i.MX audio muxer
+
+Note: The AUDMUX port numbering should start at 1, which is consistent with
+hardware manual.
+
+Example:
+
+sound {
+ compatible = "fsl,imx6q-sabresd-wm8962",
+ "fsl,imx-audio-wm8962";
+ model = "wm8962-audio";
+ ssi-controller = <&ssi2>;
+ audio-codec = <&codec>;
+ audio-routing =
+ "Headphone Jack", "HPOUTL",
+ "Headphone Jack", "HPOUTR",
+ "Ext Spk", "SPKOUTL",
+ "Ext Spk", "SPKOUTR",
+ "MICBIAS", "AMIC",
+ "IN3R", "MICBIAS",
+ "DMIC", "MICBIAS",
+ "DMICDAT", "DMIC";
+ mux-int-port = <2>;
+ mux-ext-port = <3>;
+};
diff --git a/Documentation/devicetree/bindings/sound/mxs-saif.txt b/Documentation/devicetree/bindings/sound/mxs-saif.txt
index c37ba61..7ba07a1 100644
--- a/Documentation/devicetree/bindings/sound/mxs-saif.txt
+++ b/Documentation/devicetree/bindings/sound/mxs-saif.txt
@@ -3,8 +3,11 @@
Required properties:
- compatible: Should be "fsl,<chip>-saif"
- reg: Should contain registers location and length
-- interrupts: Should contain ERROR and DMA interrupts
-- fsl,saif-dma-channel: APBX DMA channel for the SAIF
+- interrupts: Should contain ERROR interrupt number
+- dmas: DMA specifier, consisting of a phandle to DMA controller node
+ and SAIF DMA channel ID.
+ Refer to dma.txt and fsl-mxs-dma.txt for details.
+- dma-names: Must be "rx-tx".
Optional properties:
- fsl,saif-master: phandle to the master SAIF. It's only required for
@@ -23,14 +26,16 @@
saif0: saif@80042000 {
compatible = "fsl,imx28-saif";
reg = <0x80042000 2000>;
- interrupts = <59 80>;
- fsl,saif-dma-channel = <4>;
+ interrupts = <59>;
+ dmas = <&dma_apbx 4>;
+ dma-names = "rx-tx";
};
saif1: saif@80046000 {
compatible = "fsl,imx28-saif";
reg = <0x80046000 2000>;
- interrupts = <58 81>;
- fsl,saif-dma-channel = <5>;
+ interrupts = <58>;
+ dmas = <&dma_apbx 5>;
+ dma-names = "rx-tx";
fsl,saif-master = <&saif0>;
};
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-alc5632.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-alc5632.txt
index b77a97c..05ffecb 100644
--- a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-alc5632.txt
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-alc5632.txt
@@ -2,6 +2,11 @@
Required properties:
- compatible : "nvidia,tegra-audio-alc5632"
+- clocks : Must contain an entry for each entry in clock-names.
+- clock-names : Must include the following entries:
+ "pll_a" (The Tegra clock of that name),
+ "pll_a_out0" (The Tegra clock of that name),
+ "mclk" (The Tegra cdev1/extern1 clock, which feeds the CODEC's mclk)
- nvidia,model : The user-visible name of this sound complex.
- nvidia,audio-routing : A list of the connections between audio components.
Each entry is a pair of strings, the first being the connection's sink,
@@ -56,4 +61,7 @@
nvidia,i2s-controller = <&tegra_i2s1>;
nvidia,audio-codec = <&alc5632>;
+
+ clocks = <&tegra_car 112>, <&tegra_car 113>, <&tegra_car 93>;
+ clock-names = "pll_a", "pll_a_out0", "mclk";
};
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-rt5640.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-rt5640.txt
new file mode 100644
index 0000000..d130818
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-rt5640.txt
@@ -0,0 +1,71 @@
+NVIDIA Tegra audio complex, with RT5640 CODEC
+
+Required properties:
+- compatible : "nvidia,tegra-audio-rt5640"
+- clocks : Must contain an entry for each entry in clock-names.
+- clock-names : Must include the following entries:
+ "pll_a" (The Tegra clock of that name),
+ "pll_a_out0" (The Tegra clock of that name),
+ "mclk" (The Tegra cdev1/extern1 clock, which feeds the CODEC's mclk)
+- nvidia,model : The user-visible name of this sound complex.
+- nvidia,audio-routing : A list of the connections between audio components.
+ Each entry is a pair of strings, the first being the connection's sink,
+ the second being the connection's source. Valid names for sources and
+ sinks are the RT5640's pins, and the jacks on the board:
+
+ RT5640 pins:
+
+ * DMIC1
+ * DMIC2
+ * MICBIAS1
+ * IN1P
+ * IN1R
+ * IN2P
+ * IN2R
+ * HPOL
+ * HPOR
+ * LOUTL
+ * LOUTR
+ * MONOP
+ * MONON
+ * SPOLP
+ * SPOLN
+ * SPORP
+ * SPORN
+
+ Board connectors:
+
+ * Headphones
+ * Speakers
+
+- nvidia,i2s-controller : The phandle of the Tegra I2S controller that's
+ connected to the CODEC.
+- nvidia,audio-codec : The phandle of the RT5640 audio codec. This binding
+ assumes that AIF1 on the CODEC is connected to Tegra.
+
+Optional properties:
+- nvidia,hp-det-gpios : The GPIO that detects headphones are plugged in
+
+Example:
+
+sound {
+ compatible = "nvidia,tegra-audio-rt5640-dalmore",
+ "nvidia,tegra-audio-rt5640";
+ nvidia,model = "NVIDIA Tegra Dalmore";
+
+ nvidia,audio-routing =
+ "Headphones", "HPOR",
+ "Headphones", "HPOL",
+ "Speakers", "SPORP",
+ "Speakers", "SPORN",
+ "Speakers", "SPOLP",
+ "Speakers", "SPOLN";
+
+ nvidia,i2s-controller = <&tegra_i2s1>;
+ nvidia,audio-codec = <&rt5640>;
+
+ nvidia,hp-det-gpios = <&gpio 143 0>; /* GPIO PR7 */
+
+ clocks = <&tegra_car 216>, <&tegra_car 217>, <&tegra_car 120>;
+ clock-names = "pll_a", "pll_a_out0", "mclk";
+};
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-trimslice.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-trimslice.txt
index 04b14cf..ef1fe73 100644
--- a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-trimslice.txt
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-trimslice.txt
@@ -2,6 +2,11 @@
Required properties:
- compatible : "nvidia,tegra-audio-trimslice"
+- clocks : Must contain an entry for each entry in clock-names.
+- clock-names : Must include the following entries:
+ "pll_a" (The Tegra clock of that name),
+ "pll_a_out0" (The Tegra clock of that name),
+ "mclk" (The Tegra cdev1/extern1 clock, which feeds the CODEC's mclk)
- nvidia,i2s-controller : The phandle of the Tegra I2S1 controller
- nvidia,audio-codec : The phandle of the WM8903 audio codec
@@ -11,4 +16,6 @@
compatible = "nvidia,tegra-audio-trimslice";
nvidia,i2s-controller = <&tegra_i2s1>;
nvidia,audio-codec = <&codec>;
+ clocks = <&tegra_car 112>, <&tegra_car 113>, <&tegra_car 93>;
+ clock-names = "pll_a", "pll_a_out0", "mclk";
};
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8753.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8753.txt
index c4dd39c..d145106 100644
--- a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8753.txt
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8753.txt
@@ -2,6 +2,11 @@
Required properties:
- compatible : "nvidia,tegra-audio-wm8753"
+- clocks : Must contain an entry for each entry in clock-names.
+- clock-names : Must include the following entries:
+ "pll_a" (The Tegra clock of that name),
+ "pll_a_out0" (The Tegra clock of that name),
+ "mclk" (The Tegra cdev1/extern1 clock, which feeds the CODEC's mclk)
- nvidia,model : The user-visible name of this sound complex.
- nvidia,audio-routing : A list of the connections between audio components.
Each entry is a pair of strings, the first being the connection's sink,
@@ -50,5 +55,8 @@
nvidia,i2s-controller = <&i2s1>;
nvidia,audio-codec = <&wm8753>;
+
+ clocks = <&tegra_car 112>, <&tegra_car 113>, <&tegra_car 93>;
+ clock-names = "pll_a", "pll_a_out0", "mclk";
};
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8903.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8903.txt
index d5b0da8..3bf722d 100644
--- a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8903.txt
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8903.txt
@@ -2,6 +2,11 @@
Required properties:
- compatible : "nvidia,tegra-audio-wm8903"
+- clocks : Must contain an entry for each entry in clock-names.
+- clock-names : Must include the following entries:
+ "pll_a" (The Tegra clock of that name),
+ "pll_a_out0" (The Tegra clock of that name),
+ "mclk" (The Tegra cdev1/extern1 clock, which feeds the CODEC's mclk)
- nvidia,model : The user-visible name of this sound complex.
- nvidia,audio-routing : A list of the connections between audio components.
Each entry is a pair of strings, the first being the connection's sink,
@@ -67,5 +72,8 @@
nvidia,hp-det-gpios = <&gpio 178 0>; /* gpio PW2 */
nvidia,int-mic-en-gpios = <&gpio 184 0>; /*gpio PX0 */
nvidia,ext-mic-en-gpios = <&gpio 185 0>; /* gpio PX1 */
+
+ clocks = <&tegra_car 112>, <&tegra_car 113>, <&tegra_car 93>;
+ clock-names = "pll_a", "pll_a_out0", "mclk";
};
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm9712.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm9712.txt
new file mode 100644
index 0000000..ad589b1
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm9712.txt
@@ -0,0 +1,59 @@
+NVIDIA Tegra audio complex
+
+Required properties:
+- compatible : "nvidia,tegra-audio-wm9712"
+- clocks : Must contain an entry for each entry in clock-names.
+- clock-names : Must include the following entries:
+ "pll_a" (The Tegra clock of that name),
+ "pll_a_out0" (The Tegra clock of that name),
+ "mclk" (The Tegra cdev1/extern1 clock, which feeds the CODEC's mclk)
+- nvidia,model : The user-visible name of this sound complex.
+- nvidia,audio-routing : A list of the connections between audio components.
+ Each entry is a pair of strings, the first being the connection's sink,
+ the second being the connection's source. Valid names for sources and
+ sinks are the WM9712's pins, and the jacks on the board:
+
+ WM9712 pins:
+
+ * MONOOUT
+ * HPOUTL
+ * HPOUTR
+ * LOUT2
+ * ROUT2
+ * OUT3
+ * LINEINL
+ * LINEINR
+ * PHONE
+ * PCBEEP
+ * MIC1
+ * MIC2
+ * Mic Bias
+
+ Board connectors:
+
+ * Headphone
+ * LineIn
+ * Mic
+
+- nvidia,ac97-controller : The phandle of the Tegra AC97 controller
+
+
+Example:
+
+sound {
+ compatible = "nvidia,tegra-audio-wm9712-colibri_t20",
+ "nvidia,tegra-audio-wm9712";
+ nvidia,model = "Toradex Colibri T20";
+
+ nvidia,audio-routing =
+ "Headphone", "HPOUTL",
+ "Headphone", "HPOUTR",
+ "LineIn", "LINEINL",
+ "LineIn", "LINEINR",
+ "Mic", "MIC1";
+
+ nvidia,ac97-controller = <&ac97>;
+
+ clocks = <&tegra_car 112>, <&tegra_car 113>, <&tegra_car 93>;
+ clock-names = "pll_a", "pll_a_out0", "mclk";
+};
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra20-ac97.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra20-ac97.txt
new file mode 100644
index 0000000..c145497
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra20-ac97.txt
@@ -0,0 +1,22 @@
+NVIDIA Tegra 20 AC97 controller
+
+Required properties:
+- compatible : "nvidia,tegra20-ac97"
+- reg : Should contain AC97 controller registers location and length
+- interrupts : Should contain AC97 interrupt
+- nvidia,dma-request-selector : The Tegra DMA controller's phandle and
+ request selector for the AC97 controller
+- nvidia,codec-reset-gpio : The Tegra GPIO controller's phandle and the number
+ of the GPIO used to reset the external AC97 codec
+- nvidia,codec-sync-gpio : The Tegra GPIO controller's phandle and the number
+ of the GPIO corresponding with the AC97 DAP _FS line
+Example:
+
+ac97@70002000 {
+ compatible = "nvidia,tegra20-ac97";
+ reg = <0x70002000 0x200>;
+ interrupts = <0 81 0x04>;
+ nvidia,dma-request-selector = <&apbdma 12>;
+ nvidia,codec-reset-gpio = <&gpio 170 0>;
+ nvidia,codec-sync-gpio = <&gpio 120 0>;
+};
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra30-ahub.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra30-ahub.txt
index 1ac7b16..0e5c12c 100644
--- a/Documentation/devicetree/bindings/sound/nvidia,tegra30-ahub.txt
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra30-ahub.txt
@@ -1,12 +1,22 @@
NVIDIA Tegra30 AHUB (Audio Hub)
Required properties:
-- compatible : "nvidia,tegra30-ahub"
+- compatible : "nvidia,tegra30-ahub", "nvidia,tegra114-ahub", etc.
- reg : Should contain the register physical address and length for each of
- the AHUB's APBIF registers and the AHUB's own registers.
+ the AHUB's register blocks.
+ - Tegra30 requires 2 entries, for the APBIF and AHUB/AUDIO register blocks.
+ - Tegra114 requires an additional entry, for the APBIF2 register block.
- interrupts : Should contain AHUB interrupt
-- nvidia,dma-request-selector : The Tegra DMA controller's phandle and
- request selector for the first APBIF channel.
+- nvidia,dma-request-selector : A list of the DMA channel specifiers. Each
+ entry contains the Tegra DMA controller's phandle and request selector.
+ If a single entry is present, the request selectors for the channels are
+ assumed to be contiguous, and increment from this value.
+ If multiple values are given, one value must be given per channel.
+- clocks : Must contain an entry for each required entry in clock-names.
+- clock-names : Must include the following entries:
+ - Tegra30: Requires d_audio, apbif, i2s0, i2s1, i2s2, i2s3, i2s4, dam0,
+ dam1, dam2, spdif_in.
+ - Tegra114: Additionally requires amx, adx.
- ranges : The bus address mapping for the configlink register bus.
Can be empty since the mapping is 1:1.
- #address-cells : For the configlink bus. Should be <1>;
@@ -25,7 +35,13 @@
reg = <0x70080000 0x200 0x70080200 0x100>;
interrupts = < 0 103 0x04 >;
nvidia,dma-request-selector = <&apbdma 1>;
-
+ clocks = <&tegra_car 106>, <&tegra_car 107>, <&tegra_car 30>,
+ <&tegra_car 11>, <&tegra_car 18>, <&tegra_car 101>,
+ <&tegra_car 102>, <&tegra_car 108>, <&tegra_car 109>,
+ <&tegra_car 110>, <&tegra_car 162>;
+ clock-names = "d_audio", "apbif", "i2s0", "i2s1", "i2s2",
+ "i2s3", "i2s4", "dam0", "dam1", "dam2",
+ "spdif_in";
ranges;
#address-cells = <1>;
#size-cells = <1>;
diff --git a/Documentation/devicetree/bindings/sound/omap-twl4030.txt b/Documentation/devicetree/bindings/sound/omap-twl4030.txt
index 6fae51c..1ab6bc8 100644
--- a/Documentation/devicetree/bindings/sound/omap-twl4030.txt
+++ b/Documentation/devicetree/bindings/sound/omap-twl4030.txt
@@ -6,6 +6,52 @@
- ti,mcbsp: phandle for the McBSP node
- ti,codec: phandle for the twl4030 audio node
+Optional properties:
+- ti,mcbsp-voice: phandle for the McBSP node connected to the voice port of twl
+- ti, jack-det-gpio: Jack detect GPIO
+- ti,audio-routing: List of connections between audio components.
+ Each entry is a pair of strings, the first being the connection's sink,
+ the second being the connection's source.
+ If the routing is not provided all possible connection will be available
+
+Available audio endpoints for the audio-routing table:
+
+Board connectors:
+ * Headset Stereophone
+ * Earpiece Spk
+ * Handsfree Spk
+ * Ext Spk
+ * Main Mic
+ * Sub Mic
+ * Headset Mic
+ * Carkit Mic
+ * Digital0 Mic
+ * Digital1 Mic
+ * Line In
+
+twl4030 pins:
+ * HSOL
+ * HSOR
+ * EARPIECE
+ * HFL
+ * HFR
+ * PREDRIVEL
+ * PREDRIVER
+ * CARKITL
+ * CARKITR
+ * MAINMIC
+ * SUBMIC
+ * HSMIC
+ * DIGIMIC0
+ * DIGIMIC1
+ * CARKITMIC
+ * AUXL
+ * AUXR
+
+ * Headset Mic Bias
+ * Mic Bias 1 /* Used for Main Mic or Digimic0 */
+ * Mic Bias 2 /* Used for Sub Mic or Digimic1 */
+
Example:
sound {
diff --git a/Documentation/devicetree/bindings/sound/renesas,fsi.txt b/Documentation/devicetree/bindings/sound/renesas,fsi.txt
new file mode 100644
index 0000000..c5be003
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/renesas,fsi.txt
@@ -0,0 +1,26 @@
+Renesas FSI
+
+Required properties:
+- compatible : "renesas,sh_fsi2" or "renesas,sh_fsi"
+- reg : Should contain the register physical address and length
+- interrupts : Should contain FSI interrupt
+
+- fsia,spdif-connection : FSI is connected by S/PDFI
+- fsia,stream-mode-support : FSI supports 16bit stream mode.
+- fsia,use-internal-clock : FSI uses internal clock when master mode.
+
+- fsib,spdif-connection : same as fsia
+- fsib,stream-mode-support : same as fsia
+- fsib,use-internal-clock : same as fsia
+
+Example:
+
+sh_fsi2: sh_fsi2@0xec230000 {
+ compatible = "renesas,sh_fsi2";
+ reg = <0xec230000 0x400>;
+ interrupts = <0 146 0x4>;
+
+ fsia,spdif-connection;
+ fsia,stream-mode-support;
+ fsia,use-internal-clock;
+};
diff --git a/Documentation/devicetree/bindings/sound/rt5640.txt b/Documentation/devicetree/bindings/sound/rt5640.txt
new file mode 100644
index 0000000..005bcb2
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/rt5640.txt
@@ -0,0 +1,30 @@
+RT5640 audio CODEC
+
+This device supports I2C only.
+
+Required properties:
+
+- compatible : "realtek,rt5640".
+
+- reg : The I2C address of the device.
+
+- interrupts : The CODEC's interrupt output.
+
+Optional properties:
+
+- realtek,in1-differential
+- realtek,in2-differential
+ Boolean. Indicate MIC1/2 input are differential, rather than single-ended.
+
+- realtek,ldo1-en-gpios : The GPIO that controls the CODEC's LDO1_EN pin.
+
+Example:
+
+rt5640 {
+ compatible = "realtek,rt5640";
+ reg = <0x1c>;
+ interrupt-parent = <&gpio>;
+ interrupts = <TEGRA_GPIO(W, 3) GPIO_ACTIVE_HIGH>;
+ realtek,ldo1-en-gpios =
+ <&gpio TEGRA_GPIO(V, 3) GPIO_ACTIVE_HIGH>;
+};
diff --git a/Documentation/devicetree/bindings/sound/samsung,smdk-wm8994.txt b/Documentation/devicetree/bindings/sound/samsung,smdk-wm8994.txt
new file mode 100644
index 0000000..4686646f
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/samsung,smdk-wm8994.txt
@@ -0,0 +1,14 @@
+Samsung SMDK audio complex
+
+Required properties:
+- compatible : "samsung,smdk-wm8994"
+- samsung,i2s-controller: The phandle of the Samsung I2S0 controller
+- samsung,audio-codec: The phandle of the WM8994 audio codec
+Example:
+
+sound {
+ compatible = "samsung,smdk-wm8994";
+
+ samsung,i2s-controller = <&i2s0>;
+ samsung,audio-codec = <&wm8994>;
+};
diff --git a/Documentation/devicetree/bindings/sound/samsung-i2s.txt b/Documentation/devicetree/bindings/sound/samsung-i2s.txt
new file mode 100644
index 0000000..025e66b
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/samsung-i2s.txt
@@ -0,0 +1,55 @@
+* Samsung I2S controller
+
+Required SoC Specific Properties:
+
+- compatible : "samsung,i2s-v5"
+- reg: physical base address of the controller and length of memory mapped
+ region.
+- dmas: list of DMA controller phandle and DMA request line ordered pairs.
+- dma-names: identifier string for each DMA request line in the dmas property.
+ These strings correspond 1:1 with the ordered pairs in dmas.
+- clocks: Handle to iis clock and RCLK source clk.
+- clock-names:
+ i2s0 uses some base clks from CMU and some are from audio subsystem internal
+ clock controller. The clock names for i2s0 should be "iis", "i2s_opclk0" and
+ "i2s_opclk1" as shown in the example below.
+ i2s1 and i2s2 uses clocks from CMU. The clock names for i2s1 and i2s2 should
+ be "iis" and "i2s_opclk0".
+ "iis" is the i2s bus clock and i2s_opclk0, i2s_opclk1 are sources of the root
+ clk. i2s0 has internal mux to select the source of root clk and i2s1 and i2s2
+ doesn't have any such mux.
+
+Optional SoC Specific Properties:
+
+- samsung,supports-6ch: If the I2S Primary sound source has 5.1 Channel
+ support, this flag is enabled.
+- samsung,supports-rstclr: This flag should be set if I2S software reset bit
+ control is required. When this flag is set I2S software reset bit will be
+ enabled or disabled based on need.
+- samsung,supports-secdai:If I2S block has a secondary FIFO and internal DMA,
+ then this flag is enabled.
+- samsung,idma-addr: Internal DMA register base address of the audio
+ sub system(used in secondary sound source).
+- pinctrl-0: Should specify pin control groups used for this controller.
+- pinctrl-names: Should contain only one value - "default".
+
+Example:
+
+i2s0: i2s@03830000 {
+ compatible = "samsung,i2s-v5";
+ reg = <0x03830000 0x100>;
+ dmas = <&pdma0 10
+ &pdma0 9
+ &pdma0 8>;
+ dma-names = "tx", "rx", "tx-sec";
+ clocks = <&clock_audss EXYNOS_I2S_BUS>,
+ <&clock_audss EXYNOS_I2S_BUS>,
+ <&clock_audss EXYNOS_SCLK_I2S>;
+ clock-names = "iis", "i2s_opclk0", "i2s_opclk1";
+ samsung,supports-6ch;
+ samsung,supports-rstclr;
+ samsung,supports-secdai;
+ samsung,idma-addr = <0x03000000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2s0_bus>;
+};
diff --git a/Documentation/devicetree/bindings/sound/sgtl5000.txt b/Documentation/devicetree/bindings/sound/sgtl5000.txt
index 9cc4444..955df60 100644
--- a/Documentation/devicetree/bindings/sound/sgtl5000.txt
+++ b/Documentation/devicetree/bindings/sound/sgtl5000.txt
@@ -5,9 +5,12 @@
- reg : the I2C address of the device
+- clocks : the clock provider of SYS_MCLK
+
Example:
codec: sgtl5000@0a {
compatible = "fsl,sgtl5000";
reg = <0x0a>;
+ clocks = <&clks 150>;
};
diff --git a/Documentation/devicetree/bindings/sound/spdif-receiver.txt b/Documentation/devicetree/bindings/sound/spdif-receiver.txt
new file mode 100644
index 0000000..80f807b
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/spdif-receiver.txt
@@ -0,0 +1,10 @@
+Device-Tree bindings for dummy spdif receiver
+
+Required properties:
+ - compatible: should be "linux,spdif-dir".
+
+Example node:
+
+ codec: spdif-receiver {
+ compatible = "linux,spdif-dir";
+ };
diff --git a/Documentation/devicetree/bindings/sound/spdif-transmitter.txt b/Documentation/devicetree/bindings/sound/spdif-transmitter.txt
new file mode 100644
index 0000000..55a8584
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/spdif-transmitter.txt
@@ -0,0 +1,10 @@
+Device-Tree bindings for dummy spdif transmitter
+
+Required properties:
+ - compatible: should be "linux,spdif-dit".
+
+Example node:
+
+ codec: spdif-transmitter {
+ compatible = "linux,spdif-dit";
+ };
diff --git a/Documentation/devicetree/bindings/sound/ssm2518.txt b/Documentation/devicetree/bindings/sound/ssm2518.txt
new file mode 100644
index 0000000..59381a7
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/ssm2518.txt
@@ -0,0 +1,20 @@
+SSM2518 audio amplifier
+
+This device supports I2C only.
+
+Required properties:
+ - compatible : Must be "adi,ssm2518"
+ - reg : the I2C address of the device. This will either be 0x34 (ADDR pin low)
+ or 0x35 (ADDR pin high)
+
+Optional properties:
+ - gpios : GPIO connected to the nSD pin. If the property is not present it is
+ assumed that the nSD pin is hardwired to always on.
+
+Example:
+
+ ssm2518: ssm2518@34 {
+ compatible = "adi,ssm2518";
+ reg = <0x34>;
+ gpios = <&gpio 5 0>;
+ };
diff --git a/Documentation/devicetree/bindings/sound/ti,tas5086.txt b/Documentation/devicetree/bindings/sound/ti,tas5086.txt
new file mode 100644
index 0000000..d2866a0
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/ti,tas5086.txt
@@ -0,0 +1,43 @@
+Texas Instruments TAS5086 6-channel PWM Processor
+
+Required properties:
+
+ - compatible: Should contain "ti,tas5086".
+ - reg: The i2c address. Should contain <0x1b>.
+
+Optional properties:
+
+ - reset-gpio: A GPIO spec to define which pin is connected to the
+ chip's !RESET pin. If specified, the driver will
+ assert a hardware reset at probe time.
+
+ - ti,charge-period: This property should contain the time in microseconds
+ that closely matches the external single-ended
+ split-capacitor charge period. The hardware chip
+ waits for this period of time before starting the
+ PWM signals. This helps reduce pops and clicks.
+
+ When not specified, the hardware default of 1300ms
+ is retained.
+
+ - ti,mid-z-channel-X: Boolean properties, X being a number from 1 to 6.
+ If given, channel X will start with the Mid-Z start
+ sequence, otherwise the default Low-Z scheme is used.
+
+ The correct configuration depends on how the power
+ stages connected to the PWM output pins work. Not all
+ power stages are compatible to Mid-Z - please refer
+ to the datasheets for more details.
+
+ Most systems should not set any of these properties.
+
+Examples:
+
+ i2c_bus {
+ tas5086@1b {
+ compatible = "ti,tas5086";
+ reg = <0x1b>;
+ reset-gpio = <&gpio 23 0>;
+ ti,charge-period = <156000>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/tlv320aic3x.txt b/Documentation/devicetree/bindings/sound/tlv320aic3x.txt
index e7b98f4..f47c3f5 100644
--- a/Documentation/devicetree/bindings/sound/tlv320aic3x.txt
+++ b/Documentation/devicetree/bindings/sound/tlv320aic3x.txt
@@ -11,6 +11,12 @@
- gpio-reset - gpio pin number used for codec reset
- ai3x-gpio-func - <array of 2 int> - AIC3X_GPIO1 & AIC3X_GPIO2 Functionality
+- ai3x-micbias-vg - MicBias Voltage required.
+ 1 - MICBIAS output is powered to 2.0V,
+ 2 - MICBIAS output is powered to 2.5V,
+ 3 - MICBIAS output is connected to AVDD,
+ If this node is not mentioned or if the value is incorrect, then MicBias
+ is powered down.
Example:
diff --git a/Documentation/devicetree/bindings/sound/wm8962.txt b/Documentation/devicetree/bindings/sound/wm8962.txt
new file mode 100644
index 0000000..7f82b59
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/wm8962.txt
@@ -0,0 +1,39 @@
+WM8962 audio CODEC
+
+This device supports I2C only.
+
+Required properties:
+
+ - compatible : "wlf,wm8962"
+
+ - reg : the I2C address of the device.
+
+Optional properties:
+ - spk-mono: This is a boolean property. If present, the SPK_MONO bit
+ of R51 (Class D Control 2) gets set, indicating that the speaker is
+ in mono mode.
+
+ - mic-cfg : Default register value for R48 (Additional Control 4).
+ If absent, the default should be the register default.
+
+ - gpio-cfg : A list of GPIO configuration register values. The list must
+ be 6 entries long. If absent, no configuration of these registers is
+ performed. And note that only the value within [0x0, 0xffff] is valid.
+ Any other value is regarded as setting the GPIO register by its reset
+ value 0x0.
+
+Example:
+
+codec: wm8962@1a {
+ compatible = "wlf,wm8962";
+ reg = <0x1a>;
+
+ gpio-cfg = <
+ 0x0000 /* 0:Default */
+ 0x0000 /* 1:Default */
+ 0x0013 /* 2:FN_DMICCLK */
+ 0x0000 /* 3:Default */
+ 0x8014 /* 4:FN_DMICCDAT */
+ 0x0000 /* 5:Default */
+ >;
+};
diff --git a/Documentation/devicetree/bindings/sound/wm8994.txt b/Documentation/devicetree/bindings/sound/wm8994.txt
index 7a7eb1e..f2f3e80 100644
--- a/Documentation/devicetree/bindings/sound/wm8994.txt
+++ b/Documentation/devicetree/bindings/sound/wm8994.txt
@@ -5,14 +5,70 @@
Required properties:
- - compatible : "wlf,wm1811", "wlf,wm8994", "wlf,wm8958"
+ - compatible : One of "wlf,wm1811", "wlf,wm8994" or "wlf,wm8958".
- reg : the I2C address of the device for I2C, the chip select
number for SPI.
+ - gpio-controller : Indicates this device is a GPIO controller.
+ - #gpio-cells : Must be 2. The first cell is the pin number and the
+ second cell is used to specify optional parameters (currently unused).
+
+ - AVDD2-supply, DBVDD1-supply, DBVDD2-supply, DBVDD3-supply, CPVDD-supply,
+ SPKVDD1-supply, SPKVDD2-supply : power supplies for the device, as covered
+ in Documentation/devicetree/bindings/regulator/regulator.txt
+
+Optional properties:
+
+ - interrupts : The interrupt line the IRQ signal for the device is
+ connected to. This is optional, if it is not connected then none
+ of the interrupt related properties should be specified.
+ - interrupt-controller : These devices contain interrupt controllers
+ and may provide interrupt services to other devices if they have an
+ interrupt line connected.
+ - interrupt-parent : The parent interrupt controller.
+ - #interrupt-cells: the number of cells to describe an IRQ, this should be 2.
+ The first cell is the IRQ number.
+ The second cell is the flags, encoded as the trigger masks from
+ Documentation/devicetree/bindings/interrupts.txt
+
+ - wlf,gpio-cfg : A list of GPIO configuration register values. If absent,
+ no configuration of these registers is performed. If any value is
+ over 0xffff then the register will be left as default. If present 11
+ values must be supplied.
+
+ - wlf,micbias-cfg : Two MICBIAS register values for WM1811 or
+ WM8958. If absent the register defaults will be used.
+
+ - wlf,ldo1ena : GPIO specifier for control of LDO1ENA input to device.
+ - wlf,ldo2ena : GPIO specifier for control of LDO2ENA input to device.
+
+ - wlf,lineout1-se : If present LINEOUT1 is in single ended mode.
+ - wlf,lineout2-se : If present LINEOUT2 is in single ended mode.
+
+ - wlf,lineout1-feedback : If present LINEOUT1 has common mode feedback
+ connected.
+ - wlf,lineout2-feedback : If present LINEOUT2 has common mode feedback
+ connected.
+
+ - wlf,ldoena-always-driven : If present LDOENA is always driven.
+
Example:
codec: wm8994@1a {
compatible = "wlf,wm8994";
reg = <0x1a>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ lineout1-se;
+
+ AVDD2-supply = <®ulator>;
+ CPVDD-supply = <®ulator>;
+ DBVDD1-supply = <®ulator>;
+ DBVDD2-supply = <®ulator>;
+ DBVDD3-supply = <®ulator>;
+ SPKVDD1-supply = <®ulator>;
+ SPKVDD2-supply = <®ulator>;
};
diff --git a/Documentation/devicetree/bindings/spi/brcm,bcm2835-spi.txt b/Documentation/devicetree/bindings/spi/brcm,bcm2835-spi.txt
new file mode 100644
index 0000000..f11f295
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/brcm,bcm2835-spi.txt
@@ -0,0 +1,22 @@
+Broadcom BCM2835 SPI0 controller
+
+The BCM2835 contains two forms of SPI master controller, one known simply as
+SPI0, and the other known as the "Universal SPI Master"; part of the
+auxiliary block. This binding applies to the SPI0 controller.
+
+Required properties:
+- compatible: Should be "brcm,bcm2835-spi".
+- reg: Should contain register location and length.
+- interrupts: Should contain interrupt.
+- clocks: The clock feeding the SPI controller.
+
+Example:
+
+spi@20204000 {
+ compatible = "brcm,bcm2835-spi";
+ reg = <0x7e204000 0x1000>;
+ interrupts = <2 22>;
+ clocks = <&clk_spi>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+};
diff --git a/Documentation/devicetree/bindings/spi/fsl-spi.txt b/Documentation/devicetree/bindings/spi/fsl-spi.txt
index 777abd7..b032dd76e 100644
--- a/Documentation/devicetree/bindings/spi/fsl-spi.txt
+++ b/Documentation/devicetree/bindings/spi/fsl-spi.txt
@@ -4,7 +4,7 @@
- cell-index : QE SPI subblock index.
0: QE subblock SPI1
1: QE subblock SPI2
-- compatible : should be "fsl,spi".
+- compatible : should be "fsl,spi" or "aeroflexgaisler,spictrl".
- mode : the SPI operation mode, it can be "cpu" or "cpu-qe".
- reg : Offset and length of the register set for the device
- interrupts : <a b> where a is the interrupt number and b is a
@@ -14,6 +14,7 @@
controller you have.
- interrupt-parent : the phandle for the interrupt controller that
services interrupts for this device.
+- clock-frequency : input clock frequency to non FSL_SOC cores
Optional properties:
- gpios : specifies the gpio pins to be used for chipselects.
diff --git a/Documentation/devicetree/bindings/spi/mxs-spi.txt b/Documentation/devicetree/bindings/spi/mxs-spi.txt
index e2e1395..3499b73 100644
--- a/Documentation/devicetree/bindings/spi/mxs-spi.txt
+++ b/Documentation/devicetree/bindings/spi/mxs-spi.txt
@@ -3,8 +3,11 @@
Required properties:
- compatible: Should be "fsl,<soc>-spi", where soc is "imx23" or "imx28"
- reg: Offset and length of the register set for the device
-- interrupts: Should contain SSP interrupts (error irq first, dma irq second)
-- fsl,ssp-dma-channel: APBX DMA channel for the SSP
+- interrupts: Should contain SSP ERROR interrupt
+- dmas: DMA specifier, consisting of a phandle to DMA controller node
+ and SSP DMA channel ID.
+ Refer to dma.txt and fsl-mxs-dma.txt for details.
+- dma-names: Must be "rx-tx".
Optional properties:
- clock-frequency : Input clock frequency to the SPI block in Hz.
@@ -17,6 +20,7 @@
#size-cells = <0>;
compatible = "fsl,imx28-spi";
reg = <0x80010000 0x2000>;
- interrupts = <96 82>;
- fsl,ssp-dma-channel = <0>;
+ interrupts = <96>;
+ dmas = <&dma_apbh 0>;
+ dma-names = "rx-tx";
};
diff --git a/Documentation/devicetree/bindings/spi/nvidia,tegra114-spi.txt b/Documentation/devicetree/bindings/spi/nvidia,tegra114-spi.txt
new file mode 100644
index 0000000..91ff771
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/nvidia,tegra114-spi.txt
@@ -0,0 +1,26 @@
+NVIDIA Tegra114 SPI controller.
+
+Required properties:
+- compatible : should be "nvidia,tegra114-spi".
+- reg: Should contain SPI registers location and length.
+- interrupts: Should contain SPI interrupts.
+- nvidia,dma-request-selector : The Tegra DMA controller's phandle and
+ request selector for this SPI controller.
+- This is also require clock named "spi" as per binding document
+ Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Recommended properties:
+- spi-max-frequency: Definition as per
+ Documentation/devicetree/bindings/spi/spi-bus.txt
+Example:
+
+spi@7000d600 {
+ compatible = "nvidia,tegra114-spi";
+ reg = <0x7000d600 0x200>;
+ interrupts = <0 82 0x04>;
+ nvidia,dma-request-selector = <&apbdma 16>;
+ spi-max-frequency = <25000000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+};
diff --git a/Documentation/devicetree/bindings/spi/omap-spi.txt b/Documentation/devicetree/bindings/spi/omap-spi.txt
index 938809c..4c85c4c 100644
--- a/Documentation/devicetree/bindings/spi/omap-spi.txt
+++ b/Documentation/devicetree/bindings/spi/omap-spi.txt
@@ -10,7 +10,18 @@
input. The default is D0 as input and
D1 as output.
-Example:
+Optional properties:
+- dmas: List of DMA specifiers with the controller specific format
+ as described in the generic DMA client binding. A tx and rx
+ specifier is required for each chip select.
+- dma-names: List of DMA request names. These strings correspond
+ 1:1 with the DMA specifiers listed in dmas. The string naming
+ is to be "rxN" and "txN" for RX and TX requests,
+ respectively, where N equals the chip select number.
+
+Examples:
+
+[hwmod populated DMA resources]
mcspi1: mcspi@1 {
#address-cells = <1>;
@@ -20,3 +31,17 @@
ti,spi-num-cs = <4>;
};
+[generic DMA request binding]
+
+mcspi1: mcspi@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "ti,omap4-mcspi";
+ ti,hwmods = "mcspi1";
+ ti,spi-num-cs = <2>;
+ dmas = <&edma 42
+ &edma 43
+ &edma 44
+ &edma 45>;
+ dma-names = "tx0", "rx0", "tx1", "rx1";
+};
diff --git a/Documentation/devicetree/bindings/spi/sh-msiof.txt b/Documentation/devicetree/bindings/spi/sh-msiof.txt
new file mode 100644
index 0000000..e622210
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/sh-msiof.txt
@@ -0,0 +1,12 @@
+Renesas MSIOF spi controller
+
+Required properties:
+- compatible : "renesas,sh-msiof" for SuperH or
+ "renesas,sh-mobile-msiof" for SH Mobile series
+- reg : Offset and length of the register set for the device
+- interrupts : interrupt line used by MSIOF
+
+Optional properties:
+- num-cs : total number of chip-selects
+- renesas,tx-fifo-size : Overrides the default tx fifo size given in words
+- renesas,rx-fifo-size : Overrides the default rx fifo size given in words
diff --git a/Documentation/devicetree/bindings/spi/spi-davinci.txt b/Documentation/devicetree/bindings/spi/spi-davinci.txt
new file mode 100644
index 0000000..6d0ac8d
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/spi-davinci.txt
@@ -0,0 +1,51 @@
+Davinci SPI controller device bindings
+
+Required properties:
+- #address-cells: number of cells required to define a chip select
+ address on the SPI bus. Should be set to 1.
+- #size-cells: should be zero.
+- compatible:
+ - "ti,dm6441-spi" for SPI used similar to that on DM644x SoC family
+ - "ti,da830-spi" for SPI used similar to that on DA8xx SoC family
+- reg: Offset and length of SPI controller register space
+- num-cs: Number of chip selects
+- ti,davinci-spi-intr-line: interrupt line used to connect the SPI
+ IP to the interrupt controller within the SoC. Possible values
+ are 0 and 1. Manual says one of the two possible interrupt
+ lines can be tied to the interrupt controller. Set this
+ based on a specifc SoC configuration.
+- interrupts: interrupt number mapped to CPU.
+- clocks: spi clk phandle
+
+Example of a NOR flash slave device (n25q032) connected to DaVinci
+SPI controller device over the SPI bus.
+
+spi0:spi@20BF0000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "ti,dm6446-spi";
+ reg = <0x20BF0000 0x1000>;
+ num-cs = <4>;
+ ti,davinci-spi-intr-line = <0>;
+ interrupts = <338>;
+ clocks = <&clkspi>;
+
+ flash: n25q032@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "st,m25p32";
+ spi-max-frequency = <25000000>;
+ reg = <0>;
+
+ partition@0 {
+ label = "u-boot-spl";
+ reg = <0x0 0x80000>;
+ read-only;
+ };
+
+ partition@1 {
+ label = "test";
+ reg = <0x80000 0x380000>;
+ };
+ };
+};
diff --git a/Documentation/devicetree/bindings/spi/spi-samsung.txt b/Documentation/devicetree/bindings/spi/spi-samsung.txt
index a15ffed..86aa061 100644
--- a/Documentation/devicetree/bindings/spi/spi-samsung.txt
+++ b/Documentation/devicetree/bindings/spi/spi-samsung.txt
@@ -31,9 +31,6 @@
- #address-cells: should be 1.
- #size-cells: should be 0.
-- gpios: The gpio specifier for clock, mosi and miso interface lines (in the
- order specified). The format of the gpio specifier depends on the gpio
- controller.
Optional Board Specific Properties:
@@ -86,9 +83,8 @@
spi_0: spi@12d20000 {
#address-cells = <1>;
#size-cells = <0>;
- gpios = <&gpa2 4 2 3 0>,
- <&gpa2 6 2 3 0>,
- <&gpa2 7 2 3 0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi0_bus>;
w25q80bw@0 {
#address-cells = <1>;
diff --git a/Documentation/devicetree/bindings/spi/spi_pl022.txt b/Documentation/devicetree/bindings/spi/spi_pl022.txt
index f158fd3..22ed679 100644
--- a/Documentation/devicetree/bindings/spi/spi_pl022.txt
+++ b/Documentation/devicetree/bindings/spi/spi_pl022.txt
@@ -16,6 +16,11 @@
device will be suspended immediately
- pl022,rt : indicates the controller should run the message pump with realtime
priority to minimise the transfer latency on the bus (boolean)
+- dmas : Two or more DMA channel specifiers following the convention outlined
+ in bindings/dma/dma.txt
+- dma-names: Names for the dma channels, if present. There must be at
+ least one channel named "tx" for transmit and named "rx" for
+ receive.
SPI slave nodes must be children of the SPI master node and can
@@ -32,3 +37,34 @@
- pl022,wait-state : Microwire interface: Wait state
- pl022,duplex : Microwire interface: Full/Half duplex
+
+Example:
+
+ spi@e0100000 {
+ compatible = "arm,pl022", "arm,primecell";
+ reg = <0xe0100000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = <0 31 0x4>;
+ dmas = <&dma-controller 23 1>,
+ <&dma-controller 24 0>;
+ dma-names = "rx", "tx";
+
+ m25p80@1 {
+ compatible = "st,m25p80";
+ reg = <1>;
+ spi-max-frequency = <12000000>;
+ spi-cpol;
+ spi-cpha;
+ pl022,hierarchy = <0>;
+ pl022,interface = <0>;
+ pl022,slave-tx-disable;
+ pl022,com-mode = <0x2>;
+ pl022,rx-level-trig = <0>;
+ pl022,tx-level-trig = <0>;
+ pl022,ctrl-len = <0x11>;
+ pl022,wait-state = <0>;
+ pl022,duplex = <0>;
+ };
+ };
+
diff --git a/Documentation/devicetree/bindings/staging/dwc2.txt b/Documentation/devicetree/bindings/staging/dwc2.txt
new file mode 100644
index 0000000..1a1b7cf
--- /dev/null
+++ b/Documentation/devicetree/bindings/staging/dwc2.txt
@@ -0,0 +1,15 @@
+Platform DesignWare HS OTG USB 2.0 controller
+-----------------------------------------------------
+
+Required properties:
+- compatible : "snps,dwc2"
+- reg : Should contain 1 register range (address and length)
+- interrupts : Should contain 1 interrupt
+
+Example:
+
+ usb@101c0000 {
+ compatible = "ralink,rt3050-usb, snps,dwc2";
+ reg = <0x101c0000 40000>;
+ interrupts = <18>;
+ };
diff --git a/Documentation/devicetree/bindings/staging/iio/adc/mxs-lradc.txt b/Documentation/devicetree/bindings/staging/iio/adc/mxs-lradc.txt
index 801d58c..4688205 100644
--- a/Documentation/devicetree/bindings/staging/iio/adc/mxs-lradc.txt
+++ b/Documentation/devicetree/bindings/staging/iio/adc/mxs-lradc.txt
@@ -5,6 +5,12 @@
- reg: Address and length of the register set for the device
- interrupts: Should contain the LRADC interrupts
+Optional properties:
+- fsl,lradc-touchscreen-wires: Number of wires used to connect the touchscreen
+ to LRADC. Valid value is either 4 or 5. If this
+ property is not present, then the touchscreen is
+ disabled.
+
Examples:
lradc@80050000 {
diff --git a/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt b/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
index 07654f0..b876d49 100644
--- a/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
+++ b/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
@@ -8,6 +8,8 @@
- interrupts: Should contain sync interrupt and error interrupt,
in this order.
- #crtc-cells: 1, See below
+- resets: phandle pointing to the system reset controller and
+ reset line index, see reset/fsl,imx-src.txt for details
example:
@@ -16,6 +18,7 @@
compatible = "fsl,imx53-ipu";
reg = <0x18000000 0x080000000>;
interrupts = <11 10>;
+ resets = <&src 2>;
};
Parallel display support
@@ -26,7 +29,7 @@
- crtc: the crtc this display is connected to, see below
Optional properties:
- interface_pix_fmt: How this display is connected to the
- crtc. Currently supported types: "rgb24", "rgb565"
+ crtc. Currently supported types: "rgb24", "rgb565", "bgr666"
- edid: verbatim EDID data block describing attached display.
- ddc: phandle describing the i2c bus handling the display data
channel
diff --git a/Documentation/devicetree/bindings/staging/imx-drm/ldb.txt b/Documentation/devicetree/bindings/staging/imx-drm/ldb.txt
new file mode 100644
index 0000000..ed93778
--- /dev/null
+++ b/Documentation/devicetree/bindings/staging/imx-drm/ldb.txt
@@ -0,0 +1,99 @@
+Device-Tree bindings for LVDS Display Bridge (ldb)
+
+LVDS Display Bridge
+===================
+
+The LVDS Display Bridge device tree node contains up to two lvds-channel
+nodes describing each of the two LVDS encoder channels of the bridge.
+
+Required properties:
+ - #address-cells : should be <1>
+ - #size-cells : should be <0>
+ - compatible : should be "fsl,imx53-ldb" or "fsl,imx6q-ldb".
+ Both LDB versions are similar, but i.MX6 has an additional
+ multiplexer in the front to select any of the four IPU display
+ interfaces as input for each LVDS channel.
+ - gpr : should be <&gpr> on i.MX53 and i.MX6q.
+ The phandle points to the iomuxc-gpr region containing the LVDS
+ control register.
+- clocks, clock-names : phandles to the LDB divider and selector clocks and to
+ the display interface selector clocks, as described in
+ Documentation/devicetree/bindings/clock/clock-bindings.txt
+ The following clocks are expected on i.MX53:
+ "di0_pll" - LDB LVDS channel 0 mux
+ "di1_pll" - LDB LVDS channel 1 mux
+ "di0" - LDB LVDS channel 0 gate
+ "di1" - LDB LVDS channel 1 gate
+ "di0_sel" - IPU1 DI0 mux
+ "di1_sel" - IPU1 DI1 mux
+ On i.MX6q the following additional clocks are needed:
+ "di2_sel" - IPU2 DI0 mux
+ "di3_sel" - IPU2 DI1 mux
+ The needed clock numbers for each are documented in
+ Documentation/devicetree/bindings/clock/imx5-clock.txt, and in
+ Documentation/devicetree/bindings/clock/imx6q-clock.txt.
+
+Optional properties:
+ - pinctrl-names : should be "default" on i.MX53, not used on i.MX6q
+ - pinctrl-0 : a phandle pointing to LVDS pin settings on i.MX53,
+ not used on i.MX6q
+ - fsl,dual-channel : boolean. if it exists, only LVDS channel 0 should
+ be configured - one input will be distributed on both outputs in dual
+ channel mode
+
+LVDS Channel
+============
+
+Each LVDS Channel has to contain a display-timings node that describes the
+video timings for the connected LVDS display. For detailed information, also
+have a look at Documentation/devicetree/bindings/video/display-timing.txt.
+
+Required properties:
+ - reg : should be <0> or <1>
+ - crtcs : a list of phandles with index pointing to the IPU display interfaces
+ that can be used as video source for this channel.
+ - fsl,data-mapping : should be "spwg" or "jeida"
+ This describes how the color bits are laid out in the
+ serialized LVDS signal.
+ - fsl,data-width : should be <18> or <24>
+
+example:
+
+gpr: iomuxc-gpr@53fa8000 {
+ /* ... */
+};
+
+ldb: ldb@53fa8008 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,imx53-ldb";
+ gpr = <&gpr>;
+ clocks = <&clks 122>, <&clks 120>,
+ <&clks 115>, <&clks 116>,
+ <&clks 123>, <&clks 85>;
+ clock-names = "di0_pll", "di1_pll",
+ "di0_sel", "di1_sel",
+ "di0", "di1";
+
+ lvds-channel@0 {
+ reg = <0>;
+ crtcs = <&ipu 0>;
+ fsl,data-mapping = "spwg";
+ fsl,data-width = <24>;
+
+ display-timings {
+ /* ... */
+ };
+ };
+
+ lvds-channel@1 {
+ reg = <1>;
+ crtcs = <&ipu 1>;
+ fsl,data-mapping = "spwg";
+ fsl,data-width = <24>;
+
+ display-timings {
+ /* ... */
+ };
+ };
+};
diff --git a/Documentation/devicetree/bindings/thermal/armada-thermal.txt b/Documentation/devicetree/bindings/thermal/armada-thermal.txt
new file mode 100644
index 0000000..fff93d5
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/armada-thermal.txt
@@ -0,0 +1,22 @@
+* Marvell Armada 370/XP thermal management
+
+Required properties:
+
+- compatible: Should be set to one of the following:
+ marvell,armada370-thermal
+ marvell,armadaxp-thermal
+
+- reg: Device's register space.
+ Two entries are expected, see the examples below.
+ The first one is required for the sensor register;
+ the second one is required for the control register
+ to be used for sensor initialization (a.k.a. calibration).
+
+Example:
+
+ thermal@d0018300 {
+ compatible = "marvell,armada370-thermal";
+ reg = <0xd0018300 0x4
+ 0xd0018304 0x4>;
+ status = "okay";
+ };
diff --git a/Documentation/devicetree/bindings/thermal/dove-thermal.txt b/Documentation/devicetree/bindings/thermal/dove-thermal.txt
new file mode 100644
index 0000000..6f47467
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/dove-thermal.txt
@@ -0,0 +1,18 @@
+* Dove Thermal
+
+This driver is for Dove SoCs which contain a thermal sensor.
+
+Required properties:
+- compatible : "marvell,dove-thermal"
+- reg : Address range of the thermal registers
+
+The reg properties should contain two ranges. The first is for the
+three Thermal Manager registers, while the second range contains the
+Thermal Diode Control Registers.
+
+Example:
+
+ thermal@10078 {
+ compatible = "marvell,dove-thermal";
+ reg = <0xd001c 0x0c>, <0xd005c 0x08>;
+ };
diff --git a/Documentation/devicetree/bindings/thermal/kirkwood-thermal.txt b/Documentation/devicetree/bindings/thermal/kirkwood-thermal.txt
new file mode 100644
index 0000000..8c0f5eb
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/kirkwood-thermal.txt
@@ -0,0 +1,15 @@
+* Kirkwood Thermal
+
+This version is for Kirkwood 88F8262 & 88F6283 SoCs. Other kirkwoods
+don't contain a thermal sensor.
+
+Required properties:
+- compatible : "marvell,kirkwood-thermal"
+- reg : Address range of the thermal registers
+
+Example:
+
+ thermal@10078 {
+ compatible = "marvell,kirkwood-thermal";
+ reg = <0x10078 0x4>;
+ };
diff --git a/Documentation/devicetree/bindings/thermal/rcar-thermal.txt b/Documentation/devicetree/bindings/thermal/rcar-thermal.txt
new file mode 100644
index 0000000..28ef498
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/rcar-thermal.txt
@@ -0,0 +1,29 @@
+* Renesas R-Car Thermal
+
+Required properties:
+- compatible : "renesas,rcar-thermal"
+- reg : Address range of the thermal registers.
+ The 1st reg will be recognized as common register
+ if it has "interrupts".
+
+Option properties:
+
+- interrupts : use interrupt
+
+Example (non interrupt support):
+
+thermal@e61f0100 {
+ compatible = "renesas,rcar-thermal";
+ reg = <0xe61f0100 0x38>;
+};
+
+Example (interrupt support):
+
+thermal@e61f0000 {
+ compatible = "renesas,rcar-thermal";
+ reg = <0xe61f0000 0x14
+ 0xe61f0100 0x38
+ 0xe61f0200 0x38
+ 0xe61f0300 0x38>;
+ interrupts = <0 69 4>;
+};
diff --git a/Documentation/devicetree/bindings/thermal/ti_soc_thermal.txt b/Documentation/devicetree/bindings/thermal/ti_soc_thermal.txt
new file mode 100644
index 0000000..0c9222d
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/ti_soc_thermal.txt
@@ -0,0 +1,74 @@
+* Texas Instrument OMAP SCM bandgap bindings
+
+In the System Control Module, OMAP supplies a voltage reference
+and a temperature sensor feature that are gathered in the band
+gap voltage and temperature sensor (VBGAPTS) module. The band
+gap provides current and voltage reference for its internal
+circuits and other analog IP blocks. The analog-to-digital
+converter (ADC) produces an output value that is proportional
+to the silicon temperature.
+
+Required properties:
+- compatible : Should be:
+ - "ti,omap4430-bandgap" : for OMAP4430 bandgap
+ - "ti,omap4460-bandgap" : for OMAP4460 bandgap
+ - "ti,omap4470-bandgap" : for OMAP4470 bandgap
+ - "ti,omap5430-bandgap" : for OMAP5430 bandgap
+- interrupts : this entry should indicate which interrupt line
+the talert signal is routed to;
+Specific:
+- gpios : this entry should be used to inform which GPIO
+line the tshut signal is routed to. The informed GPIO will
+be treated as an IRQ;
+- regs : this entry must also be specified and it is specific
+to each bandgap version, because the mapping may change from
+soc to soc, apart of depending on available features.
+
+Example:
+OMAP4430:
+bandgap {
+ reg = <0x4a002260 0x4 0x4a00232C 0x4>;
+ compatible = "ti,omap4430-bandgap";
+};
+
+OMAP4460:
+bandgap {
+ reg = <0x4a002260 0x4
+ 0x4a00232C 0x4
+ 0x4a002378 0x18>;
+ compatible = "ti,omap4460-bandgap";
+ interrupts = <0 126 4>; /* talert */
+ gpios = <&gpio3 22 0>; /* tshut */
+};
+
+OMAP4470:
+bandgap {
+ reg = <0x4a002260 0x4
+ 0x4a00232C 0x4
+ 0x4a002378 0x18>;
+ compatible = "ti,omap4470-bandgap";
+ interrupts = <0 126 4>; /* talert */
+ gpios = <&gpio3 22 0>; /* tshut */
+};
+
+OMAP5430:
+bandgap {
+ reg = <0x4a0021e0 0xc
+ 0x4a00232c 0xc
+ 0x4a002380 0x2c
+ 0x4a0023C0 0x3c>;
+ compatible = "ti,omap5430-bandgap";
+ interrupts = <0 126 4>; /* talert */
+};
+
+DRA752:
+bandgap {
+ reg = <0x4a0021e0 0xc
+ 0x4a00232c 0xc
+ 0x4a002380 0x2c
+ 0x4a0023C0 0x3c
+ 0x4a002564 0x8
+ 0x4a002574 0x50>;
+ compatible = "ti,dra752-bandgap";
+ interrupts = <0 126 4>; /* talert */
+};
diff --git a/Documentation/devicetree/bindings/timer/allwinner,sun4i-timer.txt b/Documentation/devicetree/bindings/timer/allwinner,sun4i-timer.txt
new file mode 100644
index 0000000..48aeb78
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/allwinner,sun4i-timer.txt
@@ -0,0 +1,17 @@
+Allwinner A1X SoCs Timer Controller
+
+Required properties:
+
+- compatible : should be "allwinner,sun4i-timer"
+- reg : Specifies base physical address and size of the registers.
+- interrupts : The interrupt of the first timer
+- clocks: phandle to the source clock (usually a 24 MHz fixed clock)
+
+Example:
+
+timer {
+ compatible = "allwinner,sun4i-timer";
+ reg = <0x01c20c00 0x400>;
+ interrupts = <22>;
+ clocks = <&osc>;
+};
diff --git a/Documentation/devicetree/bindings/timer/allwinner,sunxi-timer.txt b/Documentation/devicetree/bindings/timer/allwinner,sunxi-timer.txt
deleted file mode 100644
index 0c7b64e..0000000
--- a/Documentation/devicetree/bindings/timer/allwinner,sunxi-timer.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-Allwinner A1X SoCs Timer Controller
-
-Required properties:
-
-- compatible : should be "allwinner,sunxi-timer"
-- reg : Specifies base physical address and size of the registers.
-- interrupts : The interrupt of the first timer
-- clocks: phandle to the source clock (usually a 24 MHz fixed clock)
-
-Example:
-
-timer {
- compatible = "allwinner,sunxi-timer";
- reg = <0x01c20c00 0x400>;
- interrupts = <22>;
- clocks = <&osc>;
-};
diff --git a/Documentation/devicetree/bindings/timer/arm,sp804.txt b/Documentation/devicetree/bindings/timer/arm,sp804.txt
new file mode 100644
index 0000000..5cd8eee
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/arm,sp804.txt
@@ -0,0 +1,29 @@
+ARM sp804 Dual Timers
+---------------------------------------
+
+Required properties:
+- compatible: Should be "arm,sp804" & "arm,primecell"
+- interrupts: Should contain the list of Dual Timer interrupts. This is the
+ interrupt for timer 1 and timer 2. In the case of a single entry, it is
+ the combined interrupt or if "arm,sp804-has-irq" is present that
+ specifies which timer interrupt is connected.
+- reg: Should contain location and length for dual timer register.
+- clocks: clocks driving the dual timer hardware. This list should be 1 or 3
+ clocks. With 3 clocks, the order is timer0 clock, timer1 clock,
+ apb_pclk. A single clock can also be specified if the same clock is
+ used for all clock inputs.
+
+Optional properties:
+- arm,sp804-has-irq = <#>: In the case of only 1 timer irq line connected, this
+ specifies if the irq connection is for timer 1 or timer 2. A value of 1
+ or 2 should be used.
+
+Example:
+
+ timer0: timer@fc800000 {
+ compatible = "arm,sp804", "arm,primecell";
+ reg = <0xfc800000 0x1000>;
+ interrupts = <0 0 4>, <0 1 4>;
+ clocks = <&timclk1 &timclk2 &pclk>;
+ clock-names = "timer1", "timer2", "apb_pclk";
+ };
diff --git a/Documentation/devicetree/bindings/timer/cadence,ttc-timer.txt b/Documentation/devicetree/bindings/timer/cadence,ttc-timer.txt
new file mode 100644
index 0000000..993695c
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/cadence,ttc-timer.txt
@@ -0,0 +1,17 @@
+Cadence TTC - Triple Timer Counter
+
+Required properties:
+- compatible : Should be "cdns,ttc".
+- reg : Specifies base physical address and size of the registers.
+- interrupts : A list of 3 interrupts; one per timer channel.
+- clocks: phandle to the source clock
+
+Example:
+
+ttc0: ttc0@f8001000 {
+ interrupt-parent = <&intc>;
+ interrupts = < 0 10 4 0 11 4 0 12 4 >;
+ compatible = "cdns,ttc";
+ reg = <0xF8001000 0x1000>;
+ clocks = <&cpu_clk 3>;
+};
diff --git a/Documentation/devicetree/bindings/timer/fsl,imxgpt.txt b/Documentation/devicetree/bindings/timer/fsl,imxgpt.txt
new file mode 100644
index 0000000..9809b11
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/fsl,imxgpt.txt
@@ -0,0 +1,18 @@
+Freescale i.MX General Purpose Timer (GPT)
+
+Required properties:
+
+- compatible : should be "fsl,<soc>-gpt"
+- reg : Specifies base physical address and size of the registers.
+- interrupts : A list of 4 interrupts; one per timer channel.
+- clocks : The clocks provided by the SoC to drive the timer.
+
+Example:
+
+gpt1: timer@10003000 {
+ compatible = "fsl,imx27-gpt", "fsl,imx1-gpt";
+ reg = <0x10003000 0x1000>;
+ interrupts = <26>;
+ clocks = <&clks 46>, <&clks 61>;
+ clock-names = "ipg", "per";
+};
diff --git a/Documentation/devicetree/bindings/timer/lsi,zevio-timer.txt b/Documentation/devicetree/bindings/timer/lsi,zevio-timer.txt
new file mode 100644
index 0000000..b2d07ad
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/lsi,zevio-timer.txt
@@ -0,0 +1,33 @@
+TI-NSPIRE timer
+
+Required properties:
+
+- compatible : should be "lsi,zevio-timer".
+- reg : The physical base address and size of the timer (always first).
+- clocks: phandle to the source clock.
+
+Optional properties:
+
+- interrupts : The interrupt number of the first timer.
+- reg : The interrupt acknowledgement registers
+ (always after timer base address)
+
+If any of the optional properties are not given, the timer is added as a
+clock-source only.
+
+Example:
+
+timer {
+ compatible = "lsi,zevio-timer";
+ reg = <0x900D0000 0x1000>, <0x900A0020 0x8>;
+ interrupts = <19>;
+ clocks = <&timer_clk>;
+};
+
+Example (no clock-events):
+
+timer {
+ compatible = "lsi,zevio-timer";
+ reg = <0x900D0000 0x1000>;
+ clocks = <&timer_clk>;
+};
diff --git a/Documentation/devicetree/bindings/timer/marvell,armada-370-xp-timer.txt b/Documentation/devicetree/bindings/timer/marvell,armada-370-xp-timer.txt
new file mode 100644
index 0000000..3638112
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/marvell,armada-370-xp-timer.txt
@@ -0,0 +1,15 @@
+Marvell Armada 370 and Armada XP Timers
+---------------------------------------
+
+Required properties:
+- compatible: Should be "marvell,armada-370-xp-timer"
+- interrupts: Should contain the list of Global Timer interrupts and
+ then local timer interrupts
+- reg: Should contain location and length for timers register. First
+ pair for the Global Timer registers, second pair for the
+ local/private timers.
+- clocks: clock driving the timer hardware
+
+Optional properties:
+- marvell,timer-25Mhz: Tells whether the Global timer supports the 25
+ Mhz fixed mode (available on Armada XP and not on Armada 370)
diff --git a/Documentation/devicetree/bindings/timer/marvell,orion-timer.txt b/Documentation/devicetree/bindings/timer/marvell,orion-timer.txt
new file mode 100644
index 0000000..62bb826
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/marvell,orion-timer.txt
@@ -0,0 +1,17 @@
+Marvell Orion SoC timer
+
+Required properties:
+- compatible: shall be "marvell,orion-timer"
+- reg: base address of the timer register starting with TIMERS CONTROL register
+- interrupt-parent: phandle of the bridge interrupt controller
+- interrupts: should contain the interrupts for Timer0 and Timer1
+- clocks: phandle of timer reference clock (tclk)
+
+Example:
+ timer: timer {
+ compatible = "marvell,orion-timer";
+ reg = <0x20300 0x20>;
+ interrupt-parent = <&bridge_intc>;
+ interrupts = <1>, <2>;
+ clocks = <&core_clk 0>;
+ };
diff --git a/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt b/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt
new file mode 100644
index 0000000..b5a86d2
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt
@@ -0,0 +1,68 @@
+Samsung's Multi Core Timer (MCT)
+
+The Samsung's Multi Core Timer (MCT) module includes two main blocks, the
+global timer and CPU local timers. The global timer is a 64-bit free running
+up-counter and can generate 4 interrupts when the counter reaches one of the
+four preset counter values. The CPU local timers are 32-bit free running
+down-counters and generate an interrupt when the counter expires. There is
+one CPU local timer instantiated in MCT for every CPU in the system.
+
+Required properties:
+
+- compatible: should be "samsung,exynos4210-mct".
+ (a) "samsung,exynos4210-mct", for mct compatible with Exynos4210 mct.
+ (b) "samsung,exynos4412-mct", for mct compatible with Exynos4412 mct.
+
+- reg: base address of the mct controller and length of the address space
+ it occupies.
+
+- interrupts: the list of interrupts generated by the controller. The following
+ should be the order of the interrupts specified. The local timer interrupts
+ should be specified after the four global timer interrupts have been
+ specified.
+
+ 0: Global Timer Interrupt 0
+ 1: Global Timer Interrupt 1
+ 2: Global Timer Interrupt 2
+ 3: Global Timer Interrupt 3
+ 4: Local Timer Interrupt 0
+ 5: Local Timer Interrupt 1
+ 6: ..
+ 7: ..
+ i: Local Timer Interrupt n
+
+Example 1: In this example, the system uses only the first global timer
+ interrupt generated by MCT and the remaining three global timer
+ interrupts are unused. Two local timer interrupts have been
+ specified.
+
+ mct@10050000 {
+ compatible = "samsung,exynos4210-mct";
+ reg = <0x10050000 0x800>;
+ interrupts = <0 57 0>, <0 0 0>, <0 0 0>, <0 0 0>,
+ <0 42 0>, <0 48 0>;
+ };
+
+Example 2: In this example, the MCT global and local timer interrupts are
+ connected to two separate interrupt controllers. Hence, an
+ interrupt-map is created to map the interrupts to the respective
+ interrupt controllers.
+
+ mct@101C0000 {
+ compatible = "samsung,exynos4210-mct";
+ reg = <0x101C0000 0x800>;
+ interrupt-controller;
+ #interrups-cells = <2>;
+ interrupt-parent = <&mct_map>;
+ interrupts = <0 0>, <1 0>, <2 0>, <3 0>,
+ <4 0>, <5 0>;
+
+ mct_map: mct-map {
+ #interrupt-cells = <2>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-map = <0x0 0 &combiner 23 3>,
+ <0x4 0 &gic 0 120 0>,
+ <0x5 0 &gic 0 121 0>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/timer/stericsson-u300-apptimer.txt b/Documentation/devicetree/bindings/timer/stericsson-u300-apptimer.txt
new file mode 100644
index 0000000..9499bc8
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/stericsson-u300-apptimer.txt
@@ -0,0 +1,18 @@
+ST-Ericsson U300 apptimer
+
+Required properties:
+
+- compatible : should be "stericsson,u300-apptimer"
+- reg : Specifies base physical address and size of the registers.
+- interrupts : A list of 4 interrupts; one for each subtimer. These
+ are, in order: OS (operating system), DD (device driver) both
+ adopted for EPOC/Symbian with two specific IRQs for these tasks,
+ then GP1 and GP2, which are general-purpose timers.
+
+Example:
+
+timer {
+ compatible = "stericsson,u300-apptimer";
+ reg = <0xc0014000 0x1000>;
+ interrupts = <24 25 26 27>;
+};
diff --git a/Documentation/devicetree/bindings/tty/serial/arc-uart.txt b/Documentation/devicetree/bindings/tty/serial/arc-uart.txt
new file mode 100644
index 0000000..5cae2eb
--- /dev/null
+++ b/Documentation/devicetree/bindings/tty/serial/arc-uart.txt
@@ -0,0 +1,26 @@
+* Synopsys ARC UART : Non standard UART used in some of the ARC FPGA boards
+
+Required properties:
+- compatible : "snps,arc-uart"
+- reg : offset and length of the register set for the device.
+- interrupts : device interrupt
+- clock-frequency : the input clock frequency for the UART
+- current-speed : baud rate for UART
+
+e.g.
+
+arcuart0: serial@c0fc1000 {
+ compatible = "snps,arc-uart";
+ reg = <0xc0fc1000 0x100>;
+ interrupts = <5>;
+ clock-frequency = <80000000>;
+ current-speed = <115200>;
+ status = "okay";
+};
+
+Note: Each port should have an alias correctly numbered in "aliases" node.
+
+e.g.
+aliases {
+ serial0 = &arcuart0;
+};
diff --git a/Documentation/devicetree/bindings/tty/serial/efm32-uart.txt b/Documentation/devicetree/bindings/tty/serial/efm32-uart.txt
index 6588b69..8e080b8 100644
--- a/Documentation/devicetree/bindings/tty/serial/efm32-uart.txt
+++ b/Documentation/devicetree/bindings/tty/serial/efm32-uart.txt
@@ -5,10 +5,16 @@
- reg : Address and length of the register set
- interrupts : Should contain uart interrupt
+Optional properties:
+- location : Decides the location of the USART I/O pins.
+ Allowed range : [0 .. 5]
+ Default: 0
+
Example:
uart@0x4000c400 {
compatible = "efm32,uart";
reg = <0x4000c400 0x400>;
interrupts = <15>;
+ location = <0>;
};
diff --git a/Documentation/devicetree/bindings/tty/serial/fsl-imx-uart.txt b/Documentation/devicetree/bindings/tty/serial/fsl-imx-uart.txt
index b462d0c..c662eb3 100644
--- a/Documentation/devicetree/bindings/tty/serial/fsl-imx-uart.txt
+++ b/Documentation/devicetree/bindings/tty/serial/fsl-imx-uart.txt
@@ -8,6 +8,8 @@
Optional properties:
- fsl,uart-has-rtscts : Indicate the uart has rts and cts
- fsl,irda-mode : Indicate the uart supports irda mode
+- fsl,dte-mode : Indicate the uart works in DTE mode. The uart works
+ is DCE mode by default.
Example:
@@ -16,4 +18,5 @@
reg = <0x73fbc000 0x4000>;
interrupts = <31>;
fsl,uart-has-rtscts;
+ fsl,dte-mode;
};
diff --git a/Documentation/devicetree/bindings/tty/serial/fsl-lpuart.txt b/Documentation/devicetree/bindings/tty/serial/fsl-lpuart.txt
new file mode 100644
index 0000000..6fd1dd1
--- /dev/null
+++ b/Documentation/devicetree/bindings/tty/serial/fsl-lpuart.txt
@@ -0,0 +1,14 @@
+* Freescale low power universal asynchronous receiver/transmitter (lpuart)
+
+Required properties:
+- compatible : Should be "fsl,<soc>-lpuart"
+- reg : Address and length of the register set for the device
+- interrupts : Should contain uart interrupt
+
+Example:
+
+uart0: serial@40027000 {
+ compatible = "fsl,vf610-lpuart";
+ reg = <0x40027000 0x1000>;
+ interrupts = <0 61 0x00>;
+ };
diff --git a/Documentation/devicetree/bindings/tty/serial/fsl-mxs-auart.txt b/Documentation/devicetree/bindings/tty/serial/fsl-mxs-auart.txt
index 273a8d5..2c00ec6 100644
--- a/Documentation/devicetree/bindings/tty/serial/fsl-mxs-auart.txt
+++ b/Documentation/devicetree/bindings/tty/serial/fsl-mxs-auart.txt
@@ -5,20 +5,18 @@
imx23 and imx28.
- reg : Address and length of the register set for the device
- interrupts : Should contain the auart interrupt numbers
-
-Optional properties:
-- fsl,auart-dma-channel : The DMA channels, the first is for RX, the other
- is for TX. If you add this property, it also means that you
- will enable the DMA support for the auart.
- Note: due to the hardware bug in imx23(see errata : 2836),
- only the imx28 can enable the DMA support for the auart.
+- dmas: DMA specifier, consisting of a phandle to DMA controller node
+ and AUART DMA channel ID.
+ Refer to dma.txt and fsl-mxs-dma.txt for details.
+- dma-names: "rx" for RX channel, "tx" for TX channel.
Example:
auart0: serial@8006a000 {
compatible = "fsl,imx28-auart", "fsl,imx23-auart";
reg = <0x8006a000 0x2000>;
- interrupts = <112 70 71>;
- fsl,auart-dma-channel = <8 9>;
+ interrupts = <112>;
+ dmas = <&dma_apbx 8>, <&dma_apbx 9>;
+ dma-names = "rx", "tx";
};
Note: Each auart port should have an alias correctly numbered in "aliases"
diff --git a/Documentation/devicetree/bindings/tty/serial/of-serial.txt b/Documentation/devicetree/bindings/tty/serial/of-serial.txt
index 1e1145c..1928a3e 100644
--- a/Documentation/devicetree/bindings/tty/serial/of-serial.txt
+++ b/Documentation/devicetree/bindings/tty/serial/of-serial.txt
@@ -11,6 +11,9 @@
- "nvidia,tegra20-uart"
- "nxp,lpc3220-uart"
- "ibm,qpace-nwp-serial"
+ - "altr,16550-FIFO32"
+ - "altr,16550-FIFO64"
+ - "altr,16550-FIFO128"
- "serial" if the port type is unknown.
- reg : offset and length of the register set for the device.
- interrupts : should contain uart interrupt.
@@ -30,6 +33,10 @@
RTAS and should not be registered.
- no-loopback-test: set to indicate that the port does not implements loopback
test mode
+- fifo-size: the fifo size of the UART.
+- auto-flow-control: one way to enable automatic flow control support. The
+ driver is allowed to detect support for the capability even without this
+ property.
Example:
diff --git a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
new file mode 100644
index 0000000..20468b2
--- /dev/null
+++ b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
@@ -0,0 +1,16 @@
+* Universal Flash Storage (UFS) Host Controller
+
+UFSHC nodes are defined to describe on-chip UFS host controllers.
+Each UFS controller instance should have its own node.
+
+Required properties:
+- compatible : compatible list, contains "jedec,ufs-1.1"
+- interrupts : <interrupt mapping for UFS host controller IRQ>
+- reg : <registers mapping>
+
+Example:
+ ufshc@0xfc598000 {
+ compatible = "jedec,ufs-1.1";
+ reg = <0xfc598000 0x800>;
+ interrupts = <0 28 0>;
+ };
diff --git a/Documentation/devicetree/bindings/usb/am33xx-usb.txt b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
index ea840f7..dc9dc8c 100644
--- a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
+++ b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
@@ -12,7 +12,7 @@
represents PERIPHERAL.
- port1-mode : Should be "1" to represent HOST. "3" signifies OTG and "2"
represents PERIPHERAL.
- - power : Should be "250". This signifies the controller can supply upto
+ - power : Should be "250". This signifies the controller can supply up to
500mA when operating in host mode.
Example:
diff --git a/Documentation/devicetree/bindings/usb/atmel-usb.txt b/Documentation/devicetree/bindings/usb/atmel-usb.txt
index 60bd215..55f51af 100644
--- a/Documentation/devicetree/bindings/usb/atmel-usb.txt
+++ b/Documentation/devicetree/bindings/usb/atmel-usb.txt
@@ -47,3 +47,85 @@
interrupts = <10 4>;
atmel,vbus-gpio = <&pioC 5 0>;
};
+
+Atmel High-Speed USB device controller
+
+Required properties:
+ - compatible: Should be "atmel,at91sam9rl-udc"
+ - reg: Address and length of the register set for the device
+ - interrupts: Should contain usba interrupt
+ - ep childnode: To specify the number of endpoints and their properties.
+
+Optional properties:
+ - atmel,vbus-gpio: If present, specifies a gpio that needs to be
+ activated for the bus to be powered.
+
+Required child node properties:
+ - name: Name of the endpoint.
+ - reg: Num of the endpoint.
+ - atmel,fifo-size: Size of the fifo.
+ - atmel,nb-banks: Number of banks.
+ - atmel,can-dma: Boolean to specify if the endpoint support DMA.
+ - atmel,can-isoc: Boolean to specify if the endpoint support ISOC.
+
+usb2: gadget@fff78000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "atmel,at91sam9rl-udc";
+ reg = <0x00600000 0x80000
+ 0xfff78000 0x400>;
+ interrupts = <27 4 0>;
+ atmel,vbus-gpio = <&pioB 19 0>;
+
+ ep0 {
+ reg = <0>;
+ atmel,fifo-size = <64>;
+ atmel,nb-banks = <1>;
+ };
+
+ ep1 {
+ reg = <1>;
+ atmel,fifo-size = <1024>;
+ atmel,nb-banks = <2>;
+ atmel,can-dma;
+ atmel,can-isoc;
+ };
+
+ ep2 {
+ reg = <2>;
+ atmel,fifo-size = <1024>;
+ atmel,nb-banks = <2>;
+ atmel,can-dma;
+ atmel,can-isoc;
+ };
+
+ ep3 {
+ reg = <3>;
+ atmel,fifo-size = <1024>;
+ atmel,nb-banks = <3>;
+ atmel,can-dma;
+ };
+
+ ep4 {
+ reg = <4>;
+ atmel,fifo-size = <1024>;
+ atmel,nb-banks = <3>;
+ atmel,can-dma;
+ };
+
+ ep5 {
+ reg = <5>;
+ atmel,fifo-size = <1024>;
+ atmel,nb-banks = <3>;
+ atmel,can-dma;
+ atmel,can-isoc;
+ };
+
+ ep6 {
+ reg = <6>;
+ atmel,fifo-size = <1024>;
+ atmel,nb-banks = <3>;
+ atmel,can-dma;
+ atmel,can-isoc;
+ };
+};
diff --git a/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt b/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt
index 5778b9c..b4b5b79 100644
--- a/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt
+++ b/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt
@@ -5,12 +5,19 @@
- reg: Should contain registers location and length
- interrupts: Should contain controller interrupt
+Recommended properies:
+- phy_type: the type of the phy connected to the core. Should be one
+ of "utmi", "utmi_wide", "ulpi", "serial" or "hsic". Without this
+ property the PORTSC register won't be touched
+- dr_mode: One of "host", "peripheral" or "otg". Defaults to "otg"
+
Optional properties:
- fsl,usbphy: phandler of usb phy that connects to the only one port
- fsl,usbmisc: phandler of non-core register device, with one argument
that indicate usb controller index
- vbus-supply: regulator for vbus
- disable-over-current: disable over current detect
+- external-vbus-divider: enables off-chip resistor divider for Vbus
Examples:
usb@02184000 { /* USB OTG */
@@ -20,4 +27,5 @@
fsl,usbphy = <&usbphy1>;
fsl,usbmisc = <&usbmisc 0>;
disable-over-current;
+ external-vbus-divider;
};
diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt b/Documentation/devicetree/bindings/usb/dwc3.txt
new file mode 100644
index 0000000..7a95c65
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -0,0 +1,22 @@
+synopsys DWC3 CORE
+
+DWC3- USB3 CONTROLLER
+
+Required properties:
+ - compatible: must be "synopsys,dwc3"
+ - reg : Address and length of the register set for the device
+ - interrupts: Interrupts used by the dwc3 controller.
+ - usb-phy : array of phandle for the PHY device
+
+Optional properties:
+ - tx-fifo-resize: determines if the FIFO *has* to be reallocated.
+
+This is usually a subnode to DWC3 glue to which it is connected.
+
+dwc3@4a030000 {
+ compatible = "synopsys,dwc3";
+ reg = <0x4a030000 0xcfff>;
+ interrupts = <0 92 4>
+ usb-phy = <&usb2_phy>, <&usb3,phy>;
+ tx-fifo-resize;
+};
diff --git a/Documentation/devicetree/bindings/usb/ehci-omap.txt b/Documentation/devicetree/bindings/usb/ehci-omap.txt
new file mode 100644
index 0000000..485a9a1
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/ehci-omap.txt
@@ -0,0 +1,32 @@
+OMAP HS USB EHCI controller
+
+This device is usually the child of the omap-usb-host
+Documentation/devicetree/bindings/mfd/omap-usb-host.txt
+
+Required properties:
+
+- compatible: should be "ti,ehci-omap"
+- reg: should contain one register range i.e. start and length
+- interrupts: description of the interrupt line
+
+Optional properties:
+
+- phys: list of phandles to PHY nodes.
+ This property is required if at least one of the ports are in
+ PHY mode i.e. OMAP_EHCI_PORT_MODE_PHY
+
+To specify the port mode, see
+Documentation/devicetree/bindings/mfd/omap-usb-host.txt
+
+Example for OMAP4:
+
+usbhsehci: ehci@4a064c00 {
+ compatible = "ti,ehci-omap", "usb-ehci";
+ reg = <0x4a064c00 0x400>;
+ interrupts = <0 77 0x4>;
+};
+
+&usbhsehci {
+ phys = <&hsusb1_phy 0 &hsusb3_phy>;
+};
+
diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt b/Documentation/devicetree/bindings/usb/exynos-usb.txt
new file mode 100644
index 0000000..d967ba1
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
@@ -0,0 +1,84 @@
+Samsung Exynos SoC USB controller
+
+The USB devices interface with USB controllers on Exynos SOCs.
+The device node has following properties.
+
+EHCI
+Required properties:
+ - compatible: should be "samsung,exynos4210-ehci" for USB 2.0
+ EHCI controller in host mode.
+ - reg: physical base address of the controller and length of memory mapped
+ region.
+ - interrupts: interrupt number to the cpu.
+ - clocks: from common clock binding: handle to usb clock.
+ - clock-names: from common clock binding: Shall be "usbhost".
+
+Optional properties:
+ - samsung,vbus-gpio: if present, specifies the GPIO that
+ needs to be pulled up for the bus to be powered.
+
+Example:
+
+ usb@12110000 {
+ compatible = "samsung,exynos4210-ehci";
+ reg = <0x12110000 0x100>;
+ interrupts = <0 71 0>;
+ samsung,vbus-gpio = <&gpx2 6 1 3 3>;
+
+ clocks = <&clock 285>;
+ clock-names = "usbhost";
+ };
+
+OHCI
+Required properties:
+ - compatible: should be "samsung,exynos4210-ohci" for USB 2.0
+ OHCI companion controller in host mode.
+ - reg: physical base address of the controller and length of memory mapped
+ region.
+ - interrupts: interrupt number to the cpu.
+ - clocks: from common clock binding: handle to usb clock.
+ - clock-names: from common clock binding: Shall be "usbhost".
+
+Example:
+ usb@12120000 {
+ compatible = "samsung,exynos4210-ohci";
+ reg = <0x12120000 0x100>;
+ interrupts = <0 71 0>;
+
+ clocks = <&clock 285>;
+ clock-names = "usbhost";
+ };
+
+DWC3
+Required properties:
+ - compatible: should be "samsung,exynos5250-dwusb3" for USB 3.0 DWC3
+ controller.
+ - #address-cells, #size-cells : should be '1' if the device has sub-nodes
+ with 'reg' property.
+ - ranges: allows valid 1:1 translation between child's address space and
+ parent's address space
+ - clocks: Clock IDs array as required by the controller.
+ - clock-names: names of clocks correseponding to IDs in the clock property
+
+Sub-nodes:
+The dwc3 core should be added as subnode to Exynos dwc3 glue.
+- dwc3 :
+ The binding details of dwc3 can be found in:
+ Documentation/devicetree/bindings/usb/dwc3.txt
+
+Example:
+ usb@12000000 {
+ compatible = "samsung,exynos5250-dwusb3";
+ clocks = <&clock 286>;
+ clock-names = "usbdrd30";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ dwc3 {
+ compatible = "synopsys,dwc3";
+ reg = <0x12000000 0x10000>;
+ interrupts = <0 72 0>;
+ usb-phy = <&usb2_phy &usb3_phy>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra20-ehci.txt b/Documentation/devicetree/bindings/usb/nvidia,tegra20-ehci.txt
index e9b005d..df09330 100644
--- a/Documentation/devicetree/bindings/usb/nvidia,tegra20-ehci.txt
+++ b/Documentation/devicetree/bindings/usb/nvidia,tegra20-ehci.txt
@@ -6,24 +6,10 @@
and additions :
Required properties :
- - compatible : Should be "nvidia,tegra20-ehci" for USB controllers
- used in host mode.
- - phy_type : Should be one of "ulpi" or "utmi".
- - nvidia,vbus-gpio : If present, specifies a gpio that needs to be
- activated for the bus to be powered.
-
-Required properties for phy_type == ulpi:
- - nvidia,phy-reset-gpio : The GPIO used to reset the PHY.
+ - compatible : Should be "nvidia,tegra20-ehci".
+ - nvidia,phy : phandle of the PHY that the controller is connected to.
+ - clocks : Contains a single entry which defines the USB controller's clock.
Optional properties:
- - dr_mode : dual role mode. Indicates the working mode for
- nvidia,tegra20-ehci compatible controllers. Can be "host", "peripheral",
- or "otg". Default to "host" if not defined for backward compatibility.
- host means this is a host controller
- peripheral means it is device controller
- otg means it can operate as either ("on the go")
- - nvidia,has-legacy-mode : boolean indicates whether this controller can
- operate in legacy mode (as APX 2500 / 2600). In legacy mode some
- registers are accessed through the APB_MISC base address instead of
- the USB controller. Since this is a legacy issue it probably does not
- warrant a compatible string of its own.
+ - nvidia,needs-double-reset : boolean is to be set for some of the Tegra20
+ USB ports, which need reset twice due to hardware issues.
diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra20-usb-phy.txt b/Documentation/devicetree/bindings/usb/nvidia,tegra20-usb-phy.txt
new file mode 100644
index 0000000..c4c9e9e
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/nvidia,tegra20-usb-phy.txt
@@ -0,0 +1,52 @@
+Tegra SOC USB PHY
+
+The device node for Tegra SOC USB PHY:
+
+Required properties :
+ - compatible : Should be "nvidia,tegra20-usb-phy".
+ - reg : Defines the following set of registers, in the order listed:
+ - The PHY's own register set.
+ Always present.
+ - The register set of the PHY containing the UTMI pad control registers.
+ Present if-and-only-if phy_type == utmi.
+ - phy_type : Should be one of "utmi", "ulpi" or "hsic".
+ - clocks : Defines the clocks listed in the clock-names property.
+ - clock-names : The following clock names must be present:
+ - reg: The clock needed to access the PHY's own registers. This is the
+ associated EHCI controller's clock. Always present.
+ - pll_u: PLL_U. Always present.
+ - timer: The timeout clock (clk_m). Present if phy_type == utmi.
+ - utmi-pads: The clock needed to access the UTMI pad control registers.
+ Present if phy_type == utmi.
+ - ulpi-link: The clock Tegra provides to the ULPI PHY (cdev2).
+ Present if phy_type == ulpi, and ULPI link mode is in use.
+
+Required properties for phy_type == ulpi:
+ - nvidia,phy-reset-gpio : The GPIO used to reset the PHY.
+
+Required PHY timing params for utmi phy:
+ - nvidia,hssync-start-delay : Number of 480 Mhz clock cycles to wait before
+ start of sync launches RxActive
+ - nvidia,elastic-limit : Variable FIFO Depth of elastic input store
+ - nvidia,idle-wait-delay : Number of 480 Mhz clock cycles of idle to wait
+ before declare IDLE.
+ - nvidia,term-range-adj : Range adjusment on terminations
+ - nvidia,xcvr-setup : HS driver output control
+ - nvidia,xcvr-lsfslew : LS falling slew rate control.
+ - nvidia,xcvr-lsrslew : LS rising slew rate control.
+
+Optional properties:
+ - nvidia,has-legacy-mode : boolean indicates whether this controller can
+ operate in legacy mode (as APX 2500 / 2600). In legacy mode some
+ registers are accessed through the APB_MISC base address instead of
+ the USB controller.
+ - nvidia,is-wired : boolean. Indicates whether we can do certain kind of power
+ optimizations for the devices that are always connected. e.g. modem.
+ - dr_mode : dual role mode. Indicates the working mode for the PHY. Can be
+ "host", "peripheral", or "otg". Defaults to "host" if not defined.
+ host means this is a host controller
+ peripheral means it is device controller
+ otg means it can operate as either ("on the go")
+
+Required properties for dr_mode == otg:
+ - vbus-supply: regulator for VBUS
diff --git a/Documentation/devicetree/bindings/usb/ohci-omap3.txt b/Documentation/devicetree/bindings/usb/ohci-omap3.txt
new file mode 100644
index 0000000..14ab428
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/ohci-omap3.txt
@@ -0,0 +1,15 @@
+OMAP HS USB OHCI controller (OMAP3 and later)
+
+Required properties:
+
+- compatible: should be "ti,ohci-omap3"
+- reg: should contain one register range i.e. start and length
+- interrupts: description of the interrupt line
+
+Example for OMAP4:
+
+usbhsohci: ohci@4a064800 {
+ compatible = "ti,ohci-omap3", "usb-ohci";
+ reg = <0x4a064800 0x400>;
+ interrupts = <0 76 0x4>;
+};
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt b/Documentation/devicetree/bindings/usb/omap-usb.txt
index 29a043e..57e71f6 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -1,33 +1,94 @@
-OMAP GLUE
+OMAP GLUE AND OTHER OMAP SPECIFIC COMPONENTS
OMAP MUSB GLUE
- compatible : Should be "ti,omap4-musb" or "ti,omap3-musb"
- ti,hwmods : must be "usb_otg_hs"
+ - ti,has-mailbox : to specify that omap uses an external mailbox
+ (in control module) to communicate with the musb core during device connect
+ and disconnect.
- multipoint : Should be "1" indicating the musb controller supports
multipoint. This is a MUSB configuration-specific setting.
- - num_eps : Specifies the number of endpoints. This is also a
+ - num-eps : Specifies the number of endpoints. This is also a
MUSB configuration-specific setting. Should be set to "16"
- - ram_bits : Specifies the ram address size. Should be set to "12"
- - interface_type : This is a board specific setting to describe the type of
+ - ram-bits : Specifies the ram address size. Should be set to "12"
+ - interface-type : This is a board specific setting to describe the type of
interface between the controller and the phy. It should be "0" or "1"
specifying ULPI and UTMI respectively.
- mode : Should be "3" to represent OTG. "1" signifies HOST and "2"
represents PERIPHERAL.
- - power : Should be "50". This signifies the controller can supply upto
+ - power : Should be "50". This signifies the controller can supply up to
100mA when operating in host mode.
+ - usb-phy : the phandle for the PHY device
+
+Optional properties:
+ - ctrl-module : phandle of the control module this glue uses to write to
+ mailbox
SOC specific device node entry
usb_otg_hs: usb_otg_hs@4a0ab000 {
compatible = "ti,omap4-musb";
ti,hwmods = "usb_otg_hs";
+ ti,has-mailbox;
multipoint = <1>;
- num_eps = <16>;
- ram_bits = <12>;
+ num-eps = <16>;
+ ram-bits = <12>;
+ ctrl-module = <&omap_control_usb>;
};
Board specific device node entry
&usb_otg_hs {
- interface_type = <1>;
+ interface-type = <1>;
mode = <3>;
power = <50>;
};
+
+OMAP DWC3 GLUE
+ - compatible : Should be "ti,dwc3"
+ - ti,hwmods : Should be "usb_otg_ss"
+ - reg : Address and length of the register set for the device.
+ - interrupts : The irq number of this device that is used to interrupt the
+ MPU
+ - #address-cells, #size-cells : Must be present if the device has sub-nodes
+ - utmi-mode : controls the source of UTMI/PIPE status for VBUS and OTG ID.
+ It should be set to "1" for HW mode and "2" for SW mode.
+ - ranges: the child address space are mapped 1:1 onto the parent address space
+
+Sub-nodes:
+The dwc3 core should be added as subnode to omap dwc3 glue.
+- dwc3 :
+ The binding details of dwc3 can be found in:
+ Documentation/devicetree/bindings/usb/dwc3.txt
+
+omap_dwc3 {
+ compatible = "ti,dwc3";
+ ti,hwmods = "usb_otg_ss";
+ reg = <0x4a020000 0x1ff>;
+ interrupts = <0 93 4>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ utmi-mode = <2>;
+ ranges;
+};
+
+OMAP CONTROL USB
+
+Required properties:
+ - compatible: Should be "ti,omap-control-usb"
+ - reg : Address and length of the register set for the device. It contains
+ the address of "control_dev_conf" and "otghs_control" or "phy_power_usb"
+ depending upon omap4 or omap5.
+ - reg-names: The names of the register addresses corresponding to the registers
+ filled in "reg".
+ - ti,type: This is used to differentiate whether the control module has
+ usb mailbox or usb3 phy power. omap4 has usb mailbox in control module to
+ notify events to the musb core and omap5 has usb3 phy power register to
+ power on usb3 phy. Should be "1" if it has mailbox and "2" if it has usb3
+ phy power.
+
+omap_control_usb: omap-control-usb@4a002300 {
+ compatible = "ti,omap-control-usb";
+ reg = <0x4a002300 0x4>,
+ <0x4a00233c 0x4>;
+ reg-names = "control_dev_conf", "otghs_control";
+ ti,type = <1>;
+};
diff --git a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
new file mode 100644
index 0000000..33fd354
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
@@ -0,0 +1,117 @@
+SAMSUNG USB-PHY controllers
+
+** Samsung's usb 2.0 phy transceiver
+
+The Samsung's usb 2.0 phy transceiver is used for controlling
+usb 2.0 phy for s3c-hsotg as well as ehci-s5p and ohci-exynos
+usb controllers across Samsung SOCs.
+TODO: Adding the PHY binding with controller(s) according to the under
+development generic PHY driver.
+
+Required properties:
+
+Exynos4210:
+- compatible : should be "samsung,exynos4210-usb2phy"
+- reg : base physical address of the phy registers and length of memory mapped
+ region.
+- clocks: Clock IDs array as required by the controller.
+- clock-names: names of clock correseponding IDs clock property as requested
+ by the controller driver.
+
+Exynos5250:
+- compatible : should be "samsung,exynos5250-usb2phy"
+- reg : base physical address of the phy registers and length of memory mapped
+ region.
+
+Optional properties:
+- #address-cells: should be '1' when usbphy node has a child node with 'reg'
+ property.
+- #size-cells: should be '1' when usbphy node has a child node with 'reg'
+ property.
+- ranges: allows valid translation between child's address space and parent's
+ address space.
+
+- The child node 'usbphy-sys' to the node 'usbphy' is for the system controller
+ interface for usb-phy. It should provide the following information required by
+ usb-phy controller to control phy.
+ - reg : base physical address of PHY_CONTROL registers.
+ The size of this register is the total sum of size of all PHY_CONTROL
+ registers that the SoC has. For example, the size will be
+ '0x4' in case we have only one PHY_CONTROL register (e.g.
+ OTHERS register in S3C64XX or USB_PHY_CONTROL register in S5PV210)
+ and, '0x8' in case we have two PHY_CONTROL registers (e.g.
+ USBDEVICE_PHY_CONTROL and USBHOST_PHY_CONTROL registers in exynos4x).
+ and so on.
+
+Example:
+ - Exynos4210
+
+ usbphy@125B0000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "samsung,exynos4210-usb2phy";
+ reg = <0x125B0000 0x100>;
+ ranges;
+
+ clocks = <&clock 2>, <&clock 305>;
+ clock-names = "xusbxti", "otg";
+
+ usbphy-sys {
+ /* USB device and host PHY_CONTROL registers */
+ reg = <0x10020704 0x8>;
+ };
+ };
+
+
+** Samsung's usb 3.0 phy transceiver
+
+Starting exynso5250, Samsung's SoC have usb 3.0 phy transceiver
+which is used for controlling usb 3.0 phy for dwc3-exynos usb 3.0
+controllers across Samsung SOCs.
+
+Required properties:
+
+Exynos5250:
+- compatible : should be "samsung,exynos5250-usb3phy"
+- reg : base physical address of the phy registers and length of memory mapped
+ region.
+- clocks: Clock IDs array as required by the controller.
+- clock-names: names of clocks correseponding to IDs in the clock property
+ as requested by the controller driver.
+
+Optional properties:
+- #address-cells: should be '1' when usbphy node has a child node with 'reg'
+ property.
+- #size-cells: should be '1' when usbphy node has a child node with 'reg'
+ property.
+- ranges: allows valid translation between child's address space and parent's
+ address space.
+
+- The child node 'usbphy-sys' to the node 'usbphy' is for the system controller
+ interface for usb-phy. It should provide the following information required by
+ usb-phy controller to control phy.
+ - reg : base physical address of PHY_CONTROL registers.
+ The size of this register is the total sum of size of all PHY_CONTROL
+ registers that the SoC has. For example, the size will be
+ '0x4' in case we have only one PHY_CONTROL register (e.g.
+ OTHERS register in S3C64XX or USB_PHY_CONTROL register in S5PV210)
+ and, '0x8' in case we have two PHY_CONTROL registers (e.g.
+ USBDEVICE_PHY_CONTROL and USBHOST_PHY_CONTROL registers in exynos4x).
+ and so on.
+
+Example:
+ usbphy@12100000 {
+ compatible = "samsung,exynos5250-usb3phy";
+ reg = <0x12100000 0x100>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ clocks = <&clock 1>, <&clock 286>;
+ clock-names = "ext_xtal", "usbdrd30";
+
+ usbphy-sys {
+ /* USB device and host PHY_CONTROL registers */
+ reg = <0x10040704 0x8>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/usb/twlxxxx-usb.txt b/Documentation/devicetree/bindings/usb/twlxxxx-usb.txt
index 36b9aed..0aee0ad 100644
--- a/Documentation/devicetree/bindings/usb/twlxxxx-usb.txt
+++ b/Documentation/devicetree/bindings/usb/twlxxxx-usb.txt
@@ -8,7 +8,7 @@
usb interrupt number that raises VBUS interrupts when the controller has to
act as device
- usb-supply : phandle to the regulator device tree node. It should be vusb
- if it is twl6030 or ldousb if it is twl6025 subclass.
+ if it is twl6030 or ldousb if it is twl6032 subclass.
twl6030-usb {
compatible = "ti,twl6030-usb";
diff --git a/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
new file mode 100644
index 0000000..d7e2726
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
@@ -0,0 +1,34 @@
+USB NOP PHY
+
+Required properties:
+- compatible: should be usb-nop-xceiv
+
+Optional properties:
+- clocks: phandle to the PHY clock. Use as per Documentation/devicetree
+ /bindings/clock/clock-bindings.txt
+ This property is required if clock-frequency is specified.
+
+- clock-names: Should be "main_clk"
+
+- clock-frequency: the clock frequency (in Hz) that the PHY clock must
+ be configured to.
+
+- vcc-supply: phandle to the regulator that provides RESET to the PHY.
+
+- reset-supply: phandle to the regulator that provides power to the PHY.
+
+Example:
+
+ hsusb1_phy {
+ compatible = "usb-nop-xceiv";
+ clock-frequency = <19200000>;
+ clocks = <&osc 0>;
+ clock-names = "main_clk";
+ vcc-supply = <&hsusb1_vcc_regulator>;
+ reset-supply = <&hsusb1_reset_regulator>;
+ };
+
+hsusb1_phy is a NOP USB PHY device that gets its clock from an oscillator
+and expects that clock to be configured to 19.2MHz by the NOP PHY driver.
+hsusb1_vcc_regulator provides power to the PHY and hsusb1_reset_regulator
+controls RESET.
diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt b/Documentation/devicetree/bindings/usb/usb-phy.txt
index 80d4148..61496f5 100644
--- a/Documentation/devicetree/bindings/usb/usb-phy.txt
+++ b/Documentation/devicetree/bindings/usb/usb-phy.txt
@@ -4,14 +4,39 @@
Required properties:
- compatible: Should be "ti,omap-usb2"
- - reg : Address and length of the register set for the device. Also
-add the address of control module dev conf register until a driver for
-control module is added
+ - reg : Address and length of the register set for the device.
+
+Optional properties:
+ - ctrl-module : phandle of the control module used by PHY driver to power on
+ the PHY.
This is usually a subnode of ocp2scp to which it is connected.
usb2phy@4a0ad080 {
compatible = "ti,omap-usb2";
- reg = <0x4a0ad080 0x58>,
- <0x4a002300 0x4>;
+ reg = <0x4a0ad080 0x58>;
+ ctrl-module = <&omap_control_usb>;
+};
+
+OMAP USB3 PHY
+
+Required properties:
+ - compatible: Should be "ti,omap-usb3"
+ - reg : Address and length of the register set for the device.
+ - reg-names: The names of the register addresses corresponding to the registers
+ filled in "reg".
+
+Optional properties:
+ - ctrl-module : phandle of the control module used by PHY driver to power on
+ the PHY.
+
+This is usually a subnode of ocp2scp to which it is connected.
+
+usb3phy@4a084400 {
+ compatible = "ti,omap-usb3";
+ reg = <0x4a084400 0x80>,
+ <0x4a084800 0x64>,
+ <0x4a084c00 0x40>;
+ reg-names = "phy_rx", "phy_tx", "pll_ctrl";
+ ctrl-module = <&omap_control_usb>;
};
diff --git a/Documentation/devicetree/bindings/usb/usb3503.txt b/Documentation/devicetree/bindings/usb/usb3503.txt
new file mode 100644
index 0000000..8c5be48
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/usb3503.txt
@@ -0,0 +1,25 @@
+SMSC USB3503 High-Speed Hub Controller
+
+Required properties:
+- compatible: Should be "smsc,usb3503".
+- reg: Specifies the i2c slave address, it should be 0x08.
+- connect-gpios: Should specify GPIO for connect.
+- disabled-ports: Should specify the ports unused.
+ '1' or '2' or '3' are availe for this property to describe the port
+ number. 1~3 property values are possible to be desribed.
+ Do not describe this property if all ports have to be enabled.
+- intn-gpios: Should specify GPIO for interrupt.
+- reset-gpios: Should specify GPIO for reset.
+- initial-mode: Should specify initial mode.
+ (1 for HUB mode, 2 for STANDBY mode)
+
+Examples:
+ usb3503@08 {
+ compatible = "smsc,usb3503";
+ reg = <0x08>;
+ connect-gpios = <&gpx3 0 1>;
+ disabled-ports = <2 3>;
+ intn-gpios = <&gpx3 4 1>;
+ reset-gpios = <&gpx3 5 1>;
+ initial-mode = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/usb/ux500-usb.txt b/Documentation/devicetree/bindings/usb/ux500-usb.txt
new file mode 100644
index 0000000..330d6ec
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/ux500-usb.txt
@@ -0,0 +1,50 @@
+Ux500 MUSB
+
+Required properties:
+ - compatible : Should be "stericsson,db8500-musb"
+ - reg : Offset and length of registers
+ - interrupts : Interrupt; mode, number and trigger
+ - dr_mode : Dual-role; either host mode "host", peripheral mode "peripheral"
+ or both "otg"
+
+Optional properties:
+ - dmas : A list of dma channels;
+ dma-controller, event-line, fixed-channel, flags
+ - dma-names : An ordered list of channel names affiliated to the above
+
+Example:
+
+usb_per5@a03e0000 {
+ compatible = "stericsson,db8500-musb", "mentor,musb";
+ reg = <0xa03e0000 0x10000>;
+ interrupts = <0 23 0x4>;
+ interrupt-names = "mc";
+
+ dr_mode = "otg";
+
+ dmas = <&dma 38 0 0x2>, /* Logical - DevToMem */
+ <&dma 38 0 0x0>, /* Logical - MemToDev */
+ <&dma 37 0 0x2>, /* Logical - DevToMem */
+ <&dma 37 0 0x0>, /* Logical - MemToDev */
+ <&dma 36 0 0x2>, /* Logical - DevToMem */
+ <&dma 36 0 0x0>, /* Logical - MemToDev */
+ <&dma 19 0 0x2>, /* Logical - DevToMem */
+ <&dma 19 0 0x0>, /* Logical - MemToDev */
+ <&dma 18 0 0x2>, /* Logical - DevToMem */
+ <&dma 18 0 0x0>, /* Logical - MemToDev */
+ <&dma 17 0 0x2>, /* Logical - DevToMem */
+ <&dma 17 0 0x0>, /* Logical - MemToDev */
+ <&dma 16 0 0x2>, /* Logical - DevToMem */
+ <&dma 16 0 0x0>, /* Logical - MemToDev */
+ <&dma 39 0 0x2>, /* Logical - DevToMem */
+ <&dma 39 0 0x0>; /* Logical - MemToDev */
+
+ dma-names = "iep_1_9", "oep_1_9",
+ "iep_2_10", "oep_2_10",
+ "iep_3_11", "oep_3_11",
+ "iep_4_12", "oep_4_12",
+ "iep_5_13", "oep_5_13",
+ "iep_6_14", "oep_6_14",
+ "iep_7_15", "oep_7_15",
+ "iep_8", "oep_8";
+};
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 902b1b1..d5a79ca 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -5,6 +5,7 @@
ad Avionic Design GmbH
adi Analog Devices, Inc.
+aeroflexgaisler Aeroflex Gaisler AB
ak Asahi Kasei Corp.
amcc Applied Micro Circuits Corporation (APM, formally AMCC)
apm Applied Micro Circuits Corporation (APM)
@@ -14,8 +15,10 @@
brcm Broadcom Corporation
cavium Cavium, Inc.
chrp Common Hardware Reference Platform
+cirrus Cirrus Logic, Inc.
cortina Cortina Systems, Inc.
dallas Maxim Integrated Products (formerly Dallas Semiconductor)
+davicom DAVICOM Semiconductor, Inc.
denx Denx Software Engineering
emmicro EM Microelectronic
epson Seiko Epson Corp.
@@ -29,6 +32,7 @@
img Imagination Technologies Ltd.
intercontrol Inter Control Group
linux Linux-specific binding
+lsi LSI Corp. (LSI Logic)
marvell Marvell Technology Group Ltd.
maxim Maxim Integrated Products
mosaixtech Mosaix Technologies, Inc.
@@ -40,18 +44,25 @@
picochip Picochip Ltd
powervr PowerVR (deprecated, use img)
qcom Qualcomm, Inc.
+ralink Mediatek/Ralink Technology Corp.
ramtron Ramtron International
realtek Realtek Semiconductor Corp.
+renesas Renesas Electronics Corporation
samsung Samsung Semiconductor
sbs Smart Battery System
schindler Schindler
sil Silicon Image
+silabs Silicon Laboratories
simtek
sirf SiRF Technology, Inc.
snps Synopsys, Inc.
st STMicroelectronics
+ste ST-Ericsson
stericsson ST-Ericsson
+toumaz Toumaz
ti Texas Instruments
+toshiba Toshiba Corporation
+v3 V3 Semiconductor
via VIA Technologies, Inc.
wlf Wolfson Microelectronics
wm Wondermedia Technologies, Inc.
diff --git a/Documentation/devicetree/bindings/video/backlight/lp855x.txt b/Documentation/devicetree/bindings/video/backlight/lp855x.txt
new file mode 100644
index 0000000..1482103
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/backlight/lp855x.txt
@@ -0,0 +1,41 @@
+lp855x bindings
+
+Required properties:
+ - compatible: "ti,lp8550", "ti,lp8551", "ti,lp8552", "ti,lp8553",
+ "ti,lp8556", "ti,lp8557"
+ - reg: I2C slave address (u8)
+ - dev-ctrl: Value of DEVICE CONTROL register (u8). It depends on the device.
+
+Optional properties:
+ - bl-name: Backlight device name (string)
+ - init-brt: Initial value of backlight brightness (u8)
+ - pwm-period: PWM period value. Set only PWM input mode used (u32)
+ - rom-addr: Register address of ROM area to be updated (u8)
+ - rom-val: Register value to be updated (u8)
+
+Example:
+
+ /* LP8556 */
+ backlight@2c {
+ compatible = "ti,lp8556";
+ reg = <0x2c>;
+
+ bl-name = "lcd-bl";
+ dev-ctrl = /bits/ 8 <0x85>;
+ init-brt = /bits/ 8 <0x10>;
+ };
+
+ /* LP8557 */
+ backlight@2c {
+ compatible = "ti,lp8557";
+ reg = <0x2c>;
+
+ dev-ctrl = /bits/ 8 <0x41>;
+ init-brt = /bits/ 8 <0x0a>;
+
+ /* 4V OV, 4 output LED string enabled */
+ rom_14h {
+ rom-addr = /bits/ 8 <0x14>;
+ rom-val = /bits/ 8 <0xcf>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/video/backlight/max8925-backlight.txt b/Documentation/devicetree/bindings/video/backlight/max8925-backlight.txt
new file mode 100644
index 0000000..b4cffda
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/backlight/max8925-backlight.txt
@@ -0,0 +1,10 @@
+88pm860x-backlight bindings
+
+Optional properties:
+ - maxim,max8925-dual-string: whether support dual string
+
+Example:
+
+ backlights {
+ maxim,max8925-dual-string = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/video/backlight/tps65217-backlight.txt b/Documentation/devicetree/bindings/video/backlight/tps65217-backlight.txt
new file mode 100644
index 0000000..5fb9279
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/backlight/tps65217-backlight.txt
@@ -0,0 +1,27 @@
+TPS65217 family of regulators
+
+The TPS65217 chip contains a boost converter and current sinks which can be
+used to drive LEDs for use as backlights.
+
+Required properties:
+- compatible: "ti,tps65217"
+- reg: I2C slave address
+- backlight: node for specifying WLED1 and WLED2 lines in TPS65217
+- isel: selection bit, valid values: 1 for ISEL1 (low-level) and 2 for ISEL2 (high-level)
+- fdim: PWM dimming frequency, valid values: 100, 200, 500, 1000
+- default-brightness: valid values: 0-100
+
+Each regulator is defined using the standard binding for regulators.
+
+Example:
+
+ tps: tps@24 {
+ reg = <0x24>;
+ compatible = "ti,tps65217";
+ backlight {
+ isel = <1>; /* 1 - ISET1, 2 ISET2 */
+ fdim = <100>; /* TPS65217_BL_FDIM_100HZ */
+ default-brightness = <50>;
+ };
+ };
+
diff --git a/Documentation/devicetree/bindings/video/display-timing.txt b/Documentation/devicetree/bindings/video/display-timing.txt
new file mode 100644
index 0000000..e1d4a0b
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/display-timing.txt
@@ -0,0 +1,110 @@
+display-timing bindings
+=======================
+
+display-timings node
+--------------------
+
+required properties:
+ - none
+
+optional properties:
+ - native-mode: The native mode for the display, in case multiple modes are
+ provided. When omitted, assume the first node is the native.
+
+timing subnode
+--------------
+
+required properties:
+ - hactive, vactive: display resolution
+ - hfront-porch, hback-porch, hsync-len: horizontal display timing parameters
+ in pixels
+ vfront-porch, vback-porch, vsync-len: vertical display timing parameters in
+ lines
+ - clock-frequency: display clock in Hz
+
+optional properties:
+ - hsync-active: hsync pulse is active low/high/ignored
+ - vsync-active: vsync pulse is active low/high/ignored
+ - de-active: data-enable pulse is active low/high/ignored
+ - pixelclk-active: with
+ - active high = drive pixel data on rising edge/
+ sample data on falling edge
+ - active low = drive pixel data on falling edge/
+ sample data on rising edge
+ - ignored = ignored
+ - interlaced (bool): boolean to enable interlaced mode
+ - doublescan (bool): boolean to enable doublescan mode
+ - doubleclk (bool): boolean to enable doubleclock mode
+
+All the optional properties that are not bool follow the following logic:
+ <1>: high active
+ <0>: low active
+ omitted: not used on hardware
+
+There are different ways of describing the capabilities of a display. The
+devicetree representation corresponds to the one commonly found in datasheets
+for displays. If a display supports multiple signal timings, the native-mode
+can be specified.
+
+The parameters are defined as:
+
+ +----------+-------------------------------------+----------+-------+
+ | | ↑ | | |
+ | | |vback_porch | | |
+ | | ↓ | | |
+ +----------#######################################----------+-------+
+ | # ↑ # | |
+ | # | # | |
+ | hback # | # hfront | hsync |
+ | porch # | hactive # porch | len |
+ |<-------->#<-------+--------------------------->#<-------->|<----->|
+ | # | # | |
+ | # |vactive # | |
+ | # | # | |
+ | # ↓ # | |
+ +----------#######################################----------+-------+
+ | | ↑ | | |
+ | | |vfront_porch | | |
+ | | ↓ | | |
+ +----------+-------------------------------------+----------+-------+
+ | | ↑ | | |
+ | | |vsync_len | | |
+ | | ↓ | | |
+ +----------+-------------------------------------+----------+-------+
+
+Example:
+
+ display-timings {
+ native-mode = <&timing0>;
+ timing0: 1080p24 {
+ /* 1920x1080p24 */
+ clock-frequency = <52000000>;
+ hactive = <1920>;
+ vactive = <1080>;
+ hfront-porch = <25>;
+ hback-porch = <25>;
+ hsync-len = <25>;
+ vback-porch = <2>;
+ vfront-porch = <2>;
+ vsync-len = <2>;
+ hsync-active = <1>;
+ };
+ };
+
+Every required property also supports the use of ranges, so the commonly used
+datasheet description with minimum, typical and maximum values can be used.
+
+Example:
+
+ timing1: timing {
+ /* 1920x1080p24 */
+ clock-frequency = <148500000>;
+ hactive = <1920>;
+ vactive = <1080>;
+ hsync-len = <0 44 60>;
+ hfront-porch = <80 88 95>;
+ hback-porch = <100 148 160>;
+ vfront-porch = <0 4 6>;
+ vback-porch = <0 36 50>;
+ vsync-len = <0 5 6>;
+ };
diff --git a/Documentation/devicetree/bindings/video/exynos_dp.txt b/Documentation/devicetree/bindings/video/exynos_dp.txt
index c60da67..84f10c1 100644
--- a/Documentation/devicetree/bindings/video/exynos_dp.txt
+++ b/Documentation/devicetree/bindings/video/exynos_dp.txt
@@ -21,6 +21,10 @@
of memory mapped region.
-interrupts:
interrupt combiner values.
+ -clocks:
+ from common clock binding: handle to dp clock.
+ -clock-names:
+ from common clock binding: Shall be "dp".
-interrupt-parent:
phandle to Interrupt combiner node.
-samsung,color-space:
@@ -61,6 +65,8 @@
reg = <0x145b0000 0x10000>;
interrupts = <10 3>;
interrupt-parent = <&combiner>;
+ clocks = <&clock 342>;
+ clock-names = "dp";
dptx-phy {
reg = <0x10040720>;
diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
new file mode 100644
index 0000000..323983b
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
@@ -0,0 +1,23 @@
+Device-Tree bindings for drm hdmi driver
+
+Required properties:
+- compatible: value should be one among the following:
+ 1) "samsung,exynos5-hdmi" <DEPRECATED>
+ 2) "samsung,exynos4210-hdmi"
+ 3) "samsung,exynos4212-hdmi"
+- reg: physical base address of the hdmi and length of memory mapped
+ region.
+- interrupts: interrupt number to the cpu.
+- hpd-gpio: following information about the hotplug gpio pin.
+ a) phandle of the gpio controller node.
+ b) pin number within the gpio controller.
+ c) optional flags and pull up/down.
+
+Example:
+
+ hdmi {
+ compatible = "samsung,exynos4212-hdmi";
+ reg = <0x14530000 0x100000>;
+ interrupts = <0 95 0>;
+ hpd-gpio = <&gpx3 7 1>;
+ };
diff --git a/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt b/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
new file mode 100644
index 0000000..41eee97
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
@@ -0,0 +1,15 @@
+Device-Tree bindings for hdmiddc driver
+
+Required properties:
+- compatible: value should be one of the following
+ 1) "samsung,exynos5-hdmiddc" <DEPRECATED>
+ 2) "samsung,exynos4210-hdmiddc"
+
+- reg: I2C address of the hdmiddc device.
+
+Example:
+
+ hdmiddc {
+ compatible = "samsung,exynos4210-hdmiddc";
+ reg = <0x50>;
+ };
diff --git a/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt b/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
new file mode 100644
index 0000000..162f641
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
@@ -0,0 +1,15 @@
+Device-Tree bindings for hdmiphy driver
+
+Required properties:
+- compatible: value should be one of the following:
+ 1) "samsung,exynos5-hdmiphy" <DEPRECATED>
+ 2) "samsung,exynos4210-hdmiphy".
+ 3) "samsung,exynos4212-hdmiphy".
+- reg: I2C address of the hdmiphy device.
+
+Example:
+
+ hdmiphy {
+ compatible = "samsung,exynos4210-hdmiphy";
+ reg = <0x38>;
+ };
diff --git a/Documentation/devicetree/bindings/video/exynos_mixer.txt b/Documentation/devicetree/bindings/video/exynos_mixer.txt
new file mode 100644
index 0000000..3334b0a
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/exynos_mixer.txt
@@ -0,0 +1,20 @@
+Device-Tree bindings for mixer driver
+
+Required properties:
+- compatible: value should be one of the following:
+ 1) "samsung,exynos5-mixer" <DEPRECATED>
+ 2) "samsung,exynos4210-mixer"
+ 3) "samsung,exynos5250-mixer"
+ 4) "samsung,exynos5420-mixer"
+
+- reg: physical base address of the mixer and length of memory mapped
+ region.
+- interrupts: interrupt number to the cpu.
+
+Example:
+
+ mixer {
+ compatible = "samsung,exynos5250-mixer";
+ reg = <0x14450000 0x10000>;
+ interrupts = <0 94 0>;
+ };
diff --git a/Documentation/devicetree/bindings/video/fsl,imx-fb.txt b/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
new file mode 100644
index 0000000..46da08d
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
@@ -0,0 +1,51 @@
+Freescale imx21 Framebuffer
+
+This framebuffer driver supports devices imx1, imx21, imx25, and imx27.
+
+Required properties:
+- compatible : "fsl,<chip>-fb", chip should be imx1 or imx21
+- reg : Should contain 1 register ranges(address and length)
+- interrupts : One interrupt of the fb dev
+
+Required nodes:
+- display: Phandle to a display node as described in
+ Documentation/devicetree/bindings/video/display-timing.txt
+ Additional, the display node has to define properties:
+ - bits-per-pixel: Bits per pixel
+ - fsl,pcr: LCDC PCR value
+
+Optional properties:
+- fsl,dmacr: DMA Control Register value. This is optional. By default, the
+ register is not modified as recommended by the datasheet.
+- fsl,lscr1: LCDC Sharp Configuration Register value.
+
+Example:
+
+ imxfb: fb@10021000 {
+ compatible = "fsl,imx21-fb";
+ interrupts = <61>;
+ reg = <0x10021000 0x1000>;
+ display = <&display0>;
+ };
+
+ ...
+
+ display0: display0 {
+ model = "Primeview-PD050VL1";
+ native-mode = <&timing_disp0>;
+ bits-per-pixel = <16>;
+ fsl,pcr = <0xf0c88080>; /* non-standard but required */
+ display-timings {
+ timing_disp0: 640x480 {
+ hactive = <640>;
+ vactive = <480>;
+ hback-porch = <112>;
+ hfront-porch = <36>;
+ hsync-len = <32>;
+ vback-porch = <33>;
+ vfront-porch = <33>;
+ vsync-len = <2>;
+ clock-frequency = <25000000>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/video/samsung-fimd.txt b/Documentation/devicetree/bindings/video/samsung-fimd.txt
new file mode 100644
index 0000000..778838a
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/samsung-fimd.txt
@@ -0,0 +1,65 @@
+Device-Tree bindings for Samsung SoC display controller (FIMD)
+
+FIMD (Fully Interactive Mobile Display) is the Display Controller for the
+Samsung series of SoCs which transfers the image data from a video memory
+buffer to an external LCD interface.
+
+Required properties:
+- compatible: value should be one of the following
+ "samsung,s3c2443-fimd"; /* for S3C24XX SoCs */
+ "samsung,s3c6400-fimd"; /* for S3C64XX SoCs */
+ "samsung,s5p6440-fimd"; /* for S5P64X0 SoCs */
+ "samsung,s5pc100-fimd"; /* for S5PC100 SoC */
+ "samsung,s5pv210-fimd"; /* for S5PV210 SoC */
+ "samsung,exynos4210-fimd"; /* for Exynos4 SoCs */
+ "samsung,exynos5250-fimd"; /* for Exynos5 SoCs */
+
+- reg: physical base address and length of the FIMD registers set.
+
+- interrupt-parent: should be the phandle of the fimd controller's
+ parent interrupt controller.
+
+- interrupts: should contain a list of all FIMD IP block interrupts in the
+ order: FIFO Level, VSYNC, LCD_SYSTEM. The interrupt specifier
+ format depends on the interrupt controller used.
+
+- interrupt-names: should contain the interrupt names: "fifo", "vsync",
+ "lcd_sys", in the same order as they were listed in the interrupts
+ property.
+
+- pinctrl-0: pin control group to be used for this controller.
+
+- pinctrl-names: must contain a "default" entry.
+
+- clocks: must include clock specifiers corresponding to entries in the
+ clock-names property.
+
+- clock-names: list of clock names sorted in the same order as the clocks
+ property. Must contain "sclk_fimd" and "fimd".
+
+Optional Properties:
+- samsung,power-domain: a phandle to FIMD power domain node.
+
+Example:
+
+SoC specific DT entry:
+
+ fimd@11c00000 {
+ compatible = "samsung,exynos4210-fimd";
+ interrupt-parent = <&combiner>;
+ reg = <0x11c00000 0x20000>;
+ interrupt-names = "fifo", "vsync", "lcd_sys";
+ interrupts = <11 0>, <11 1>, <11 2>;
+ clocks = <&clock 140>, <&clock 283>;
+ clock-names = "sclk_fimd", "fimd";
+ samsung,power-domain = <&pd_lcd0>;
+ status = "disabled";
+ };
+
+Board specific DT entry:
+
+ fimd@11c00000 {
+ pinctrl-0 = <&lcd_clk &lcd_data24 &pwm1_out>;
+ pinctrl-names = "default";
+ status = "okay";
+ };
diff --git a/Documentation/devicetree/bindings/video/simple-framebuffer.txt b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
new file mode 100644
index 0000000..3ea4605
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
@@ -0,0 +1,25 @@
+Simple Framebuffer
+
+A simple frame-buffer describes a raw memory region that may be rendered to,
+with the assumption that the display hardware has already been set up to scan
+out from that buffer.
+
+Required properties:
+- compatible: "simple-framebuffer"
+- reg: Should contain the location and size of the framebuffer memory.
+- width: The width of the framebuffer in pixels.
+- height: The height of the framebuffer in pixels.
+- stride: The number of bytes in each line of the framebuffer.
+- format: The format of the framebuffer surface. Valid values are:
+ - r5g6b5 (16-bit pixels, d[15:11]=r, d[10:5]=g, d[4:0]=b).
+
+Example:
+
+ framebuffer {
+ compatible = "simple-framebuffer";
+ reg = <0x1d385000 (1600 * 1200 * 2)>;
+ width = <1600>;
+ height = <1200>;
+ stride = <(1600 * 2)>;
+ format = "r5g6b5";
+ };
diff --git a/Documentation/devicetree/bindings/video/ssd1307fb.txt b/Documentation/devicetree/bindings/video/ssd1307fb.txt
index 3d0060c..7a12542 100644
--- a/Documentation/devicetree/bindings/video/ssd1307fb.txt
+++ b/Documentation/devicetree/bindings/video/ssd1307fb.txt
@@ -1,13 +1,17 @@
* Solomon SSD1307 Framebuffer Driver
Required properties:
- - compatible: Should be "solomon,ssd1307fb-<bus>". The only supported bus for
- now is i2c.
+ - compatible: Should be "solomon,<chip>fb-<bus>". The only supported bus for
+ now is i2c, and the supported chips are ssd1306 and ssd1307.
- reg: Should contain address of the controller on the I2C bus. Most likely
0x3c or 0x3d
- pwm: Should contain the pwm to use according to the OF device tree PWM
- specification [0]
+ specification [0]. Only required for the ssd1307.
- reset-gpios: Should contain the GPIO used to reset the OLED display
+ - solomon,height: Height in pixel of the screen driven by the controller
+ - solomon,width: Width in pixel of the screen driven by the controller
+ - solomon,page-offset: Offset of pages (band of 8 pixels) that the screen is
+ mapped to.
Optional properties:
- reset-active-low: Is the reset gpio is active on physical low?
diff --git a/Documentation/devicetree/bindings/video/via,vt8500-fb.txt b/Documentation/devicetree/bindings/video/via,vt8500-fb.txt
index c870b64..2871e21 100644
--- a/Documentation/devicetree/bindings/video/via,vt8500-fb.txt
+++ b/Documentation/devicetree/bindings/video/via,vt8500-fb.txt
@@ -5,58 +5,32 @@
- compatible : "via,vt8500-fb"
- reg : Should contain 1 register ranges(address and length)
- interrupts : framebuffer controller interrupt
-- display: a phandle pointing to the display node
+- bits-per-pixel : bit depth of framebuffer (16 or 32)
-Required nodes:
-- display: a display node is required to initialize the lcd panel
- This should be in the board dts.
-- default-mode: a videomode within the display with timing parameters
- as specified below.
+Required subnodes:
+- display-timings: see display-timing.txt for information
Example:
- fb@d800e400 {
+ fb@d8050800 {
compatible = "via,vt8500-fb";
reg = <0xd800e400 0x400>;
interrupts = <12>;
- display = <&display>;
- default-mode = <&mode0>;
- };
+ bits-per-pixel = <16>;
-VIA VT8500 Display
------------------------------------------------------
-Required properties (as per of_videomode_helper):
-
- - hactive, vactive: Display resolution
- - hfront-porch, hback-porch, hsync-len: Horizontal Display timing parameters
- in pixels
- vfront-porch, vback-porch, vsync-len: Vertical display timing parameters in
- lines
- - clock: displayclock in Hz
- - bpp: lcd panel bit-depth.
- <16> for RGB565, <32> for RGB888
-
-Optional properties (as per of_videomode_helper):
- - width-mm, height-mm: Display dimensions in mm
- - hsync-active-high (bool): Hsync pulse is active high
- - vsync-active-high (bool): Vsync pulse is active high
- - interlaced (bool): This is an interlaced mode
- - doublescan (bool): This is a doublescan mode
-
-Example:
- display: display@0 {
- modes {
- mode0: mode@0 {
+ display-timings {
+ native-mode = <&timing0>;
+ timing0: 800x480 {
+ clock-frequency = <0>; /* unused but required */
hactive = <800>;
vactive = <480>;
- hback-porch = <88>;
hfront-porch = <40>;
+ hback-porch = <88>;
hsync-len = <0>;
vback-porch = <32>;
vfront-porch = <11>;
vsync-len = <1>;
- clock = <0>; /* unused but required */
- bpp = <16>; /* non-standard but required */
};
};
};
+
diff --git a/Documentation/devicetree/bindings/video/wm,wm8505-fb.txt b/Documentation/devicetree/bindings/video/wm,wm8505-fb.txt
index 3d325e1..0bcadb2 100644
--- a/Documentation/devicetree/bindings/video/wm,wm8505-fb.txt
+++ b/Documentation/devicetree/bindings/video/wm,wm8505-fb.txt
@@ -4,20 +4,30 @@
Required properties:
- compatible : "wm,wm8505-fb"
- reg : Should contain 1 register ranges(address and length)
-- via,display: a phandle pointing to the display node
+- bits-per-pixel : bit depth of framebuffer (16 or 32)
-Required nodes:
-- display: a display node is required to initialize the lcd panel
- This should be in the board dts. See definition in
- Documentation/devicetree/bindings/video/via,vt8500-fb.txt
-- default-mode: a videomode node as specified in
- Documentation/devicetree/bindings/video/via,vt8500-fb.txt
+Required subnodes:
+- display-timings: see display-timing.txt for information
Example:
- fb@d8050800 {
+ fb@d8051700 {
compatible = "wm,wm8505-fb";
- reg = <0xd8050800 0x200>;
- display = <&display>;
- default-mode = <&mode0>;
+ reg = <0xd8051700 0x200>;
+ bits-per-pixel = <16>;
+
+ display-timings {
+ native-mode = <&timing0>;
+ timing0: 800x480 {
+ clock-frequency = <0>; /* unused but required */
+ hactive = <800>;
+ vactive = <480>;
+ hfront-porch = <40>;
+ hback-porch = <88>;
+ hsync-len = <0>;
+ vback-porch = <32>;
+ vfront-porch = <11>;
+ vsync-len = <1>;
+ };
+ };
};
diff --git a/Documentation/devicetree/bindings/w1/fsl-imx-owire.txt b/Documentation/devicetree/bindings/w1/fsl-imx-owire.txt
new file mode 100644
index 0000000..ecf42c0
--- /dev/null
+++ b/Documentation/devicetree/bindings/w1/fsl-imx-owire.txt
@@ -0,0 +1,19 @@
+* Freescale i.MX One wire bus master controller
+
+Required properties:
+- compatible : should be "fsl,imx21-owire"
+- reg : Address and length of the register set for the device
+
+Optional properties:
+- clocks : phandle of clock that supplies the module (required if platform
+ clock bindings use device tree)
+
+Example:
+
+- From imx53.dtsi:
+owire: owire@63fa4000 {
+ compatible = "fsl,imx53-owire", "fsl,imx21-owire";
+ reg = <0x63fa4000 0x4000>;
+ clocks = <&clks 159>;
+ status = "disabled";
+};
diff --git a/Documentation/devicetree/bindings/watchdog/atmel-at91rm9200-wdt.txt b/Documentation/devicetree/bindings/watchdog/atmel-at91rm9200-wdt.txt
new file mode 100644
index 0000000..d4d86cf
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/atmel-at91rm9200-wdt.txt
@@ -0,0 +1,9 @@
+Atmel AT91RM9200 System Timer Watchdog
+
+Required properties:
+- compatible: must be "atmel,at91sam9260-wdt".
+
+Example:
+ watchdog@fffffd00 {
+ compatible = "atmel,at91rm9200-wdt";
+ };
diff --git a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt
index 2957ebb..fcdd48f 100644
--- a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt
+++ b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt
@@ -7,9 +7,13 @@
- reg: physical base address of the controller and length of memory mapped
region.
+Optional properties:
+- timeout-sec: contains the watchdog timeout in seconds.
+
Example:
watchdog@fffffd40 {
compatible = "atmel,at91sam9260-wdt";
reg = <0xfffffd40 0x10>;
+ timeout-sec = <10>;
};
diff --git a/Documentation/devicetree/bindings/watchdog/brcm,bcm2835-pm-wdog.txt b/Documentation/devicetree/bindings/watchdog/brcm,bcm2835-pm-wdog.txt
index d209366..f801d71 100644
--- a/Documentation/devicetree/bindings/watchdog/brcm,bcm2835-pm-wdog.txt
+++ b/Documentation/devicetree/bindings/watchdog/brcm,bcm2835-pm-wdog.txt
@@ -5,9 +5,14 @@
- compatible : should be "brcm,bcm2835-pm-wdt"
- reg : Specifies base physical address and size of the registers.
+Optional properties:
+
+- timeout-sec : Contains the watchdog timeout in seconds
+
Example:
watchdog {
compatible = "brcm,bcm2835-pm-wdt";
reg = <0x7e100000 0x28>;
+ timeout-sec = <10>;
};
diff --git a/Documentation/devicetree/bindings/watchdog/marvel.txt b/Documentation/devicetree/bindings/watchdog/marvel.txt
index 0b2503a..5dc8d30 100644
--- a/Documentation/devicetree/bindings/watchdog/marvel.txt
+++ b/Documentation/devicetree/bindings/watchdog/marvel.txt
@@ -5,10 +5,15 @@
- Compatibility : "marvell,orion-wdt"
- reg : Address of the timer registers
+Optional properties:
+
+- timeout-sec : Contains the watchdog timeout in seconds
+
Example:
wdt@20300 {
compatible = "marvell,orion-wdt";
reg = <0x20300 0x28>;
+ timeout-sec = <10>;
status = "okay";
};
diff --git a/Documentation/devicetree/bindings/watchdog/pnx4008-wdt.txt b/Documentation/devicetree/bindings/watchdog/pnx4008-wdt.txt
index 7c7f688..556d06c 100644
--- a/Documentation/devicetree/bindings/watchdog/pnx4008-wdt.txt
+++ b/Documentation/devicetree/bindings/watchdog/pnx4008-wdt.txt
@@ -5,9 +5,13 @@
- reg: physical base address of the controller and length of memory mapped
region.
+Optional properties:
+- timeout-sec: contains the watchdog timeout in seconds.
+
Example:
watchdog@4003C000 {
compatible = "nxp,pnx4008-wdt";
reg = <0x4003C000 0x1000>;
+ timeout-sec = <10>;
};
diff --git a/Documentation/devicetree/bindings/watchdog/qca-ar7130-wdt.txt b/Documentation/devicetree/bindings/watchdog/qca-ar7130-wdt.txt
new file mode 100644
index 0000000..7a89e5f
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/qca-ar7130-wdt.txt
@@ -0,0 +1,13 @@
+* Qualcomm Atheros AR7130 Watchdog Timer (WDT) Controller
+
+Required properties:
+- compatible: must be "qca,ar7130-wdt"
+- reg: physical base address of the controller and length of memory mapped
+ region.
+
+Example:
+
+wdt@18060008 {
+ compatible = "qca,ar9330-wdt", "qca,ar7130-wdt";
+ reg = <0x18060008 0x8>;
+};
diff --git a/Documentation/devicetree/bindings/watchdog/samsung-wdt.txt b/Documentation/devicetree/bindings/watchdog/samsung-wdt.txt
index 79ead82..2aa486c 100644
--- a/Documentation/devicetree/bindings/watchdog/samsung-wdt.txt
+++ b/Documentation/devicetree/bindings/watchdog/samsung-wdt.txt
@@ -2,10 +2,13 @@
The Samsung's Watchdog controller is used for resuming system operation
after a preset amount of time during which the WDT reset event has not
-occured.
+occurred.
Required properties:
- compatible : should be "samsung,s3c2410-wdt"
- reg : base physical address of the controller and length of memory mapped
region.
- interrupts : interrupt number to the cpu.
+
+Optional properties:
+- timeout-sec : contains the watchdog timeout in seconds.
diff --git a/Documentation/devicetree/bindings/watchdog/stericsson-coh901327.txt b/Documentation/devicetree/bindings/watchdog/stericsson-coh901327.txt
new file mode 100644
index 0000000..8ffb88e
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/stericsson-coh901327.txt
@@ -0,0 +1,19 @@
+ST-Ericsson COH 901 327 Watchdog timer
+
+Required properties:
+- compatible: must be "stericsson,coh901327".
+- reg: physical base address of the controller and length of memory mapped
+ region.
+- interrupts: the interrupt used for the watchdog timeout warning.
+
+Optional properties:
+- timeout-sec: contains the watchdog timeout in seconds.
+
+Example:
+
+watchdog: watchdog@c0012000 {
+ compatible = "stericsson,coh901327";
+ reg = <0xc0012000 0x1000>;
+ interrupts = <3>;
+ timeout-sec = <60>;
+};
diff --git a/Documentation/devicetree/bindings/watchdog/sun4i-wdt.txt b/Documentation/devicetree/bindings/watchdog/sun4i-wdt.txt
new file mode 100644
index 0000000..ecd650a
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/sun4i-wdt.txt
@@ -0,0 +1,13 @@
+Allwinner sun4i Watchdog timer
+
+Required properties:
+
+- compatible : should be "allwinner,sun4i-wdt"
+- reg : Specifies base physical address and size of the registers.
+
+Example:
+
+wdt: watchdog@01c20c90 {
+ compatible = "allwinner,sun4i-wdt";
+ reg = <0x01c20c90 0x10>;
+};
diff --git a/Documentation/devicetree/bindings/watchdog/sunxi-wdt.txt b/Documentation/devicetree/bindings/watchdog/sunxi-wdt.txt
deleted file mode 100644
index 0b27177..0000000
--- a/Documentation/devicetree/bindings/watchdog/sunxi-wdt.txt
+++ /dev/null
@@ -1,13 +0,0 @@
-Allwinner sunXi Watchdog timer
-
-Required properties:
-
-- compatible : should be "allwinner,sunxi-wdt"
-- reg : Specifies base physical address and size of the registers.
-
-Example:
-
-wdt: watchdog@01c20c90 {
- compatible = "allwinner,sunxi-wdt";
- reg = <0x01c20c90 0x10>;
-};
diff --git a/Documentation/devicetree/bindings/watchdog/twl4030-wdt.txt b/Documentation/devicetree/bindings/watchdog/twl4030-wdt.txt
new file mode 100644
index 0000000..80a3719
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/twl4030-wdt.txt
@@ -0,0 +1,10 @@
+Device tree bindings for twl4030-wdt driver (TWL4030 watchdog)
+
+Required properties:
+ compatible = "ti,twl4030-wdt";
+
+Example:
+
+watchdog {
+ compatible = "ti,twl4030-wdt";
+};
diff --git a/Documentation/devicetree/booting-without-of.txt b/Documentation/devicetree/booting-without-of.txt
index d4d6675..b2fb2f5 100644
--- a/Documentation/devicetree/booting-without-of.txt
+++ b/Documentation/devicetree/booting-without-of.txt
@@ -1228,7 +1228,7 @@
The interrupt tree model is fully described in the
document "Open Firmware Recommended Practice: Interrupt
Mapping Version 0.9". The document is available at:
-<http://playground.sun.com/1275/practice>.
+<http://www.openfirmware.org/ofwg/practice/>
1) interrupts property
----------------------
diff --git a/Documentation/devicetree/usage-model.txt b/Documentation/devicetree/usage-model.txt
index ef9d06c..2b6b3d3 100644
--- a/Documentation/devicetree/usage-model.txt
+++ b/Documentation/devicetree/usage-model.txt
@@ -106,17 +106,18 @@
kernel will instead select setup code based on the machine's core
CPU or SoC. On ARM for example, setup_arch() in
arch/arm/kernel/setup.c will call setup_machine_fdt() in
-arch/arm/kernel/devicetree.c which searches through the machine_desc
+arch/arm/kernel/devtree.c which searches through the machine_desc
table and selects the machine_desc which best matches the device tree
data. It determines the best match by looking at the 'compatible'
property in the root device tree node, and comparing it with the
-dt_compat list in struct machine_desc.
+dt_compat list in struct machine_desc (which is defined in
+arch/arm/include/asm/mach/arch.h if you're curious).
The 'compatible' property contains a sorted list of strings starting
with the exact name of the machine, followed by an optional list of
boards it is compatible with sorted from most compatible to least. For
example, the root compatible properties for the TI BeagleBoard and its
-successor, the BeagleBoard xM board might look like:
+successor, the BeagleBoard xM board might look like, respectively:
compatible = "ti,omap3-beagleboard", "ti,omap3450", "ti,omap3";
compatible = "ti,omap3-beagleboard-xm", "ti,omap3450", "ti,omap3";
@@ -161,7 +162,7 @@
Instead, the compatible list allows a generic machine_desc to provide
support for a wide common set of boards by specifying "less
-compatible" value in the dt_compat list. In the example above,
+compatible" values in the dt_compat list. In the example above,
generic board support can claim compatibility with "ti,omap3" or
"ti,omap3450". If a bug was discovered on the original beagleboard
that required special workaround code during early boot, then a new
@@ -191,9 +192,11 @@
};
The bootargs property contains the kernel arguments, and the initrd-*
-properties define the address and size of an initrd blob. The
-chosen node may also optionally contain an arbitrary number of
-additional properties for platform-specific configuration data.
+properties define the address and size of an initrd blob. Note that
+initrd-end is the first address after the initrd image, so this doesn't
+match the usual semantic of struct resource. The chosen node may also
+optionally contain an arbitrary number of additional properties for
+platform-specific configuration data.
During early boot, the architecture setup code calls of_scan_flat_dt()
several times with different helper callbacks to parse device tree
@@ -375,7 +378,7 @@
device tree support code reflects that and makes the above example
simpler. The second argument to of_platform_populate() is an
of_device_id table, and any node that matches an entry in that table
-will also get its child nodes registered. In the tegra case, the code
+will also get its child nodes registered. In the Tegra case, the code
can look something like this:
static void __init harmony_init_machine(void)
diff --git a/Documentation/dma-buf-sharing.txt b/Documentation/dma-buf-sharing.txt
index 0188903..0b23261 100644
--- a/Documentation/dma-buf-sharing.txt
+++ b/Documentation/dma-buf-sharing.txt
@@ -52,14 +52,23 @@
associated with this buffer.
Interface:
- struct dma_buf *dma_buf_export(void *priv, struct dma_buf_ops *ops,
- size_t size, int flags)
+ struct dma_buf *dma_buf_export_named(void *priv, struct dma_buf_ops *ops,
+ size_t size, int flags,
+ const char *exp_name)
If this succeeds, dma_buf_export allocates a dma_buf structure, and returns a
pointer to the same. It also associates an anonymous file with this buffer,
so it can be exported. On failure to allocate the dma_buf object, it returns
NULL.
+ 'exp_name' is the name of exporter - to facilitate information while
+ debugging.
+
+ Exporting modules which do not wish to provide any specific name may use the
+ helper define 'dma_buf_export()', with the same arguments as above, but
+ without the last argument; a __FILE__ pre-processor directive will be
+ inserted in place of 'exp_name' instead.
+
2. Userspace gets a handle to pass around to potential buffer-users
Userspace entity requests for a file-descriptor (fd) which is a handle to the
@@ -302,7 +311,11 @@
void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
The vmap call can fail if there is no vmap support in the exporter, or if it
- runs out of vmalloc space. Fallback to kmap should be implemented.
+ runs out of vmalloc space. Fallback to kmap should be implemented. Note that
+ the dma-buf layer keeps a reference count for all vmap access and calls down
+ into the exporter's vmap function only when no vmapping exists, and only
+ unmaps it once. Protection against concurrent vmap/vunmap calls is provided
+ by taking the dma_buf->lock mutex.
3. Finish access
diff --git a/Documentation/dmatest.txt b/Documentation/dmatest.txt
new file mode 100644
index 0000000..132a094
--- /dev/null
+++ b/Documentation/dmatest.txt
@@ -0,0 +1,81 @@
+ DMA Test Guide
+ ==============
+
+ Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+
+This small document introduces how to test DMA drivers using dmatest module.
+
+ Part 1 - How to build the test module
+
+The menuconfig contains an option that could be found by following path:
+ Device Drivers -> DMA Engine support -> DMA Test client
+
+In the configuration file the option called CONFIG_DMATEST. The dmatest could
+be built as module or inside kernel. Let's consider those cases.
+
+ Part 2 - When dmatest is built as a module...
+
+After mounting debugfs and loading the module, the /sys/kernel/debug/dmatest
+folder with nodes will be created. They are the same as module parameters with
+addition of the 'run' node that controls run and stop phases of the test.
+
+Note that in this case test will not run on load automatically.
+
+Example of usage:
+ % echo dma0chan0 > /sys/kernel/debug/dmatest/channel
+ % echo 2000 > /sys/kernel/debug/dmatest/timeout
+ % echo 1 > /sys/kernel/debug/dmatest/iterations
+ % echo 1 > /sys/kernel/debug/dmatest/run
+
+Hint: available channel list could be extracted by running the following
+command:
+ % ls -1 /sys/class/dma/
+
+After a while you will start to get messages about current status or error like
+in the original code.
+
+Note that running a new test will not stop any in progress test.
+
+The following command should return actual state of the test.
+ % cat /sys/kernel/debug/dmatest/run
+
+To wait for test done the user may perform a busy loop that checks the state.
+
+ % while [ $(cat /sys/kernel/debug/dmatest/run) = "Y" ]
+ > do
+ > echo -n "."
+ > sleep 1
+ > done
+ > echo
+
+ Part 3 - When built-in in the kernel...
+
+The module parameters that is supplied to the kernel command line will be used
+for the first performed test. After user gets a control, the test could be
+re-run with the same or different parameters. For the details see the above
+section "Part 2 - When dmatest is built as a module..."
+
+In both cases the module parameters are used as initial values for the test case.
+You always could check them at run-time by running
+ % grep -H . /sys/module/dmatest/parameters/*
+
+ Part 4 - Gathering the test results
+
+The module provides a storage for the test results in the memory. The gathered
+data could be used after test is done.
+
+The special file 'results' in the debugfs represents gathered data of the in
+progress test. The messages collected are printed to the kernel log as well.
+
+Example of output:
+ % cat /sys/kernel/debug/dmatest/results
+ dma0chan0-copy0: #1: No errors with src_off=0x7bf dst_off=0x8ad len=0x3fea (0)
+
+The message format is unified across the different types of errors. A number in
+the parens represents additional information, e.g. error code, error counter,
+or status.
+
+Comparison between buffers is stored to the dedicated structure.
+
+Note that the verify result is now accessible only via file 'results' in the
+debugfs.
diff --git a/Documentation/driver-model/devres.txt b/Documentation/driver-model/devres.txt
index 43cff70..b467145 100644
--- a/Documentation/driver-model/devres.txt
+++ b/Documentation/driver-model/devres.txt
@@ -266,7 +266,8 @@
devm_ioremap()
devm_ioremap_nocache()
devm_iounmap()
- devm_request_and_ioremap() : checks resource, requests region, ioremaps
+ devm_ioremap_resource() : checks resource, requests memory region, ioremaps
+ devm_request_and_ioremap() : obsoleted by devm_ioremap_resource()
pcim_iomap()
pcim_iounmap()
pcim_iomap_table() : array of mapped addresses indexed by BAR
@@ -288,3 +289,7 @@
PWM
devm_pwm_get()
devm_pwm_put()
+
+PHY
+ devm_usb_get_phy()
+ devm_usb_put_phy()
diff --git a/Documentation/dvb/get_dvb_firmware b/Documentation/dvb/get_dvb_firmware
index 32bc56b..5d5ee4c 100755
--- a/Documentation/dvb/get_dvb_firmware
+++ b/Documentation/dvb/get_dvb_firmware
@@ -23,7 +23,7 @@
@components = ( "sp8870", "sp887x", "tda10045", "tda10046",
"tda10046lifeview", "av7110", "dec2000t", "dec2540t",
- "dec3000s", "vp7041", "dibusb", "nxt2002", "nxt2004",
+ "dec3000s", "vp7041", "vp7049", "dibusb", "nxt2002", "nxt2004",
"or51211", "or51132_qam", "or51132_vsb", "bluebird",
"opera1", "cx231xx", "cx18", "cx23885", "pvrusb2", "mpc718",
"af9015", "ngene", "az6027", "lme2510_lg", "lme2510c_s7395",
@@ -289,6 +289,19 @@
$outfile;
}
+sub vp7049 {
+ my $fwfile = "dvb-usb-vp7049-0.95.fw";
+ my $url = "http://ao2.it/sites/default/files/blog/2012/11/06/linux-support-digicom-digitune-s-vp7049-udtt7049/$fwfile";
+ my $hash = "5609fd295168aea88b25ff43a6f79c36";
+
+ checkstandard();
+
+ wgetfile($fwfile, $url);
+ verify($fwfile, $hash);
+
+ $fwfile;
+}
+
sub dibusb {
my $url = "http://www.linuxtv.org/downloads/firmware/dvb-usb-dibusb-5.0.0.11.fw";
my $outfile = "dvb-dibusb-5.0.0.11.fw";
@@ -677,7 +690,7 @@
}
sub drxk_terratec_htc_stick {
- my $url = "http://ftp.terratec.de/Receiver/Cinergy_HTC_Stick/Updates/";
+ my $url = "http://ftp.terratec.de/Receiver/Cinergy_HTC_Stick/Updates/History/";
my $zipfile = "Cinergy_HTC_Stick_Drv_5.09.1202.00_XP_Vista_7.exe";
my $hash = "6722a2442a05423b781721fbc069ed5e";
my $tmpdir = tempdir(DIR => "/tmp", CLEANUP => 0);
diff --git a/Documentation/dynamic-debug-howto.txt b/Documentation/dynamic-debug-howto.txt
index 6e16849..1bbdcfc 100644
--- a/Documentation/dynamic-debug-howto.txt
+++ b/Documentation/dynamic-debug-howto.txt
@@ -6,8 +6,16 @@
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.
+CONFIG_DYNAMIC_DEBUG is set, then all pr_debug()/dev_dbg() and
+print_hex_dump_debug()/print_hex_dump_bytes() calls can be dynamically
+enabled per-callsite.
+
+If CONFIG_DYNAMIC_DEBUG is not set, print_hex_dump_debug() is just
+shortcut for print_hex_dump(KERN_DEBUG).
+
+For print_hex_dump_debug()/print_hex_dump_bytes(), format string is
+its 'prefix_str' argument, if it is constant string; or "hexdump"
+in case 'prefix_str' is build dynamically.
Dynamic debug has even more useful features:
@@ -202,6 +210,9 @@
t Include thread ID in messages not generated from interrupt context
_ No flags are set. (Or'd with others on input)
+For print_hex_dump_debug() and print_hex_dump_bytes(), only 'p' flag
+have meaning, other flags ignored.
+
For display, the flags are preceded by '='
(mnemonic: what the flags are currently equal to).
@@ -268,7 +279,7 @@
- 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/
+- it doesn't 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
diff --git a/Documentation/early-userspace/README b/Documentation/early-userspace/README
index e35d830..661a73f 100644
--- a/Documentation/early-userspace/README
+++ b/Documentation/early-userspace/README
@@ -71,7 +71,7 @@
gen_initramfs_list.sh. If a directory is specified as an argument then
the contents are scanned, uid/gid translation is performed, and
usr/gen_init_cpio file directives are output. If a directory is
-specified as an arugemnt to scripts/gen_initramfs_list.sh then the
+specified as an argument to scripts/gen_initramfs_list.sh then the
contents of the file are simply copied to the output. All of the output
directives from directory scanning and file contents copying are
processed by usr/gen_init_cpio.
diff --git a/Documentation/fb/cirrusfb.txt b/Documentation/fb/cirrusfb.txt
index f943684..f75950d 100644
--- a/Documentation/fb/cirrusfb.txt
+++ b/Documentation/fb/cirrusfb.txt
@@ -55,7 +55,7 @@
* Overhaul color register routines.
* Associated with the above, console colors are now obtained from a LUT
called 'palette' instead of from the VGA registers. This code was
- modeled after that in atyfb and matroxfb.
+ modelled after that in atyfb and matroxfb.
* Code cleanup, add comments.
* Overhaul SR07 handling.
* Bug fixes.
diff --git a/Documentation/fb/uvesafb.txt b/Documentation/fb/uvesafb.txt
index eefdd91..f6362d8 100644
--- a/Documentation/fb/uvesafb.txt
+++ b/Documentation/fb/uvesafb.txt
@@ -81,17 +81,11 @@
mtrr:n Setup memory type range registers for the framebuffer
where n:
- 0 - disabled (equivalent to nomtrr) (default)
- 1 - uncachable
- 2 - write-back
- 3 - write-combining
- 4 - write-through
+ 0 - disabled (equivalent to nomtrr)
+ 3 - write-combining (default)
- If you see the following in dmesg, choose the type that matches
- the old one. In this example, use "mtrr:2".
-...
-mtrr: type mismatch for e0000000,8000000 old: write-back new: write-combining
-...
+ Values other than 0 and 3 will result in a warning and will be
+ treated just like 3.
nomtrr Do not use memory type range registers.
diff --git a/Documentation/filesystems/Locking b/Documentation/filesystems/Locking
index f48e0c6..fe7afe2 100644
--- a/Documentation/filesystems/Locking
+++ b/Documentation/filesystems/Locking
@@ -10,10 +10,9 @@
--------------------------- dentry_operations --------------------------
prototypes:
int (*d_revalidate)(struct dentry *, unsigned int);
- int (*d_hash)(const struct dentry *, const struct inode *,
- struct qstr *);
- int (*d_compare)(const struct dentry *, const struct inode *,
- const struct dentry *, const struct inode *,
+ int (*d_weak_revalidate)(struct dentry *, unsigned int);
+ int (*d_hash)(const struct dentry *, struct qstr *);
+ int (*d_compare)(const struct dentry *, const struct dentry *,
unsigned int, const char *, const struct qstr *);
int (*d_delete)(struct dentry *);
void (*d_release)(struct dentry *);
@@ -25,6 +24,7 @@
locking rules:
rename_lock ->d_lock may block rcu-walk
d_revalidate: no no yes (ref-walk) maybe
+d_weak_revalidate:no no yes no
d_hash no no no maybe
d_compare: yes no no maybe
d_delete: no yes no no
@@ -64,6 +64,7 @@
int (*atomic_open)(struct inode *, struct dentry *,
struct file *, unsigned open_flag,
umode_t create_mode, int *opened);
+ int (*tmpfile) (struct inode *, struct dentry *, umode_t);
locking rules:
all may block
@@ -91,6 +92,7 @@
fiemap: no
update_time: no
atomic_open: yes
+tmpfile: no
Additionally, ->rmdir(), ->unlink() and ->rename() have ->i_mutex on
victim.
@@ -187,7 +189,7 @@
loff_t pos, unsigned len, unsigned copied,
struct page *page, void *fsdata);
sector_t (*bmap)(struct address_space *, sector_t);
- int (*invalidatepage) (struct page *, unsigned long);
+ void (*invalidatepage) (struct page *, unsigned int, unsigned int);
int (*releasepage) (struct page *, int);
void (*freepage)(struct page *);
int (*direct_IO)(int, struct kiocb *, const struct iovec *iov,
@@ -308,8 +310,8 @@
keep it that way and don't breed new callers.
->invalidatepage() is called when the filesystem must attempt to drop
-some or all of the buffers from the page when it is being truncated. It
-returns zero on success. If ->invalidatepage is zero, the kernel uses
+some or all of the buffers from the page when it is being truncated. It
+returns zero on success. If ->invalidatepage is zero, the kernel uses
block_invalidatepage() instead.
->releasepage() is called when the kernel is about to try to drop the
@@ -342,25 +344,38 @@
locking rules:
- file_lock_lock may block
+ inode->i_lock may block
fl_copy_lock: yes no
fl_release_private: maybe no
----------------------- lock_manager_operations ---------------------------
prototypes:
int (*lm_compare_owner)(struct file_lock *, struct file_lock *);
+ unsigned long (*lm_owner_key)(struct file_lock *);
void (*lm_notify)(struct file_lock *); /* unblock callback */
int (*lm_grant)(struct file_lock *, struct file_lock *, int);
void (*lm_break)(struct file_lock *); /* break_lease callback */
int (*lm_change)(struct file_lock **, int);
locking rules:
- file_lock_lock may block
-lm_compare_owner: yes no
-lm_notify: yes no
-lm_grant: no no
-lm_break: yes no
-lm_change yes no
+
+ inode->i_lock blocked_lock_lock may block
+lm_compare_owner: yes[1] maybe no
+lm_owner_key yes[1] yes no
+lm_notify: yes yes no
+lm_grant: no no no
+lm_break: yes no no
+lm_change yes no no
+
+[1]: ->lm_compare_owner and ->lm_owner_key are generally called with
+*an* inode->i_lock held. It may not be the i_lock of the inode
+associated with either file_lock argument! This is the case with deadlock
+detection, since the code has to chase down the owners of locks that may
+be entirely unrelated to the one on which the lock is being acquired.
+For deadlock detection however, the blocked_lock_lock is also held. The
+fact that these locks are held ensures that the file_locks do not
+disappear out from under you while doing the comparison or generating an
+owner key.
--------------------------- buffer_head -----------------------------------
prototypes:
@@ -412,7 +427,7 @@
ssize_t (*write) (struct file *, const char __user *, size_t, loff_t *);
ssize_t (*aio_read) (struct kiocb *, const struct iovec *, unsigned long, loff_t);
ssize_t (*aio_write) (struct kiocb *, const struct iovec *, unsigned long, loff_t);
- int (*readdir) (struct file *, void *, filldir_t);
+ int (*iterate) (struct file *, struct dir_context *);
unsigned int (*poll) (struct file *, struct poll_table_struct *);
long (*unlocked_ioctl) (struct file *, unsigned int, unsigned long);
long (*compat_ioctl) (struct file *, unsigned int, unsigned long);
diff --git a/Documentation/filesystems/btrfs.txt b/Documentation/filesystems/btrfs.txt
index 7671352..b349d57 100644
--- a/Documentation/filesystems/btrfs.txt
+++ b/Documentation/filesystems/btrfs.txt
@@ -1,8 +1,8 @@
- BTRFS
- =====
+BTRFS
+=====
-Btrfs is a new copy on write filesystem for Linux aimed at
+Btrfs is a copy on write filesystem for Linux aimed at
implementing advanced features while focusing on fault tolerance,
repair and easy administration. Initially developed by Oracle, Btrfs
is licensed under the GPL and open for contribution from anyone.
@@ -34,9 +34,175 @@
* Online filesystem defragmentation
+Mount Options
+=============
- MAILING LIST
- ============
+When mounting a btrfs filesystem, the following option are accepted.
+Unless otherwise specified, all options default to off.
+
+ alloc_start=<bytes>
+ Debugging option to force all block allocations above a certain
+ byte threshold on each block device. The value is specified in
+ bytes, optionally with a K, M, or G suffix, case insensitive.
+ Default is 1MB.
+
+ autodefrag
+ Detect small random writes into files and queue them up for the
+ defrag process. Works best for small files; Not well suited for
+ large database workloads.
+
+ check_int
+ check_int_data
+ check_int_print_mask=<value>
+ These debugging options control the behavior of the integrity checking
+ module (the BTRFS_FS_CHECK_INTEGRITY config option required).
+
+ check_int enables the integrity checker module, which examines all
+ block write requests to ensure on-disk consistency, at a large
+ memory and CPU cost.
+
+ check_int_data includes extent data in the integrity checks, and
+ implies the check_int option.
+
+ check_int_print_mask takes a bitmask of BTRFSIC_PRINT_MASK_* values
+ as defined in fs/btrfs/check-integrity.c, to control the integrity
+ checker module behavior.
+
+ See comments at the top of fs/btrfs/check-integrity.c for more info.
+
+ compress
+ compress=<type>
+ compress-force
+ compress-force=<type>
+ Control BTRFS file data compression. Type may be specified as "zlib"
+ "lzo" or "no" (for no compression, used for remounting). If no type
+ is specified, zlib is used. If compress-force is specified,
+ all files will be compressed, whether or not they compress well.
+ If compression is enabled, nodatacow and nodatasum are disabled.
+
+ degraded
+ Allow mounts to continue with missing devices. A read-write mount may
+ fail with too many devices missing, for example if a stripe member
+ is completely missing.
+
+ device=<devicepath>
+ Specify a device during mount so that ioctls on the control device
+ can be avoided. Especialy useful when trying to mount a multi-device
+ setup as root. May be specified multiple times for multiple devices.
+
+ discard
+ Issue frequent commands to let the block device reclaim space freed by
+ the filesystem. This is useful for SSD devices, thinly provisioned
+ LUNs and virtual machine images, but may have a significant
+ performance impact. (The fstrim command is also available to
+ initiate batch trims from userspace).
+
+ enospc_debug
+ Debugging option to be more verbose in some ENOSPC conditions.
+
+ fatal_errors=<action>
+ Action to take when encountering a fatal error:
+ "bug" - BUG() on a fatal error. This is the default.
+ "panic" - panic() on a fatal error.
+
+ flushoncommit
+ The 'flushoncommit' mount option forces any data dirtied by a write in a
+ prior transaction to commit as part of the current commit. This makes
+ the committed state a fully consistent view of the file system from the
+ application's perspective (i.e., it includes all completed file system
+ operations). This was previously the behavior only when a snapshot is
+ created.
+
+ inode_cache
+ Enable free inode number caching. Defaults to off due to an overflow
+ problem when the free space crcs don't fit inside a single page.
+
+ max_inline=<bytes>
+ Specify the maximum amount of space, in bytes, that can be inlined in
+ a metadata B-tree leaf. The value is specified in bytes, optionally
+ with a K, M, or G suffix, case insensitive. In practice, this value
+ is limited by the root sector size, with some space unavailable due
+ to leaf headers. For a 4k sectorsize, max inline data is ~3900 bytes.
+
+ metadata_ratio=<value>
+ Specify that 1 metadata chunk should be allocated after every <value>
+ data chunks. Off by default.
+
+ noacl
+ Disable support for Posix Access Control Lists (ACLs). See the
+ acl(5) manual page for more information about ACLs.
+
+ nobarrier
+ Disables the use of block layer write barriers. Write barriers ensure
+ that certain IOs make it through the device cache and are on persistent
+ storage. If used on a device with a volatile (non-battery-backed)
+ write-back cache, this option will lead to filesystem corruption on a
+ system crash or power loss.
+
+ nodatacow
+ Disable data copy-on-write for newly created files. Implies nodatasum,
+ and disables all compression.
+
+ nodatasum
+ Disable data checksumming for newly created files.
+
+ notreelog
+ Disable the tree logging used for fsync and O_SYNC writes.
+
+ recovery
+ Enable autorecovery attempts if a bad tree root is found at mount time.
+ Currently this scans a list of several previous tree roots and tries to
+ use the first readable.
+
+ skip_balance
+ Skip automatic resume of interrupted balance operation after mount.
+ May be resumed with "btrfs balance resume."
+
+ space_cache (*)
+ Enable the on-disk freespace cache.
+ nospace_cache
+ Disable freespace cache loading without clearing the cache.
+ clear_cache
+ Force clearing and rebuilding of the disk space cache if something
+ has gone wrong.
+
+ ssd
+ nossd
+ ssd_spread
+ Options to control ssd allocation schemes. By default, BTRFS will
+ enable or disable ssd allocation heuristics depending on whether a
+ rotational or nonrotational disk is in use. The ssd and nossd options
+ can override this autodetection.
+
+ The ssd_spread mount option attempts to allocate into big chunks
+ of unused space, and may perform better on low-end ssds. ssd_spread
+ implies ssd, enabling all other ssd heuristics as well.
+
+ subvol=<path>
+ Mount subvolume at <path> rather than the root subvolume. <path> is
+ relative to the top level subvolume.
+
+ subvolid=<ID>
+ Mount subvolume specified by an ID number rather than the root subvolume.
+ This allows mounting of subvolumes which are not in the root of the mounted
+ filesystem.
+ You can use "btrfs subvolume list" to see subvolume ID numbers.
+
+ subvolrootid=<objectid> (deprecated)
+ Mount subvolume specified by <objectid> rather than the root subvolume.
+ This allows mounting of subvolumes which are not in the root of the mounted
+ filesystem.
+ You can use "btrfs subvolume show " to see the object ID for a subvolume.
+
+ thread_pool=<number>
+ The number of worker threads to allocate. The default number is equal
+ to the number of CPUs + 2, or 8, whichever is smaller.
+
+ user_subvol_rm_allowed
+ Allow subvolumes to be deleted by a non-root user. Use with caution.
+
+MAILING LIST
+============
There is a Btrfs mailing list hosted on vger.kernel.org. You can
find details on how to subscribe here:
@@ -49,8 +215,8 @@
- IRC
- ===
+IRC
+===
Discussion of Btrfs also occurs on the #btrfs channel of the Freenode
IRC network.
diff --git a/Documentation/filesystems/ext4.txt b/Documentation/filesystems/ext4.txt
index 34ea4f1..f7cbf57 100644
--- a/Documentation/filesystems/ext4.txt
+++ b/Documentation/filesystems/ext4.txt
@@ -494,6 +494,17 @@
session_write_kbytes This file is read-only and shows the number of
kilobytes of data that have been written to this
filesystem since it was mounted.
+
+ reserved_clusters This is RW file and contains number of reserved
+ clusters in the file system which will be used
+ in the specific situations to avoid costly
+ zeroout, unexpected ENOSPC, or possible data
+ loss. The default is 2% or 4096 clusters,
+ whichever is smaller and this can be changed
+ however it can never exceed number of clusters
+ in the file system. If there is not enough space
+ for the reserved space when mounting the file
+ mount will _not_ fail.
..............................................................................
Ioctls
@@ -587,6 +598,16 @@
bitmaps and inode table, the userspace tool thus
just passes the new number of blocks.
+EXT4_IOC_SWAP_BOOT Swap i_blocks and associated attributes
+ (like i_blocks, i_size, i_flags, ...) from
+ the specified inode with inode
+ EXT4_BOOT_LOADER_INO (#5). This is typically
+ used to store a boot loader in a secure part of
+ the filesystem, where it can't be changed by a
+ normal user by accident.
+ The data blocks of the previous boot loader
+ will be associated with the given inode.
+
..............................................................................
References
diff --git a/Documentation/filesystems/f2fs.txt b/Documentation/filesystems/f2fs.txt
index 8fbd8b4..b91e2f2 100644
--- a/Documentation/filesystems/f2fs.txt
+++ b/Documentation/filesystems/f2fs.txt
@@ -98,8 +98,13 @@
MOUNT OPTIONS
================================================================================
-background_gc_off Turn off cleaning operations, namely garbage collection,
- triggered in background when I/O subsystem is idle.
+background_gc=%s Turn on/off cleaning operations, namely garbage
+ collection, triggered in background when I/O subsystem is
+ idle. If background_gc=on, it will turn on the garbage
+ collection and if background_gc=off, garbage collection
+ will be truned off.
+ Default value for this option is on. So garbage
+ collection is on by default.
disable_roll_forward Disable the roll-forward recovery routine
discard Issue discard/TRIM commands when a segment is cleaned.
no_heap Disable heap-style segment allocation which finds free
@@ -146,7 +151,7 @@
Format options
--------------
--l [label] : Give a volume label, up to 256 unicode name.
+-l [label] : Give a volume label, up to 512 unicode name.
-a [0 or 1] : Split start location of each area for heap-based allocation.
1 is set by default, which performs this.
-o [int] : Set overprovision ratio in percent over volume size.
@@ -156,6 +161,8 @@
-z [int] : Set the number of sections per zone.
1 is set by default.
-e [str] : Set basic extension list. e.g. "mp3,gif,mov"
+-t [0 or 1] : Disable discard command or not.
+ 1 is set by default, which conducts discard.
================================================================================
DESIGN
@@ -175,9 +182,9 @@
align with the zone size <-|
|-> align with the segment size
_________________________________________________________________________
- | | | Node | Segment | Segment | |
- | Superblock | Checkpoint | Address | Info. | Summary | Main |
- | (SB) | (CP) | Table (NAT) | Table (SIT) | Area (SSA) | |
+ | | | Segment | Node | Segment | |
+ | Superblock | Checkpoint | Info. | Address | Summary | Main |
+ | (SB) | (CP) | Table (SIT) | Table (NAT) | Area (SSA) | |
|____________|_____2______|______N______|______N______|______N_____|__N___|
. .
. .
@@ -200,14 +207,14 @@
: It contains file system information, bitmaps for valid NAT/SIT sets, orphan
inode lists, and summary entries of current active segments.
-- Node Address Table (NAT)
- : It is composed of a block address table for all the node blocks stored in
- Main area.
-
- Segment Information Table (SIT)
: It contains segment information such as valid block count and bitmap for the
validity of all the blocks.
+- Node Address Table (NAT)
+ : It is composed of a block address table for all the node blocks stored in
+ Main area.
+
- Segment Summary Area (SSA)
: It contains summary entries which contains the owner information of all the
data and node blocks stored in Main area.
@@ -236,13 +243,13 @@
valid, as shown as below.
+--------+----------+---------+
- | CP | NAT | SIT |
+ | CP | SIT | NAT |
+--------+----------+---------+
. . . .
. . . .
. . . .
+-------+-------+--------+--------+--------+--------+
- | CP #0 | CP #1 | NAT #0 | NAT #1 | SIT #0 | SIT #1 |
+ | CP #0 | CP #1 | SIT #0 | SIT #1 | NAT #0 | NAT #1 |
+-------+-------+--------+--------+--------+--------+
| ^ ^
| | |
diff --git a/Documentation/filesystems/jfs.txt b/Documentation/filesystems/jfs.txt
index f743335..41fd757 100644
--- a/Documentation/filesystems/jfs.txt
+++ b/Documentation/filesystems/jfs.txt
@@ -42,7 +42,7 @@
devices and sparse/thinly-provisioned LUNs. The FITRIM ioctl
command is also available together with the nodiscard option.
The value of minlen specifies the minimum blockcount, when
- a TRIM command to the block device is considered usefull.
+ a TRIM command to the block device is considered useful.
When no value is given to the discard option, it defaults to
64 blocks, which means 256KiB in JFS.
The minlen value of discard overrides the minlen value given
diff --git a/Documentation/filesystems/nfs/00-INDEX b/Documentation/filesystems/nfs/00-INDEX
index 1716874a..66eb6c8 100644
--- a/Documentation/filesystems/nfs/00-INDEX
+++ b/Documentation/filesystems/nfs/00-INDEX
@@ -20,3 +20,5 @@
- introduction to the caching mechanisms in the sunrpc layer.
idmapper.txt
- information for configuring request-keys to be used by idmapper
+knfsd-rpcgss.txt
+ - Information on GSS authentication support in the NFS Server
diff --git a/Documentation/filesystems/nfs/rpc-server-gss.txt b/Documentation/filesystems/nfs/rpc-server-gss.txt
new file mode 100644
index 0000000..716f4be
--- /dev/null
+++ b/Documentation/filesystems/nfs/rpc-server-gss.txt
@@ -0,0 +1,91 @@
+
+rpcsec_gss support for kernel RPC servers
+=========================================
+
+This document gives references to the standards and protocols used to
+implement RPCGSS authentication in kernel RPC servers such as the NFS
+server and the NFS client's NFSv4.0 callback server. (But note that
+NFSv4.1 and higher don't require the client to act as a server for the
+purposes of authentication.)
+
+RPCGSS is specified in a few IETF documents:
+ - RFC2203 v1: http://tools.ietf.org/rfc/rfc2203.txt
+ - RFC5403 v2: http://tools.ietf.org/rfc/rfc5403.txt
+and there is a 3rd version being proposed:
+ - http://tools.ietf.org/id/draft-williams-rpcsecgssv3.txt
+ (At draft n. 02 at the time of writing)
+
+Background
+----------
+
+The RPCGSS Authentication method describes a way to perform GSSAPI
+Authentication for NFS. Although GSSAPI is itself completely mechanism
+agnostic, in many cases only the KRB5 mechanism is supported by NFS
+implementations.
+
+The Linux kernel, at the moment, supports only the KRB5 mechanism, and
+depends on GSSAPI extensions that are KRB5 specific.
+
+GSSAPI is a complex library, and implementing it completely in kernel is
+unwarranted. However GSSAPI operations are fundementally separable in 2
+parts:
+- initial context establishment
+- integrity/privacy protection (signing and encrypting of individual
+ packets)
+
+The former is more complex and policy-independent, but less
+performance-sensitive. The latter is simpler and needs to be very fast.
+
+Therefore, we perform per-packet integrity and privacy protection in the
+kernel, but leave the initial context establishment to userspace. We
+need upcalls to request userspace to perform context establishment.
+
+NFS Server Legacy Upcall Mechanism
+----------------------------------
+
+The classic upcall mechanism uses a custom text based upcall mechanism
+to talk to a custom daemon called rpc.svcgssd that is provide by the
+nfs-utils package.
+
+This upcall mechanism has 2 limitations:
+
+A) It can handle tokens that are no bigger than 2KiB
+
+In some Kerberos deployment GSSAPI tokens can be quite big, up and
+beyond 64KiB in size due to various authorization extensions attacked to
+the Kerberos tickets, that needs to be sent through the GSS layer in
+order to perform context establishment.
+
+B) It does not properly handle creds where the user is member of more
+than a few housand groups (the current hard limit in the kernel is 65K
+groups) due to limitation on the size of the buffer that can be send
+back to the kernel (4KiB).
+
+NFS Server New RPC Upcall Mechanism
+-----------------------------------
+
+The newer upcall mechanism uses RPC over a unix socket to a daemon
+called gss-proxy, implemented by a userspace program called Gssproxy.
+
+The gss_proxy RPC protocol is currently documented here:
+
+ https://fedorahosted.org/gss-proxy/wiki/ProtocolDocumentation
+
+This upcall mechanism uses the kernel rpc client and connects to the gssproxy
+userspace program over a regular unix socket. The gssproxy protocol does not
+suffer from the size limitations of the legacy protocol.
+
+Negotiating Upcall Mechanisms
+-----------------------------
+
+To provide backward compatibility, the kernel defaults to using the
+legacy mechanism. To switch to the new mechanism, gss-proxy must bind
+to /var/run/gssproxy.sock and then write "1" to
+/proc/net/rpc/use-gss-proxy. If gss-proxy dies, it must repeat both
+steps.
+
+Once the upcall mechanism is chosen, it cannot be changed. To prevent
+locking into the legacy mechanisms, the above steps must be performed
+before starting nfsd. Whoever starts nfsd can guarantee this by reading
+from /proc/net/rpc/use-gss-proxy and checking that it contains a
+"1"--the read will block until gss-proxy has done its write to the file.
diff --git a/Documentation/filesystems/porting b/Documentation/filesystems/porting
index 0472c31..206a1bd 100644
--- a/Documentation/filesystems/porting
+++ b/Documentation/filesystems/porting
@@ -441,3 +441,13 @@
two, it gets "is it an O_EXCL or equivalent?" boolean argument. Note that
local filesystems can ignore tha argument - they are guaranteed that the
object doesn't exist. It's remote/distributed ones that might care...
+--
+[mandatory]
+ FS_REVAL_DOT is gone; if you used to have it, add ->d_weak_revalidate()
+in your dentry operations instead.
+--
+[mandatory]
+ vfs_readdir() is gone; switch to iterate_dir() instead
+--
+[mandatory]
+ ->readdir() is gone now; switch to ->iterate()
diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt
index fd8d0d5..fcc22c9 100644
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -473,7 +473,8 @@
enabled.
The /proc/PID/clear_refs is used to reset the PG_Referenced and ACCESSED/YOUNG
-bits on both physical and virtual pages associated with a process.
+bits on both physical and virtual pages associated with a process, and the
+soft-dirty bit on pte (see Documentation/vm/soft-dirty.txt for details).
To clear the bits for all the pages associated with the process
> echo 1 > /proc/PID/clear_refs
@@ -482,6 +483,10 @@
To clear the bits for the file mapped pages associated with the process
> echo 3 > /proc/PID/clear_refs
+
+To clear the soft-dirty bit
+ > echo 4 > /proc/PID/clear_refs
+
Any other value written to /proc/PID/clear_refs will have no effect.
The /proc/pid/pagemap gives the PFN, which can be used to find the pageflags
diff --git a/Documentation/filesystems/qnx6.txt b/Documentation/filesystems/qnx6.txt
index e59f2f0..99e9018 100644
--- a/Documentation/filesystems/qnx6.txt
+++ b/Documentation/filesystems/qnx6.txt
@@ -148,7 +148,7 @@
Bitmap system area
------------------
-The bitmap itself is devided into three parts.
+The bitmap itself is divided into three parts.
First the system area, that is split into two halfs.
Then userspace.
diff --git a/Documentation/filesystems/vfat.txt b/Documentation/filesystems/vfat.txt
index d230dd9..aa1f459 100644
--- a/Documentation/filesystems/vfat.txt
+++ b/Documentation/filesystems/vfat.txt
@@ -150,12 +150,28 @@
device when blocks are freed. This is useful for SSD devices
and sparse/thinly-provisoned LUNs.
-nfs -- This option maintains an index (cache) of directory
- inodes by i_logstart which is used by the nfs-related code to
- improve look-ups.
+nfs=stale_rw|nostale_ro
+ Enable this only if you want to export the FAT filesystem
+ over NFS.
- Enable this only if you want to export the FAT filesystem
- over NFS
+ stale_rw: This option maintains an index (cache) of directory
+ inodes by i_logstart which is used by the nfs-related code to
+ improve look-ups. Full file operations (read/write) over NFS is
+ supported but with cache eviction at NFS server, this could
+ result in ESTALE issues.
+
+ nostale_ro: This option bases the inode number and filehandle
+ on the on-disk location of a file in the MS-DOS directory entry.
+ This ensures that ESTALE will not be returned after a file is
+ evicted from the inode cache. However, it means that operations
+ such as rename, create and unlink could cause filehandles that
+ previously pointed at one file to point at a different file,
+ potentially causing data corruption. For this reason, this
+ option also mounts the filesystem readonly.
+
+ To maintain backward compatibility, '-o nfs' is also accepted,
+ defaulting to stale_rw
+
<bool>: 0,1,yes,no,true,false
@@ -291,7 +307,7 @@
<proceeding files...>
<slot #3, id = 0x43, characters = "h is long">
- <slot #2, id = 0x02, characters = "xtension whic">
+ <slot #2, id = 0x02, characters = "xtension which">
<slot #1, id = 0x01, characters = "My Big File.E">
<directory entry, name = "MYBIGFIL.EXT">
diff --git a/Documentation/filesystems/vfs.txt b/Documentation/filesystems/vfs.txt
index e3869098..f93a882 100644
--- a/Documentation/filesystems/vfs.txt
+++ b/Documentation/filesystems/vfs.txt
@@ -360,6 +360,8 @@
int (*removexattr) (struct dentry *, const char *);
void (*update_time)(struct inode *, struct timespec *, int);
int (*atomic_open)(struct inode *, struct dentry *,
+ int (*tmpfile) (struct inode *, struct dentry *, umode_t);
+} ____cacheline_aligned;
struct file *, unsigned open_flag,
umode_t create_mode, int *opened);
};
@@ -472,6 +474,9 @@
component is negative or needs lookup. Cached positive dentries are
still handled by f_op->open().
+ tmpfile: called in the end of O_TMPFILE open(). Optional, equivalent to
+ atomically creating, opening and unlinking a file in given directory.
+
The Address Space Object
========================
@@ -549,12 +554,11 @@
-------------------------------
This describes how the VFS can manipulate mapping of a file to page cache in
-your filesystem. As of kernel 2.6.22, the following members are defined:
+your filesystem. The following members are defined:
struct address_space_operations {
int (*writepage)(struct page *page, struct writeback_control *wbc);
int (*readpage)(struct file *, struct page *);
- int (*sync_page)(struct page *);
int (*writepages)(struct address_space *, struct writeback_control *);
int (*set_page_dirty)(struct page *page);
int (*readpages)(struct file *filp, struct address_space *mapping,
@@ -566,7 +570,7 @@
loff_t pos, unsigned len, unsigned copied,
struct page *page, void *fsdata);
sector_t (*bmap)(struct address_space *, sector_t);
- int (*invalidatepage) (struct page *, unsigned long);
+ void (*invalidatepage) (struct page *, unsigned int, unsigned int);
int (*releasepage) (struct page *, int);
void (*freepage)(struct page *);
ssize_t (*direct_IO)(int, struct kiocb *, const struct iovec *iov,
@@ -576,6 +580,9 @@
/* migrate the contents of a page to the specified target */
int (*migratepage) (struct page *, struct page *);
int (*launder_page) (struct page *);
+ int (*is_partially_uptodate) (struct page *, read_descriptor_t *,
+ unsigned long);
+ void (*is_dirty_writeback) (struct page *, bool *, bool *);
int (*error_remove_page) (struct mapping *mapping, struct page *page);
int (*swap_activate)(struct file *);
int (*swap_deactivate)(struct file *);
@@ -607,13 +614,6 @@
In this case, the page will be relocated, relocked and if
that all succeeds, ->readpage will be called again.
- sync_page: called by the VM to notify the backing store to perform all
- queued I/O operations for a page. I/O operations for other pages
- associated with this address_space object may also be performed.
-
- This function is optional and is called only for pages with
- PG_Writeback set while waiting for the writeback to complete.
-
writepages: called by the VM to write out pages associated with the
address_space object. If wbc->sync_mode is WBC_SYNC_ALL, then
the writeback_control will specify a range of pages that must be
@@ -685,14 +685,14 @@
invalidatepage: If a page has PagePrivate set, then invalidatepage
will be called when part or all of the page is to be removed
from the address space. This generally corresponds to either a
- truncation or a complete invalidation of the address space
- (in the latter case 'offset' will always be 0).
- Any private data associated with the page should be updated
- to reflect this truncation. If offset is 0, then
- the private data should be released, because the page
- must be able to be completely discarded. This may be done by
- calling the ->releasepage function, but in this case the
- release MUST succeed.
+ truncation, punch hole or a complete invalidation of the address
+ space (in the latter case 'offset' will always be 0 and 'length'
+ will be PAGE_CACHE_SIZE). Any private data associated with the page
+ should be updated to reflect this truncation. If offset is 0 and
+ length is PAGE_CACHE_SIZE, then the private data should be released,
+ because the page must be able to be completely discarded. This may
+ be done by calling the ->releasepage function, but in this case the
+ release MUST succeed.
releasepage: releasepage is called on PagePrivate pages to indicate
that the page should be freed if possible. ->releasepage
@@ -742,6 +742,20 @@
prevent redirtying the page, it is kept locked during the whole
operation.
+ is_partially_uptodate: Called by the VM when reading a file through the
+ pagecache when the underlying blocksize != pagesize. If the required
+ block is up to date then the read can complete without needing the IO
+ to bring the whole page up to date.
+
+ is_dirty_writeback: Called by the VM when attempting to reclaim a page.
+ The VM uses dirty and writeback information to determine if it needs
+ to stall to allow flushers a chance to complete some IO. Ordinarily
+ it can use PageDirty and PageWriteback but some filesystems have
+ more complex state (unstable pages in NFS prevent reclaim) or
+ do not set those flags due to locking problems (jbd). This callback
+ allows a filesystem to indicate to the VM if a page should be
+ treated as dirty or writeback for the purposes of stalling.
+
error_remove_page: normally set to generic_error_remove_page if truncation
is ok for this address space. Used for memory failure handling.
Setting this implies you deal with pages going away under you,
@@ -777,7 +791,7 @@
ssize_t (*write) (struct file *, const char __user *, size_t, loff_t *);
ssize_t (*aio_read) (struct kiocb *, const struct iovec *, unsigned long, loff_t);
ssize_t (*aio_write) (struct kiocb *, const struct iovec *, unsigned long, loff_t);
- int (*readdir) (struct file *, void *, filldir_t);
+ int (*iterate) (struct file *, struct dir_context *);
unsigned int (*poll) (struct file *, struct poll_table_struct *);
long (*unlocked_ioctl) (struct file *, unsigned int, unsigned long);
long (*compat_ioctl) (struct file *, unsigned int, unsigned long);
@@ -815,7 +829,7 @@
aio_write: called by io_submit(2) and other asynchronous I/O operations
- readdir: called when the VFS needs to read the directory contents
+ iterate: called when the VFS needs to read the directory contents
poll: called by the VFS when a process wants to check if there is
activity on this file and (optionally) go to sleep until there
@@ -900,10 +914,9 @@
struct dentry_operations {
int (*d_revalidate)(struct dentry *, unsigned int);
- int (*d_hash)(const struct dentry *, const struct inode *,
- struct qstr *);
- int (*d_compare)(const struct dentry *, const struct inode *,
- const struct dentry *, const struct inode *,
+ int (*d_weak_revalidate)(struct dentry *, unsigned int);
+ int (*d_hash)(const struct dentry *, struct qstr *);
+ int (*d_compare)(const struct dentry *, const struct dentry *,
unsigned int, const char *, const struct qstr *);
int (*d_delete)(const struct dentry *);
void (*d_release)(struct dentry *);
@@ -915,8 +928,13 @@
d_revalidate: called when the VFS needs to revalidate a dentry. This
is called whenever a name look-up finds a dentry in the
- dcache. Most filesystems leave this as NULL, because all their
- dentries in the dcache are valid
+ dcache. Most local filesystems leave this as NULL, because all their
+ dentries in the dcache are valid. Network filesystems are different
+ since things can change on the server without the client necessarily
+ being aware of it.
+
+ This function should return a positive value if the dentry is still
+ valid, and zero or a negative error code if it isn't.
d_revalidate may be called in rcu-walk mode (flags & LOOKUP_RCU).
If in rcu-walk mode, the filesystem must revalidate the dentry without
@@ -927,27 +945,40 @@
If a situation is encountered that rcu-walk cannot handle, return
-ECHILD and it will be called again in ref-walk mode.
+ d_weak_revalidate: called when the VFS needs to revalidate a "jumped" dentry.
+ This is called when a path-walk ends at dentry that was not acquired by
+ doing a lookup in the parent directory. This includes "/", "." and "..",
+ as well as procfs-style symlinks and mountpoint traversal.
+
+ In this case, we are less concerned with whether the dentry is still
+ fully correct, but rather that the inode is still valid. As with
+ d_revalidate, most local filesystems will set this to NULL since their
+ dcache entries are always valid.
+
+ This function has the same return code semantics as d_revalidate.
+
+ d_weak_revalidate is only called after leaving rcu-walk mode.
+
d_hash: called when the VFS adds a dentry to the hash table. The first
dentry passed to d_hash is the parent directory that the name is
- to be hashed into. The inode is the dentry's inode.
+ to be hashed into.
Same locking and synchronisation rules as d_compare regarding
what is safe to dereference etc.
d_compare: called to compare a dentry name with a given name. The first
dentry is the parent of the dentry to be compared, the second is
- the parent's inode, then the dentry and inode (may be NULL) of the
- child dentry. len and name string are properties of the dentry to be
- compared. qstr is the name to compare it with.
+ the child dentry. len and name string are properties of the dentry
+ to be compared. qstr is the name to compare it with.
Must be constant and idempotent, and should not take locks if
- possible, and should not or store into the dentry or inodes.
- Should not dereference pointers outside the dentry or inodes without
+ possible, and should not or store into the dentry.
+ Should not dereference pointers outside the dentry without
lots of care (eg. d_parent, d_inode, d_name should not be used).
However, our vfsmount is pinned, and RCU held, so the dentries and
inodes won't disappear, neither will our sb or filesystem module.
- ->i_sb and ->d_sb may be used.
+ ->d_sb may be used.
It is a tricky calling convention because it needs to be called under
"rcu-walk", ie. without any locks or references on things.
diff --git a/Documentation/filesystems/xfs-self-describing-metadata.txt b/Documentation/filesystems/xfs-self-describing-metadata.txt
new file mode 100644
index 0000000..05aa455
--- /dev/null
+++ b/Documentation/filesystems/xfs-self-describing-metadata.txt
@@ -0,0 +1,350 @@
+XFS Self Describing Metadata
+----------------------------
+
+Introduction
+------------
+
+The largest scalability problem facing XFS is not one of algorithmic
+scalability, but of verification of the filesystem structure. Scalabilty of the
+structures and indexes on disk and the algorithms for iterating them are
+adequate for supporting PB scale filesystems with billions of inodes, however it
+is this very scalability that causes the verification problem.
+
+Almost all metadata on XFS is dynamically allocated. The only fixed location
+metadata is the allocation group headers (SB, AGF, AGFL and AGI), while all
+other metadata structures need to be discovered by walking the filesystem
+structure in different ways. While this is already done by userspace tools for
+validating and repairing the structure, there are limits to what they can
+verify, and this in turn limits the supportable size of an XFS filesystem.
+
+For example, it is entirely possible to manually use xfs_db and a bit of
+scripting to analyse the structure of a 100TB filesystem when trying to
+determine the root cause of a corruption problem, but it is still mainly a
+manual task of verifying that things like single bit errors or misplaced writes
+weren't the ultimate cause of a corruption event. It may take a few hours to a
+few days to perform such forensic analysis, so for at this scale root cause
+analysis is entirely possible.
+
+However, if we scale the filesystem up to 1PB, we now have 10x as much metadata
+to analyse and so that analysis blows out towards weeks/months of forensic work.
+Most of the analysis work is slow and tedious, so as the amount of analysis goes
+up, the more likely that the cause will be lost in the noise. Hence the primary
+concern for supporting PB scale filesystems is minimising the time and effort
+required for basic forensic analysis of the filesystem structure.
+
+
+Self Describing Metadata
+------------------------
+
+One of the problems with the current metadata format is that apart from the
+magic number in the metadata block, we have no other way of identifying what it
+is supposed to be. We can't even identify if it is the right place. Put simply,
+you can't look at a single metadata block in isolation and say "yes, it is
+supposed to be there and the contents are valid".
+
+Hence most of the time spent on forensic analysis is spent doing basic
+verification of metadata values, looking for values that are in range (and hence
+not detected by automated verification checks) but are not correct. Finding and
+understanding how things like cross linked block lists (e.g. sibling
+pointers in a btree end up with loops in them) are the key to understanding what
+went wrong, but it is impossible to tell what order the blocks were linked into
+each other or written to disk after the fact.
+
+Hence we need to record more information into the metadata to allow us to
+quickly determine if the metadata is intact and can be ignored for the purpose
+of analysis. We can't protect against every possible type of error, but we can
+ensure that common types of errors are easily detectable. Hence the concept of
+self describing metadata.
+
+The first, fundamental requirement of self describing metadata is that the
+metadata object contains some form of unique identifier in a well known
+location. This allows us to identify the expected contents of the block and
+hence parse and verify the metadata object. IF we can't independently identify
+the type of metadata in the object, then the metadata doesn't describe itself
+very well at all!
+
+Luckily, almost all XFS metadata has magic numbers embedded already - only the
+AGFL, remote symlinks and remote attribute blocks do not contain identifying
+magic numbers. Hence we can change the on-disk format of all these objects to
+add more identifying information and detect this simply by changing the magic
+numbers in the metadata objects. That is, if it has the current magic number,
+the metadata isn't self identifying. If it contains a new magic number, it is
+self identifying and we can do much more expansive automated verification of the
+metadata object at runtime, during forensic analysis or repair.
+
+As a primary concern, self describing metadata needs some form of overall
+integrity checking. We cannot trust the metadata if we cannot verify that it has
+not been changed as a result of external influences. Hence we need some form of
+integrity check, and this is done by adding CRC32c validation to the metadata
+block. If we can verify the block contains the metadata it was intended to
+contain, a large amount of the manual verification work can be skipped.
+
+CRC32c was selected as metadata cannot be more than 64k in length in XFS and
+hence a 32 bit CRC is more than sufficient to detect multi-bit errors in
+metadata blocks. CRC32c is also now hardware accelerated on common CPUs so it is
+fast. So while CRC32c is not the strongest of possible integrity checks that
+could be used, it is more than sufficient for our needs and has relatively
+little overhead. Adding support for larger integrity fields and/or algorithms
+does really provide any extra value over CRC32c, but it does add a lot of
+complexity and so there is no provision for changing the integrity checking
+mechanism.
+
+Self describing metadata needs to contain enough information so that the
+metadata block can be verified as being in the correct place without needing to
+look at any other metadata. This means it needs to contain location information.
+Just adding a block number to the metadata is not sufficient to protect against
+mis-directed writes - a write might be misdirected to the wrong LUN and so be
+written to the "correct block" of the wrong filesystem. Hence location
+information must contain a filesystem identifier as well as a block number.
+
+Another key information point in forensic analysis is knowing who the metadata
+block belongs to. We already know the type, the location, that it is valid
+and/or corrupted, and how long ago that it was last modified. Knowing the owner
+of the block is important as it allows us to find other related metadata to
+determine the scope of the corruption. For example, if we have a extent btree
+object, we don't know what inode it belongs to and hence have to walk the entire
+filesystem to find the owner of the block. Worse, the corruption could mean that
+no owner can be found (i.e. it's an orphan block), and so without an owner field
+in the metadata we have no idea of the scope of the corruption. If we have an
+owner field in the metadata object, we can immediately do top down validation to
+determine the scope of the problem.
+
+Different types of metadata have different owner identifiers. For example,
+directory, attribute and extent tree blocks are all owned by an inode, whilst
+freespace btree blocks are owned by an allocation group. Hence the size and
+contents of the owner field are determined by the type of metadata object we are
+looking at. The owner information can also identify misplaced writes (e.g.
+freespace btree block written to the wrong AG).
+
+Self describing metadata also needs to contain some indication of when it was
+written to the filesystem. One of the key information points when doing forensic
+analysis is how recently the block was modified. Correlation of set of corrupted
+metadata blocks based on modification times is important as it can indicate
+whether the corruptions are related, whether there's been multiple corruption
+events that lead to the eventual failure, and even whether there are corruptions
+present that the run-time verification is not detecting.
+
+For example, we can determine whether a metadata object is supposed to be free
+space or still allocated if it is still referenced by its owner by looking at
+when the free space btree block that contains the block was last written
+compared to when the metadata object itself was last written. If the free space
+block is more recent than the object and the object's owner, then there is a
+very good chance that the block should have been removed from the owner.
+
+To provide this "written timestamp", each metadata block gets the Log Sequence
+Number (LSN) of the most recent transaction it was modified on written into it.
+This number will always increase over the life of the filesystem, and the only
+thing that resets it is running xfs_repair on the filesystem. Further, by use of
+the LSN we can tell if the corrupted metadata all belonged to the same log
+checkpoint and hence have some idea of how much modification occurred between
+the first and last instance of corrupt metadata on disk and, further, how much
+modification occurred between the corruption being written and when it was
+detected.
+
+Runtime Validation
+------------------
+
+Validation of self-describing metadata takes place at runtime in two places:
+
+ - immediately after a successful read from disk
+ - immediately prior to write IO submission
+
+The verification is completely stateless - it is done independently of the
+modification process, and seeks only to check that the metadata is what it says
+it is and that the metadata fields are within bounds and internally consistent.
+As such, we cannot catch all types of corruption that can occur within a block
+as there may be certain limitations that operational state enforces of the
+metadata, or there may be corruption of interblock relationships (e.g. corrupted
+sibling pointer lists). Hence we still need stateful checking in the main code
+body, but in general most of the per-field validation is handled by the
+verifiers.
+
+For read verification, the caller needs to specify the expected type of metadata
+that it should see, and the IO completion process verifies that the metadata
+object matches what was expected. If the verification process fails, then it
+marks the object being read as EFSCORRUPTED. The caller needs to catch this
+error (same as for IO errors), and if it needs to take special action due to a
+verification error it can do so by catching the EFSCORRUPTED error value. If we
+need more discrimination of error type at higher levels, we can define new
+error numbers for different errors as necessary.
+
+The first step in read verification is checking the magic number and determining
+whether CRC validating is necessary. If it is, the CRC32c is calculated and
+compared against the value stored in the object itself. Once this is validated,
+further checks are made against the location information, followed by extensive
+object specific metadata validation. If any of these checks fail, then the
+buffer is considered corrupt and the EFSCORRUPTED error is set appropriately.
+
+Write verification is the opposite of the read verification - first the object
+is extensively verified and if it is OK we then update the LSN from the last
+modification made to the object, After this, we calculate the CRC and insert it
+into the object. Once this is done the write IO is allowed to continue. If any
+error occurs during this process, the buffer is again marked with a EFSCORRUPTED
+error for the higher layers to catch.
+
+Structures
+----------
+
+A typical on-disk structure needs to contain the following information:
+
+struct xfs_ondisk_hdr {
+ __be32 magic; /* magic number */
+ __be32 crc; /* CRC, not logged */
+ uuid_t uuid; /* filesystem identifier */
+ __be64 owner; /* parent object */
+ __be64 blkno; /* location on disk */
+ __be64 lsn; /* last modification in log, not logged */
+};
+
+Depending on the metadata, this information may be part of a header structure
+separate to the metadata contents, or may be distributed through an existing
+structure. The latter occurs with metadata that already contains some of this
+information, such as the superblock and AG headers.
+
+Other metadata may have different formats for the information, but the same
+level of information is generally provided. For example:
+
+ - short btree blocks have a 32 bit owner (ag number) and a 32 bit block
+ number for location. The two of these combined provide the same
+ information as @owner and @blkno in eh above structure, but using 8
+ bytes less space on disk.
+
+ - directory/attribute node blocks have a 16 bit magic number, and the
+ header that contains the magic number has other information in it as
+ well. hence the additional metadata headers change the overall format
+ of the metadata.
+
+A typical buffer read verifier is structured as follows:
+
+#define XFS_FOO_CRC_OFF offsetof(struct xfs_ondisk_hdr, crc)
+
+static void
+xfs_foo_read_verify(
+ struct xfs_buf *bp)
+{
+ struct xfs_mount *mp = bp->b_target->bt_mount;
+
+ if ((xfs_sb_version_hascrc(&mp->m_sb) &&
+ !xfs_verify_cksum(bp->b_addr, BBTOB(bp->b_length),
+ XFS_FOO_CRC_OFF)) ||
+ !xfs_foo_verify(bp)) {
+ XFS_CORRUPTION_ERROR(__func__, XFS_ERRLEVEL_LOW, mp, bp->b_addr);
+ xfs_buf_ioerror(bp, EFSCORRUPTED);
+ }
+}
+
+The code ensures that the CRC is only checked if the filesystem has CRCs enabled
+by checking the superblock of the feature bit, and then if the CRC verifies OK
+(or is not needed) it verifies the actual contents of the block.
+
+The verifier function will take a couple of different forms, depending on
+whether the magic number can be used to determine the format of the block. In
+the case it can't, the code is structured as follows:
+
+static bool
+xfs_foo_verify(
+ struct xfs_buf *bp)
+{
+ struct xfs_mount *mp = bp->b_target->bt_mount;
+ struct xfs_ondisk_hdr *hdr = bp->b_addr;
+
+ if (hdr->magic != cpu_to_be32(XFS_FOO_MAGIC))
+ return false;
+
+ if (!xfs_sb_version_hascrc(&mp->m_sb)) {
+ if (!uuid_equal(&hdr->uuid, &mp->m_sb.sb_uuid))
+ return false;
+ if (bp->b_bn != be64_to_cpu(hdr->blkno))
+ return false;
+ if (hdr->owner == 0)
+ return false;
+ }
+
+ /* object specific verification checks here */
+
+ return true;
+}
+
+If there are different magic numbers for the different formats, the verifier
+will look like:
+
+static bool
+xfs_foo_verify(
+ struct xfs_buf *bp)
+{
+ struct xfs_mount *mp = bp->b_target->bt_mount;
+ struct xfs_ondisk_hdr *hdr = bp->b_addr;
+
+ if (hdr->magic == cpu_to_be32(XFS_FOO_CRC_MAGIC)) {
+ if (!uuid_equal(&hdr->uuid, &mp->m_sb.sb_uuid))
+ return false;
+ if (bp->b_bn != be64_to_cpu(hdr->blkno))
+ return false;
+ if (hdr->owner == 0)
+ return false;
+ } else if (hdr->magic != cpu_to_be32(XFS_FOO_MAGIC))
+ return false;
+
+ /* object specific verification checks here */
+
+ return true;
+}
+
+Write verifiers are very similar to the read verifiers, they just do things in
+the opposite order to the read verifiers. A typical write verifier:
+
+static void
+xfs_foo_write_verify(
+ struct xfs_buf *bp)
+{
+ struct xfs_mount *mp = bp->b_target->bt_mount;
+ struct xfs_buf_log_item *bip = bp->b_fspriv;
+
+ if (!xfs_foo_verify(bp)) {
+ XFS_CORRUPTION_ERROR(__func__, XFS_ERRLEVEL_LOW, mp, bp->b_addr);
+ xfs_buf_ioerror(bp, EFSCORRUPTED);
+ return;
+ }
+
+ if (!xfs_sb_version_hascrc(&mp->m_sb))
+ return;
+
+
+ if (bip) {
+ struct xfs_ondisk_hdr *hdr = bp->b_addr;
+ hdr->lsn = cpu_to_be64(bip->bli_item.li_lsn);
+ }
+ xfs_update_cksum(bp->b_addr, BBTOB(bp->b_length), XFS_FOO_CRC_OFF);
+}
+
+This will verify the internal structure of the metadata before we go any
+further, detecting corruptions that have occurred as the metadata has been
+modified in memory. If the metadata verifies OK, and CRCs are enabled, we then
+update the LSN field (when it was last modified) and calculate the CRC on the
+metadata. Once this is done, we can issue the IO.
+
+Inodes and Dquots
+-----------------
+
+Inodes and dquots are special snowflakes. They have per-object CRC and
+self-identifiers, but they are packed so that there are multiple objects per
+buffer. Hence we do not use per-buffer verifiers to do the work of per-object
+verification and CRC calculations. The per-buffer verifiers simply perform basic
+identification of the buffer - that they contain inodes or dquots, and that
+there are magic numbers in all the expected spots. All further CRC and
+verification checks are done when each inode is read from or written back to the
+buffer.
+
+The structure of the verifiers and the identifiers checks is very similar to the
+buffer code described above. The only difference is where they are called. For
+example, inode read verification is done in xfs_iread() when the inode is first
+read out of the buffer and the struct xfs_inode is instantiated. The inode is
+already extensively verified during writeback in xfs_iflush_int, so the only
+addition here is to add the LSN and CRC to the inode as it is copied back into
+the buffer.
+
+XXX: inode unlinked list modification doesn't recalculate the inode CRC! None of
+the unlinked list modifications check or update CRCs, neither during unlink nor
+log recovery. So, it's gone unnoticed until now. This won't matter immediately -
+repair will probably complain about it - but it needs to be fixed.
+
diff --git a/Documentation/filesystems/xfs.txt b/Documentation/filesystems/xfs.txt
index 3e4b3dd..12525b1 100644
--- a/Documentation/filesystems/xfs.txt
+++ b/Documentation/filesystems/xfs.txt
@@ -18,6 +18,8 @@
=============
When mounting an XFS filesystem, the following options are accepted.
+For boolean mount options, the names with the (*) suffix is the
+default behaviour.
allocsize=size
Sets the buffered I/O end-of-file preallocation size when
@@ -25,94 +27,128 @@
Valid values for this option are page size (typically 4KiB)
through to 1GiB, inclusive, in power-of-2 increments.
- attr2/noattr2
- The options enable/disable (default is disabled for backward
- compatibility on-disk) an "opportunistic" improvement to be
- made in the way inline extended attributes are stored on-disk.
- When the new form is used for the first time (by setting or
- removing extended attributes) the on-disk superblock feature
- bit field will be updated to reflect this format being in use.
+ The default behaviour is for dynamic end-of-file
+ preallocation size, which uses a set of heuristics to
+ optimise the preallocation size based on the current
+ allocation patterns within the file and the access patterns
+ to the file. Specifying a fixed allocsize value turns off
+ the dynamic behaviour.
- barrier
- Enables the use of block layer write barriers for writes into
- the journal and unwritten extent conversion. This allows for
- drive level write caching to be enabled, for devices that
- support write barriers.
+ attr2
+ noattr2
+ The options enable/disable an "opportunistic" improvement to
+ be made in the way inline extended attributes are stored
+ on-disk. When the new form is used for the first time when
+ attr2 is selected (either when setting or removing extended
+ attributes) the on-disk superblock feature bit field will be
+ updated to reflect this format being in use.
+
+ The default behaviour is determined by the on-disk feature
+ bit indicating that attr2 behaviour is active. If either
+ mount option it set, then that becomes the new default used
+ by the filesystem.
+
+ CRC enabled filesystems always use the attr2 format, and so
+ will reject the noattr2 mount option if it is set.
+
+ barrier (*)
+ nobarrier
+ Enables/disables the use of block layer write barriers for
+ writes into the journal and for data integrity operations.
+ This allows for drive level write caching to be enabled, for
+ devices that support write barriers.
discard
- Issue command to let the block device reclaim space freed by the
- filesystem. This is useful for SSD devices, thinly provisioned
- LUNs and virtual machine images, but may have a performance
- impact.
+ nodiscard (*)
+ Enable/disable the issuing of commands to let the block
+ device reclaim space freed by the filesystem. This is
+ useful for SSD devices, thinly provisioned LUNs and virtual
+ machine images, but may have a performance impact.
- dmapi
- Enable the DMAPI (Data Management API) event callouts.
- Use with the "mtpt" option.
+ Note: It is currently recommended that you use the fstrim
+ application to discard unused blocks rather than the discard
+ mount option because the performance impact of this option
+ is quite severe.
- grpid/bsdgroups and nogrpid/sysvgroups
- These options define what group ID a newly created file gets.
- When grpid is set, it takes the group ID of the directory in
- which it is created; otherwise (the default) it takes the fsgid
- of the current process, unless the directory has the setgid bit
- set, in which case it takes the gid from the parent directory,
- and also gets the setgid bit set if it is a directory itself.
+ grpid/bsdgroups
+ nogrpid/sysvgroups (*)
+ These options define what group ID a newly created file
+ gets. When grpid is set, it takes the group ID of the
+ directory in which it is created; otherwise it takes the
+ fsgid of the current process, unless the directory has the
+ setgid bit set, in which case it takes the gid from the
+ parent directory, and also gets the setgid bit set if it is
+ a directory itself.
- ihashsize=value
- In memory inode hashes have been removed, so this option has
- no function as of August 2007. Option is deprecated.
+ filestreams
+ Make the data allocator use the filestreams allocation mode
+ across the entire filesystem rather than just on directories
+ configured to use it.
- ikeep/noikeep
- When ikeep is specified, XFS does not delete empty inode clusters
- and keeps them around on disk. ikeep is the traditional XFS
- behaviour. When noikeep is specified, empty inode clusters
- are returned to the free space pool. The default is noikeep for
- non-DMAPI mounts, while ikeep is the default when DMAPI is in use.
-
- inode64
- Indicates that XFS is allowed to create inodes at any location
- in the filesystem, including those which will result in inode
- numbers occupying more than 32 bits of significance. This is
- the default allocation option. Applications which do not handle
- inode numbers bigger than 32 bits, should use inode32 option.
+ ikeep
+ noikeep (*)
+ When ikeep is specified, XFS does not delete empty inode
+ clusters and keeps them around on disk. When noikeep is
+ specified, empty inode clusters are returned to the free
+ space pool.
inode32
- Indicates that XFS is limited to create inodes at locations which
- will not result in inode numbers with more than 32 bits of
- significance. This is provided for backwards compatibility, since
- 64 bits inode numbers might cause problems for some applications
- that cannot handle large inode numbers.
+ inode64 (*)
+ When inode32 is specified, it indicates that XFS limits
+ inode creation to locations which will not result in inode
+ numbers with more than 32 bits of significance.
- largeio/nolargeio
+ When inode64 is specified, it indicates that XFS is allowed
+ to create inodes at any location in the filesystem,
+ including those which will result in inode numbers occupying
+ more than 32 bits of significance.
+
+ inode32 is provided for backwards compatibility with older
+ systems and applications, since 64 bits inode numbers might
+ cause problems for some applications that cannot handle
+ large inode numbers. If applications are in use which do
+ not handle inode numbers bigger than 32 bits, the inode32
+ option should be specified.
+
+
+ largeio
+ nolargeio (*)
If "nolargeio" is specified, the optimal I/O reported in
- st_blksize by stat(2) will be as small as possible to allow user
- applications to avoid inefficient read/modify/write I/O.
- If "largeio" specified, a filesystem that has a "swidth" specified
- will return the "swidth" value (in bytes) in st_blksize. If the
- filesystem does not have a "swidth" specified but does specify
- an "allocsize" then "allocsize" (in bytes) will be returned
- instead.
- If neither of these two options are specified, then filesystem
- will behave as if "nolargeio" was specified.
+ st_blksize by stat(2) will be as small as possible to allow
+ user applications to avoid inefficient read/modify/write
+ I/O. This is typically the page size of the machine, as
+ this is the granularity of the page cache.
+
+ If "largeio" specified, a filesystem that was created with a
+ "swidth" specified will return the "swidth" value (in bytes)
+ in st_blksize. If the filesystem does not have a "swidth"
+ specified but does specify an "allocsize" then "allocsize"
+ (in bytes) will be returned instead. Otherwise the behaviour
+ is the same as if "nolargeio" was specified.
logbufs=value
- Set the number of in-memory log buffers. Valid numbers range
- from 2-8 inclusive.
- The default value is 8 buffers for filesystems with a
- blocksize of 64KiB, 4 buffers for filesystems with a blocksize
- of 32KiB, 3 buffers for filesystems with a blocksize of 16KiB
- and 2 buffers for all other configurations. Increasing the
- number of buffers may increase performance on some workloads
- at the cost of the memory used for the additional log buffers
- and their associated control structures.
+ Set the number of in-memory log buffers. Valid numbers
+ range from 2-8 inclusive.
+
+ The default value is 8 buffers.
+
+ If the memory cost of 8 log buffers is too high on small
+ systems, then it may be reduced at some cost to performance
+ on metadata intensive workloads. The logbsize option below
+ controls the size of each buffer and so is also relevent to
+ this case.
logbsize=value
- Set the size of each in-memory log buffer.
- Size may be specified in bytes, or in kilobytes with a "k" suffix.
- Valid sizes for version 1 and version 2 logs are 16384 (16k) and
- 32768 (32k). Valid sizes for version 2 logs also include
- 65536 (64k), 131072 (128k) and 262144 (256k).
- The default value for machines with more than 32MiB of memory
- is 32768, machines with less memory use 16384 by default.
+ Set the size of each in-memory log buffer. The size may be
+ specified in bytes, or in kilobytes with a "k" suffix.
+ Valid sizes for version 1 and version 2 logs are 16384 (16k)
+ and 32768 (32k). Valid sizes for version 2 logs also
+ include 65536 (64k), 131072 (128k) and 262144 (256k). The
+ logbsize must be an integer multiple of the log
+ stripe unit configured at mkfs time.
+
+ The default value for for version 1 logs is 32768, while the
+ default value for version 2 logs is MAX(32768, log_sunit).
logdev=device and rtdev=device
Use an external log (metadata journal) and/or real-time device.
@@ -121,16 +157,11 @@
optional, and the log section can be separate from the data
section or contained within it.
- mtpt=mountpoint
- Use with the "dmapi" option. The value specified here will be
- included in the DMAPI mount event, and should be the path of
- the actual mountpoint that is used.
-
noalign
- Data allocations will not be aligned at stripe unit boundaries.
-
- noatime
- Access timestamps are not updated when a file is read.
+ Data allocations will not be aligned at stripe unit
+ boundaries. This is only relevant to filesystems created
+ with non-zero data alignment parameters (sunit, swidth) by
+ mkfs.
norecovery
The filesystem will be mounted without running log recovery.
@@ -141,8 +172,14 @@
the mount will fail.
nouuid
- Don't check for double mounted file systems using the file system uuid.
- This is useful to mount LVM snapshot volumes.
+ Don't check for double mounted file systems using the file
+ system uuid. This is useful to mount LVM snapshot volumes,
+ and often used in combination with "norecovery" for mounting
+ read-only snapshots.
+
+ noquota
+ Forcibly turns off all quota accounting and enforcement
+ within the filesystem.
uquota/usrquota/uqnoenforce/quota
User disk quota accounting enabled, and limits (optionally)
@@ -157,24 +194,64 @@
enforced. Refer to xfs_quota(8) for further details.
sunit=value and swidth=value
- Used to specify the stripe unit and width for a RAID device or
- a stripe volume. "value" must be specified in 512-byte block
- units.
- If this option is not specified and the filesystem was made on
- a stripe volume or the stripe width or unit were specified for
- the RAID device at mkfs time, then the mount system call will
- restore the value from the superblock. For filesystems that
- are made directly on RAID devices, these options can be used
- to override the information in the superblock if the underlying
- disk layout changes after the filesystem has been created.
- The "swidth" option is required if the "sunit" option has been
- specified, and must be a multiple of the "sunit" value.
+ Used to specify the stripe unit and width for a RAID device
+ or a stripe volume. "value" must be specified in 512-byte
+ block units. These options are only relevant to filesystems
+ that were created with non-zero data alignment parameters.
+
+ The sunit and swidth parameters specified must be compatible
+ with the existing filesystem alignment characteristics. In
+ general, that means the only valid changes to sunit are
+ increasing it by a power-of-2 multiple. Valid swidth values
+ are any integer multiple of a valid sunit value.
+
+ Typically the only time these mount options are necessary if
+ after an underlying RAID device has had it's geometry
+ modified, such as adding a new disk to a RAID5 lun and
+ reshaping it.
swalloc
Data allocations will be rounded up to stripe width boundaries
when the current end of file is being extended and the file
size is larger than the stripe width size.
+ wsync
+ When specified, all filesystem namespace operations are
+ executed synchronously. This ensures that when the namespace
+ operation (create, unlink, etc) completes, the change to the
+ namespace is on stable storage. This is useful in HA setups
+ where failover must not result in clients seeing
+ inconsistent namespace presentation during or after a
+ failover event.
+
+
+Deprecated Mount Options
+========================
+
+ delaylog/nodelaylog
+ Delayed logging is the only logging method that XFS supports
+ now, so these mount options are now ignored.
+
+ Due for removal in 3.12.
+
+ ihashsize=value
+ In memory inode hashes have been removed, so this option has
+ no function as of August 2007. Option is deprecated.
+
+ Due for removal in 3.12.
+
+ irixsgid
+ This behaviour is now controlled by a sysctl, so the mount
+ option is ignored.
+
+ Due for removal in 3.12.
+
+ osyncisdsync
+ osyncisosync
+ O_SYNC and O_DSYNC are fully supported, so there is no need
+ for these options any more.
+
+ Due for removal in 3.12.
sysctls
=======
@@ -186,15 +263,20 @@
in /proc/fs/xfs/stat. It then immediately resets to "0".
fs.xfs.xfssyncd_centisecs (Min: 100 Default: 3000 Max: 720000)
- The interval at which the xfssyncd thread flushes metadata
- out to disk. This thread will flush log activity out, and
- do some processing on unlinked inodes.
+ The interval at which the filesystem flushes metadata
+ out to disk and runs internal cache cleanup routines.
- fs.xfs.xfsbufd_centisecs (Min: 50 Default: 100 Max: 3000)
- The interval at which xfsbufd scans the dirty metadata buffers list.
+ fs.xfs.filestream_centisecs (Min: 1 Default: 3000 Max: 360000)
+ The interval at which the filesystem ages filestreams cache
+ references and returns timed-out AGs back to the free stream
+ pool.
- fs.xfs.age_buffer_centisecs (Min: 100 Default: 1500 Max: 720000)
- The age at which xfsbufd flushes dirty metadata buffers to disk.
+ fs.xfs.speculative_prealloc_lifetime
+ (Units: seconds Min: 1 Default: 300 Max: 86400)
+ The interval at which the background scanning for inodes
+ with unused speculative preallocation runs. The scan
+ removes unused preallocation from clean inodes and releases
+ the unused space back to the free pool.
fs.xfs.error_level (Min: 0 Default: 3 Max: 11)
A volume knob for error reporting when internal errors occur.
@@ -251,9 +333,31 @@
by the xfs_io(8) chattr command on a directory to be
inherited by files in that directory.
+ fs.xfs.inherit_nodefrag (Min: 0 Default: 1 Max: 1)
+ Setting this to "1" will cause the "nodefrag" flag set
+ by the xfs_io(8) chattr command on a directory to be
+ inherited by files in that directory.
+
fs.xfs.rotorstep (Min: 1 Default: 1 Max: 256)
In "inode32" allocation mode, this option determines how many
files the allocator attempts to allocate in the same allocation
group before moving to the next allocation group. The intent
is to control the rate at which the allocator moves between
allocation groups when allocating extents for new files.
+
+Deprecated Sysctls
+==================
+
+ fs.xfs.xfsbufd_centisecs (Min: 50 Default: 100 Max: 3000)
+ Dirty metadata is now tracked by the log subsystem and
+ flushing is driven by log space and idling demands. The
+ xfsbufd no longer exists, so this syctl does nothing.
+
+ Due for removal in 3.14.
+
+ fs.xfs.age_buffer_centisecs (Min: 100 Default: 1500 Max: 720000)
+ Dirty metadata is now tracked by the log subsystem and
+ flushing is driven by log space and idling demands. The
+ xfsbufd no longer exists, so this syctl does nothing.
+
+ Due for removal in 3.14.
diff --git a/Documentation/fmc/00-INDEX b/Documentation/fmc/00-INDEX
new file mode 100644
index 0000000..431c695
--- /dev/null
+++ b/Documentation/fmc/00-INDEX
@@ -0,0 +1,38 @@
+
+Documentation in this directory comes from sections of the manual we
+wrote for the externally-developed fmc-bus package. The complete
+manual as of today (2013-02) is available in PDF format at
+http://www.ohwr.org/projects/fmc-bus/files
+
+00-INDEX
+ - this file.
+
+FMC-and-SDB.txt
+ - What are FMC and SDB, basic concepts for this framework
+
+API.txt
+ - The functions that are exported by the bus driver
+
+parameters.txt
+ - The module parameters
+
+carrier.txt
+ - writing a carrier (a device)
+
+mezzanine.txt
+ - writing code for your mezzanine (a driver)
+
+identifiers.txt
+ - how identification and matching works
+
+fmc-fakedev.txt
+ - about drivers/fmc/fmc-fakedev.ko
+
+fmc-trivial.txt
+ - about drivers/fmc/fmc-trivial.ko
+
+fmc-write-eeprom.txt
+ - about drivers/fmc/fmc-write-eeprom.ko
+
+fmc-chardev.txt
+ - about drivers/fmc/fmc-chardev.ko
diff --git a/Documentation/fmc/API.txt b/Documentation/fmc/API.txt
new file mode 100644
index 0000000..06b06b9
--- /dev/null
+++ b/Documentation/fmc/API.txt
@@ -0,0 +1,47 @@
+Functions Exported by fmc.ko
+****************************
+
+The FMC core exports the usual 4 functions that are needed for a bus to
+work, and a few more:
+
+ int fmc_driver_register(struct fmc_driver *drv);
+ void fmc_driver_unregister(struct fmc_driver *drv);
+ int fmc_device_register(struct fmc_device *fmc);
+ void fmc_device_unregister(struct fmc_device *fmc);
+
+ int fmc_device_register_n(struct fmc_device **fmc, int n);
+ void fmc_device_unregister_n(struct fmc_device **fmc, int n);
+
+ uint32_t fmc_readl(struct fmc_device *fmc, int offset);
+ void fmc_writel(struct fmc_device *fmc, uint32_t val, int off);
+ void *fmc_get_drvdata(struct fmc_device *fmc);
+ void fmc_set_drvdata(struct fmc_device *fmc, void *data);
+
+ int fmc_reprogram(struct fmc_device *f, struct fmc_driver *d, char *gw,
+ int sdb_entry);
+
+The data structure that describe a device is detailed in *note FMC
+Device::, the one that describes a driver is detailed in *note FMC
+Driver::. Please note that structures of type fmc_device must be
+allocated by the caller, but must not be released after unregistering.
+The fmc-bus itself takes care of releasing the structure when their use
+count reaches zero - actually, the device model does that in lieu of us.
+
+The functions to register and unregister n devices are meant to be used
+by carriers that host more than one mezzanine. The devices must all be
+registered at the same time because if the FPGA is reprogrammed, all
+devices in the array are affected. Usually, the driver matching the
+first device will reprogram the FPGA, so other devices must know they
+are already driven by a reprogrammed FPGA.
+
+If a carrier hosts slots that are driven by different FPGA devices, it
+should register as a group only mezzanines that are driven by the same
+FPGA, for the reason outlined above.
+
+Finally, the fmc_reprogram function calls the reprogram method (see
+*note The API Offered by Carriers:: and also scans the memory area for
+an SDB tree. You can pass -1 as sdb_entry to disable such scan.
+Otherwise, the function fails if no tree is found at the specified
+entry point. The function is meant to factorize common code, and by
+the time you read this it is already used by the spec-sw and fine-delay
+modules.
diff --git a/Documentation/fmc/FMC-and-SDB.txt b/Documentation/fmc/FMC-and-SDB.txt
new file mode 100644
index 0000000..fa14e0b
--- /dev/null
+++ b/Documentation/fmc/FMC-and-SDB.txt
@@ -0,0 +1,88 @@
+
+FMC (FPGA Mezzanine Card) is the standard we use for our I/O devices,
+in the context of White Rabbit and related hardware.
+
+In our I/O environments we need to write drivers for each mezzanine
+card, and such drivers must work regardless of the carrier being used.
+To achieve this, we abstract the FMC interface.
+
+We have a carrier for PCI-E called SPEC and one for VME called SVEC,
+but more are planned. Also, we support stand-alone devices (usually
+plugged on a SPEC card), controlled through Etherbone, developed by GSI.
+
+Code and documentation for the FMC bus was born as part of the spec-sw
+project, but now it lives in its own project. Other projects, i.e.
+software support for the various carriers, should include this as a
+submodule.
+
+The most up to date version of code and documentation is always
+available from the repository you can clone from:
+
+ git://ohwr.org/fmc-projects/fmc-bus.git (read-only)
+ git@ohwr.org:fmc-projects/fmc-bus.git (read-write for developers)
+
+Selected versions of the documentation, as well as complete tar
+archives for selected revisions are placed to the Files section of the
+project: `http://www.ohwr.org/projects/fmc-bus/files'
+
+
+What is FMC
+***********
+
+FMC, as said, stands for "FPGA Mezzanine Card". It is a standard
+developed by the VME consortium called VITA (VMEbus International Trade
+Association and ratified by ANSI, the American National Standard
+Institute. The official documentation is called "ANSI-VITA 57.1".
+
+The FMC card is an almost square PCB, around 70x75 millimeters, that is
+called mezzanine in this document. It usually lives plugged into
+another PCB for power supply and control; such bigger circuit board is
+called carrier from now on, and a single carrier may host more than one
+mezzanine.
+
+In the typical application the mezzanine is mostly analog while the
+carrier is mostly digital, and hosts an FPGA that must be configured to
+match the specific mezzanine and the desired application. Thus, you may
+need to load different FPGA images to drive different instances of the
+same mezzanine.
+
+FMC, as such, is not a bus in the usual meaning of the term, because
+most carriers have only one connector, and carriers with several
+connectors have completely separate electrical connections to them.
+This package, however, implements a bus as a software abstraction.
+
+
+What is SDB
+***********
+
+SDB (Self Describing Bus) is a set of data structures that we use for
+enumerating the internal structure of an FPGA image. We also use it as
+a filesystem inside the FMC EEPROM.
+
+SDB is not mandatory for use of this FMC kernel bus, but if you have SDB
+this package can make good use of it. SDB itself is developed in the
+fpga-config-space OHWR project. The link to the repository is
+`git://ohwr.org/hdl-core-lib/fpga-config-space.git' and what is used in
+this project lives in the sdbfs subdirectory in there.
+
+SDB support for FMC is described in *note FMC Identification:: and
+*note SDB Support::
+
+
+SDB Support
+***********
+
+The fmc.ko bus driver exports a few functions to help drivers taking
+advantage of the SDB information that may be present in your own FPGA
+memory image.
+
+The module exports the following functions, in the special header
+<linux/fmc-sdb.h>. The linux/ prefix in the name is there because we
+plan to submit it upstream in the future, and don't want to force
+changes on our drivers if that happens.
+
+ int fmc_scan_sdb_tree(struct fmc_device *fmc, unsigned long address);
+ void fmc_show_sdb_tree(struct fmc_device *fmc);
+ signed long fmc_find_sdb_device(struct sdb_array *tree, uint64_t vendor,
+ uint32_t device, unsigned long *sz);
+ int fmc_free_sdb_tree(struct fmc_device *fmc);
diff --git a/Documentation/fmc/carrier.txt b/Documentation/fmc/carrier.txt
new file mode 100644
index 0000000..173f6d6
--- /dev/null
+++ b/Documentation/fmc/carrier.txt
@@ -0,0 +1,311 @@
+FMC Device
+**********
+
+Within the Linux bus framework, the FMC device is created and
+registered by the carrier driver. For example, the PCI driver for the
+SPEC card fills a data structure for each SPEC that it drives, and
+registers an associated FMC device for each card. The SVEC driver can
+do exactly the same for the VME carrier (actually, it should do it
+twice, because the SVEC carries two FMC mezzanines). Similarly, an
+Etherbone driver will be able to register its own FMC devices, offering
+communication primitives through frame exchange.
+
+The contents of the EEPROM within the FMC are used for identification
+purposes, i.e. for matching the device with its own driver. For this
+reason the device structure includes a complete copy of the EEPROM
+(actually, the carrier driver may choose whether or not to return it -
+for example we most likely won't have the whole EEPROM available for
+Etherbone devices.
+
+The following listing shows the current structure defining a device.
+Please note that all the machinery is in place but some details may
+still change in the future. For this reason, there is a version field
+at the beginning of the structure. As usual, the minor number will
+change for compatible changes (like a new flag) and the major number
+will increase when an incompatible change happens (for example, a
+change in layout of some fmc data structures). Device writers should
+just set it to the value FMC_VERSION, and be ready to get back -EINVAL
+at registration time.
+
+ struct fmc_device {
+ unsigned long version;
+ unsigned long flags;
+ struct module *owner; /* char device must pin it */
+ struct fmc_fru_id id; /* for EEPROM-based match */
+ struct fmc_operations *op; /* carrier-provided */
+ int irq; /* according to host bus. 0 == none */
+ int eeprom_len; /* Usually 8kB, may be less */
+ int eeprom_addr; /* 0x50, 0x52 etc */
+ uint8_t *eeprom; /* Full contents or leading part */
+ char *carrier_name; /* "SPEC" or similar, for special use */
+ void *carrier_data; /* "struct spec *" or equivalent */
+ __iomem void *fpga_base; /* May be NULL (Etherbone) */
+ __iomem void *slot_base; /* Set by the driver */
+ struct fmc_device **devarray; /* Allocated by the bus */
+ int slot_id; /* Index in the slot array */
+ int nr_slots; /* Number of slots in this carrier */
+ unsigned long memlen; /* Used for the char device */
+ struct device dev; /* For Linux use */
+ struct device *hwdev; /* The underlying hardware device */
+ unsigned long sdbfs_entry;
+ struct sdb_array *sdb;
+ uint32_t device_id; /* Filled by the device */
+ char *mezzanine_name; /* Defaults to ``fmc'' */
+ void *mezzanine_data;
+ };
+
+The meaning of most fields is summarized in the code comment above.
+
+The following fields must be filled by the carrier driver before
+registration:
+
+ * version: must be set to FMC_VERSION.
+
+ * owner: set to MODULE_OWNER.
+
+ * op: the operations to act on the device.
+
+ * irq: number for the mezzanine; may be zero.
+
+ * eeprom_len: length of the following array.
+
+ * eeprom_addr: 0x50 for first mezzanine and so on.
+
+ * eeprom: the full content of the I2C EEPROM.
+
+ * carrier_name.
+
+ * carrier_data: a unique pointer for the carrier.
+
+ * fpga_base: the I/O memory address (may be NULL).
+
+ * slot_id: the index of this slot (starting from zero).
+
+ * memlen: if fpga_base is valid, the length of I/O memory.
+
+ * hwdev: to be used in some dev_err() calls.
+
+ * device_id: a slot-specific unique integer number.
+
+
+Please note that the carrier should read its own EEPROM memory before
+registering the device, as well as fill all other fields listed above.
+
+The following fields should not be assigned, because they are filled
+later by either the bus or the device driver:
+
+ * flags.
+
+ * fru_id: filled by the bus, parsing the eeprom.
+
+ * slot_base: filled and used by the driver, if useful to it.
+
+ * devarray: an array og all mezzanines driven by a singe FPGA.
+
+ * nr_slots: set by the core at registration time.
+
+ * dev: used by Linux.
+
+ * sdb: FPGA contents, scanned according to driver's directions.
+
+ * sdbfs_entry: SDB entry point in EEPROM: autodetected.
+
+ * mezzanine_data: available for the driver.
+
+ * mezzanine_name: filled by fmc-bus during identification.
+
+
+Note: mezzanine_data may be redundant, because Linux offers the drvdata
+approach, so the field may be removed in later versions of this bus
+implementation.
+
+As I write this, she SPEC carrier is already completely functional in
+the fmc-bus environment, and is a good reference to look at.
+
+
+The API Offered by Carriers
+===========================
+
+The carrier provides a number of methods by means of the
+`fmc_operations' structure, which currently is defined like this
+(again, it is a moving target, please refer to the header rather than
+this document):
+
+ struct fmc_operations {
+ uint32_t (*readl)(struct fmc_device *fmc, int offset);
+ void (*writel)(struct fmc_device *fmc, uint32_t value, int offset);
+ int (*reprogram)(struct fmc_device *f, struct fmc_driver *d, char *gw);
+ int (*validate)(struct fmc_device *fmc, struct fmc_driver *drv);
+ int (*irq_request)(struct fmc_device *fmc, irq_handler_t h,
+ char *name, int flags);
+ void (*irq_ack)(struct fmc_device *fmc);
+ int (*irq_free)(struct fmc_device *fmc);
+ int (*gpio_config)(struct fmc_device *fmc, struct fmc_gpio *gpio,
+ int ngpio);
+ int (*read_ee)(struct fmc_device *fmc, int pos, void *d, int l);
+ int (*write_ee)(struct fmc_device *fmc, int pos, const void *d, int l);
+ };
+
+The individual methods perform the following tasks:
+
+`readl'
+`writel'
+ These functions access FPGA registers by whatever means the
+ carrier offers. They are not expected to fail, and most of the time
+ they will just make a memory access to the host bus. If the
+ carrier provides a fpga_base pointer, the driver may use direct
+ access through that pointer. For this reason the header offers the
+ inline functions fmc_readl and fmc_writel that access fpga_base if
+ the respective method is NULL. A driver that wants to be portable
+ and efficient should use fmc_readl and fmc_writel. For Etherbone,
+ or other non-local carriers, error-management is still to be
+ defined.
+
+`validate'
+ Module parameters are used to manage different applications for
+ two or more boards of the same kind. Validation is based on the
+ busid module parameter, if provided, and returns the matching
+ index in the associated array. See *note Module Parameters:: in in
+ doubt. If no match is found, `-ENOENT' is returned; if the user
+ didn't pass `busid=', all devices will pass validation. The value
+ returned by the validate method can be used as index into other
+ parameters (for example, some drivers use the `lm32=' parameter in
+ this way). Such "generic parameters" are documented in *note
+ Module Parameters::, below. The validate method is used by
+ `fmc-trivial.ko', described in *note fmc-trivial::.
+
+`reprogram'
+ The carrier enumerates FMC devices by loading a standard (or
+ golden) FPGA binary that allows EEPROM access. Each driver, then,
+ will need to reprogram the FPGA by calling this function. If the
+ name argument is NULL, the carrier should reprogram the golden
+ binary. If the gateware name has been overridden through module
+ parameters (in a carrier-specific way) the file loaded will match
+ the parameters. Per-device gateware names can be specified using
+ the `gateware=' parameter, see *note Module Parameters::. Note:
+ Clients should call rhe new helper, fmc_reprogram, which both
+ calls this method and parse the SDB tree of the FPGA.
+
+`irq_request'
+`irq_ack'
+`irq_free'
+ Interrupt management is carrier-specific, so it is abstracted as
+ operations. The interrupt number is listed in the device
+ structure, and for the mezzanine driver the number is only
+ informative. The handler will receive the fmc pointer as dev_id;
+ the flags argument is passed to the Linux request_irq function,
+ but fmc-specific flags may be added in the future. You'll most
+ likely want to pass the `IRQF_SHARED' flag.
+
+`gpio_config'
+ The method allows to configure a GPIO pin in the carrier, and read
+ its current value if it is configured as input. See *note The GPIO
+ Abstraction:: for details.
+
+`read_ee'
+`write_ee'
+ Read or write the EEPROM. The functions are expected to be only
+ called before reprogramming and the carrier should refuse them
+ with `ENODEV' after reprogramming. The offset is expected to be
+ within 8kB (the current size), but addresses up to 1MB are
+ reserved to fit bigger I2C devices in the future. Carriers may
+ offer access to other internal flash memories using these same
+ methods: for example the SPEC driver may define that its carrier
+ I2C memory is seen at offset 1M and the internal SPI flash is seen
+ at offset 16M. This multiplexing of several flash memories in the
+ same address space is is carrier-specific and should only be used
+ by a driver that has verified the `carrier_name' field.
+
+
+
+The GPIO Abstraction
+====================
+
+Support for GPIO pins in the fmc-bus environment is not very
+straightforward and deserves special discussion.
+
+While the general idea of a carrier-independent driver seems to fly,
+configuration of specific signals within the carrier needs at least
+some knowledge of the carrier itself. For this reason, the specific
+driver can request to configure carrier-specific GPIO pins, numbered
+from 0 to at most 4095. Configuration is performed by passing a
+pointer to an array of struct fmc_gpio items, as well as the length of
+the array. This is the data structure:
+
+ struct fmc_gpio {
+ char *carrier_name;
+ int gpio;
+ int _gpio; /* internal use by the carrier */
+ int mode; /* GPIOF_DIR_OUT etc, from <linux/gpio.h> */
+ int irqmode; /* IRQF_TRIGGER_LOW and so on */
+ };
+
+By specifying a carrier_name for each pin, the driver may access
+different pins in different carriers. The gpio_config method is
+expected to return the number of pins successfully configured, ignoring
+requests for other carriers. However, if no pin is configured (because
+no structure at all refers to the current carrier_name), the operation
+returns an error so the caller will know that it is running under a
+yet-unsupported carrier.
+
+So, for example, a driver that has been developed and tested on both
+the SPEC and the SVEC may request configuration of two different GPIO
+pins, and expect one such configuration to succeed - if none succeeds
+it most likely means that the current carrier is a still-unknown one.
+
+If, however, your GPIO pin has a specific known role, you can pass a
+special number in the gpio field, using one of the following macros:
+
+ #define FMC_GPIO_RAW(x) (x) /* 4096 of them */
+ #define FMC_GPIO_IRQ(x) ((x) + 0x1000) /* 256 of them */
+ #define FMC_GPIO_LED(x) ((x) + 0x1100) /* 256 of them */
+ #define FMC_GPIO_KEY(x) ((x) + 0x1200) /* 256 of them */
+ #define FMC_GPIO_TP(x) ((x) + 0x1300) /* 256 of them */
+ #define FMC_GPIO_USER(x) ((x) + 0x1400) /* 256 of them */
+
+Use of virtual GPIO numbers (anything but FMC_GPIO_RAW) is allowed
+provided the carrier_name field in the data structure is left
+unspecified (NULL). Each carrier is responsible for providing a mapping
+between virtual and physical GPIO numbers. The carrier may then use the
+_gpio field to cache the result of this mapping.
+
+All carriers must map their I/O lines to the sets above starting from
+zero. The SPEC, for example, maps interrupt pins 0 and 1, and test
+points 0 through 3 (even if the test points on the PCB are called
+5,6,7,8).
+
+If, for example, a driver requires a free LED and a test point (for a
+scope probe to be plugged at some point during development) it may ask
+for FMC_GPIO_LED(0) and FMC_GPIO_TP(0). Each carrier will provide
+suitable GPIO pins. Clearly, the person running the drivers will know
+the order used by the specific carrier driver in assigning leds and
+testpoints, so to make a carrier-dependent use of the diagnostic tools.
+
+In theory, some form of autodetection should be possible: a driver like
+the wr-nic (which uses IRQ(1) on the SPEC card) should configure
+IRQ(0), make a test with software-generated interrupts and configure
+IRQ(1) if the test fails. This probing step should be used because even
+if the wr-nic gateware is known to use IRQ1 on the SPEC, the driver
+should be carrier-independent and thus use IRQ(0) as a first bet -
+actually, the knowledge that IRQ0 may fail is carrier-dependent
+information, but using it doesn't make the driver unsuitable for other
+carriers.
+
+The return value of gpio_config is defined as follows:
+
+ * If no pin in the array can be used by the carrier, `-ENODEV'.
+
+ * If at least one virtual GPIO number cannot be mapped, `-ENOENT'.
+
+ * On success, 0 or positive. The value returned is the number of
+ high input bits (if no input is configured, the value for success
+ is 0).
+
+While I admit the procedure is not completely straightforward, it
+allows configuration, input and output with a single carrier operation.
+Given the typical use case of FMC devices, GPIO operations are not
+expected to ever by in hot paths, and GPIO access so fare has only been
+used to configure the interrupt pin, mode and polarity. Especially
+reading inputs is not expected to be common. If your device has GPIO
+capabilities in the hot path, you should consider using the kernel's
+GPIO mechanisms.
diff --git a/Documentation/fmc/fmc-chardev.txt b/Documentation/fmc/fmc-chardev.txt
new file mode 100644
index 0000000..d9ccb27
--- /dev/null
+++ b/Documentation/fmc/fmc-chardev.txt
@@ -0,0 +1,64 @@
+fmc-chardev
+===========
+
+This is a simple generic driver, that allows user access by means of a
+character device (actually, one for each mezzanine it takes hold of).
+
+The char device is created as a misc device. Its name in /dev (as
+created by udev) is the same name as the underlying FMC device. Thus,
+the name can be a silly fmc-0000 look-alike if the device has no
+identifiers nor bus_id, a more specific fmc-0400 if the device has a
+bus-specific address but no associated name, or something like
+fdelay-0400 if the FMC core can rely on both a mezzanine name and a bus
+address.
+
+Currently the driver only supports read and write: you can lseek to the
+desired address and read or write a register.
+
+The driver assumes all registers are 32-bit in size, and only accepts a
+single read or write per system call. However, as a result of Unix read
+and write semantics, users can simply fread or fwrite bigger areas in
+order to dump or store bigger memory areas.
+
+There is currently no support for mmap, user-space interrupt management
+and DMA buffers. They may be added in later versions, if the need
+arises.
+
+The example below shows raw access to a SPEC card programmed with its
+golden FPGA file, that features an SDB structure at offset 256 - i.e.
+64 words. The mezzanine's EEPROM in this case is not programmed, so the
+default name is fmc-<bus><devfn>, and there are two cards in the system:
+
+ spusa.root# insmod fmc-chardev.ko
+ [ 1073.339332] spec 0000:02:00.0: Driver has no ID: matches all
+ [ 1073.345051] spec 0000:02:00.0: Created misc device "fmc-0200"
+ [ 1073.350821] spec 0000:04:00.0: Driver has no ID: matches all
+ [ 1073.356525] spec 0000:04:00.0: Created misc device "fmc-0400"
+ spusa.root# ls -l /dev/fmc*
+ crw------- 1 root root 10, 58 Nov 20 19:23 /dev/fmc-0200
+ crw------- 1 root root 10, 57 Nov 20 19:23 /dev/fmc-0400
+ spusa.root# dd bs=4 skip=64 count=1 if=/dev/fmc-0200 2> /dev/null | od -t x1z
+ 0000000 2d 42 44 53 >-BDS<
+ 0000004
+
+The simple program tools/fmc-mem in this package can access an FMC char
+device and read or write a word or a whole area. Actually, the program
+is not specific to FMC at all, it just uses lseek, read and write.
+
+Its first argument is the device name, the second the offset, the third
+(if any) the value to write and the optional last argument that must
+begin with "+" is the number of bytes to read or write. In case of
+repeated reading data is written to stdout; repeated writes read from
+stdin and the value argument is ignored.
+
+The following examples show reading the SDB magic number and the first
+SDB record from a SPEC device programmed with its golden image:
+
+ spusa.root# ./fmc-mem /dev/fmc-0200 100
+ 5344422d
+ spusa.root# ./fmc-mem /dev/fmc-0200 100 +40 | od -Ax -t x1z
+ 000000 2d 42 44 53 00 01 02 00 00 00 00 00 00 00 00 00 >-BDS............<
+ 000010 00 00 00 00 ff 01 00 00 00 00 00 00 51 06 00 00 >............Q...<
+ 000020 c9 42 a5 e6 02 00 00 00 11 05 12 20 2d 34 42 57 >.B......... -4BW<
+ 000030 73 6f 72 43 72 61 62 73 49 53 47 2d 00 20 20 20 >sorCrabsISG-. <
+ 000040
diff --git a/Documentation/fmc/fmc-fakedev.txt b/Documentation/fmc/fmc-fakedev.txt
new file mode 100644
index 0000000..e85b74a
--- /dev/null
+++ b/Documentation/fmc/fmc-fakedev.txt
@@ -0,0 +1,36 @@
+fmc-fakedev
+===========
+
+This package includes a software-only device, called fmc-fakedev, which
+is able to register up to 4 mezzanines (by default it registers one).
+Unlike the SPEC driver, which creates an FMC device for each PCI cards
+it manages, this module creates a single instance of its set of
+mezzanines.
+
+It is meant as the simplest possible example of how a driver should be
+written, and it includes a fake EEPROM image (built using the tools
+described in *note FMC Identification::),, which by default is
+replicated for each fake mezzanine.
+
+You can also use this device to verify the match algorithms, by asking
+it to test your own EEPROM image. You can provide the image by means of
+the eeprom= module parameter: the new EEPROM image is loaded, as usual,
+by means of the firmware loader. This example shows the defaults and a
+custom EEPROM image:
+
+ spusa.root# insmod fmc-fakedev.ko
+ [ 99.971247] fake-fmc-carrier: mezzanine 0
+ [ 99.975393] Manufacturer: fake-vendor
+ [ 99.979624] Product name: fake-design-for-testing
+ spusa.root# rmmod fmc-fakedev
+ spusa.root# insmod fmc-fakedev.ko eeprom=fdelay-eeprom.bin
+ [ 121.447464] fake-fmc-carrier: Mezzanine 0: eeprom "fdelay-eeprom.bin"
+ [ 121.462725] fake-fmc-carrier: mezzanine 0
+ [ 121.466858] Manufacturer: CERN
+ [ 121.470477] Product name: FmcDelay1ns4cha
+ spusa.root# rmmod fmc-fakedev
+
+After loading the device, you can use the write_ee method do modify its
+own internal fake EEPROM: whenever the image is overwritten starting at
+offset 0, the module will unregister and register again the FMC device.
+This is shown in fmc-write-eeprom.txt
diff --git a/Documentation/fmc/fmc-trivial.txt b/Documentation/fmc/fmc-trivial.txt
new file mode 100644
index 0000000..d1910bc
--- /dev/null
+++ b/Documentation/fmc/fmc-trivial.txt
@@ -0,0 +1,17 @@
+fmc-trivial
+===========
+
+The simple module fmc-trivial is just a simple client that registers an
+interrupt handler. I used it to verify the basic mechanism of the FMC
+bus and how interrupts worked.
+
+The module implements the generic FMC parameters, so it can program a
+different gateware file in each card. The whole list of parameters it
+accepts are:
+
+`busid='
+`gateware='
+ Generic parameters. See mezzanine.txt
+
+
+This driver is worth reading, in my opinion.
diff --git a/Documentation/fmc/fmc-write-eeprom.txt b/Documentation/fmc/fmc-write-eeprom.txt
new file mode 100644
index 0000000..44a3bc6
--- /dev/null
+++ b/Documentation/fmc/fmc-write-eeprom.txt
@@ -0,0 +1,125 @@
+fmc-write-eeprom
+================
+
+This module is designed to load a binary file from /lib/firmware and to
+write it to the internal EEPROM of the mezzanine card. This driver uses
+the `busid' generic parameter.
+
+Overwriting the EEPROM is not something you should do daily, and it is
+expected to only happen during manufacturing. For this reason, the
+module makes it unlikely for the random user to change a working EEPROM.
+
+The module takes the following measures:
+
+ * It accepts a `file=' argument (within /lib/firmware) and if no
+ such argument is received, it doesn't write anything to EEPROM
+ (i.e. there is no default file name).
+
+ * If the file name ends with `.bin' it is written verbatim starting
+ at offset 0.
+
+ * If the file name ends with `.tlv' it is interpreted as
+ type-length-value (i.e., it allows writev(2)-like operation).
+
+ * If the file name doesn't match any of the patterns above, it is
+ ignored and no write is performed.
+
+ * Only cards listed with `busid=' are written to. If no busid is
+ specified, no programming is done (and the probe function of the
+ driver will fail).
+
+
+Each TLV tuple is formatted in this way: the header is 5 bytes,
+followed by data. The first byte is `w' for write, the next two bytes
+represent the address, in little-endian byte order, and the next two
+represent the data length, in little-endian order. The length does not
+include the header (it is the actual number of bytes to be written).
+
+This is a real example: that writes 5 bytes at position 0x110:
+
+ spusa.root# od -t x1 -Ax /lib/firmware/try.tlv
+ 000000 77 10 01 05 00 30 31 32 33 34
+ 00000a
+ spusa.root# insmod /tmp/fmc-write-eeprom.ko busid=0x0200 file=try.tlv
+ [19983.391498] spec 0000:03:00.0: write 5 bytes at 0x0110
+ [19983.414615] spec 0000:03:00.0: write_eeprom: success
+
+Please note that you'll most likely want to use SDBFS to build your
+EEPROM image, at least if your mezzanines are being used in the White
+Rabbit environment. For this reason the TLV format is not expected to
+be used much and is not expected to be developed further.
+
+If you want to try reflashing fake EEPROM devices, you can use the
+fmc-fakedev.ko module (see *note fmc-fakedev::). Whenever you change
+the image starting at offset 0, it will deregister and register again
+after two seconds. Please note, however, that if fmc-write-eeprom is
+still loaded, the system will associate it to the new device, which
+will be reprogrammed and thus will be unloaded after two seconds. The
+following example removes the module after it reflashed fakedev the
+first time.
+
+ spusa.root# insmod fmc-fakedev.ko
+ [ 72.984733] fake-fmc: Manufacturer: fake-vendor
+ [ 72.989434] fake-fmc: Product name: fake-design-for-testing
+ spusa.root# insmod fmc-write-eeprom.ko busid=0 file=fdelay-eeprom.bin; \
+ rmmod fmc-write-eeprom
+ [ 130.874098] fake-fmc: Matching a generic driver (no ID)
+ [ 130.887845] fake-fmc: programming 6155 bytes
+ [ 130.894567] fake-fmc: write_eeprom: success
+ [ 132.895794] fake-fmc: Manufacturer: CERN
+ [ 132.899872] fake-fmc: Product name: FmcDelay1ns4cha
+
+
+Writing to the EEPROM
+=====================
+
+Once you have created a binary file for your EEPROM, you can write it
+to the storage medium using the fmc-write-eeprom (See *note
+fmc-write-eeprom::, while relying on a carrier driver. The procedure
+here shown here uses the SPEC driver
+(`http://www.ohwr.org/projects/spec-sw').
+
+The example assumes no driver is already loaded (actually, I unloaded
+them by hand as everything loads automatically at boot time after you
+installed the modules), and shows kernel messages together with
+commands. Here the prompt is spusa.root# and two SPEC cards are plugged
+in the system.
+
+ spusa.root# insmod fmc.ko
+ spusa.root# insmod spec.ko
+ [13972.382818] spec 0000:02:00.0: probe for device 0002:0000
+ [13972.392773] spec 0000:02:00.0: got file "fmc/spec-init.bin", 1484404 (0x16a674) bytes
+ [13972.591388] spec 0000:02:00.0: FPGA programming successful
+ [13972.883011] spec 0000:02:00.0: EEPROM has no FRU information
+ [13972.888719] spec 0000:02:00.0: No device_id filled, using index
+ [13972.894676] spec 0000:02:00.0: No mezzanine_name found
+ [13972.899863] /home/rubini/wip/spec-sw/kernel/spec-gpio.c - spec_gpio_init
+ [13972.906578] spec 0000:04:00.0: probe for device 0004:0000
+ [13972.916509] spec 0000:04:00.0: got file "fmc/spec-init.bin", 1484404 (0x16a674) bytes
+ [13973.115096] spec 0000:04:00.0: FPGA programming successful
+ [13973.401798] spec 0000:04:00.0: EEPROM has no FRU information
+ [13973.407474] spec 0000:04:00.0: No device_id filled, using index
+ [13973.413417] spec 0000:04:00.0: No mezzanine_name found
+ [13973.418600] /home/rubini/wip/spec-sw/kernel/spec-gpio.c - spec_gpio_init
+ spusa.root# ls /sys/bus/fmc/devices
+ fmc-0000 fmc-0001
+ spusa.root# insmod fmc-write-eeprom.ko busid=0x0200 file=fdelay-eeprom.bin
+ [14103.966259] spec 0000:02:00.0: Matching an generic driver (no ID)
+ [14103.975519] spec 0000:02:00.0: programming 6155 bytes
+ [14126.373762] spec 0000:02:00.0: write_eeprom: success
+ [14126.378770] spec 0000:04:00.0: Matching an generic driver (no ID)
+ [14126.384903] spec 0000:04:00.0: fmc_write_eeprom: no filename given: not programming
+ [14126.392600] fmc_write_eeprom: probe of fmc-0001 failed with error -2
+
+Reading back the EEPROM
+=======================
+
+In order to read back the binary content of the EEPROM of your
+mezzanine device, the bus creates a read-only sysfs file called eeprom
+for each mezzanine it knows about:
+
+ spusa.root# cd /sys/bus/fmc/devices; ls -l */eeprom
+ -r--r--r-- 1 root root 8192 Apr 9 16:53 FmcDelay1ns4cha-f001/eeprom
+ -r--r--r-- 1 root root 8192 Apr 9 17:19 fake-design-for-testing-f002/eeprom
+ -r--r--r-- 1 root root 8192 Apr 9 17:19 fake-design-for-testing-f003/eeprom
+ -r--r--r-- 1 root root 8192 Apr 9 17:19 fmc-f004/eeprom
diff --git a/Documentation/fmc/identifiers.txt b/Documentation/fmc/identifiers.txt
new file mode 100644
index 0000000..3bb577f
--- /dev/null
+++ b/Documentation/fmc/identifiers.txt
@@ -0,0 +1,168 @@
+FMC Identification
+******************
+
+The FMC standard requires every compliant mezzanine to carry
+identification information in an I2C EEPROM. The information must be
+laid out according to the "IPMI Platform Management FRU Information",
+where IPMI is a lie I'd better not expand, and FRU means "Field
+Replaceable Unit".
+
+The FRU information is an intricate unreadable binary blob that must
+live at offset 0 of the EEPROM, and typically extends for a few hundred
+bytes. The standard allows the application to use all the remaining
+storage area of the EEPROM as it wants.
+
+This chapter explains how to create your own EEPROM image and how to
+write it in your mezzanine, as well as how devices and drivers are
+paired at run time. EEPROM programming uses tools that are part of this
+package and SDB (part of the fpga-config-space package).
+
+The first sections are only interesting for manufacturers who need to
+write the EEPROM. If you are just a software developer writing an FMC
+device or driver, you may jump straight to *note SDB Support::.
+
+
+Building the FRU Structure
+==========================
+
+If you want to know the internals of the FRU structure and despair, you
+can retrieve the document from
+`http://download.intel.com/design/servers/ipmi/FRU1011.pdf' . The
+standard is awful and difficult without reason, so we only support the
+minimum mandatory subset - we create a simple structure and parse it
+back at run time, but we are not able to either generate or parse more
+arcane features like non-english languages and 6-bit text. If you need
+more items of the FRU standard for your boards, please submit patches.
+
+This package includes the Python script that Matthieu Cattin wrote to
+generate the FRU binary blob, based on an helper libipmi by Manohar
+Vanga and Matthieu himself. I changed the test script to receive
+parameters from the command line or from the environment (the command
+line takes precedence)
+
+To make a long story short, in order to build a standard-compliant
+binary file to be burned in your EEPROM, you need the following items:
+
+ Environment Opt Official Name Default
+---------------------------------------------------------------------
+ FRU_VENDOR -v "Board Manufacturer" fmc-example
+ FRU_NAME -n "Board Product Name" mezzanine
+ FRU_SERIAL -s `Board Serial Number" 0001
+ FRU_PART -p "Board Part Number" sample-part
+ FRU_OUTPUT -o not applicable /dev/stdout
+
+The "Official Name" above is what you find in the FRU official
+documentation, chapter 11, page 7 ("Board Info Area Format"). The
+output option is used to save the generated binary to a specific file
+name instead of stdout.
+
+You can pass the items to the FRU generator either in the environment
+or on the command line. This package has currently no support for
+specifying power consumption or such stuff, but I plan to add it as
+soon as I find some time for that.
+
+FIXME: consumption etc for FRU are here or in PTS?
+
+The following example creates a binary image for a specific board:
+
+ ./tools/fru-generator -v CERN -n FmcAdc100m14b4cha \
+ -s HCCFFIA___-CR000003 -p EDA-02063-V5-0 > eeprom.bin
+
+The following example shows a script that builds several binary EEPROM
+images for a series of boards, changing the serial number for each of
+them. The script uses a mix of environment variables and command line
+options, and uses the same string patterns shown above.
+
+ #!/bin/sh
+
+ export FRU_VENDOR="CERN"
+ export FRU_NAME="FmcAdc100m14b4cha"
+ export FRU_PART="EDA-02063-V5-0"
+
+ serial="HCCFFIA___-CR"
+
+ for number in $(seq 1 50); do
+ # build number-string "ns"
+ ns="$(printf %06d $number)"
+ ./fru-generator -s "${serial}${ns}" > eeprom-${ns}.bin
+ done
+
+
+Using SDB-FS in the EEPROM
+==========================
+
+If you want to use SDB as a filesystem in the EEPROM device within the
+mezzanine, you should create one such filesystem using gensdbfs, from
+the fpga-config-space package on OHWR.
+
+By using an SBD filesystem you can cluster several files in a single
+EEPROM, so both the host system and a soft-core running in the FPGA (if
+any) can access extra production-time information.
+
+We chose to use SDB as a storage filesystem because the format is very
+simple, and both the host system and the soft-core will likely already
+include support code for such format. The SDB library offered by the
+fpga-config-space is less than 1kB under LM32, so it proves quite up to
+the task.
+
+The SDB entry point (which acts as a directory listing) cannot live at
+offset zero in the flash device, because the FRU information must live
+there. To avoid wasting precious storage space while still allowing
+for more-than-minimal FRU structures, the fmc.ko will look for the SDB
+record at address 256, 512 and 1024.
+
+In order to generate the complete EEPROM image you'll need a
+configuration file for gensdbfs: you tell the program where to place
+the sdb entry point, and you must force the FRU data file to be placed
+at the beginning of the storage device. If needed, you can also place
+other files at a special offset (we sometimes do it for backward
+compatibility with drivers we wrote before implementing SDB for flash
+memory).
+
+The directory tools/sdbfs of this package includes a well-commented
+example that you may want to use as a starting point (the comments are
+in the file called -SDB-CONFIG-). Reading documentation for gensdbfs
+is a suggested first step anyways.
+
+This package (generic FMC bus support) only accesses two files in the
+EEPROM: the FRU information, at offset zero, with a suggested filename
+of IPMI-FRU and the short name for the mezzanine, in a file called
+name. The IPMI-FRU name is not mandatory, but a strongly suggested
+choice; the name filename is mandatory, because this is the preferred
+short name used by the FMC core. For example, a name of "fdelay" may
+supplement a Product Name like "FmcDelay1ns4cha" - exactly as
+demonstrated in `tools/sdbfs'.
+
+Note: SDB access to flash memory is not yet supported, so the short
+name currently in use is just the "Product Name" FRU string.
+
+The example in tools/sdbfs includes an extra file, that is needed by
+the fine-delay driver, and must live at a known address of 0x1800. By
+running gensdbfs on that directory you can output your binary EEPROM
+image (here below spusa$ is the shell prompt):
+
+ spusa$ ../fru-generator -v CERN -n FmcDelay1ns4cha -s proto-0 \
+ -p EDA-02267-V3 > IPMI-FRU
+ spusa$ ls -l
+ total 16
+ -rw-rw-r-- 1 rubini staff 975 Nov 19 18:08 --SDB-CONFIG--
+ -rw-rw-r-- 1 rubini staff 216 Nov 19 18:13 IPMI-FRU
+ -rw-rw-r-- 1 rubini staff 11 Nov 19 18:04 fd-calib
+ -rw-rw-r-- 1 rubini staff 7 Nov 19 18:04 name
+ spusa$ sudo gensdbfs . /lib/firmware/fdelay-eeprom.bin
+ spusa$ sdb-read -l -e 0x100 /lib/firmware/fdelay-eeprom.bin
+ /home/rubini/wip/sdbfs/userspace/sdb-read: listing format is to be defined
+ 46696c6544617461:2e202020 00000100-000018ff .
+ 46696c6544617461:6e616d65 00000200-00000206 name
+ 46696c6544617461:66642d63 00001800-000018ff fd-calib
+ 46696c6544617461:49504d49 00000000-000000d7 IPMI-FRU
+ spusa$ ../fru-dump /lib/firmware/fdelay-eeprom.bin
+ /lib/firmware/fdelay-eeprom.bin: manufacturer: CERN
+ /lib/firmware/fdelay-eeprom.bin: product-name: FmcDelay1ns4cha
+ /lib/firmware/fdelay-eeprom.bin: serial-number: proto-0
+ /lib/firmware/fdelay-eeprom.bin: part-number: EDA-02267-V3
+
+As expected, the output file is both a proper sdbfs object and an IPMI
+FRU information blob. The fd-calib file lives at offset 0x1800 and is
+over-allocated to 256 bytes, according to the configuration file for
+gensdbfs.
diff --git a/Documentation/fmc/mezzanine.txt b/Documentation/fmc/mezzanine.txt
new file mode 100644
index 0000000..87910db
--- /dev/null
+++ b/Documentation/fmc/mezzanine.txt
@@ -0,0 +1,123 @@
+FMC Driver
+**********
+
+An FMC driver is concerned with the specific mezzanine and associated
+gateware. As such, it is expected to be independent of the carrier
+being used: it will perform I/O accesses only by means of
+carrier-provided functions.
+
+The matching between device and driver is based on the content of the
+EEPROM (as mandated by the FMC standard) or by the actual cores
+configured in the FPGA; the latter technique is used when the FPGA is
+already programmed when the device is registered to the bus core.
+
+In some special cases it is possible for a driver to directly access
+FPGA registers, by means of the `fpga_base' field of the device
+structure. This may be needed for high-bandwidth peripherals like fast
+ADC cards. If the device module registered a remote device (for example
+by means of Etherbone), the `fpga_base' pointer will be NULL.
+Therefore, drivers must be ready to deal with NULL base pointers, and
+fail gracefully. Most driver, however, are not expected to access the
+pointer directly but run fmc_readl and fmc_writel instead, which will
+work in any case.
+
+In even more special cases, the driver may access carrier-specific
+functionality: the `carrier_name' string allows the driver to check
+which is the current carrier and make use of the `carrier_data'
+pointer. We chose to use carrier names rather than numeric identifiers
+for greater flexibility, but also to avoid a central registry within
+the `fmc.h' file - we hope other users will exploit our framework with
+their own carriers. An example use of carrier names is in GPIO setup
+(see *note The GPIO Abstraction::), although the name match is not
+expected to be performed by the driver. If you depend on specific
+carriers, please check the carrier name and fail gracefully if your
+driver finds it is running in a yet-unknown-to-it environment.
+
+
+ID Table
+========
+
+Like most other Linux drivers, and FMC driver must list all the devices
+which it is able to drive. This is usually done by means of a device
+table, but in FMC we can match hardware based either on the contents of
+their EEPROM or on the actual FPGA cores that can be enumerated.
+Therefore, we have two tables of identifiers.
+
+Matching of FRU information depends on two names, the manufacturer (or
+vendor) and the device (see *note FMC Identification::); for
+flexibility during production (i.e. before writing to the EEPROM) the
+bus supports a catch-all driver that specifies NULL strings. For this
+reason, the table is specified as pointer-and-length, not a a
+null-terminated array - the entry with NULL names can be a valid entry.
+
+Matching on FPGA cores depends on two numeric fields: the 64-bit vendor
+number and the 32-bit device number. Support for matching based on
+class is not yet implemented. Each device is expected to be uniquely
+identified by an array of cores (it matches if all of the cores are
+instantiated), and for consistency the list is passed as
+pointer-and-length. Several similar devices can be driven by the same
+driver, and thus the driver specifies and array of such arrays.
+
+The complete set of involved data structures is thus the following:
+
+ struct fmc_fru_id { char *manufacturer; char *product_name; };
+ struct fmc_sdb_one_id { uint64_t vendor; uint32_t device; };
+ struct fmc_sdb_id { struct fmc_sdb_one_id *cores; int cores_nr; };
+
+ struct fmc_device_id {
+ struct fmc_fru_id *fru_id; int fru_id_nr;
+ struct fmc_sdb_id *sdb_id; int sdb_id_nr;
+ };
+
+A better reference, with full explanation, is the <linux/fmc.h> header.
+
+
+Module Parameters
+=================
+
+Most of the FMC drivers need the same set of kernel parameters. This
+package includes support to implement common parameters by means of
+fields in the `fmc_driver' structure and simple macro definitions.
+
+The parameters are carrier-specific, in that they rely on the busid
+concept, that varies among carriers. For the SPEC, the identifier is a
+PCI bus and devfn number, 16 bits wide in total; drivers for other
+carriers will most likely offer something similar but not identical,
+and some code duplication is unavoidable.
+
+This is the list of parameters that are common to several modules to
+see how they are actually used, please look at spec-trivial.c.
+
+`busid='
+ This is an array of integers, listing carrier-specific
+ identification numbers. For PIC, for example, `0x0400' represents
+ bus 4, slot 0. If any such ID is specified, the driver will only
+ accept to drive cards that appear in the list (even if the FMC ID
+ matches). This is accomplished by the validate carrier method.
+
+`gateware='
+ The argument is an array of strings. If no busid= is specified,
+ the first string of gateware= is used for all cards; otherwise the
+ identifiers and gateware names are paired one by one, in the order
+ specified.
+
+`show_sdb='
+ For modules supporting it, this parameter asks to show the SDB
+ internal structure by means of kernel messages. It is disabled by
+ default because those lines tend to hide more important messages,
+ if you look at the system console while loading the drivers.
+ Note: the parameter is being obsoleted, because fmc.ko itself now
+ supports dump_sdb= that applies to every client driver.
+
+
+For example, if you are using the trivial driver to load two different
+gateware files to two different cards, you can use the following
+parameters to load different binaries to the cards, after looking up
+the PCI identifiers. This has been tested with a SPEC carrier.
+
+ insmod fmc-trivial.ko \
+ busid=0x0200,0x0400 \
+ gateware=fmc/fine-delay.bin,fmc/simple-dio.bin
+
+Please note that not all sub-modules support all of those parameters.
+You can use modinfo to check what is supported by each module.
diff --git a/Documentation/fmc/parameters.txt b/Documentation/fmc/parameters.txt
new file mode 100644
index 0000000..59edf08
--- /dev/null
+++ b/Documentation/fmc/parameters.txt
@@ -0,0 +1,56 @@
+Module Parameters in fmc.ko
+***************************
+
+The core driver receives two module parameters, meant to help debugging
+client modules. Both parameters can be modified by writing to
+/sys/module/fmc/parameters/, because they are used when client drivers
+are devices are registered, not when fmc.ko is loaded.
+
+`dump_eeprom='
+ If not zero, the parameter asks the bus controller to dump the
+ EEPROM of any device that is registered, using printk.
+
+`dump_sdb='
+ If not zero, the parameter prints the SDB tree of every FPGA it is
+ loaded by fmc_reprogram(). If greater than one, it asks to dump
+ the binary content of SDB records. This currently only dumps the
+ top-level SDB array, though.
+
+
+EEPROM dumping avoids repeating lines, since most of the contents is
+usually empty and all bits are one or zero. This is an example of the
+output:
+
+ [ 6625.850480] spec 0000:02:00.0: FPGA programming successful
+ [ 6626.139949] spec 0000:02:00.0: Manufacturer: CERN
+ [ 6626.144666] spec 0000:02:00.0: Product name: FmcDelay1ns4cha
+ [ 6626.150370] FMC: mezzanine 0: 0000:02:00.0 on SPEC
+ [ 6626.155179] FMC: dumping eeprom 0x2000 (8192) bytes
+ [ 6626.160087] 0000: 01 00 00 01 00 0b 00 f3 01 0a 00 a5 85 87 c4 43
+ [ 6626.167069] 0010: 45 52 4e cf 46 6d 63 44 65 6c 61 79 31 6e 73 34
+ [ 6626.174019] 0020: 63 68 61 c7 70 72 6f 74 6f 2d 30 cc 45 44 41 2d
+ [ 6626.180975] 0030: 30 32 32 36 37 2d 56 33 da 32 30 31 32 2d 31 31
+ [...]
+ [ 6626.371366] 0200: 66 64 65 6c 61 79 0a 00 00 00 00 00 00 00 00 00
+ [ 6626.378359] 0210: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+ [ 6626.385361] [...]
+ [ 6626.387308] 1800: 70 6c 61 63 65 68 6f 6c 64 65 72 ff ff ff ff ff
+ [ 6626.394259] 1810: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
+ [ 6626.401250] [...]
+
+The dump of SDB looks like the following; the example shows the simple
+golden gateware for the SPEC card, removing the leading timestamps to
+fit the page:
+
+ spec 0000:02:00.0: SDB: 00000651:e6a542c9 WB4-Crossbar-GSI
+ spec 0000:02:00.0: SDB: 0000ce42:ff07fc47 WR-Periph-Syscon (00000000-000000ff)
+ FMC: mezzanine 0: 0000:02:00.0 on SPEC
+ FMC: poor dump of sdb first level:
+ 0000: 53 44 42 2d 00 02 01 00 00 00 00 00 00 00 00 00
+ 0010: 00 00 00 00 00 00 01 ff 00 00 00 00 00 00 06 51
+ 0020: e6 a5 42 c9 00 00 00 02 20 12 05 11 57 42 34 2d
+ 0030: 43 72 6f 73 73 62 61 72 2d 47 53 49 20 20 20 00
+ 0040: 00 00 01 01 00 00 00 07 00 00 00 00 00 00 00 00
+ 0050: 00 00 00 00 00 00 00 ff 00 00 00 00 00 00 ce 42
+ 0060: ff 07 fc 47 00 00 00 01 20 12 03 05 57 52 2d 50
+ 0070: 65 72 69 70 68 2d 53 79 73 63 6f 6e 20 20 20 01
diff --git a/Documentation/gpio.txt b/Documentation/gpio.txt
index 77a1d11..6f83fa9 100644
--- a/Documentation/gpio.txt
+++ b/Documentation/gpio.txt
@@ -72,11 +72,11 @@
not care how it's implemented.)
That said, if the convention is supported on their platform, drivers should
-use it when possible. Platforms must declare GENERIC_GPIO support in their
-Kconfig (boolean true), and provide an <asm/gpio.h> file. Drivers that can't
-work without standard GPIO calls should have Kconfig entries which depend
-on GENERIC_GPIO. The GPIO calls are available, either as "real code" or as
-optimized-away stubs, when drivers use the include file:
+use it when possible. Platforms must select ARCH_REQUIRE_GPIOLIB or
+ARCH_WANT_OPTIONAL_GPIOLIB in their Kconfig. Drivers that can't work without
+standard GPIO calls should have Kconfig entries which depend on GPIOLIB. The
+GPIO calls are available, either as "real code" or as optimized-away stubs,
+when drivers use the include file:
#include <linux/gpio.h>
diff --git a/Documentation/hid/hid-sensor.txt b/Documentation/hid/hid-sensor.txt
old mode 100755
new mode 100644
diff --git a/Documentation/hw_random.txt b/Documentation/hw_random.txt
index 690f525..026e237 100644
--- a/Documentation/hw_random.txt
+++ b/Documentation/hw_random.txt
@@ -63,7 +63,7 @@
* FIXME: support poll(2)
- NOTE: request_mem_region was removed, for two reasons:
+ NOTE: request_mem_region was removed, for three reasons:
1) Only one RNG is supported by this driver, 2) The location
used by the RNG is a fixed location in MMIO-addressable memory,
3) users with properly working BIOS e820 handling will always
diff --git a/Documentation/hwmon/ab8500 b/Documentation/hwmon/ab8500
new file mode 100644
index 0000000..cf169c8
--- /dev/null
+++ b/Documentation/hwmon/ab8500
@@ -0,0 +1,22 @@
+Kernel driver ab8500
+====================
+
+Supported chips:
+ * ST-Ericsson AB8500
+ Prefix: 'ab8500'
+ Addresses scanned: -
+ Datasheet: http://www.stericsson.com/developers/documentation.jsp
+
+Authors:
+ Martin Persson <martin.persson@stericsson.com>
+ Hongbo Zhang <hongbo.zhang@linaro.org>
+
+Description
+-----------
+
+See also Documentation/hwmon/abx500. This is the ST-Ericsson AB8500 specific
+driver.
+
+Currently only the AB8500 internal sensor and one external sensor for battery
+temperature are monitored. Other GPADC channels can also be monitored if needed
+in future.
diff --git a/Documentation/hwmon/abx500 b/Documentation/hwmon/abx500
new file mode 100644
index 0000000..319a058
--- /dev/null
+++ b/Documentation/hwmon/abx500
@@ -0,0 +1,28 @@
+Kernel driver abx500
+====================
+
+Supported chips:
+ * ST-Ericsson ABx500 series
+ Prefix: 'abx500'
+ Addresses scanned: -
+ Datasheet: http://www.stericsson.com/developers/documentation.jsp
+
+Authors:
+ Martin Persson <martin.persson@stericsson.com>
+ Hongbo Zhang <hongbo.zhang@linaro.org>
+
+Description
+-----------
+
+Every ST-Ericsson Ux500 SOC consists of both ABx500 and DBx500 physically,
+this is kernel hwmon driver for ABx500.
+
+There are some GPADCs inside ABx500 which are designed for connecting to
+thermal sensors, and there is also a thermal sensor inside ABx500 too, which
+raises interrupt when critical temperature reached.
+
+This abx500 is a common layer which can monitor all of the sensors, every
+specific abx500 chip has its special configurations in its own file, e.g. some
+sensors can be configured invisible if they are not available on that chip, and
+the corresponding gpadc_addr should be set to 0, thus this sensor won't be
+polled.
diff --git a/Documentation/hwmon/adm1275 b/Documentation/hwmon/adm1275
index 2cfa256..15b4a20 100644
--- a/Documentation/hwmon/adm1275
+++ b/Documentation/hwmon/adm1275
@@ -15,7 +15,7 @@
Addresses scanned: -
Datasheet: www.analog.com/static/imported-files/data_sheets/ADM1276.pdf
-Author: Guenter Roeck <guenter.roeck@ericsson.com>
+Author: Guenter Roeck <linux@roeck-us.net>
Description
diff --git a/Documentation/hwmon/adt7410 b/Documentation/hwmon/adt7410
index 9600400..9817941 100644
--- a/Documentation/hwmon/adt7410
+++ b/Documentation/hwmon/adt7410
@@ -4,28 +4,50 @@
Supported chips:
* Analog Devices ADT7410
Prefix: 'adt7410'
- Addresses scanned: I2C 0x48 - 0x4B
+ Addresses scanned: None
Datasheet: Publicly available at the Analog Devices website
http://www.analog.com/static/imported-files/data_sheets/ADT7410.pdf
+ * Analog Devices ADT7420
+ Prefix: 'adt7420'
+ Addresses scanned: None
+ Datasheet: Publicly available at the Analog Devices website
+ http://www.analog.com/static/imported-files/data_sheets/ADT7420.pdf
+ * Analog Devices ADT7310
+ Prefix: 'adt7310'
+ Addresses scanned: None
+ Datasheet: Publicly available at the Analog Devices website
+ http://www.analog.com/static/imported-files/data_sheets/ADT7310.pdf
+ * Analog Devices ADT7320
+ Prefix: 'adt7320'
+ Addresses scanned: None
+ Datasheet: Publicly available at the Analog Devices website
+ http://www.analog.com/static/imported-files/data_sheets/ADT7320.pdf
Author: Hartmut Knaack <knaack.h@gmx.de>
Description
-----------
-The ADT7410 is a temperature sensor with rated temperature range of -55°C to
-+150°C. It has a high accuracy of +/-0.5°C and can be operated at a resolution
-of 13 bits (0.0625°C) or 16 bits (0.0078°C). The sensor provides an INT pin to
-indicate that a minimum or maximum temperature set point has been exceeded, as
-well as a critical temperature (CT) pin to indicate that the critical
-temperature set point has been exceeded. Both pins can be set up with a common
-hysteresis of 0°C - 15°C and a fault queue, ranging from 1 to 4 events. Both
-pins can individually set to be active-low or active-high, while the whole
-device can either run in comparator mode or interrupt mode. The ADT7410
-supports continous temperature sampling, as well as sampling one temperature
-value per second or even justget one sample on demand for power saving.
-Besides, it can completely power down its ADC, if power management is
-required.
+The ADT7310/ADT7410 is a temperature sensor with rated temperature range of
+-55°C to +150°C. It has a high accuracy of +/-0.5°C and can be operated at a
+resolution of 13 bits (0.0625°C) or 16 bits (0.0078°C). The sensor provides an
+INT pin to indicate that a minimum or maximum temperature set point has been
+exceeded, as well as a critical temperature (CT) pin to indicate that the
+critical temperature set point has been exceeded. Both pins can be set up with a
+common hysteresis of 0°C - 15°C and a fault queue, ranging from 1 to 4 events.
+Both pins can individually set to be active-low or active-high, while the whole
+device can either run in comparator mode or interrupt mode. The ADT7410 supports
+continuous temperature sampling, as well as sampling one temperature value per
+second or even just get one sample on demand for power saving. Besides, it can
+completely power down its ADC, if power management is required.
+
+The ADT7320/ADT7420 is register compatible, the only differences being the
+package, a slightly narrower operating temperature range (-40°C to +150°C), and
+a better accuracy (0.25°C instead of 0.50°C.)
+
+The difference between the ADT7310/ADT7320 and ADT7410/ADT7420 is the control
+interface, the ADT7310 and ADT7320 use SPI while the ADT7410 and ADT7420 use
+I2C.
Configuration Notes
-------------------
diff --git a/Documentation/hwmon/coretemp b/Documentation/hwmon/coretemp
index 3374c08..fec5a9b 100644
--- a/Documentation/hwmon/coretemp
+++ b/Documentation/hwmon/coretemp
@@ -66,6 +66,7 @@
i5 3470T 91
32nm Core i3/i5/i7 Processors
+ i7 2600 98
i7 660UM/640/620, 640LM/620, 620M, 610E 105
i5 540UM/520/430, 540M/520/450/430 105
i3 330E, 370M/350/330 90 rPGA, 105 BGA
@@ -79,7 +80,10 @@
P4505/P4500 90
32nm Atom Processors
+ S1260/1220 95
+ S1240 102
Z2460 90
+ Z2760 90
D2700/2550/2500 100
N2850/2800/2650/2600 100
@@ -98,6 +102,7 @@
45nm Atom Processors
D525/510/425/410 100
+ K525/510/425/410 100
Z670/650 90
Z560/550/540/530P/530/520PT/520/515/510PT/510P 90
Z510/500 90
@@ -107,7 +112,11 @@
330/230 125
E680/660/640/620 90
E680T/660T/640T/620T 110
+ E665C/645C 90
+ E665CT/645CT 110
CE4170/4150/4110 110
+ CE4200 series unknown
+ CE5300 series unknown
45nm Core2 Processors
Solo ULV SU3500/3300 100
diff --git a/Documentation/hwmon/ds1621 b/Documentation/hwmon/ds1621
index 5e97f33..896cdc9 100644
--- a/Documentation/hwmon/ds1621
+++ b/Documentation/hwmon/ds1621
@@ -2,16 +2,30 @@
====================
Supported chips:
- * Dallas Semiconductor DS1621
+ * Dallas Semiconductor / Maxim Integrated DS1621
Prefix: 'ds1621'
- Addresses scanned: I2C 0x48 - 0x4f
- Datasheet: Publicly available at the Dallas Semiconductor website
- http://www.dalsemi.com/
+ Addresses scanned: none
+ Datasheet: Publicly available from www.maximintegrated.com
+
* Dallas Semiconductor DS1625
- Prefix: 'ds1621'
- Addresses scanned: I2C 0x48 - 0x4f
- Datasheet: Publicly available at the Dallas Semiconductor website
- http://www.dalsemi.com/
+ Prefix: 'ds1625'
+ Addresses scanned: none
+ Datasheet: Publicly available from www.datasheetarchive.com
+
+ * Maxim Integrated DS1631
+ Prefix: 'ds1631'
+ Addresses scanned: none
+ Datasheet: Publicly available from www.maximintegrated.com
+
+ * Maxim Integrated DS1721
+ Prefix: 'ds1721'
+ Addresses scanned: none
+ Datasheet: Publicly available from www.maximintegrated.com
+
+ * Maxim Integrated DS1731
+ Prefix: 'ds1731'
+ Addresses scanned: none
+ Datasheet: Publicly available from www.maximintegrated.com
Authors:
Christian W. Zuckschwerdt <zany@triq.net>
@@ -59,5 +73,115 @@
reset. Be aware: When testing, it showed that the status of Tout can change
with neither of the alarms set.
-Temperature conversion of the DS1621 takes up to 1000ms; internal access to
-non-volatile registers may last for 10ms or below.
+Since there is no version or vendor identification register, there is
+no unique identification for these devices. Therefore, explicit device
+instantiation is required for correct device identification and functionality
+(one device per address in this address range: 0x48..0x4f).
+
+The DS1625 is pin compatible and functionally equivalent with the DS1621,
+but the DS1621 is meant to replace it. The DS1631, DS1721, and DS1731 are
+also pin compatible with the DS1621 and provide multi-resolution support.
+
+Additionally, the DS1721 data sheet says the temperature flags (THF and TLF)
+are used internally, however, these flags do get set and cleared as the actual
+temperature crosses the min or max settings (which by default are set to 75
+and 80 degrees respectively).
+
+Temperature Conversion:
+-----------------------
+DS1621 - 750ms (older devices may take up to 1000ms)
+DS1625 - 500ms
+DS1631 - 93ms..750ms for 9..12 bits resolution, respectively.
+DS1721 - 93ms..750ms for 9..12 bits resolution, respectively.
+DS1731 - 93ms..750ms for 9..12 bits resolution, respectively.
+
+Note:
+On the DS1621, internal access to non-volatile registers may last for 10ms
+or less (unverified on the other devices).
+
+Temperature Accuracy:
+---------------------
+DS1621: +/- 0.5 degree Celsius (from 0 to +70 degrees)
+DS1625: +/- 0.5 degree Celsius (from 0 to +70 degrees)
+DS1631: +/- 0.5 degree Celsius (from 0 to +70 degrees)
+DS1721: +/- 1.0 degree Celsius (from -10 to +85 degrees)
+DS1731: +/- 1.0 degree Celsius (from -10 to +85 degrees)
+
+Note:
+Please refer to the device datasheets for accuracy at other temperatures.
+
+Temperature Resolution:
+-----------------------
+As mentioned above, the DS1631, DS1721, and DS1731 provide multi-resolution
+support, which is achieved via the R0 and R1 config register bits, where:
+
+R0..R1
+------
+ 0 0 => 9 bits, 0.5 degrees Celcius
+ 1 0 => 10 bits, 0.25 degrees Celcius
+ 0 1 => 11 bits, 0.125 degrees Celcius
+ 1 1 => 12 bits, 0.0625 degrees Celcius
+
+Note:
+At initial device power-on, the default resolution is set to 12-bits.
+
+The resolution mode for the DS1631, DS1721, or DS1731 can be changed from
+userspace, via the device 'update_interval' sysfs attribute. This attribute
+will normalize the range of input values to the device maximum resolution
+values defined in the datasheet as follows:
+
+Resolution Conversion Time Input Range
+ (C/LSB) (msec) (msec)
+------------------------------------------------
+0.5 93.75 0....94
+0.25 187.5 95...187
+0.125 375 188..375
+0.0625 750 376..infinity
+------------------------------------------------
+
+The following examples show how the 'update_interval' attribute can be
+used to change the conversion time:
+
+$ cat update_interval
+750
+$ cat temp1_input
+22062
+$
+$ echo 300 > update_interval
+$ cat update_interval
+375
+$ cat temp1_input
+22125
+$
+$ echo 150 > update_interval
+$ cat update_interval
+188
+$ cat temp1_input
+22250
+$
+$ echo 1 > update_interval
+$ cat update_interval
+94
+$ cat temp1_input
+22000
+$
+$ echo 1000 > update_interval
+$ cat update_interval
+750
+$ cat temp1_input
+22062
+$
+
+As shown, the ds1621 driver automatically adjusts the 'update_interval'
+user input, via a step function. Reading back the 'update_interval' value
+after a write operation provides the conversion time used by the device.
+
+Mathematically, the resolution can be derived from the conversion time
+via the following function:
+
+ g(x) = 0.5 * [minimum_conversion_time/x]
+
+where:
+ -> 'x' = the output from 'update_interval'
+ -> 'g(x)' = the resolution in degrees C per LSB.
+ -> 93.75ms = minimum conversion time
diff --git a/Documentation/hwmon/g762 b/Documentation/hwmon/g762
new file mode 100644
index 0000000..923db9c
--- /dev/null
+++ b/Documentation/hwmon/g762
@@ -0,0 +1,65 @@
+Kernel driver g762
+==================
+
+The GMT G762 Fan Speed PWM Controller is connected directly to a fan
+and performs closed-loop or open-loop control of the fan speed. Two
+modes - PWM or DC - are supported by the device.
+
+For additional information, a detailed datasheet is available at
+http://natisbad.org/NAS/ref/GMT_EDS-762_763-080710-0.2.pdf. sysfs
+bindings are described in Documentation/hwmon/sysfs-interface.
+
+The following entries are available to the user in a subdirectory of
+/sys/bus/i2c/drivers/g762/ to control the operation of the device.
+This can be done manually using the following entries but is usually
+done via a userland daemon like fancontrol.
+
+Note that those entries do not provide ways to setup the specific
+hardware characteristics of the system (reference clock, pulses per
+fan revolution, ...); Those can be modified via devicetree bindings
+documented in Documentation/devicetree/bindings/hwmon/g762.txt or
+using a specific platform_data structure in board initialization
+file (see include/linux/platform_data/g762.h).
+
+ fan1_target: set desired fan speed. This only makes sense in closed-loop
+ fan speed control (i.e. when pwm1_enable is set to 2).
+
+ fan1_input: provide current fan rotation value in RPM as reported by
+ the fan to the device.
+
+ fan1_div: fan clock divisor. Supported value are 1, 2, 4 and 8.
+
+ fan1_pulses: number of pulses per fan revolution. Supported values
+ are 2 and 4.
+
+ fan1_fault: reports fan failure, i.e. no transition on fan gear pin for
+ about 0.7s (if the fan is not voluntarily set off).
+
+ fan1_alarm: in closed-loop control mode, if fan RPM value is 25% out
+ of the programmed value for over 6 seconds 'fan1_alarm' is
+ set to 1.
+
+ pwm1_enable: set current fan speed control mode i.e. 1 for manual fan
+ speed control (open-loop) via pwm1 described below, 2 for
+ automatic fan speed control (closed-loop) via fan1_target
+ above.
+
+ pwm1_mode: set or get fan driving mode: 1 for PWM mode, 0 for DC mode.
+
+ pwm1: get or set PWM fan control value in open-loop mode. This is an
+ integer value between 0 and 255. 0 stops the fan, 255 makes
+ it run at full speed.
+
+Both in PWM mode ('pwm1_mode' set to 1) and DC mode ('pwm1_mode' set to 0),
+when current fan speed control mode is open-loop ('pwm1_enable' set to 1),
+the fan speed is programmed by setting a value between 0 and 255 via 'pwm1'
+entry (0 stops the fan, 255 makes it run at full speed). In closed-loop mode
+('pwm1_enable' set to 2), the expected rotation speed in RPM can be passed to
+the chip via 'fan1_target'. In closed-loop mode, the target speed is compared
+with current speed (available via 'fan1_input') by the device and a feedback
+is performed to match that target value. The fan speed value is computed
+based on the parameters associated with the physical characteristics of the
+system: a reference clock source frequency, a number of pulses per fan
+revolution, etc.
+
+Note that the driver will update its values at most once per second.
diff --git a/Documentation/hwmon/ina209 b/Documentation/hwmon/ina209
new file mode 100644
index 0000000..672501d
--- /dev/null
+++ b/Documentation/hwmon/ina209
@@ -0,0 +1,93 @@
+Kernel driver ina209
+=====================
+
+Supported chips:
+ * Burr-Brown / Texas Instruments INA209
+ Prefix: 'ina209'
+ Addresses scanned: -
+ Datasheet:
+ http://www.ti.com/lit/gpn/ina209
+
+Author: Paul Hays <Paul.Hays@cattail.ca>
+Author: Ira W. Snyder <iws@ovro.caltech.edu>
+Author: Guenter Roeck <linux@roeck-us.net>
+
+
+Description
+-----------
+
+The TI / Burr-Brown INA209 monitors voltage, current, and power on the high side
+of a D.C. power supply. It can perform measurements and calculations in the
+background to supply readings at any time. It includes a programmable
+calibration multiplier to scale the displayed current and power values.
+
+
+Sysfs entries
+-------------
+
+The INA209 chip is highly configurable both via hardwiring and via
+the I2C bus. See the datasheet for details.
+
+This tries to expose most monitoring features of the hardware via
+sysfs. It does not support every feature of this chip.
+
+
+in0_input shunt voltage (mV)
+in0_input_highest shunt voltage historical maximum reading (mV)
+in0_input_lowest shunt voltage historical minimum reading (mV)
+in0_reset_history reset shunt voltage history
+in0_max shunt voltage max alarm limit (mV)
+in0_min shunt voltage min alarm limit (mV)
+in0_crit_max shunt voltage crit max alarm limit (mV)
+in0_crit_min shunt voltage crit min alarm limit (mV)
+in0_max_alarm shunt voltage max alarm limit exceeded
+in0_min_alarm shunt voltage min alarm limit exceeded
+in0_crit_max_alarm shunt voltage crit max alarm limit exceeded
+in0_crit_min_alarm shunt voltage crit min alarm limit exceeded
+
+in1_input bus voltage (mV)
+in1_input_highest bus voltage historical maximum reading (mV)
+in1_input_lowest bus voltage historical minimum reading (mV)
+in1_reset_history reset bus voltage history
+in1_max bus voltage max alarm limit (mV)
+in1_min bus voltage min alarm limit (mV)
+in1_crit_max bus voltage crit max alarm limit (mV)
+in1_crit_min bus voltage crit min alarm limit (mV)
+in1_max_alarm bus voltage max alarm limit exceeded
+in1_min_alarm bus voltage min alarm limit exceeded
+in1_crit_max_alarm bus voltage crit max alarm limit exceeded
+in1_crit_min_alarm bus voltage crit min alarm limit exceeded
+
+power1_input power measurement (uW)
+power1_input_highest power historical maximum reading (uW)
+power1_reset_history reset power history
+power1_max power max alarm limit (uW)
+power1_crit power crit alarm limit (uW)
+power1_max_alarm power max alarm limit exceeded
+power1_crit_alarm power crit alarm limit exceeded
+
+curr1_input current measurement (mA)
+
+update_interval data conversion time; affects number of samples used
+ to average results for shunt and bus voltages.
+
+General Remarks
+---------------
+
+The power and current registers in this chip require that the calibration
+register is programmed correctly before they are used. Normally this is expected
+to be done in the BIOS. In the absence of BIOS programming, the shunt resistor
+voltage can be provided using platform data. The driver uses platform data from
+the ina2xx driver for this purpose. If calibration register data is not provided
+via platform data, the driver checks if the calibration register has been
+programmed (ie has a value not equal to zero). If so, this value is retained.
+Otherwise, a default value reflecting a shunt resistor value of 10 mOhm is
+programmed into the calibration register.
+
+
+Output Pins
+-----------
+
+Output pin programming is a board feature which depends on the BIOS. It is
+outside the scope of a hardware monitoring driver to enable or disable output
+pins.
diff --git a/Documentation/hwmon/ina2xx b/Documentation/hwmon/ina2xx
index 03444f9..4223c2d 100644
--- a/Documentation/hwmon/ina2xx
+++ b/Documentation/hwmon/ina2xx
@@ -44,4 +44,6 @@
The INA230 is a high or low side current shunt and power monitor with an I2C
interface. The INA230 monitors both a shunt voltage drop and bus supply voltage.
-The shunt value in micro-ohms can be set via platform data.
+The shunt value in micro-ohms can be set via platform data or device tree.
+Please refer to the Documentation/devicetree/bindings/i2c/ina2xx.txt for bindings
+if the device tree is used.
diff --git a/Documentation/hwmon/it87 b/Documentation/hwmon/it87
index 8386aad..c263740 100644
--- a/Documentation/hwmon/it87
+++ b/Documentation/hwmon/it87
@@ -30,6 +30,14 @@
Prefix: 'it8728'
Addresses scanned: from Super I/O config space (8 I/O ports)
Datasheet: Not publicly available
+ * IT8771E
+ Prefix: 'it8771'
+ Addresses scanned: from Super I/O config space (8 I/O ports)
+ Datasheet: Not publicly available
+ * IT8772E
+ Prefix: 'it8772'
+ Addresses scanned: from Super I/O config space (8 I/O ports)
+ Datasheet: Not publicly available
* IT8782F
Prefix: 'it8782'
Addresses scanned: from Super I/O config space (8 I/O ports)
@@ -83,8 +91,8 @@
-----------
This driver implements support for the IT8705F, IT8712F, IT8716F,
-IT8718F, IT8720F, IT8721F, IT8726F, IT8728F, IT8758E, IT8781F, IT8782F,
-IT8783E/F, and SiS950 chips.
+IT8718F, IT8720F, IT8721F, IT8726F, IT8728F, IT8758E, IT8771E, IT8772E,
+IT8782F, IT8783E/F, and SiS950 chips.
These chips are 'Super I/O chips', supporting floppy disks, infrared ports,
joysticks and other miscellaneous stuff. For hardware monitoring, they
@@ -118,8 +126,8 @@
for AMD power sequencing. Therefore the chip will appear as IT8716F
to userspace applications.
-The IT8728F is considered compatible with the IT8721F, until a datasheet
-becomes available (hopefully.)
+The IT8728F, IT8771E, and IT8772E are considered compatible with the IT8721F,
+until a datasheet becomes available (hopefully.)
Temperatures are measured in degrees Celsius. An alarm is triggered once
when the Overtemperature Shutdown limit is crossed.
diff --git a/Documentation/hwmon/jc42 b/Documentation/hwmon/jc42
index 66ecb9f..868d74d 100644
--- a/Documentation/hwmon/jc42
+++ b/Documentation/hwmon/jc42
@@ -17,12 +17,13 @@
* Maxim MAX6604
Datasheets:
http://datasheets.maxim-ic.com/en/ds/MAX6604.pdf
- * Microchip MCP9804, MCP9805, MCP98242, MCP98243, MCP9843
+ * Microchip MCP9804, MCP9805, MCP98242, MCP98243, MCP98244, MCP9843
Datasheets:
http://ww1.microchip.com/downloads/en/DeviceDoc/22203C.pdf
http://ww1.microchip.com/downloads/en/DeviceDoc/21977b.pdf
http://ww1.microchip.com/downloads/en/DeviceDoc/21996a.pdf
http://ww1.microchip.com/downloads/en/DeviceDoc/22153c.pdf
+ http://ww1.microchip.com/downloads/en/DeviceDoc/22327A.pdf
* NXP Semiconductors SE97, SE97B, SE98, SE98A
Datasheets:
http://www.nxp.com/documents/data_sheet/SE97.pdf
@@ -48,7 +49,7 @@
Addresses scanned: I2C 0x18 - 0x1f
Author:
- Guenter Roeck <guenter.roeck@ericsson.com>
+ Guenter Roeck <linux@roeck-us.net>
Description
diff --git a/Documentation/hwmon/lineage-pem b/Documentation/hwmon/lineage-pem
index 2ba5ed1..83b2ddc 100644
--- a/Documentation/hwmon/lineage-pem
+++ b/Documentation/hwmon/lineage-pem
@@ -8,7 +8,7 @@
Documentation:
http://www.lineagepower.com/oem/pdf/CPLI2C.pdf
-Author: Guenter Roeck <guenter.roeck@ericsson.com>
+Author: Guenter Roeck <linux@roeck-us.net>
Description
diff --git a/Documentation/hwmon/lm25066 b/Documentation/hwmon/lm25066
index a21db81..c1b57d7 100644
--- a/Documentation/hwmon/lm25066
+++ b/Documentation/hwmon/lm25066
@@ -1,7 +1,13 @@
-Kernel driver max8688
+Kernel driver lm25066
=====================
Supported chips:
+ * TI LM25056
+ Prefix: 'lm25056'
+ Addresses scanned: -
+ Datasheets:
+ http://www.ti.com/lit/gpn/lm25056
+ http://www.ti.com/lit/gpn/lm25056a
* National Semiconductor LM25066
Prefix: 'lm25066'
Addresses scanned: -
@@ -19,14 +25,15 @@
Datasheet:
http://www.national.com/pf/LM/LM5066.html
-Author: Guenter Roeck <guenter.roeck@ericsson.com>
+Author: Guenter Roeck <linux@roeck-us.net>
Description
-----------
-This driver supports hardware montoring for National Semiconductor LM25066,
-LM5064, and LM5064 Power Management, Monitoring, Control, and Protection ICs.
+This driver supports hardware montoring for National Semiconductor / TI LM25056,
+LM25066, LM5064, and LM5064 Power Management, Monitoring, Control, and
+Protection ICs.
The driver is a client driver to the core PMBus driver. Please see
Documentation/hwmon/pmbus for details on PMBus client drivers.
@@ -60,14 +67,19 @@
in1_min_alarm Input voltage low alarm.
in1_max_alarm Input voltage high alarm.
-in2_label "vout1"
-in2_input Measured output voltage.
-in2_average Average measured output voltage.
-in2_min Minimum output voltage.
-in2_min_alarm Output voltage low alarm.
+in2_label "vmon"
+in2_input Measured voltage on VAUX pin
+in2_min Minimum VAUX voltage (LM25056 only).
+in2_max Maximum VAUX voltage (LM25056 only).
+in2_min_alarm VAUX voltage low alarm (LM25056 only).
+in2_max_alarm VAUX voltage high alarm (LM25056 only).
-in3_label "vout2"
-in3_input Measured voltage on vaux pin
+in3_label "vout1"
+ Not supported on LM25056.
+in3_input Measured output voltage.
+in3_average Average measured output voltage.
+in3_min Minimum output voltage.
+in3_min_alarm Output voltage low alarm.
curr1_label "iin"
curr1_input Measured input current.
diff --git a/Documentation/hwmon/lm73 b/Documentation/hwmon/lm73
new file mode 100644
index 0000000..8af059d
--- /dev/null
+++ b/Documentation/hwmon/lm73
@@ -0,0 +1,90 @@
+Kernel driver lm73
+==================
+
+Supported chips:
+ * Texas Instruments LM73
+ Prefix: 'lm73'
+ Addresses scanned: I2C 0x48, 0x49, 0x4a, 0x4c, 0x4d, and 0x4e
+ Datasheet: Publicly available at the Texas Instruments website
+ http://www.ti.com/product/lm73
+
+Author: Guillaume Ligneul <guillaume.ligneul@gmail.com>
+Documentation: Chris Verges <kg4ysn@gmail.com>
+
+
+Description
+-----------
+
+The LM73 is a digital temperature sensor. All temperature values are
+given in degrees Celsius.
+
+Measurement Resolution Support
+------------------------------
+
+The LM73 supports four resolutions, defined in terms of degrees C per
+LSB: 0.25, 0.125, 0.0625, and 0.3125. Changing the resolution mode
+affects the conversion time of the LM73's analog-to-digital converter.
+From userspace, the desired resolution can be specified as a function of
+conversion time via the 'update_interval' sysfs attribute for the
+device. This attribute will normalize ranges of input values to the
+maximum times defined for the resolution in the datasheet.
+
+ Resolution Conv. Time Input Range
+ (C/LSB) (msec) (msec)
+ --------------------------------------
+ 0.25 14 0..14
+ 0.125 28 15..28
+ 0.0625 56 29..56
+ 0.03125 112 57..infinity
+ --------------------------------------
+
+The following examples show how the 'update_interval' attribute can be
+used to change the conversion time:
+
+ $ echo 0 > update_interval
+ $ cat update_interval
+ 14
+ $ cat temp1_input
+ 24250
+
+ $ echo 22 > update_interval
+ $ cat update_interval
+ 28
+ $ cat temp1_input
+ 24125
+
+ $ echo 56 > update_interval
+ $ cat update_interval
+ 56
+ $ cat temp1_input
+ 24062
+
+ $ echo 85 > update_interval
+ $ cat update_interval
+ 112
+ $ cat temp1_input
+ 24031
+
+As shown here, the lm73 driver automatically adjusts any user input for
+'update_interval' via a step function. Reading back the
+'update_interval' value after a write operation will confirm the
+conversion time actively in use.
+
+Mathematically, the resolution can be derived from the conversion time
+via the following function:
+
+ g(x) = 0.250 * [log(x/14) / log(2)]
+
+where 'x' is the output from 'update_interval' and 'g(x)' is the
+resolution in degrees C per LSB.
+
+Alarm Support
+-------------
+
+The LM73 features a simple over-temperature alarm mechanism. This
+feature is exposed via the sysfs attributes.
+
+The attributes 'temp1_max_alarm' and 'temp1_min_alarm' are flags
+provided by the LM73 that indicate whether the measured temperature has
+passed the 'temp1_max' and 'temp1_min' thresholds, respectively. These
+values _must_ be read to clear the registers on the LM73.
diff --git a/Documentation/hwmon/lm75 b/Documentation/hwmon/lm75
index c91a1d1..2560a9c 100644
--- a/Documentation/hwmon/lm75
+++ b/Documentation/hwmon/lm75
@@ -12,18 +12,18 @@
Addresses scanned: I2C 0x48 - 0x4f
Datasheet: Publicly available at the National Semiconductor website
http://www.national.com/
- * Dallas Semiconductor DS75, DS1775
- Prefixes: 'ds75', 'ds1775'
+ * Dallas Semiconductor (now Maxim) DS75, DS1775, DS7505
+ Prefixes: 'ds75', 'ds1775', 'ds7505'
Addresses scanned: none
- Datasheet: Publicly available at the Dallas Semiconductor website
- http://www.maxim-ic.com/
+ Datasheet: Publicly available at the Maxim website
+ http://www.maximintegrated.com/
* Maxim MAX6625, MAX6626
Prefixes: 'max6625', 'max6626'
Addresses scanned: none
Datasheet: Publicly available at the Maxim website
http://www.maxim-ic.com/
* Microchip (TelCom) TCN75
- Prefix: 'lm75'
+ Prefix: 'tcn75'
Addresses scanned: none
Datasheet: Publicly available at the Microchip website
http://www.microchip.com/
@@ -67,7 +67,8 @@
All temperatures are in degrees Celsius, and are guaranteed within a
range of -55 to +125 degrees.
-The LM75 only updates its values each 1.5 seconds; reading it more often
+The driver caches the values for a period varying between 1 second for the
+slowest chips and 125 ms for the fastest chips; reading it more often
will do no harm, but will return 'old' values.
The original LM75 was typically used in combination with LM78-like chips
@@ -78,8 +79,8 @@
LM75 clones not listed here, with or without various enhancements,
that are supported. The clones are not detected by the driver, unless
they reproduce the exact register tricks of the original LM75, and must
-therefore be instantiated explicitly. The specific enhancements (such as
-higher resolution) are not currently supported by the driver.
+therefore be instantiated explicitly. Higher resolution up to 12-bit
+is supported by this driver, other specific enhancements are not.
The LM77 is not supported, contrary to what we pretended for a long time.
Both chips are simply not compatible, value encoding differs.
diff --git a/Documentation/hwmon/lm95234 b/Documentation/hwmon/lm95234
new file mode 100644
index 0000000..a0e95dd
--- /dev/null
+++ b/Documentation/hwmon/lm95234
@@ -0,0 +1,36 @@
+Kernel driver lm95234
+=====================
+
+Supported chips:
+ * National Semiconductor / Texas Instruments LM95234
+ Addresses scanned: I2C 0x18, 0x4d, 0x4e
+ Datasheet: Publicly available at the Texas Instruments website
+ http://www.ti.com/product/lm95234
+
+
+Author: Guenter Roeck <linux@roeck-us.net>
+
+Description
+-----------
+
+LM95234 is an 11-bit digital temperature sensor with a 2-wire System Management
+Bus (SMBus) interface and TrueTherm technology that can very accurately monitor
+the temperature of four remote diodes as well as its own temperature.
+The four remote diodes can be external devices such as microprocessors,
+graphics processors or diode-connected 2N3904s. The LM95234's TruTherm
+beta compensation technology allows sensing of 90 nm or 65 nm process
+thermal diodes accurately.
+
+All temperature values are given in millidegrees Celsius. Temperature
+is provided within a range of -127 to +255 degrees (+127.875 degrees for
+the internal sensor). Resolution depends on temperature input and range.
+
+Each sensor has its own maximum limit, but the hysteresis is common to all
+channels. The hysteresis is configurable with the tem1_max_hyst attribute and
+affects the hysteresis on all channels. The first two external sensors also
+have a critical limit.
+
+The lm95234 driver can change its update interval to a fixed set of values.
+It will round up to the next selectable interval. See the datasheet for exact
+values. Reading sensor values more often will do no harm, but will return
+'old' values.
diff --git a/Documentation/hwmon/ltc2978 b/Documentation/hwmon/ltc2978
index c365f9b..dc0d08c 100644
--- a/Documentation/hwmon/ltc2978
+++ b/Documentation/hwmon/ltc2978
@@ -2,24 +2,32 @@
=====================
Supported chips:
+ * Linear Technology LTC2974
+ Prefix: 'ltc2974'
+ Addresses scanned: -
+ Datasheet: http://www.linear.com/product/ltc2974
* Linear Technology LTC2978
Prefix: 'ltc2978'
Addresses scanned: -
- Datasheet: http://cds.linear.com/docs/Datasheet/2978fa.pdf
+ Datasheet: http://www.linear.com/product/ltc2978
* Linear Technology LTC3880
Prefix: 'ltc3880'
Addresses scanned: -
- Datasheet: http://cds.linear.com/docs/Datasheet/3880f.pdf
+ Datasheet: http://www.linear.com/product/ltc3880
+ * Linear Technology LTC3883
+ Prefix: 'ltc3883'
+ Addresses scanned: -
+ Datasheet: http://www.linear.com/product/ltc3883
-Author: Guenter Roeck <guenter.roeck@ericsson.com>
+Author: Guenter Roeck <linux@roeck-us.net>
Description
-----------
-The LTC2978 is an octal power supply monitor, supervisor, sequencer and
-margin controller. The LTC3880 is a dual, PolyPhase DC/DC synchronous
-step-down switching regulator controller.
+LTC2974 is a quad digital power supply manager. LTC2978 is an octal power supply
+monitor. LTC3880 is a dual output poly-phase step-down DC/DC controller. LTC3883
+is a single phase step-down DC/DC controller.
Usage Notes
@@ -41,63 +49,90 @@
in1_label "vin"
in1_input Measured input voltage.
in1_min Minimum input voltage.
-in1_max Maximum input voltage.
-in1_lcrit Critical minimum input voltage.
+in1_max Maximum input voltage. LTC2974 and LTC2978 only.
+in1_lcrit Critical minimum input voltage. LTC2974 and LTC2978
+ only.
in1_crit Critical maximum input voltage.
in1_min_alarm Input voltage low alarm.
-in1_max_alarm Input voltage high alarm.
-in1_lcrit_alarm Input voltage critical low alarm.
+in1_max_alarm Input voltage high alarm. LTC2974 and LTC2978 only.
+in1_lcrit_alarm Input voltage critical low alarm. LTC2974 and LTC2978
+ only.
in1_crit_alarm Input voltage critical high alarm.
-in1_lowest Lowest input voltage. LTC2978 only.
+in1_lowest Lowest input voltage. LTC2974 and LTC2978 only.
in1_highest Highest input voltage.
-in1_reset_history Reset history. Writing into this attribute will reset
- history for all attributes.
+in1_reset_history Reset input voltage history.
-in[2-9]_label "vout[1-8]". Channels 3 to 9 on LTC2978 only.
-in[2-9]_input Measured output voltage.
-in[2-9]_min Minimum output voltage.
-in[2-9]_max Maximum output voltage.
-in[2-9]_lcrit Critical minimum output voltage.
-in[2-9]_crit Critical maximum output voltage.
-in[2-9]_min_alarm Output voltage low alarm.
-in[2-9]_max_alarm Output voltage high alarm.
-in[2-9]_lcrit_alarm Output voltage critical low alarm.
-in[2-9]_crit_alarm Output voltage critical high alarm.
-in[2-9]_lowest Lowest output voltage. LTC2978 only.
-in[2-9]_highest Lowest output voltage.
-in[2-9]_reset_history Reset history. Writing into this attribute will reset
- history for all attributes.
+in[N]_label "vout[1-8]".
+ LTC2974: N=2-5
+ LTC2978: N=2-9
+ LTC3880: N=2-3
+ LTC3883: N=2
+in[N]_input Measured output voltage.
+in[N]_min Minimum output voltage.
+in[N]_max Maximum output voltage.
+in[N]_lcrit Critical minimum output voltage.
+in[N]_crit Critical maximum output voltage.
+in[N]_min_alarm Output voltage low alarm.
+in[N]_max_alarm Output voltage high alarm.
+in[N]_lcrit_alarm Output voltage critical low alarm.
+in[N]_crit_alarm Output voltage critical high alarm.
+in[N]_lowest Lowest output voltage. LTC2974 and LTC2978 only.
+in[N]_highest Highest output voltage.
+in[N]_reset_history Reset output voltage history.
-temp[1-3]_input Measured temperature.
+temp[N]_input Measured temperature.
+ On LTC2974, temp[1-4] report external temperatures,
+ and temp5 reports the chip temperature.
On LTC2978, only one temperature measurement is
- supported and reflects the internal temperature.
+ supported and reports the chip temperature.
On LTC3880, temp1 and temp2 report external
- temperatures, and temp3 reports the internal
- temperature.
-temp[1-3]_min Mimimum temperature.
-temp[1-3]_max Maximum temperature.
-temp[1-3]_lcrit Critical low temperature.
-temp[1-3]_crit Critical high temperature.
-temp[1-3]_min_alarm Chip temperature low alarm.
-temp[1-3]_max_alarm Chip temperature high alarm.
-temp[1-3]_lcrit_alarm Chip temperature critical low alarm.
-temp[1-3]_crit_alarm Chip temperature critical high alarm.
-temp[1-3]_lowest Lowest measured temperature. LTC2978 only.
-temp[1-3]_highest Highest measured temperature.
-temp[1-3]_reset_history Reset history. Writing into this attribute will reset
- history for all attributes.
+ temperatures, and temp3 reports the chip temperature.
+ On LTC3883, temp1 reports an external temperature,
+ and temp2 reports the chip temperature.
+temp[N]_min Mimimum temperature. LTC2974 and LTC2978 only.
+temp[N]_max Maximum temperature.
+temp[N]_lcrit Critical low temperature.
+temp[N]_crit Critical high temperature.
+temp[N]_min_alarm Temperature low alarm. LTC2974 and LTC2978 only.
+temp[N]_max_alarm Temperature high alarm.
+temp[N]_lcrit_alarm Temperature critical low alarm.
+temp[N]_crit_alarm Temperature critical high alarm.
+temp[N]_lowest Lowest measured temperature. LTC2974 and LTC2978 only.
+ Not supported for chip temperature sensor on LTC2974.
+temp[N]_highest Highest measured temperature. Not supported for chip
+ temperature sensor on LTC2974.
+temp[N]_reset_history Reset temperature history. Not supported for chip
+ temperature sensor on LTC2974.
-power[1-2]_label "pout[1-2]". LTC3880 only.
-power[1-2]_input Measured power.
+power1_label "pin". LTC3883 only.
+power1_input Measured input power.
-curr1_label "iin". LTC3880 only.
+power[N]_label "pout[1-4]".
+ LTC2974: N=1-4
+ LTC2978: Not supported
+ LTC3880: N=1-2
+ LTC3883: N=2
+power[N]_input Measured output power.
+
+curr1_label "iin". LTC3880 and LTC3883 only.
curr1_input Measured input current.
curr1_max Maximum input current.
curr1_max_alarm Input current high alarm.
+curr1_highest Highest input current. LTC3883 only.
+curr1_reset_history Reset input current history. LTC3883 only.
-curr[2-3]_label "iout[1-2]". LTC3880 only.
-curr[2-3]_input Measured input current.
-curr[2-3]_max Maximum input current.
-curr[2-3]_crit Critical input current.
-curr[2-3]_max_alarm Input current high alarm.
-curr[2-3]_crit_alarm Input current critical high alarm.
+curr[N]_label "iout[1-4]".
+ LTC2974: N=1-4
+ LTC2978: not supported
+ LTC3880: N=2-3
+ LTC3883: N=2
+curr[N]_input Measured output current.
+curr[N]_max Maximum output current.
+curr[N]_crit Critical high output current.
+curr[N]_lcrit Critical low output current. LTC2974 only.
+curr[N]_max_alarm Output current high alarm.
+curr[N]_crit_alarm Output current critical high alarm.
+curr[N]_lcrit_alarm Output current critical low alarm. LTC2974 only.
+curr[N]_lowest Lowest output current. LTC2974 only.
+curr[N]_highest Highest output current.
+curr[N]_reset_history Reset output current history.
diff --git a/Documentation/hwmon/ltc4261 b/Documentation/hwmon/ltc4261
index eba2e2c..9378a75 100644
--- a/Documentation/hwmon/ltc4261
+++ b/Documentation/hwmon/ltc4261
@@ -8,7 +8,7 @@
Datasheet:
http://cds.linear.com/docs/Datasheet/42612fb.pdf
-Author: Guenter Roeck <guenter.roeck@ericsson.com>
+Author: Guenter Roeck <linux@roeck-us.net>
Description
diff --git a/Documentation/hwmon/max16064 b/Documentation/hwmon/max16064
index f8b4780..d59cc78 100644
--- a/Documentation/hwmon/max16064
+++ b/Documentation/hwmon/max16064
@@ -7,7 +7,7 @@
Addresses scanned: -
Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX16064.pdf
-Author: Guenter Roeck <guenter.roeck@ericsson.com>
+Author: Guenter Roeck <linux@roeck-us.net>
Description
diff --git a/Documentation/hwmon/max16065 b/Documentation/hwmon/max16065
index c11f64a..208a29e 100644
--- a/Documentation/hwmon/max16065
+++ b/Documentation/hwmon/max16065
@@ -24,7 +24,7 @@
http://datasheets.maxim-ic.com/en/ds/MAX16070-MAX16071.pdf
-Author: Guenter Roeck <guenter.roeck@ericsson.com>
+Author: Guenter Roeck <linux@roeck-us.net>
Description
diff --git a/Documentation/hwmon/max34440 b/Documentation/hwmon/max34440
index 0448222..37cbf47 100644
--- a/Documentation/hwmon/max34440
+++ b/Documentation/hwmon/max34440
@@ -16,8 +16,18 @@
Prefixes: 'max34446'
Addresses scanned: -
Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX34446.pdf
+ * Maxim MAX34460
+ PMBus 12-Channel Voltage Monitor & Sequencer
+ Prefix: 'max34460'
+ Addresses scanned: -
+ Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX34460.pdf
+ * Maxim MAX34461
+ PMBus 16-Channel Voltage Monitor & Sequencer
+ Prefix: 'max34461'
+ Addresses scanned: -
+ Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX34461.pdf
-Author: Guenter Roeck <guenter.roeck@ericsson.com>
+Author: Guenter Roeck <linux@roeck-us.net>
Description
@@ -26,6 +36,9 @@
This driver supports hardware montoring for Maxim MAX34440 PMBus 6-Channel
Power-Supply Manager, MAX34441 PMBus 5-Channel Power-Supply Manager
and Intelligent Fan Controller, and MAX34446 PMBus Power-Supply Data Logger.
+It also supports the MAX34460 and MAX34461 PMBus Voltage Monitor & Sequencers.
+The MAX34460 supports 12 voltage channels, and the MAX34461 supports 16 voltage
+channels.
The driver is a client driver to the core PMBus driver. Please see
Documentation/hwmon/pmbus for details on PMBus client drivers.
@@ -109,3 +122,6 @@
temp7 and temp8 attributes only exist for MAX34440.
MAX34446 only supports temp[1-3].
+
+MAX34460 supports attribute groups in[1-12] and temp[1-5].
+MAX34461 supports attribute groups in[1-16] and temp[1-5].
diff --git a/Documentation/hwmon/max6697 b/Documentation/hwmon/max6697
new file mode 100644
index 0000000..6594177
--- /dev/null
+++ b/Documentation/hwmon/max6697
@@ -0,0 +1,58 @@
+Kernel driver max6697
+=====================
+
+Supported chips:
+ * Maxim MAX6581
+ Prefix: 'max6581'
+ Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6581.pdf
+ * Maxim MAX6602
+ Prefix: 'max6602'
+ Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6602.pdf
+ * Maxim MAX6622
+ Prefix: 'max6622'
+ Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6622.pdf
+ * Maxim MAX6636
+ Prefix: 'max6636'
+ Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6636.pdf
+ * Maxim MAX6689
+ Prefix: 'max6689'
+ Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6689.pdf
+ * Maxim MAX6693
+ Prefix: 'max6693'
+ Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6693.pdf
+ * Maxim MAX6694
+ Prefix: 'max6694'
+ Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6694.pdf
+ * Maxim MAX6697
+ Prefix: 'max6697'
+ Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6697.pdf
+ * Maxim MAX6698
+ Prefix: 'max6698'
+ Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6698.pdf
+ * Maxim MAX6699
+ Prefix: 'max6699'
+ Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6699.pdf
+
+Author:
+ Guenter Roeck <linux@roeck-us.net>
+
+Description
+-----------
+
+This driver implements support for several MAX6697 compatible temperature sensor
+chips. The chips support one local temperature sensor plus four, six, or seven
+remote temperature sensors. Remote temperature sensors are diode-connected
+thermal transitors, except for MAX6698 which supports three diode-connected
+thermal transistors plus three thermistors in addition to the local temperature
+sensor.
+
+The driver provides the following sysfs attributes. temp1 is the local (chip)
+temperature, temp[2..n] are remote temperatures. The actually supported
+per-channel attributes are chip type and channel dependent.
+
+tempX_input RO temperature
+tempX_max RW temperature maximum threshold
+tempX_max_alarm RO temperature maximum threshold alarm
+tempX_crit RW temperature critical threshold
+tempX_crit_alarm RO temperature critical threshold alarm
+tempX_fault RO temperature diode fault (remote sensors only)
diff --git a/Documentation/hwmon/max8688 b/Documentation/hwmon/max8688
index fe84987..e780786 100644
--- a/Documentation/hwmon/max8688
+++ b/Documentation/hwmon/max8688
@@ -7,7 +7,7 @@
Addresses scanned: -
Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX8688.pdf
-Author: Guenter Roeck <guenter.roeck@ericsson.com>
+Author: Guenter Roeck <linux@roeck-us.net>
Description
diff --git a/Documentation/hwmon/nct6775 b/Documentation/hwmon/nct6775
new file mode 100644
index 0000000..4e9ef60
--- /dev/null
+++ b/Documentation/hwmon/nct6775
@@ -0,0 +1,188 @@
+Note
+====
+
+This driver supersedes the NCT6775F and NCT6776F support in the W83627EHF
+driver.
+
+Kernel driver NCT6775
+=====================
+
+Supported chips:
+ * Nuvoton NCT5572D/NCT6771F/NCT6772F/NCT6775F/W83677HG-I
+ Prefix: 'nct6775'
+ Addresses scanned: ISA address retrieved from Super I/O registers
+ Datasheet: Available from Nuvoton upon request
+ * Nuvoton NCT5577D/NCT6776D/NCT6776F
+ Prefix: 'nct6776'
+ Addresses scanned: ISA address retrieved from Super I/O registers
+ Datasheet: Available from Nuvoton upon request
+ * Nuvoton NCT5532D/NCT6779D
+ Prefix: 'nct6779'
+ Addresses scanned: ISA address retrieved from Super I/O registers
+ Datasheet: Available from Nuvoton upon request
+
+Authors:
+ Guenter Roeck <linux@roeck-us.net>
+
+Description
+-----------
+
+This driver implements support for the Nuvoton NCT6775F, NCT6776F, and NCT6779D
+and compatible super I/O chips.
+
+The chips support up to 25 temperature monitoring sources. Up to 6 of those are
+direct temperature sensor inputs, the others are special sources such as PECI,
+PCH, and SMBUS. Depending on the chip type, 2 to 6 of the temperature sources
+can be monitored and compared against minimum, maximum, and critical
+temperatures. The driver reports up to 10 of the temperatures to the user.
+There are 4 to 5 fan rotation speed sensors, 8 to 15 analog voltage sensors,
+one VID, alarms with beep warnings (control unimplemented), and some automatic
+fan regulation strategies (plus manual fan control mode).
+
+The temperature sensor sources on all chips are configurable. The configured
+source for each of the temperature sensors is provided in tempX_label.
+
+Temperatures are measured in degrees Celsius and measurement resolution is
+either 1 degC or 0.5 degC, depending on the temperature source and
+configuration. An alarm is triggered when the temperature gets higher than
+the high limit; it stays on until the temperature falls below the hysteresis
+value. Alarms are only supported for temp1 to temp6, depending on the chip type.
+
+Fan rotation speeds are reported in RPM (rotations per minute). An alarm is
+triggered if the rotation speed has dropped below a programmable limit. On
+NCT6775F, fan readings can be divided by a programmable divider (1, 2, 4, 8,
+16, 32, 64 or 128) to give the readings more range or accuracy; the other chips
+do not have a fan speed divider. The driver sets the most suitable fan divisor
+itself; specifically, it increases the divider value each time a fan speed
+reading returns an invalid value, and it reduces it if the fan speed reading
+is lower than optimal. Some fans might not be present because they share pins
+with other functions.
+
+Voltage sensors (also known as IN sensors) report their values in millivolts.
+An alarm is triggered if the voltage has crossed a programmable minimum
+or maximum limit.
+
+The driver supports automatic fan control mode known as Thermal Cruise.
+In this mode, the chip attempts to keep the measured temperature in a
+predefined temperature range. If the temperature goes out of range, fan
+is driven slower/faster to reach the predefined range again.
+
+The mode works for fan1-fan5.
+
+sysfs attributes
+----------------
+
+pwm[1-5] - this file stores PWM duty cycle or DC value (fan speed) in range:
+ 0 (lowest speed) to 255 (full)
+
+pwm[1-5]_enable - this file controls mode of fan/temperature control:
+ * 0 Fan control disabled (fans set to maximum speed)
+ * 1 Manual mode, write to pwm[0-5] any value 0-255
+ * 2 "Thermal Cruise" mode
+ * 3 "Fan Speed Cruise" mode
+ * 4 "Smart Fan III" mode (NCT6775F only)
+ * 5 "Smart Fan IV" mode
+
+pwm[1-5]_mode - controls if output is PWM or DC level
+ * 0 DC output
+ * 1 PWM output
+
+Common fan control attributes
+-----------------------------
+
+pwm[1-5]_temp_sel Temperature source. Value is temperature sensor index.
+ For example, select '1' for temp1_input.
+pwm[1-5]_weight_temp_sel
+ Secondary temperature source. Value is temperature
+ sensor index. For example, select '1' for temp1_input.
+ Set to 0 to disable secondary temperature control.
+
+If secondary temperature functionality is enabled, it is controlled with the
+following attributes.
+
+pwm[1-5]_weight_duty_step
+ Duty step size.
+pwm[1-5]_weight_temp_step
+ Temperature step size. With each step over
+ temp_step_base, the value of weight_duty_step is added
+ to the current pwm value.
+pwm[1-5]_weight_temp_step_base
+ Temperature at which secondary temperature control kicks
+ in.
+pwm[1-5]_weight_temp_step_tol
+ Temperature step tolerance.
+
+Thermal Cruise mode (2)
+-----------------------
+
+If the temperature is in the range defined by:
+
+pwm[1-5]_target_temp Target temperature, unit millidegree Celsius
+ (range 0 - 127000)
+pwm[1-5]_temp_tolerance
+ Target temperature tolerance, unit millidegree Celsius
+
+there are no changes to fan speed. Once the temperature leaves the interval, fan
+speed increases (if temperature is higher that desired) or decreases (if
+temperature is lower than desired), using the following limits and time
+intervals.
+
+pwm[1-5]_start fan pwm start value (range 1 - 255), to start fan
+ when the temperature is above defined range.
+pwm[1-5]_floor lowest fan pwm (range 0 - 255) if temperature is below
+ the defined range. If set to 0, the fan is expected to
+ stop if the temperature is below the defined range.
+pwm[1-5]_step_up_time milliseconds before fan speed is increased
+pwm[1-5]_step_down_time milliseconds before fan speed is decreased
+pwm[1-5]_stop_time how many milliseconds must elapse to switch
+ corresponding fan off (when the temperature was below
+ defined range).
+
+Speed Cruise mode (3)
+---------------------
+
+This modes tries to keep the fan speed constant.
+
+fan[1-5]_target Target fan speed
+fan[1-5]_tolerance
+ Target speed tolerance
+
+
+Untested; use at your own risk.
+
+Smart Fan IV mode (5)
+---------------------
+
+This mode offers multiple slopes to control the fan speed. The slopes can be
+controlled by setting the pwm and temperature attributes. When the temperature
+rises, the chip will calculate the DC/PWM output based on the current slope.
+There are up to seven data points depending on the chip type. Subsequent data
+points should be set to higher temperatures and higher pwm values to achieve
+higher fan speeds with increasing temperature. The last data point reflects
+critical temperature mode, in which the fans should run at full speed.
+
+pwm[1-5]_auto_point[1-7]_pwm
+ pwm value to be set if temperature reaches matching
+ temperature range.
+pwm[1-5]_auto_point[1-7]_temp
+ Temperature over which the matching pwm is enabled.
+pwm[1-5]_temp_tolerance
+ Temperature tolerance, unit millidegree Celsius
+pwm[1-5]_crit_temp_tolerance
+ Temperature tolerance for critical temperature,
+ unit millidegree Celsius
+
+pwm[1-5]_step_up_time milliseconds before fan speed is increased
+pwm[1-5]_step_down_time milliseconds before fan speed is decreased
+
+Usage Notes
+-----------
+
+On various ASUS boards with NCT6776F, it appears that CPUTIN is not really
+connected to anything and floats, or that it is connected to some non-standard
+temperature measurement device. As a result, the temperature reported on CPUTIN
+will not reflect a usable value. It often reports unreasonably high
+temperatures, and in some cases the reported temperature declines if the actual
+temperature increases (similar to the raw PECI temperature value - see PECI
+specification for details). CPUTIN should therefore be be ignored on ASUS
+boards. The CPU temperature on ASUS boards is reported from PECI 0.
diff --git a/Documentation/hwmon/pmbus b/Documentation/hwmon/pmbus
index 3d3a0f9..cf756ed 100644
--- a/Documentation/hwmon/pmbus
+++ b/Documentation/hwmon/pmbus
@@ -34,7 +34,7 @@
Addresses scanned: -
Datasheet: n.a.
-Author: Guenter Roeck <guenter.roeck@ericsson.com>
+Author: Guenter Roeck <linux@roeck-us.net>
Description
diff --git a/Documentation/hwmon/sht15 b/Documentation/hwmon/sht15
index 02850bd..778987d 100644
--- a/Documentation/hwmon/sht15
+++ b/Documentation/hwmon/sht15
@@ -40,7 +40,7 @@
The humidity calibration coefficients are programmed into an OTP memory on the
chip. These coefficients are used to internally calibrate the signals from the
sensors. Disabling the reload of those coefficients allows saving 10ms for each
-measurement and decrease power consumption, while loosing on precision.
+measurement and decrease power consumption, while losing on precision.
Some options may be set directly in the sht15_platform_data structure
or via sysfs attributes.
diff --git a/Documentation/hwmon/smm665 b/Documentation/hwmon/smm665
index 59e3161..a341eee 100644
--- a/Documentation/hwmon/smm665
+++ b/Documentation/hwmon/smm665
@@ -29,7 +29,7 @@
http://www.summitmicro.com/prod_select/summary/SMM766/SMM766_2086.pdf
http://www.summitmicro.com/prod_select/summary/SMM766B/SMM766B_2122.pdf
-Author: Guenter Roeck <guenter.roeck@ericsson.com>
+Author: Guenter Roeck <linux@roeck-us.net>
Module Parameters
diff --git a/Documentation/hwmon/submitting-patches b/Documentation/hwmon/submitting-patches
index 843751c..4628646 100644
--- a/Documentation/hwmon/submitting-patches
+++ b/Documentation/hwmon/submitting-patches
@@ -27,8 +27,7 @@
explicitly below the patch header.
* If your patch (or the driver) is affected by configuration options such as
- CONFIG_SMP or CONFIG_HOTPLUG, make sure it compiles for all configuration
- variants.
+ CONFIG_SMP, make sure it compiles for all configuration variants.
2. Adding functionality to existing drivers
diff --git a/Documentation/hwmon/sysfs-interface b/Documentation/hwmon/sysfs-interface
index 1f4dd85..79f8257 100644
--- a/Documentation/hwmon/sysfs-interface
+++ b/Documentation/hwmon/sysfs-interface
@@ -722,14 +722,14 @@
What to do if a value is found to be invalid, depends on the type of the
sysfs attribute that is being set. If it is a continuous setting like a
tempX_max or inX_max attribute, then the value should be clamped to its
-limits using SENSORS_LIMIT(value, min_limit, max_limit). If it is not
-continuous like for example a tempX_type, then when an invalid value is
-written, -EINVAL should be returned.
+limits using clamp_val(value, min_limit, max_limit). If it is not continuous
+like for example a tempX_type, then when an invalid value is written,
+-EINVAL should be returned.
Example1, temp1_max, register is a signed 8 bit value (-128 - 127 degrees):
long v = simple_strtol(buf, NULL, 10) / 1000;
- v = SENSORS_LIMIT(v, -128, 127);
+ v = clamp_val(v, -128, 127);
/* write v to register */
Example2, fan divider setting, valid values 2, 4 and 8:
diff --git a/Documentation/hwmon/tmp401 b/Documentation/hwmon/tmp401
index 9fc4472..f91e3fa 100644
--- a/Documentation/hwmon/tmp401
+++ b/Documentation/hwmon/tmp401
@@ -8,8 +8,16 @@
Datasheet: http://focus.ti.com/docs/prod/folders/print/tmp401.html
* Texas Instruments TMP411
Prefix: 'tmp411'
- Addresses scanned: I2C 0x4c
+ Addresses scanned: I2C 0x4c, 0x4d, 0x4e
Datasheet: http://focus.ti.com/docs/prod/folders/print/tmp411.html
+ * Texas Instruments TMP431
+ Prefix: 'tmp431'
+ Addresses scanned: I2C 0x4c, 0x4d
+ Datasheet: http://focus.ti.com/docs/prod/folders/print/tmp431.html
+ * Texas Instruments TMP432
+ Prefix: 'tmp432'
+ Addresses scanned: I2C 0x4c, 0x4d
+ Datasheet: http://focus.ti.com/docs/prod/folders/print/tmp432.html
Authors:
Hans de Goede <hdegoede@redhat.com>
@@ -18,19 +26,19 @@
Description
-----------
-This driver implements support for Texas Instruments TMP401 and
-TMP411 chips. These chips implements one remote and one local
-temperature sensor. Temperature is measured in degrees
+This driver implements support for Texas Instruments TMP401, TMP411,
+TMP431, and TMP432 chips. These chips implement one or two remote and
+one local temperature sensors. Temperature is measured in degrees
Celsius. Resolution of the remote sensor is 0.0625 degree. Local
sensor resolution can be set to 0.5, 0.25, 0.125 or 0.0625 degree (not
supported by the driver so far, so using the default resolution of 0.5
degree).
The driver provides the common sysfs-interface for temperatures (see
-/Documentation/hwmon/sysfs-interface under Temperatures).
+Documentation/hwmon/sysfs-interface under Temperatures).
-The TMP411 chip is compatible with TMP401. It provides some additional
-features.
+The TMP411 and TMP431 chips are compatible with TMP401. TMP411 provides
+some additional features.
* Minimum and Maximum temperature measured since power-on, chip-reset
@@ -40,3 +48,6 @@
Exported via sysfs attribute temp_reset_history. Writing 1 to this
file triggers a reset.
+
+TMP432 is compatible with TMP401 and TMP431. It supports two external
+temperature sensors.
diff --git a/Documentation/hwmon/ucd9000 b/Documentation/hwmon/ucd9000
index 0df5f27..805e33e 100644
--- a/Documentation/hwmon/ucd9000
+++ b/Documentation/hwmon/ucd9000
@@ -11,7 +11,7 @@
http://focus.ti.com/lit/ds/symlink/ucd9090.pdf
http://focus.ti.com/lit/ds/symlink/ucd90910.pdf
-Author: Guenter Roeck <guenter.roeck@ericsson.com>
+Author: Guenter Roeck <linux@roeck-us.net>
Description
diff --git a/Documentation/hwmon/ucd9200 b/Documentation/hwmon/ucd9200
index fd7d07b..1e8060e 100644
--- a/Documentation/hwmon/ucd9200
+++ b/Documentation/hwmon/ucd9200
@@ -15,7 +15,7 @@
http://focus.ti.com/lit/ds/symlink/ucd9246.pdf
http://focus.ti.com/lit/ds/symlink/ucd9248.pdf
-Author: Guenter Roeck <guenter.roeck@ericsson.com>
+Author: Guenter Roeck <linux@roeck-us.net>
Description
diff --git a/Documentation/hwmon/zl6100 b/Documentation/hwmon/zl6100
index a995b41..33908a4 100644
--- a/Documentation/hwmon/zl6100
+++ b/Documentation/hwmon/zl6100
@@ -54,7 +54,7 @@
http://archive.ericsson.net/service/internet/picov/get?DocNo=28701-EN/LZT146256
-Author: Guenter Roeck <guenter.roeck@ericsson.com>
+Author: Guenter Roeck <linux@roeck-us.net>
Description
@@ -121,12 +121,26 @@
in1_lcrit_alarm Input voltage critical low alarm.
in1_crit_alarm Input voltage critical high alarm.
-in2_label "vout1"
-in2_input Measured output voltage.
-in2_lcrit Critical minimum output Voltage.
-in2_crit Critical maximum output voltage.
-in2_lcrit_alarm Critical output voltage critical low alarm.
-in2_crit_alarm Critical output voltage critical high alarm.
+in2_label "vmon"
+in2_input Measured voltage on VMON (ZL2004) or VDRV (ZL9101M,
+ ZL9117M) pin. Reported voltage is 16x the voltage on the
+ pin (adjusted internally by the chip).
+in2_lcrit Critical minimum VMON/VDRV Voltage.
+in2_crit Critical maximum VMON/VDRV voltage.
+in2_lcrit_alarm VMON/VDRV voltage critical low alarm.
+in2_crit_alarm VMON/VDRV voltage critical high alarm.
+
+ vmon attributes are supported on ZL2004, ZL9101M,
+ and ZL9117M only.
+
+inX_label "vout1"
+inX_input Measured output voltage.
+inX_lcrit Critical minimum output Voltage.
+inX_crit Critical maximum output voltage.
+inX_lcrit_alarm Critical output voltage critical low alarm.
+inX_crit_alarm Critical output voltage critical high alarm.
+
+ X is 3 for ZL2004, ZL9101M, and ZL9117M, 2 otherwise.
curr1_label "iout1"
curr1_input Measured output current.
diff --git a/Documentation/i2c/busses/i2c-diolan-u2c b/Documentation/i2c/busses/i2c-diolan-u2c
index 30fe4bb..0d6018c 100644
--- a/Documentation/i2c/busses/i2c-diolan-u2c
+++ b/Documentation/i2c/busses/i2c-diolan-u2c
@@ -5,7 +5,7 @@
Documentation:
http://www.diolan.com/i2c/u2c12.html
-Author: Guenter Roeck <guenter.roeck@ericsson.com>
+Author: Guenter Roeck <linux@roeck-us.net>
Description
-----------
diff --git a/Documentation/i2c/busses/i2c-i801 b/Documentation/i2c/busses/i2c-i801
index 157416e7..d29dea0 100644
--- a/Documentation/i2c/busses/i2c-i801
+++ b/Documentation/i2c/busses/i2c-i801
@@ -22,6 +22,9 @@
* Intel Panther Point (PCH)
* Intel Lynx Point (PCH)
* Intel Lynx Point-LP (PCH)
+ * Intel Avoton (SOC)
+ * Intel Wellsburg (PCH)
+ * Intel Coleto Creek (PCH)
Datasheets: Publicly available at the Intel website
On Intel Patsburg and later chipsets, both the normal host SMBus controller
diff --git a/Documentation/i2c/busses/i2c-ismt b/Documentation/i2c/busses/i2c-ismt
new file mode 100644
index 0000000..7373558
--- /dev/null
+++ b/Documentation/i2c/busses/i2c-ismt
@@ -0,0 +1,36 @@
+Kernel driver i2c-ismt
+
+Supported adapters:
+ * Intel S12xx series SOCs
+
+Authors:
+ Bill Brown <bill.e.brown@intel.com>
+
+
+Module Parameters
+-----------------
+
+* bus_speed (unsigned int)
+Allows changing of the bus speed. Normally, the bus speed is set by the BIOS
+and never needs to be changed. However, some SMBus analyzers are too slow for
+monitoring the bus during debug, thus the need for this module parameter.
+Specify the bus speed in kHz.
+Available bus frequency settings:
+ 0 no change
+ 80 kHz
+ 100 kHz
+ 400 kHz
+ 1000 kHz
+
+
+Description
+-----------
+
+The S12xx series of SOCs have a pair of integrated SMBus 2.0 controllers
+targeted primarily at the microserver and storage markets.
+
+The S12xx series contain a pair of PCI functions. An output of lspci will show
+something similar to the following:
+
+ 00:13.0 System peripheral: Intel Corporation Centerton SMBus 2.0 Controller 0
+ 00:13.1 System peripheral: Intel Corporation Centerton SMBus 2.0 Controller 1
diff --git a/Documentation/i2c/busses/i2c-piix4 b/Documentation/i2c/busses/i2c-piix4
index 1e6634f..a370b20 100644
--- a/Documentation/i2c/busses/i2c-piix4
+++ b/Documentation/i2c/busses/i2c-piix4
@@ -13,7 +13,7 @@
* AMD SP5100 (SB700 derivative found on some server mainboards)
Datasheet: Publicly available at the AMD website
http://support.amd.com/us/Embedded_TechDocs/44413.pdf
- * AMD Hudson-2
+ * AMD Hudson-2, CZ
Datasheet: Not publicly available
* Standard Microsystems (SMSC) SLC90E66 (Victory66) southbridge
Datasheet: Publicly available at the SMSC website http://www.smsc.com
diff --git a/Documentation/i2c/busses/i2c-sis630 b/Documentation/i2c/busses/i2c-sis630
index 0b96973..ee79436 100644
--- a/Documentation/i2c/busses/i2c-sis630
+++ b/Documentation/i2c/busses/i2c-sis630
@@ -4,9 +4,11 @@
* Silicon Integrated Systems Corp (SiS)
630 chipset (Datasheet: available at http://www.sfr-fresh.com/linux)
730 chipset
+ 964 chipset
* Possible other SiS chipsets ?
Author: Alexander Malysh <amalysh@web.de>
+ Amaury Decrême <amaury.decreme@gmail.com> - SiS964 support
Module Parameters
-----------------
@@ -18,6 +20,7 @@
* high_clock = [1|0] Forcibly set Host Master Clock to 56KHz (default,
what your BIOS use). DANGEROUS! This should be a bit
faster, but freeze some systems (i.e. my Laptop).
+ SIS630/730 chip only.
Description
@@ -36,6 +39,12 @@
00:00.0 Host bridge: Silicon Integrated Systems [SiS] 730 Host (rev 02)
00:01.0 ISA bridge: Silicon Integrated Systems [SiS] 85C503/5513
+or like this:
+
+00:00.0 Host bridge: Silicon Integrated Systems [SiS] 760/M760 Host (rev 02)
+00:02.0 ISA bridge: Silicon Integrated Systems [SiS] SiS964 [MuTIOL Media IO]
+ LPC Controller (rev 36)
+
in your 'lspci' output , then this driver is for your chipset.
Thank You
diff --git a/Documentation/i2c/instantiating-devices b/Documentation/i2c/instantiating-devices
index abf6361..2218266 100644
--- a/Documentation/i2c/instantiating-devices
+++ b/Documentation/i2c/instantiating-devices
@@ -91,7 +91,7 @@
static const unsigned short normal_i2c[] = { 0x2c, 0x2d, I2C_CLIENT_END };
-static int __devinit usb_hcd_nxp_probe(struct platform_device *pdev)
+static int usb_hcd_nxp_probe(struct platform_device *pdev)
{
(...)
struct i2c_adapter *i2c_adap;
diff --git a/Documentation/i2c/smbus-protocol b/Documentation/i2c/smbus-protocol
index d1f2261..6012b12 100644
--- a/Documentation/i2c/smbus-protocol
+++ b/Documentation/i2c/smbus-protocol
@@ -137,8 +137,8 @@
around (not SMBus compliant, but very popular.)
-SMBus Process Call: i2c_smbus_process_call()
-=============================================
+SMBus Process Call:
+===================
This command selects a device register (through the Comm byte), sends
16 bits of data to it, and reads 16 bits of data in return.
diff --git a/Documentation/i2c/writing-clients b/Documentation/i2c/writing-clients
index 3a94b0e..6b344b5 100644
--- a/Documentation/i2c/writing-clients
+++ b/Documentation/i2c/writing-clients
@@ -365,8 +365,6 @@
s32 i2c_smbus_read_word_data(struct i2c_client *client, u8 command);
s32 i2c_smbus_write_word_data(struct i2c_client *client,
u8 command, u16 value);
- s32 i2c_smbus_process_call(struct i2c_client *client,
- u8 command, u16 value);
s32 i2c_smbus_read_block_data(struct i2c_client *client,
u8 command, u8 *values);
s32 i2c_smbus_write_block_data(struct i2c_client *client,
@@ -381,6 +379,8 @@
be added back later if needed:
s32 i2c_smbus_write_quick(struct i2c_client *client, u8 value);
+ s32 i2c_smbus_process_call(struct i2c_client *client,
+ u8 command, u16 value);
s32 i2c_smbus_block_process_call(struct i2c_client *client,
u8 command, u8 length, u8 *values);
diff --git a/Documentation/ia64/err_inject.txt b/Documentation/ia64/err_inject.txt
index 223e4f0..9f651c1 100644
--- a/Documentation/ia64/err_inject.txt
+++ b/Documentation/ia64/err_inject.txt
@@ -882,7 +882,7 @@
cpu=parameters[i].cpu;
k = cpu%64;
j = cpu/64;
- mask[j]=1<<k;
+ mask[j] = 1UL << k;
if (sched_setaffinity(0, MASK_SIZE*8, mask)==-1) {
perror("Error sched_setaffinity:");
diff --git a/Documentation/input/alps.txt b/Documentation/input/alps.txt
index 3262b6e..e544c7f 100644
--- a/Documentation/input/alps.txt
+++ b/Documentation/input/alps.txt
@@ -3,10 +3,26 @@
Introduction
------------
+Currently the ALPS touchpad driver supports five protocol versions in use by
+ALPS touchpads, called versions 1, 2, 3, 4 and 5.
-Currently the ALPS touchpad driver supports four protocol versions in use by
-ALPS touchpads, called versions 1, 2, 3, and 4. Information about the various
-protocol versions is contained in the following sections.
+Since roughly mid-2010 several new ALPS touchpads have been released and
+integrated into a variety of laptops and netbooks. These new touchpads
+have enough behavior differences that the alps_model_data definition
+table, describing the properties of the different versions, is no longer
+adequate. The design choices were to re-define the alps_model_data
+table, with the risk of regression testing existing devices, or isolate
+the new devices outside of the alps_model_data table. The latter design
+choice was made. The new touchpad signatures are named: "Rushmore",
+"Pinnacle", and "Dolphin", which you will see in the alps.c code.
+For the purposes of this document, this group of ALPS touchpads will
+generically be called "new ALPS touchpads".
+
+We experimented with probing the ACPI interface _HID (Hardware ID)/_CID
+(Compatibility ID) definition as a way to uniquely identify the
+different ALPS variants but there did not appear to be a 1:1 mapping.
+In fact, it appeared to be an m:n mapping between the _HID and actual
+hardware type.
Detection
---------
@@ -20,9 +36,13 @@
report" sequence: E8-E7-E7-E7-E9. The response is the model signature and is
matched against known models in the alps_model_data_array.
-With protocol versions 3 and 4, the E7 report model signature is always
-73-02-64. To differentiate between these versions, the response from the
-"Enter Command Mode" sequence must be inspected as described below.
+For older touchpads supporting protocol versions 3 and 4, the E7 report
+model signature is always 73-02-64. To differentiate between these
+versions, the response from the "Enter Command Mode" sequence must be
+inspected as described below.
+
+The new ALPS touchpads have an E7 signature of 73-03-50 or 73-03-0A but
+seem to be better differentiated by the EC Command Mode response.
Command Mode
------------
@@ -47,6 +67,14 @@
register. Registers are written by writing the value one nibble at a time
using the same encoding used for addresses.
+For the new ALPS touchpads, the EC command is used to enter command
+mode. The response in the new ALPS touchpads is significantly different,
+and more important in determining the behavior. This code has been
+separated from the original alps_model_data table and put in the
+alps_identify function. For example, there seem to be two hardware init
+sequences for the "Dolphin" touchpads as determined by the second byte
+of the EC response.
+
Packet Format
-------------
@@ -187,3 +215,28 @@
well.
So far no v4 devices with tracksticks have been encountered.
+
+ALPS Absolute Mode - Protocol Version 5
+---------------------------------------
+This is basically Protocol Version 3 but with different logic for packet
+decode. It uses the same alps_process_touchpad_packet_v3 call with a
+specialized decode_fields function pointer to correctly interpret the
+packets. This appears to only be used by the Dolphin devices.
+
+For single-touch, the 6-byte packet format is:
+
+ byte 0: 1 1 0 0 1 0 0 0
+ byte 1: 0 x6 x5 x4 x3 x2 x1 x0
+ byte 2: 0 y6 y5 y4 y3 y2 y1 y0
+ byte 3: 0 M R L 1 m r l
+ byte 4: y10 y9 y8 y7 x10 x9 x8 x7
+ byte 5: 0 z6 z5 z4 z3 z2 z1 z0
+
+For mt, the format is:
+
+ byte 0: 1 1 1 n3 1 n2 n1 x24
+ byte 1: 1 y7 y6 y5 y4 y3 y2 y1
+ byte 2: ? x2 x1 y12 y11 y10 y9 y8
+ byte 3: 0 x23 x22 x21 x20 x19 x18 x17
+ byte 4: 0 x9 x8 x7 x6 x5 x4 x3
+ byte 5: 0 x16 x15 x14 x13 x12 x11 x10
diff --git a/Documentation/input/multi-touch-protocol.txt b/Documentation/input/multi-touch-protocol.txt
index 2c17961..de139b1 100644
--- a/Documentation/input/multi-touch-protocol.txt
+++ b/Documentation/input/multi-touch-protocol.txt
@@ -80,6 +80,8 @@
by noting that the largest supported BTN_TOOL_*TAP event is larger than the
total number of type B slots reported in the absinfo for the ABS_MT_SLOT axis.
+The minimum value of the ABS_MT_SLOT axis must be 0.
+
Protocol Example A
------------------
diff --git a/Documentation/intel_txt.txt b/Documentation/intel_txt.txt
index 849de1a..91d89c5 100644
--- a/Documentation/intel_txt.txt
+++ b/Documentation/intel_txt.txt
@@ -192,7 +192,7 @@
The kernel option for enabling Intel TXT support is found under the
Security top-level menu and is called "Enable Intel(R) Trusted
-Execution Technology (TXT)". It is marked as EXPERIMENTAL and
+Execution Technology (TXT)". It is considered EXPERIMENTAL and
depends on the generic x86 support (to allow maximum flexibility in
kernel build options), since the tboot code will detect whether the
platform actually supports Intel TXT and thus whether any of the
diff --git a/Documentation/ioctl/ioctl-number.txt b/Documentation/ioctl/ioctl-number.txt
index 2152b0e..2a5f0e1 100644
--- a/Documentation/ioctl/ioctl-number.txt
+++ b/Documentation/ioctl/ioctl-number.txt
@@ -72,6 +72,7 @@
0x06 all linux/lp.h
0x09 all linux/raid/md_u.h
0x10 00-0F drivers/char/s390/vmcp.h
+0x10 10-1F arch/s390/include/uapi/sclp_ctl.h
0x12 all linux/fs.h
linux/blkpg.h
0x1b all InfiniBand Subsystem <http://infiniband.sourceforge.net/>
@@ -131,6 +132,7 @@
'H' 40-4F sound/hdspm.h conflict!
'H' 40-4F sound/hdsp.h conflict!
'H' 90 sound/usb/usx2y/usb_stream.h
+'H' A0 uapi/linux/usb/cdc-wdm.h
'H' C0-F0 net/bluetooth/hci.h conflict!
'H' C0-DF net/bluetooth/hidp/hidp.h conflict!
'H' C0-DF net/bluetooth/cmtp/cmtp.h conflict!
@@ -179,7 +181,7 @@
'V' C0 media/davinci/vpfe_capture.h conflict!
'V' C0 media/si4713.h conflict!
'W' 00-1F linux/watchdog.h conflict!
-'W' 00-1F linux/wanrouter.h conflict!
+'W' 00-1F linux/wanrouter.h conflict! (pre 3.9)
'W' 00-3F sound/asound.h conflict!
'X' all fs/xfs/xfs_fs.h conflict!
and fs/xfs/linux-2.6/xfs_ioctl32.h
diff --git a/Documentation/iostats.txt b/Documentation/iostats.txt
index c76c21d..65f694f 100644
--- a/Documentation/iostats.txt
+++ b/Documentation/iostats.txt
@@ -71,6 +71,8 @@
measured from __make_request() to end_that_request_last()).
Field 5 -- # of writes completed
This is the total number of writes completed successfully.
+Field 6 -- # of writes merged
+ See the description of field 2.
Field 7 -- # of sectors written
This is the total number of sectors written successfully.
Field 8 -- # of milliseconds spent writing
diff --git a/Documentation/kbuild/kconfig-language.txt b/Documentation/kbuild/kconfig-language.txt
index a686f9c..c858f84 100644
--- a/Documentation/kbuild/kconfig-language.txt
+++ b/Documentation/kbuild/kconfig-language.txt
@@ -388,26 +388,3 @@
depends on BAR && m
limits FOO to module (=m) or disabled (=n).
-
-Kconfig symbol existence
-~~~~~~~~~~~~~~~~~~~~~~~~
-The following two methods produce the same kconfig symbol dependencies
-but differ greatly in kconfig symbol existence (production) in the
-generated config file.
-
-case 1:
-
-config FOO
- tristate "about foo"
- depends on BAR
-
-vs. case 2:
-
-if BAR
-config FOO
- tristate "about foo"
-endif
-
-In case 1, the symbol FOO will always exist in the config file (given
-no other dependencies). In case 2, the symbol FOO will only exist in
-the config file if BAR is enabled.
diff --git a/Documentation/kbuild/kconfig.txt b/Documentation/kbuild/kconfig.txt
index a09f1a6..e349f29 100644
--- a/Documentation/kbuild/kconfig.txt
+++ b/Documentation/kbuild/kconfig.txt
@@ -46,6 +46,12 @@
If you set KCONFIG_OVERWRITECONFIG in the environment, Kconfig will not
break symlinks when .config is a symlink to somewhere else.
+CONFIG_
+--------------------------------------------------
+If you set CONFIG_ in the environment, Kconfig will prefix all symbols
+with its value when saving the configuration, instead of using the default,
+"CONFIG_".
+
______________________________________________________________________
Environment variables for '{allyes/allmod/allno/rand}config'
@@ -84,6 +90,42 @@
mini-config files.
______________________________________________________________________
+Environment variables for 'randconfig'
+
+KCONFIG_SEED
+--------------------------------------------------
+You can set this to the integer value used to seed the RNG, if you want
+to somehow debug the behaviour of the kconfig parser/frontends.
+If not set, the current time will be used.
+
+KCONFIG_PROBABILITY
+--------------------------------------------------
+This variable can be used to skew the probabilities. This variable can
+be unset or empty, or set to three different formats:
+ KCONFIG_PROBABILITY y:n split y:m:n split
+ -----------------------------------------------------------------
+ unset or empty 50 : 50 33 : 33 : 34
+ N N : 100-N N/2 : N/2 : 100-N
+ [1] N:M N+M : 100-(N+M) N : M : 100-(N+M)
+ [2] N:M:L N : 100-N M : L : 100-(M+L)
+
+where N, M and L are integers (in base 10) in the range [0,100], and so
+that:
+ [1] N+M is in the range [0,100]
+ [2] M+L is in the range [0,100]
+
+Examples:
+ KCONFIG_PROBABILITY=10
+ 10% of booleans will be set to 'y', 90% to 'n'
+ 5% of tristates will be set to 'y', 5% to 'm', 90% to 'n'
+ KCONFIG_PROBABILITY=15:25
+ 40% of booleans will be set to 'y', 60% to 'n'
+ 15% of tristates will be set to 'y', 25% to 'm', 60% to 'n'
+ KCONFIG_PROBABILITY=10:15:15
+ 10% of booleans will be set to 'y', 90% to 'n'
+ 15% of tristates will be set to 'y', 15% to 'm', 70% to 'n'
+
+______________________________________________________________________
Environment variables for 'silentoldconfig'
KCONFIG_NOSILENTUPDATE
@@ -123,7 +165,7 @@
Example:
/hotplug
This lists all config symbols that contain "hotplug",
- e.g., HOTPLUG, HOTPLUG_CPU, MEMORY_HOTPLUG.
+ e.g., HOTPLUG_CPU, MEMORY_HOTPLUG.
For search help, enter / followed TAB-TAB-TAB (to highlight
<Help>) and Enter. This will tell you that you can also use
@@ -132,6 +174,19 @@
/^hotplug
+ When searching, symbols are sorted thus:
+ - exact match first: an exact match is when the search matches
+ the complete symbol name;
+ - alphabetical order: when two symbols do not match exactly,
+ they are sorted in alphabetical order (in the user's current
+ locale).
+ For example: ^ATH.K matches:
+ ATH5K ATH9K ATH5K_AHB ATH5K_DEBUG [...] ATH6KL ATH6KL_DEBUG
+ [...] ATH9K_AHB ATH9K_BTCOEX_SUPPORT ATH9K_COMMON [...]
+ of which only ATH5K and ATH9K match exactly and so are sorted
+ first (and in alphabetical order), then come all other symbols,
+ sorted in alphabetical order.
+
______________________________________________________________________
User interface options for 'menuconfig'
diff --git a/Documentation/kbuild/makefiles.txt b/Documentation/kbuild/makefiles.txt
index 14c3f4f..d567a7c 100644
--- a/Documentation/kbuild/makefiles.txt
+++ b/Documentation/kbuild/makefiles.txt
@@ -593,7 +593,7 @@
Example:
#Makefile
- LDFLAGS_vmlinux += $(call really-ld-option, -X)
+ LDFLAGS_vmlinux += $(call ld-option, -X)
=== 4 Host Program support
@@ -921,8 +921,9 @@
Often, the KBUILD_CFLAGS variable depends on the configuration.
Example:
- #arch/x86/Makefile
- cflags-$(CONFIG_M386) += -march=i386
+ #arch/x86/boot/compressed/Makefile
+ cflags-$(CONFIG_X86_32) := -march=i386
+ cflags-$(CONFIG_X86_64) := -mcmodel=small
KBUILD_CFLAGS += $(cflags-y)
Many arch Makefiles dynamically run the target C compiler to
@@ -1186,6 +1187,29 @@
clean-files += *.dtb
DTC_FLAGS ?= -p 1024
+ dtc_cpp
+ This is just like dtc as describe above, except that the C pre-
+ processor is invoked upon the .dtsp file before compiling the result
+ with dtc.
+
+ In order for build dependencies to work, all files compiled using
+ dtc_cpp must use the C pre-processor's #include functionality and not
+ dtc's /include/ functionality.
+
+ Using the C pre-processor allows use of #define to create named
+ constants. In turn, the #defines will typically appear in a header
+ file, which may be shared with regular C code. Since the dtc language
+ represents a data structure rather than code in C syntax, similar
+ restrictions are placed on a header file included by a device tree
+ file as for a header file included by an assembly language file.
+ In particular, the C pre-processor is passed -x assembler-with-cpp,
+ which sets macro __ASSEMBLY__. __DTS__ is also set. These allow header
+ files to restrict their content to that compatible with device tree
+ source.
+
+ A central rule exists to create $(obj)/%.dtb from $(src)/%.dtsp;
+ architecture Makefiles do no need to explicitly write out that rule.
+
--- 6.8 Custom kbuild commands
When kbuild is executing with KBUILD_VERBOSE=0, then only a shorthand
diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
index 13f1aa0..88d5a86 100644
--- a/Documentation/kdump/kdump.txt
+++ b/Documentation/kdump/kdump.txt
@@ -47,19 +47,12 @@
when using the elfcorehdr=[size[KMG]@]offset[KMG] syntax.
-With the dump-capture kernel, you can access the memory image, or "old
-memory," in two ways:
-
-- Through a /dev/oldmem device interface. A capture utility can read the
- device file and write out the memory in raw format. This is a raw dump
- of memory. Analysis and capture tools must be intelligent enough to
- determine where to look for the right information.
-
-- Through /proc/vmcore. This exports the dump as an ELF-format file that
- you can write out using file copy commands such as cp or scp. Further,
- you can use analysis tools such as the GNU Debugger (GDB) and the Crash
- tool to debug the dump file. This method ensures that the dump pages are
- correctly ordered.
+With the dump-capture kernel, you can access the memory image through
+/proc/vmcore. This exports the dump as an ELF-format file that you can
+write out using file copy commands such as cp or scp. Further, you can
+use analysis tools such as the GNU Debugger (GDB) and the Crash tool to
+debug the dump file. This method ensures that the dump pages are correctly
+ordered.
Setup and Installation
@@ -297,6 +290,7 @@
On ia64, 256M@256M is a generous value that typically works.
The region may be automatically placed on ia64, see the
dump-capture kernel config option notes above.
+ If use sparse memory, the size should be rounded to GRANULE boundaries.
On s390x, typically use "crashkernel=xxM". The value of xx is dependent
on the memory consumption of the kdump system. In general this is not
@@ -422,18 +416,6 @@
cp /proc/vmcore <dump-file>
-You can also access dumped memory as a /dev/oldmem device for a linear
-and raw view. To create the device, use the following command:
-
- mknod /dev/oldmem c 1 12
-
-Use the dd command with suitable options for count, bs, and skip to
-access specific portions of the dump.
-
-To see the entire memory, use the following command:
-
- dd if=/dev/oldmem of=oldmem.001
-
Analysis
========
@@ -460,14 +442,6 @@
http://people.redhat.com/~anderson/
-To Do
-=====
-
-1) Provide relocatable kernels for all architectures to help in maintaining
- multiple kernels for crash_dump, and the same kernel as the system kernel
- can be used to capture the dump.
-
-
Contact
=======
diff --git a/Documentation/kernel-doc-nano-HOWTO.txt b/Documentation/kernel-doc-nano-HOWTO.txt
index 99b57ab..acbc1a3 100644
--- a/Documentation/kernel-doc-nano-HOWTO.txt
+++ b/Documentation/kernel-doc-nano-HOWTO.txt
@@ -142,9 +142,10 @@
- Makefile
- The targets 'sgmldocs', 'psdocs', 'pdfdocs', and 'htmldocs' are used
- to build DocBook files, PostScript files, PDF files, and html files
- in Documentation/DocBook.
+ The targets 'xmldocs', 'psdocs', 'pdfdocs', and 'htmldocs' are used
+ to build XML DocBook files, PostScript files, PDF files, and html files
+ in Documentation/DocBook. The older target 'sgmldocs' is equivalent
+ to 'xmldocs'.
- Documentation/DocBook/Makefile
@@ -158,8 +159,8 @@
subsystems (see Documentation/DocBook/*.tmpl), just type 'make
psdocs', or 'make pdfdocs', or 'make htmldocs', depending on your
preference. If you would rather read a different format, you can type
-'make sgmldocs' and then use DocBook tools to convert
-Documentation/DocBook/*.sgml to a format of your choice (for example,
+'make xmldocs' and then use DocBook tools to convert
+Documentation/DocBook/*.xml to a format of your choice (for example,
'db2html ...' if 'make htmldocs' was not defined).
If you want to see man pages instead, you can do this:
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 363e348..15356ac 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -44,6 +44,8 @@
AVR32 AVR32 architecture is enabled.
AX25 Appropriate AX.25 support is enabled.
BLACKFIN Blackfin architecture is enabled.
+ CLK Common clock infrastructure is enabled.
+ CMA Contiguous Memory Area support is enabled.
DRM Direct Rendering Management support is enabled.
DYNAMIC_DEBUG Build in debug messages and enable them at runtime
EDD BIOS Enhanced Disk Drive Services (EDD) is enabled
@@ -320,6 +322,13 @@
on: enable for both 32- and 64-bit processes
off: disable for both 32- and 64-bit processes
+ alloc_snapshot [FTRACE]
+ Allocate the ftrace snapshot buffer on boot up when the
+ main buffer is allocated. This is handy if debugging
+ and you need to use tracing_snapshot() on boot up, and
+ do not want to use tracing_snapshot_alloc() as it needs
+ to be done where GFP_KERNEL allocations are allowed.
+
amd_iommu= [HW,X86-64]
Pass parameters to the AMD IOMMU driver in the system.
Possible values are:
@@ -465,6 +474,13 @@
cio_ignore= [S390]
See Documentation/s390/CommonIO for details.
+ clk_ignore_unused
+ [CLK]
+ Keep all clocks already enabled by bootloader on,
+ even if no driver has claimed them. This is useful
+ for debug and development, but should not be
+ needed on a platform with proper driver support.
+ For more information, see Documentation/clk.txt.
clock= [BUGS=X86-32, HW] gettimeofday clocksource override.
[Deprecated]
@@ -564,6 +580,8 @@
UART at the specified I/O port or MMIO address,
switching to the matching ttyS device later. The
options are the same as for ttyS, above.
+ hvc<n> Use the hypervisor console device <n>. This is for
+ both Xen and PowerPC hypervisors.
If the device connected to the port is not a TTY but a braille
device, prepend "brl," before the device type, for instance
@@ -601,6 +619,26 @@
a memory unit (amount[KMG]). See also
Documentation/kdump/kdump.txt for an example.
+ crashkernel=size[KMG],high
+ [KNL, x86_64] range could be above 4G. Allow kernel
+ to allocate physical memory region from top, so could
+ be above 4G if system have more than 4G ram installed.
+ Otherwise memory region will be allocated below 4G, if
+ available.
+ It will be ignored if crashkernel=X is specified.
+ crashkernel=size[KMG],low
+ [KNL, x86_64] range under 4G. When crashkernel=X,high
+ is passed, kernel could allocate physical memory region
+ above 4G, that cause second kernel crash on system
+ that require some amount of low memory, e.g. swiotlb
+ requires at least 64M+32K low memory. Kernel would
+ try to allocate 72M below 4G automatically.
+ This one let user to specify own low range under 4G
+ for second kernel instead.
+ 0: to disable low allocation.
+ It will be ignored when crashkernel=X,high is not used
+ or memory reserved is below 4G.
+
cs89x0_dma= [HW,NET]
Format: <dma>
@@ -752,18 +790,31 @@
(mmio) or 32-bit (mmio32).
The options are the same as for ttyS, above.
- earlyprintk= [X86,SH,BLACKFIN]
+ earlyprintk= [X86,SH,BLACKFIN,ARM]
earlyprintk=vga
+ earlyprintk=xen
earlyprintk=serial[,ttySn[,baudrate]]
+ earlyprintk=serial[,0x...[,baudrate]]
earlyprintk=ttySn[,baudrate]
earlyprintk=dbgp[debugController#]
+ earlyprintk is useful when the kernel crashes before
+ the normal console is initialized. It is not enabled by
+ default because it has some cosmetic problems.
+
Append ",keep" to not disable it when the real console
takes over.
Only vga or serial or usb debug port at a time.
- Currently only ttyS0 and ttyS1 are supported.
+ Currently only ttyS0 and ttyS1 may be specified by
+ name. Other I/O ports may be explicitly specified
+ on some architectures (x86 and arm at least) by
+ replacing ttySn with an I/O port address, like this:
+ earlyprintk=serial,0x1008,115200
+ You can find the port for a given device in
+ /proc/tty/driver/serial:
+ 2: uart:ST16650V2 port:00001008 irq:18 ...
Interaction with the standard serial driver is not
very good.
@@ -771,6 +822,8 @@
The VGA output is eventually overwritten by the real
console.
+ The xen output can only be used by Xen PV guests.
+
ekgdboc= [X86,KGDB] Allow early kernel console debugging
ekgdboc=kbd
@@ -780,6 +833,12 @@
edd= [EDD]
Format: {"off" | "on" | "skip[mbr]"}
+ efi_no_storage_paranoia [EFI; X86]
+ Using this parameter you can use more than 50% of
+ your efi variable storage. Use this parameter only if
+ you are really sure that your UEFI does sane gc and
+ fulfills the spec otherwise your board may brick.
+
eisa_irq_edge= [PARISC,HW]
See header of drivers/parisc/eisa.c.
@@ -970,6 +1029,10 @@
If specified, z/VM IUCV HVC accepts connections
from listed z/VM user IDs only.
+ hwthread_map= [METAG] Comma-separated list of Linux cpu id to
+ hardware thread id mappings.
+ Format: <cpu>:<hwthread>
+
keep_bootcon [KNL]
Do not unregister boot console at start. This is only
useful for debugging when something happens in the window
@@ -1039,16 +1102,11 @@
Claim all unknown PCI IDE storage controllers.
idle= [X86]
- Format: idle=poll, idle=mwait, idle=halt, idle=nomwait
+ Format: idle=poll, idle=halt, idle=nomwait
Poll forces a polling idle loop that can slightly
improve the performance of waking up a idle CPU, but
will use a lot of power and make the system run hot.
Not recommended.
- idle=mwait: On systems which support MONITOR/MWAIT but
- the kernel chose to not use it because it doesn't save
- as much power as a normal idle loop, use the
- MONITOR/MWAIT idle loop anyways. Performance should be
- the same as idle=poll.
idle=halt: Halt is forced to be used for CPU idle.
In such case C2/C3 won't be used again.
idle=nomwait: Disable mwait for CPU C-states
@@ -1071,11 +1129,6 @@
The builtin appraise policy appraises all files
owned by uid=0.
- ima_audit= [IMA]
- Format: { "0" | "1" }
- 0 -- integrity auditing messages. (Default)
- 1 -- enable informational integrity auditing messages.
-
ima_hash= [IMA]
Format: { "sha1" | "md5" }
default: "sha1"
@@ -1100,6 +1153,13 @@
inport.irq= [HW] Inport (ATI XL and Microsoft) busmouse driver
Format: <irq>
+ int_pln_enable [x86] Enable power limit notification interrupt
+
+ integrity_audit=[IMA]
+ Format: { "0" | "1" }
+ 0 -- basic integrity auditing messages. (Default)
+ 1 -- additional integrity auditing messages.
+
intel_iommu= [DMAR] Intel IOMMU driver (DMAR) option
on
Enable intel iommu driver.
@@ -1131,6 +1191,11 @@
0 disables intel_idle and fall back on acpi_idle.
1 to 6 specify maximum depth of C-state.
+ intel_pstate= [X86]
+ disable
+ Do not enable intel_pstate as the default
+ scaling driver for the supported processors
+
intremap= [X86-64, Intel-IOMMU]
on enable Interrupt Remapping (default)
off disable Interrupt Remapping
@@ -1214,6 +1279,20 @@
iucv= [HW,NET]
+ ivrs_ioapic [HW,X86_64]
+ Provide an override to the IOAPIC-ID<->DEVICE-ID
+ mapping provided in the IVRS ACPI table. For
+ example, to map IOAPIC-ID decimal 10 to
+ PCI device 00:14.0 write the parameter as:
+ ivrs_ioapic[10]=00:14.0
+
+ ivrs_hpet [HW,X86_64]
+ Provide an override to the HPET-ID<->DEVICE-ID
+ mapping provided in the IVRS ACPI table. For
+ example, to map HPET-ID decimal 0 to
+ PCI device 00:14.0 write the parameter as:
+ ivrs_hpet[0]=00:14.0
+
js= [HW,JOY] Analog joystick
See Documentation/input/joystick.txt.
@@ -1379,6 +1458,8 @@
* dump_id: dump IDENTIFY data.
+ * atapi_dmadir: Enable ATAPI DMADIR bridge support
+
If there are multiple matching configurations changing
the same attribute, the last one is used.
@@ -1613,7 +1694,7 @@
module.sig_enforce
[KNL] When CONFIG_MODULE_SIG is set, this means that
modules without (valid) signatures will fail to load.
- Note that if CONFIG_MODULE_SIG_ENFORCE is set, that
+ Note that if CONFIG_MODULE_SIG_FORCE is set, that
is always true, so this option does nothing.
mousedev.tap_time=
@@ -1886,10 +1967,6 @@
wfi(ARM) instruction doesn't work correctly and not to
use it. This is also useful when using JTAG debugger.
- no-hlt [BUGS=X86-32] Tells the kernel that the hlt
- instruction doesn't work correctly and not to
- use it.
-
no_file_caps Tells the kernel not to honor file capabilities. The
only way then for a file to be executed with privilege
is to be setuid root or executed by root.
@@ -1905,6 +1982,14 @@
Valid arguments: on, off
Default: on
+ nohz_full= [KNL,BOOT]
+ In kernels built with CONFIG_NO_HZ_FULL=y, set
+ the specified list of CPUs whose tick will be stopped
+ whenever possible. The boot CPU will be forced outside
+ the range to maintain the timekeeping.
+ The CPUs in this range must also be included in the
+ rcu_nocbs= set.
+
noiotrap [SH] Disables trapped I/O port accesses.
noirqdebug [X86-32] Disables the code which attempts to detect and
@@ -1966,8 +2051,6 @@
noreplace-smp [X86-32,SMP] Don't replace SMP instructions
with UP alternatives
- noresidual [PPC] Don't use residual data on PReP machines.
-
nordrand [X86] Disable the direct use of the RDRAND
instruction even if it is supported by the
processor. RDRAND is still available to user
@@ -2227,6 +2310,21 @@
This sorting is done to get a device
order compatible with older (<= 2.4) kernels.
nobfsort Don't sort PCI devices into breadth-first order.
+ pcie_bus_tune_off Disable PCIe MPS (Max Payload Size)
+ tuning and use the BIOS-configured MPS defaults.
+ pcie_bus_safe Set every device's MPS to the largest value
+ supported by all devices below the root complex.
+ pcie_bus_perf Set device MPS to the largest allowable MPS
+ based on its parent bus. Also set MRRS (Max
+ Read Request Size) to the largest supported
+ value (no larger than the MPS that the device
+ or bus can support) for best performance.
+ pcie_bus_peer2peer Set every device's MPS to 128B, which
+ every device is guaranteed to support. This
+ configuration allows peer-to-peer DMA between
+ any pair of devices, possibly at the cost of
+ reduced performance. This also guarantees
+ that hot-added devices will work.
cbiosize=nn[KMG] The fixed amount of bus space which is
reserved for the CardBus bridge's IO window.
The default value is 256 bytes.
@@ -2248,6 +2346,12 @@
the default.
off: Turn ECRC off
on: Turn ECRC on.
+ hpiosize=nn[KMG] The fixed amount of bus space which is
+ reserved for hotplug bridge's IO window.
+ Default size is 256 bytes.
+ hpmemsize=nn[KMG] The fixed amount of bus space which is
+ reserved for hotplug bridge's memory window.
+ Default size is 2 megabytes.
realloc= Enable/disable reallocating PCI bridge resources
if allocations done by BIOS are too small to
accommodate resources required by all child
@@ -2432,13 +2536,16 @@
In kernels built with CONFIG_RCU_NOCB_CPU=y, set
the specified list of CPUs to be no-callback CPUs.
Invocation of these CPUs' RCU callbacks will
- be offloaded to "rcuoN" kthreads created for
- that purpose. This reduces OS jitter on the
+ be offloaded to "rcuox/N" kthreads created for
+ that purpose, where "x" is "b" for RCU-bh, "p"
+ for RCU-preempt, and "s" for RCU-sched, and "N"
+ is the CPU number. This reduces OS jitter on the
offloaded CPUs, which can be useful for HPC and
+
real-time workloads. It can also improve energy
efficiency for asymmetric multiprocessors.
- rcu_nocbs_poll [KNL,BOOT]
+ rcu_nocb_poll [KNL,BOOT]
Rather than requiring that offloaded CPUs
(specified by rcu_nocbs= above) explicitly
awaken the corresponding "rcuoN" kthreads,
@@ -2458,6 +2565,17 @@
leaf rcu_node structure. Useful for very large
systems.
+ rcutree.jiffies_till_first_fqs= [KNL,BOOT]
+ Set delay from grace-period initialization to
+ first attempt to force quiescent states.
+ Units are jiffies, minimum value is zero,
+ and maximum value is HZ.
+
+ rcutree.jiffies_till_next_fqs= [KNL,BOOT]
+ Set delay between subsequent attempts to force
+ quiescent states. Units are jiffies, minimum
+ value is one, and maximum value is HZ.
+
rcutree.qhimark= [KNL,BOOT]
Set threshold of queued
RCU callbacks over which batch limiting is disabled.
@@ -2472,16 +2590,15 @@
rcutree.rcu_cpu_stall_timeout= [KNL,BOOT]
Set timeout for RCU CPU stall warning messages.
- rcutree.jiffies_till_first_fqs= [KNL,BOOT]
- Set delay from grace-period initialization to
- first attempt to force quiescent states.
- Units are jiffies, minimum value is zero,
- and maximum value is HZ.
+ rcutree.rcu_idle_gp_delay= [KNL,BOOT]
+ Set wakeup interval for idle CPUs that have
+ RCU callbacks (RCU_FAST_NO_HZ=y).
- rcutree.jiffies_till_next_fqs= [KNL,BOOT]
- Set delay between subsequent attempts to force
- quiescent states. Units are jiffies, minimum
- value is one, and maximum value is HZ.
+ rcutree.rcu_idle_lazy_gp_delay= [KNL,BOOT]
+ Set wakeup interval for idle CPUs that have
+ only "lazy" RCU callbacks (RCU_FAST_NO_HZ=y).
+ Lazy RCU callbacks are those which RCU can
+ prove do nothing more than free memory.
rcutorture.fqs_duration= [KNL,BOOT]
Set duration of force_quiescent_state bursts.
@@ -2564,9 +2681,17 @@
Run specified binary instead of /init from the ramdisk,
used for early userspace startup. See initrd.
- reboot= [BUGS=X86-32,BUGS=ARM,BUGS=IA-64] Rebooting mode
- Format: <reboot_mode>[,<reboot_mode2>[,...]]
- See arch/*/kernel/reboot.c or arch/*/kernel/process.c
+ reboot= [KNL]
+ Format (x86 or x86_64):
+ [w[arm] | c[old] | h[ard] | s[oft] | g[pio]] \
+ [[,]s[mp]#### \
+ [[,]b[ios] | a[cpi] | k[bd] | t[riple] | e[fi] | p[ci]] \
+ [[,]f[orce]
+ Where reboot_mode is one of warm (soft) or cold (hard) or gpio,
+ reboot_type is one of bios, acpi, kbd, triple, efi, or pci,
+ reboot_force is either force or not specified,
+ reboot_cpu is s[mp]#### with #### being the processor
+ to be used for rebooting.
relax_domain_level=
[KNL, SMP] Set scheduler's default relax_domain_level.
@@ -2634,6 +2759,11 @@
Useful for devices that are detected asynchronously
(e.g. USB and MMC devices).
+ rproc_mem=nn[KMG][@address]
+ [KNL,ARM,CMA] Remoteproc physical memory block.
+ Memory area to be used by remote processor image,
+ managed by CMA.
+
rw [KNL] Mount root device read-write on boot
S [KNL] Run init in single mode
@@ -2887,6 +3017,27 @@
Force threading of all interrupt handlers except those
marked explicitly IRQF_NO_THREAD.
+ tmem [KNL,XEN]
+ Enable the Transcendent memory driver if built-in.
+
+ tmem.cleancache=0|1 [KNL, XEN]
+ Default is on (1). Disable the usage of the cleancache
+ API to send anonymous pages to the hypervisor.
+
+ tmem.frontswap=0|1 [KNL, XEN]
+ Default is on (1). Disable the usage of the frontswap
+ API to send swap pages to the hypervisor. If disabled
+ the selfballooning and selfshrinking are force disabled.
+
+ tmem.selfballooning=0|1 [KNL, XEN]
+ Default is on (1). Disable the driving of swap pages
+ to the hypervisor.
+
+ tmem.selfshrinking=0|1 [KNL, XEN]
+ Default is on (1). Partial swapoff that immediately
+ transfers pages from Xen hypervisor back to the
+ kernel based on different criteria.
+
topology= [S390]
Format: {off | on}
Specify if the kernel should make use of the cpu
@@ -2930,6 +3081,19 @@
See also Documentation/trace/ftrace.txt "trace options"
section.
+ traceoff_on_warning
+ [FTRACE] enable this option to disable tracing when a
+ warning is hit. This turns off "tracing_on". Tracing can
+ be enabled again by echoing '1' into the "tracing_on"
+ file located in /sys/kernel/debug/tracing/
+
+ This option is useful, as it disables the trace before
+ the WARNING dump is called, which prevents the trace to
+ be filled with content caused by the warning output.
+
+ This option can also be set at run time via the sysctl
+ option: kernel/traceoff_on_warning
+
transparent_hugepage=
[KNL]
Format: [always|madvise|never]
@@ -3090,6 +3254,15 @@
video= [FB] Frame buffer configuration
See Documentation/fb/modedb.txt.
+ video.brightness_switch_enabled= [0,1]
+ If set to 1, on receiving an ACPI notify event
+ generated by hotkey, video driver will adjust brightness
+ level and then send out the event to user space through
+ the allocated input device; If set to 0, video driver
+ will only send out the event without touching backlight
+ brightness level.
+ default: 1
+
virtio_mmio.device=
[VMMIO] Memory mapped virtio (platform) device.
@@ -3193,6 +3366,30 @@
or other driver-specific files in the
Documentation/watchdog/ directory.
+ workqueue.disable_numa
+ By default, all work items queued to unbound
+ workqueues are affine to the NUMA nodes they're
+ issued on, which results in better behavior in
+ general. If NUMA affinity needs to be disabled for
+ whatever reason, this option can be used. Note
+ that this also can be controlled per-workqueue for
+ workqueues visible under /sys/bus/workqueue/.
+
+ workqueue.power_efficient
+ Per-cpu workqueues are generally preferred because
+ they show better performance thanks to cache
+ locality; unfortunately, per-cpu workqueues tend to
+ be more power hungry than unbound workqueues.
+
+ Enabling this makes the per-cpu workqueues which
+ were observed to contribute significantly to power
+ consumption unbound, leading to measurably lower
+ power usage at the cost of small performance
+ overhead.
+
+ The default value of this parameter is determined by
+ the config option CONFIG_WQ_POWER_EFFICIENT_DEFAULT.
+
x2apic_phys [X86-64,APIC] Use x2apic physical mode instead of
default x2apic cluster mode on platforms
supporting x2apic.
@@ -3203,9 +3400,6 @@
plus one apbt timer for broadcast timer.
x86_mrst_timer=apbt_only | lapic_and_apbt
- xd= [HW,XT] Original XT pre-IDE (RLL encoded) disks.
- xd_geo= See header of drivers/block/xd.c.
-
xen_emul_unplug= [HW,X86,XEN]
Unplug Xen emulated devices
Format: [unplug0,][unplug1]
diff --git a/Documentation/kernel-per-CPU-kthreads.txt b/Documentation/kernel-per-CPU-kthreads.txt
new file mode 100644
index 0000000..32351bf
--- /dev/null
+++ b/Documentation/kernel-per-CPU-kthreads.txt
@@ -0,0 +1,249 @@
+REDUCING OS JITTER DUE TO PER-CPU KTHREADS
+
+This document lists per-CPU kthreads in the Linux kernel and presents
+options to control their OS jitter. Note that non-per-CPU kthreads are
+not listed here. To reduce OS jitter from non-per-CPU kthreads, bind
+them to a "housekeeping" CPU dedicated to such work.
+
+
+REFERENCES
+
+o Documentation/IRQ-affinity.txt: Binding interrupts to sets of CPUs.
+
+o Documentation/cgroups: Using cgroups to bind tasks to sets of CPUs.
+
+o man taskset: Using the taskset command to bind tasks to sets
+ of CPUs.
+
+o man sched_setaffinity: Using the sched_setaffinity() system
+ call to bind tasks to sets of CPUs.
+
+o /sys/devices/system/cpu/cpuN/online: Control CPU N's hotplug state,
+ writing "0" to offline and "1" to online.
+
+o In order to locate kernel-generated OS jitter on CPU N:
+
+ cd /sys/kernel/debug/tracing
+ echo 1 > max_graph_depth # Increase the "1" for more detail
+ echo function_graph > current_tracer
+ # run workload
+ cat per_cpu/cpuN/trace
+
+
+KTHREADS
+
+Name: ehca_comp/%u
+Purpose: Periodically process Infiniband-related work.
+To reduce its OS jitter, do any of the following:
+1. Don't use eHCA Infiniband hardware, instead choosing hardware
+ that does not require per-CPU kthreads. This will prevent these
+ kthreads from being created in the first place. (This will
+ work for most people, as this hardware, though important, is
+ relatively old and is produced in relatively low unit volumes.)
+2. Do all eHCA-Infiniband-related work on other CPUs, including
+ interrupts.
+3. Rework the eHCA driver so that its per-CPU kthreads are
+ provisioned only on selected CPUs.
+
+
+Name: irq/%d-%s
+Purpose: Handle threaded interrupts.
+To reduce its OS jitter, do the following:
+1. Use irq affinity to force the irq threads to execute on
+ some other CPU.
+
+Name: kcmtpd_ctr_%d
+Purpose: Handle Bluetooth work.
+To reduce its OS jitter, do one of the following:
+1. Don't use Bluetooth, in which case these kthreads won't be
+ created in the first place.
+2. Use irq affinity to force Bluetooth-related interrupts to
+ occur on some other CPU and furthermore initiate all
+ Bluetooth activity on some other CPU.
+
+Name: ksoftirqd/%u
+Purpose: Execute softirq handlers when threaded or when under heavy load.
+To reduce its OS jitter, each softirq vector must be handled
+separately as follows:
+TIMER_SOFTIRQ: Do all of the following:
+1. To the extent possible, keep the CPU out of the kernel when it
+ is non-idle, for example, by avoiding system calls and by forcing
+ both kernel threads and interrupts to execute elsewhere.
+2. Build with CONFIG_HOTPLUG_CPU=y. After boot completes, force
+ the CPU offline, then bring it back online. This forces
+ recurring timers to migrate elsewhere. If you are concerned
+ with multiple CPUs, force them all offline before bringing the
+ first one back online. Once you have onlined the CPUs in question,
+ do not offline any other CPUs, because doing so could force the
+ timer back onto one of the CPUs in question.
+NET_TX_SOFTIRQ and NET_RX_SOFTIRQ: Do all of the following:
+1. Force networking interrupts onto other CPUs.
+2. Initiate any network I/O on other CPUs.
+3. Once your application has started, prevent CPU-hotplug operations
+ from being initiated from tasks that might run on the CPU to
+ be de-jittered. (It is OK to force this CPU offline and then
+ bring it back online before you start your application.)
+BLOCK_SOFTIRQ: Do all of the following:
+1. Force block-device interrupts onto some other CPU.
+2. Initiate any block I/O on other CPUs.
+3. Once your application has started, prevent CPU-hotplug operations
+ from being initiated from tasks that might run on the CPU to
+ be de-jittered. (It is OK to force this CPU offline and then
+ bring it back online before you start your application.)
+BLOCK_IOPOLL_SOFTIRQ: Do all of the following:
+1. Force block-device interrupts onto some other CPU.
+2. Initiate any block I/O and block-I/O polling on other CPUs.
+3. Once your application has started, prevent CPU-hotplug operations
+ from being initiated from tasks that might run on the CPU to
+ be de-jittered. (It is OK to force this CPU offline and then
+ bring it back online before you start your application.)
+TASKLET_SOFTIRQ: Do one or more of the following:
+1. Avoid use of drivers that use tasklets. (Such drivers will contain
+ calls to things like tasklet_schedule().)
+2. Convert all drivers that you must use from tasklets to workqueues.
+3. Force interrupts for drivers using tasklets onto other CPUs,
+ and also do I/O involving these drivers on other CPUs.
+SCHED_SOFTIRQ: Do all of the following:
+1. Avoid sending scheduler IPIs to the CPU to be de-jittered,
+ for example, ensure that at most one runnable kthread is present
+ on that CPU. If a thread that expects to run on the de-jittered
+ CPU awakens, the scheduler will send an IPI that can result in
+ a subsequent SCHED_SOFTIRQ.
+2. Build with CONFIG_RCU_NOCB_CPU=y, CONFIG_RCU_NOCB_CPU_ALL=y,
+ CONFIG_NO_HZ_FULL=y, and, in addition, ensure that the CPU
+ to be de-jittered is marked as an adaptive-ticks CPU using the
+ "nohz_full=" boot parameter. This reduces the number of
+ scheduler-clock interrupts that the de-jittered CPU receives,
+ minimizing its chances of being selected to do the load balancing
+ work that runs in SCHED_SOFTIRQ context.
+3. To the extent possible, keep the CPU out of the kernel when it
+ is non-idle, for example, by avoiding system calls and by
+ forcing both kernel threads and interrupts to execute elsewhere.
+ This further reduces the number of scheduler-clock interrupts
+ received by the de-jittered CPU.
+HRTIMER_SOFTIRQ: Do all of the following:
+1. To the extent possible, keep the CPU out of the kernel when it
+ is non-idle. For example, avoid system calls and force both
+ kernel threads and interrupts to execute elsewhere.
+2. Build with CONFIG_HOTPLUG_CPU=y. Once boot completes, force the
+ CPU offline, then bring it back online. This forces recurring
+ timers to migrate elsewhere. If you are concerned with multiple
+ CPUs, force them all offline before bringing the first one
+ back online. Once you have onlined the CPUs in question, do not
+ offline any other CPUs, because doing so could force the timer
+ back onto one of the CPUs in question.
+RCU_SOFTIRQ: Do at least one of the following:
+1. Offload callbacks and keep the CPU in either dyntick-idle or
+ adaptive-ticks state by doing all of the following:
+ a. Build with CONFIG_RCU_NOCB_CPU=y, CONFIG_RCU_NOCB_CPU_ALL=y,
+ CONFIG_NO_HZ_FULL=y, and, in addition ensure that the CPU
+ to be de-jittered is marked as an adaptive-ticks CPU using
+ the "nohz_full=" boot parameter. Bind the rcuo kthreads
+ to housekeeping CPUs, which can tolerate OS jitter.
+ b. To the extent possible, keep the CPU out of the kernel
+ when it is non-idle, for example, by avoiding system
+ calls and by forcing both kernel threads and interrupts
+ to execute elsewhere.
+2. Enable RCU to do its processing remotely via dyntick-idle by
+ doing all of the following:
+ a. Build with CONFIG_NO_HZ=y and CONFIG_RCU_FAST_NO_HZ=y.
+ b. Ensure that the CPU goes idle frequently, allowing other
+ CPUs to detect that it has passed through an RCU quiescent
+ state. If the kernel is built with CONFIG_NO_HZ_FULL=y,
+ userspace execution also allows other CPUs to detect that
+ the CPU in question has passed through a quiescent state.
+ c. To the extent possible, keep the CPU out of the kernel
+ when it is non-idle, for example, by avoiding system
+ calls and by forcing both kernel threads and interrupts
+ to execute elsewhere.
+
+Name: kworker/%u:%d%s (cpu, id, priority)
+Purpose: Execute workqueue requests
+To reduce its OS jitter, do any of the following:
+1. Run your workload at a real-time priority, which will allow
+ preempting the kworker daemons.
+2. Do any of the following needed to avoid jitter that your
+ application cannot tolerate:
+ a. Build your kernel with CONFIG_SLUB=y rather than
+ CONFIG_SLAB=y, thus avoiding the slab allocator's periodic
+ use of each CPU's workqueues to run its cache_reap()
+ function.
+ b. Avoid using oprofile, thus avoiding OS jitter from
+ wq_sync_buffer().
+ c. Limit your CPU frequency so that a CPU-frequency
+ governor is not required, possibly enlisting the aid of
+ special heatsinks or other cooling technologies. If done
+ correctly, and if you CPU architecture permits, you should
+ be able to build your kernel with CONFIG_CPU_FREQ=n to
+ avoid the CPU-frequency governor periodically running
+ on each CPU, including cs_dbs_timer() and od_dbs_timer().
+ WARNING: Please check your CPU specifications to
+ make sure that this is safe on your particular system.
+ d. It is not possible to entirely get rid of OS jitter
+ from vmstat_update() on CONFIG_SMP=y systems, but you
+ can decrease its frequency by writing a large value to
+ /proc/sys/vm/stat_interval. The default value is HZ,
+ for an interval of one second. Of course, larger values
+ will make your virtual-memory statistics update more
+ slowly. Of course, you can also run your workload at
+ a real-time priority, thus preempting vmstat_update().
+ e. If running on high-end powerpc servers, build with
+ CONFIG_PPC_RTAS_DAEMON=n. This prevents the RTAS
+ daemon from running on each CPU every second or so.
+ (This will require editing Kconfig files and will defeat
+ this platform's RAS functionality.) This avoids jitter
+ due to the rtas_event_scan() function.
+ WARNING: Please check your CPU specifications to
+ make sure that this is safe on your particular system.
+ f. If running on Cell Processor, build your kernel with
+ CBE_CPUFREQ_SPU_GOVERNOR=n to avoid OS jitter from
+ spu_gov_work().
+ WARNING: Please check your CPU specifications to
+ make sure that this is safe on your particular system.
+ g. If running on PowerMAC, build your kernel with
+ CONFIG_PMAC_RACKMETER=n to disable the CPU-meter,
+ avoiding OS jitter from rackmeter_do_timer().
+
+Name: rcuc/%u
+Purpose: Execute RCU callbacks in CONFIG_RCU_BOOST=y kernels.
+To reduce its OS jitter, do at least one of the following:
+1. Build the kernel with CONFIG_PREEMPT=n. This prevents these
+ kthreads from being created in the first place, and also obviates
+ the need for RCU priority boosting. This approach is feasible
+ for workloads that do not require high degrees of responsiveness.
+2. Build the kernel with CONFIG_RCU_BOOST=n. This prevents these
+ kthreads from being created in the first place. This approach
+ is feasible only if your workload never requires RCU priority
+ boosting, for example, if you ensure frequent idle time on all
+ CPUs that might execute within the kernel.
+3. Build with CONFIG_RCU_NOCB_CPU=y and CONFIG_RCU_NOCB_CPU_ALL=y,
+ which offloads all RCU callbacks to kthreads that can be moved
+ off of CPUs susceptible to OS jitter. This approach prevents the
+ rcuc/%u kthreads from having any work to do, so that they are
+ never awakened.
+4. Ensure that the CPU never enters the kernel, and, in particular,
+ avoid initiating any CPU hotplug operations on this CPU. This is
+ another way of preventing any callbacks from being queued on the
+ CPU, again preventing the rcuc/%u kthreads from having any work
+ to do.
+
+Name: rcuob/%d, rcuop/%d, and rcuos/%d
+Purpose: Offload RCU callbacks from the corresponding CPU.
+To reduce its OS jitter, do at least one of the following:
+1. Use affinity, cgroups, or other mechanism to force these kthreads
+ to execute on some other CPU.
+2. Build with CONFIG_RCU_NOCB_CPU=n, which will prevent these
+ kthreads from being created in the first place. However, please
+ note that this will not eliminate OS jitter, but will instead
+ shift it to RCU_SOFTIRQ.
+
+Name: watchdog/%u
+Purpose: Detect software lockups on each CPU.
+To reduce its OS jitter, do at least one of the following:
+1. Build with CONFIG_LOCKUP_DETECTOR=n, which will prevent these
+ kthreads from being created in the first place.
+2. Echo a zero to /proc/sys/kernel/watchdog to disable the
+ watchdog timer.
+3. Echo a large number of /proc/sys/kernel/watchdog_thresh in
+ order to reduce the frequency of OS jitter due to the watchdog
+ timer down to a level that is acceptable for your workload.
diff --git a/Documentation/laptops/dslm.c b/Documentation/laptops/dslm.c
index 72ff290..d5dd2d4 100644
--- a/Documentation/laptops/dslm.c
+++ b/Documentation/laptops/dslm.c
@@ -2,7 +2,7 @@
* dslm.c
* Simple Disk Sleep Monitor
* by Bartek Kania
- * Licenced under the GPL
+ * Licensed under the GPL
*/
#include <unistd.h>
#include <stdlib.h>
diff --git a/Documentation/laptops/thinkpad-acpi.txt b/Documentation/laptops/thinkpad-acpi.txt
index 9d66682..cf7bc6c 100644
--- a/Documentation/laptops/thinkpad-acpi.txt
+++ b/Documentation/laptops/thinkpad-acpi.txt
@@ -1398,7 +1398,7 @@
EXPERIMENTAL: UWB
-----------------
-This feature is marked EXPERIMENTAL because it has not been extensively
+This feature is considered EXPERIMENTAL because it has not been extensively
tested and validated in various ThinkPad models yet. The feature may not
work as expected. USE WITH CAUTION! To use this feature, you need to supply
the experimental=1 parameter when loading the module.
diff --git a/Documentation/leds/00-INDEX b/Documentation/leds/00-INDEX
index 5fefe37..1ecd159 100644
--- a/Documentation/leds/00-INDEX
+++ b/Documentation/leds/00-INDEX
@@ -6,5 +6,9 @@
- notes on how to use the leds-lp5521 driver.
leds-lp5523.txt
- notes on how to use the leds-lp5523 driver.
+leds-lp5562.txt
+ - notes on how to use the leds-lp5562 driver.
+leds-lp55xx.txt
+ - description about lp55xx common driver.
leds-lm3556.txt
- notes on how to use the leds-lm3556 driver.
diff --git a/Documentation/leds/leds-lp5521.txt b/Documentation/leds/leds-lp5521.txt
index 0e542ab..79e4c2e 100644
--- a/Documentation/leds/leds-lp5521.txt
+++ b/Documentation/leds/leds-lp5521.txt
@@ -17,19 +17,8 @@
All three channels can be also controlled using the engine micro programs.
More details of the instructions can be found from the public data sheet.
-Control interface for the engines:
-x is 1 .. 3
-enginex_mode : disabled, load, run
-enginex_load : store program (visible only in engine load mode)
-
-Example (start to blink the channel 2 led):
-cd /sys/class/leds/lp5521:channel2/device
-echo "load" > engine3_mode
-echo "037f4d0003ff6000" > engine3_load
-echo "run" > engine3_mode
-
-stop the engine:
-echo "disabled" > engine3_mode
+LP5521 has the internal program memory for running various LED patterns.
+For the details, please refer to 'firmware' section in leds-lp55xx.txt
sysfs contains a selftest entry.
The test communicates with the chip and checks that
@@ -47,7 +36,7 @@
If the name field is not defined, the default name will be set to 'xxxx:channelN'
(XXXX : pdata->label or i2c client name, N : channel number)
-static struct lp5521_led_config lp5521_led_config[] = {
+static struct lp55xx_led_config lp5521_led_config[] = {
{
.name = "red",
.chan_nr = 0,
@@ -81,10 +70,10 @@
/* Control of chip enable signal */
}
-static struct lp5521_platform_data lp5521_platform_data = {
+static struct lp55xx_platform_data lp5521_platform_data = {
.led_config = lp5521_led_config,
.num_channels = ARRAY_SIZE(lp5521_led_config),
- .clock_mode = LP5521_CLOCK_EXT,
+ .clock_mode = LP55XX_CLOCK_EXT,
.setup_resources = lp5521_setup,
.release_resources = lp5521_release,
.enable = lp5521_enable,
@@ -92,60 +81,3 @@
If the current is set to 0 in the platform data, that channel is
disabled and it is not visible in the sysfs.
-
-The 'update_config' : CONFIG register (ADDR 08h)
-This value is platform-specific data.
-If update_config is not defined, the CONFIG register is set with
-'LP5521_PWRSAVE_EN | LP5521_CP_MODE_AUTO | LP5521_R_TO_BATT'.
-(Enable auto-powersave, set charge pump to auto, red to battery)
-
-example of update_config :
-
-#define LP5521_CONFIGS (LP5521_PWM_HF | LP5521_PWRSAVE_EN | \
- LP5521_CP_MODE_AUTO | LP5521_R_TO_BATT | \
- LP5521_CLK_INT)
-
-static struct lp5521_platform_data lp5521_pdata = {
- .led_config = lp5521_led_config,
- .num_channels = ARRAY_SIZE(lp5521_led_config),
- .clock_mode = LP5521_CLOCK_INT,
- .update_config = LP5521_CONFIGS,
-};
-
-LED patterns : LP5521 has autonomous operation without external control.
-Pattern data can be defined in the platform data.
-
-example of led pattern data :
-
-/* RGB(50,5,0) 500ms on, 500ms off, infinite loop */
-static u8 pattern_red[] = {
- 0x40, 0x32, 0x60, 0x00, 0x40, 0x00, 0x60, 0x00,
- };
-
-static u8 pattern_green[] = {
- 0x40, 0x05, 0x60, 0x00, 0x40, 0x00, 0x60, 0x00,
- };
-
-static struct lp5521_led_pattern board_led_patterns[] = {
- {
- .r = pattern_red,
- .g = pattern_green,
- .size_r = ARRAY_SIZE(pattern_red),
- .size_g = ARRAY_SIZE(pattern_green),
- },
-};
-
-static struct lp5521_platform_data lp5521_platform_data = {
- .led_config = lp5521_led_config,
- .num_channels = ARRAY_SIZE(lp5521_led_config),
- .clock_mode = LP5521_CLOCK_EXT,
- .patterns = board_led_patterns,
- .num_patterns = ARRAY_SIZE(board_led_patterns),
-};
-
-Then predefined led pattern(s) can be executed via the sysfs.
-To start the pattern #1,
-# echo 1 > /sys/bus/i2c/devices/xxxx/led_pattern
-(xxxx : i2c bus & slave address)
-To end the pattern,
-# echo 0 > /sys/bus/i2c/devices/xxxx/led_pattern
diff --git a/Documentation/leds/leds-lp5523.txt b/Documentation/leds/leds-lp5523.txt
index c2743f5..899fdad 100644
--- a/Documentation/leds/leds-lp5523.txt
+++ b/Documentation/leds/leds-lp5523.txt
@@ -27,25 +27,8 @@
If both fields are NULL, 'lp5523' is used by default.
/sys/class/leds/lp5523:channelN (N: 0 ~ 8)
-The chip provides 3 engines. Each engine can control channels without
-interaction from the main CPU. Details of the micro engine code can be found
-from the public data sheet. Leds can be muxed to different channels.
-
-Control interface for the engines:
-x is 1 .. 3
-enginex_mode : disabled, load, run
-enginex_load : microcode load (visible only in load mode)
-enginex_leds : led mux control (visible only in load mode)
-
-cd /sys/class/leds/lp5523:channel2/device
-echo "load" > engine3_mode
-echo "9d80400004ff05ff437f0000" > engine3_load
-echo "111111111" > engine3_leds
-echo "run" > engine3_mode
-
-sysfs contains a selftest entry. It measures each channel
-voltage level and checks if it looks reasonable. If the level is too high,
-the led is missing; if the level is too low, there is a short circuit.
+LP5523 has the internal program memory for running various LED patterns.
+For the details, please refer to 'firmware' section in leds-lp55xx.txt
Selftest uses always the current from the platform data.
@@ -58,7 +41,7 @@
Note - chan_nr can have values between 0 and 8.
-static struct lp5523_led_config lp5523_led_config[] = {
+static struct lp55xx_led_config lp5523_led_config[] = {
{
.name = "D1",
.chan_nr = 0,
@@ -88,10 +71,10 @@
/* Control chip enable signal */
}
-static struct lp5523_platform_data lp5523_platform_data = {
+static struct lp55xx_platform_data lp5523_platform_data = {
.led_config = lp5523_led_config,
.num_channels = ARRAY_SIZE(lp5523_led_config),
- .clock_mode = LP5523_CLOCK_EXT,
+ .clock_mode = LP55XX_CLOCK_EXT,
.setup_resources = lp5523_setup,
.release_resources = lp5523_release,
.enable = lp5523_enable,
diff --git a/Documentation/leds/leds-lp5562.txt b/Documentation/leds/leds-lp5562.txt
new file mode 100644
index 0000000..5a823ff
--- /dev/null
+++ b/Documentation/leds/leds-lp5562.txt
@@ -0,0 +1,120 @@
+Kernel driver for LP5562
+========================
+
+* TI LP5562 LED Driver
+
+Author: Milo(Woogyom) Kim <milo.kim@ti.com>
+
+Description
+
+ LP5562 can drive up to 4 channels. R/G/B and White.
+ LEDs can be controlled directly via the led class control interface.
+
+ All four channels can be also controlled using the engine micro programs.
+ LP5562 has the internal program memory for running various LED patterns.
+ For the details, please refer to 'firmware' section in leds-lp55xx.txt
+
+Device attribute: engine_mux
+
+ 3 Engines are allocated in LP5562, but the number of channel is 4.
+ Therefore each channel should be mapped to the engine number.
+ Value : RGB or W
+
+ This attribute is used for programming LED data with the firmware interface.
+ Unlike the LP5521/LP5523/55231, LP5562 has unique feature for the engine mux,
+ so additional sysfs is required.
+
+ LED Map
+ Red ... Engine 1 (fixed)
+ Green ... Engine 2 (fixed)
+ Blue ... Engine 3 (fixed)
+ White ... Engine 1 or 2 or 3 (selective)
+
+How to load the program data using engine_mux
+
+ Before loading the LP5562 program data, engine_mux should be written between
+ the engine selection and loading the firmware.
+ Engine mux has two different mode, RGB and W.
+ RGB is used for loading RGB program data, W is used for W program data.
+
+ For example, run blinking green channel pattern,
+ echo 2 > /sys/bus/i2c/devices/xxxx/select_engine # 2 is for green channel
+ echo "RGB" > /sys/bus/i2c/devices/xxxx/engine_mux # engine mux for RGB
+ echo 1 > /sys/class/firmware/lp5562/loading
+ echo "4000600040FF6000" > /sys/class/firmware/lp5562/data
+ echo 0 > /sys/class/firmware/lp5562/loading
+ echo 1 > /sys/bus/i2c/devices/xxxx/run_engine
+
+ To run a blinking white pattern,
+ echo 1 or 2 or 3 > /sys/bus/i2c/devices/xxxx/select_engine
+ echo "W" > /sys/bus/i2c/devices/xxxx/engine_mux
+ echo 1 > /sys/class/firmware/lp5562/loading
+ echo "4000600040FF6000" > /sys/class/firmware/lp5562/data
+ echo 0 > /sys/class/firmware/lp5562/loading
+ echo 1 > /sys/bus/i2c/devices/xxxx/run_engine
+
+How to load the predefined patterns
+
+ Please refer to 'leds-lp55xx.txt"
+
+Setting Current of Each Channel
+
+ Like LP5521 and LP5523/55231, LP5562 provides LED current settings.
+ The 'led_current' and 'max_current' are used.
+
+(Example of Platform data)
+
+To configure the platform specific data, lp55xx_platform_data structure is used.
+
+static struct lp55xx_led_config lp5562_led_config[] = {
+ {
+ .name = "R",
+ .chan_nr = 0,
+ .led_current = 20,
+ .max_current = 40,
+ },
+ {
+ .name = "G",
+ .chan_nr = 1,
+ .led_current = 20,
+ .max_current = 40,
+ },
+ {
+ .name = "B",
+ .chan_nr = 2,
+ .led_current = 20,
+ .max_current = 40,
+ },
+ {
+ .name = "W",
+ .chan_nr = 3,
+ .led_current = 20,
+ .max_current = 40,
+ },
+};
+
+static int lp5562_setup(void)
+{
+ /* setup HW resources */
+}
+
+static void lp5562_release(void)
+{
+ /* Release HW resources */
+}
+
+static void lp5562_enable(bool state)
+{
+ /* Control of chip enable signal */
+}
+
+static struct lp55xx_platform_data lp5562_platform_data = {
+ .led_config = lp5562_led_config,
+ .num_channels = ARRAY_SIZE(lp5562_led_config),
+ .setup_resources = lp5562_setup,
+ .release_resources = lp5562_release,
+ .enable = lp5562_enable,
+};
+
+If the current is set to 0 in the platform data, that channel is
+disabled and it is not visible in the sysfs.
diff --git a/Documentation/leds/leds-lp55xx.txt b/Documentation/leds/leds-lp55xx.txt
new file mode 100644
index 0000000..eec8fa2
--- /dev/null
+++ b/Documentation/leds/leds-lp55xx.txt
@@ -0,0 +1,162 @@
+LP5521/LP5523/LP55231 Common Driver
+===================================
+
+Authors: Milo(Woogyom) Kim <milo.kim@ti.com>
+
+Description
+-----------
+LP5521, LP5523/55231 and LP5562 have common features as below.
+
+ Register access via the I2C
+ Device initialization/deinitialization
+ Create LED class devices for multiple output channels
+ Device attributes for user-space interface
+ Program memory for running LED patterns
+
+The LP55xx common driver provides these features using exported functions.
+ lp55xx_init_device() / lp55xx_deinit_device()
+ lp55xx_register_leds() / lp55xx_unregister_leds()
+ lp55xx_regsister_sysfs() / lp55xx_unregister_sysfs()
+
+( Driver Structure Data )
+
+In lp55xx common driver, two different data structure is used.
+
+o lp55xx_led
+ control multi output LED channels such as led current, channel index.
+o lp55xx_chip
+ general chip control such like the I2C and platform data.
+
+For example, LP5521 has maximum 3 LED channels.
+LP5523/55231 has 9 output channels.
+
+lp55xx_chip for LP5521 ... lp55xx_led #1
+ lp55xx_led #2
+ lp55xx_led #3
+
+lp55xx_chip for LP5523 ... lp55xx_led #1
+ lp55xx_led #2
+ .
+ .
+ lp55xx_led #9
+
+( Chip Dependent Code )
+
+To support device specific configurations, special structure
+'lpxx_device_config' is used.
+
+ Maximum number of channels
+ Reset command, chip enable command
+ Chip specific initialization
+ Brightness control register access
+ Setting LED output current
+ Program memory address access for running patterns
+ Additional device specific attributes
+
+( Firmware Interface )
+
+LP55xx family devices have the internal program memory for running
+various LED patterns.
+This pattern data is saved as a file in the user-land or
+hex byte string is written into the memory through the I2C.
+LP55xx common driver supports the firmware interface.
+
+LP55xx chips have three program engines.
+To load and run the pattern, the programming sequence is following.
+ (1) Select an engine number (1/2/3)
+ (2) Mode change to load
+ (3) Write pattern data into selected area
+ (4) Mode change to run
+
+The LP55xx common driver provides simple interfaces as below.
+select_engine : Select which engine is used for running program
+run_engine : Start program which is loaded via the firmware interface
+firmware : Load program data
+
+For example, run blinking pattern in engine #1 of LP5521
+echo 1 > /sys/bus/i2c/devices/xxxx/select_engine
+echo 1 > /sys/class/firmware/lp5521/loading
+echo "4000600040FF6000" > /sys/class/firmware/lp5521/data
+echo 0 > /sys/class/firmware/lp5521/loading
+echo 1 > /sys/bus/i2c/devices/xxxx/run_engine
+
+For example, run blinking pattern in engine #3 of LP55231
+echo 3 > /sys/bus/i2c/devices/xxxx/select_engine
+echo 1 > /sys/class/firmware/lp55231/loading
+echo "9d0740ff7e0040007e00a0010000" > /sys/class/firmware/lp55231/data
+echo 0 > /sys/class/firmware/lp55231/loading
+echo 1 > /sys/bus/i2c/devices/xxxx/run_engine
+
+To start blinking patterns in engine #2 and #3 simultaneously,
+for idx in 2 3
+do
+ echo $idx > /sys/class/leds/red/device/select_engine
+ sleep 0.1
+ echo 1 > /sys/class/firmware/lp5521/loading
+ echo "4000600040FF6000" > /sys/class/firmware/lp5521/data
+ echo 0 > /sys/class/firmware/lp5521/loading
+done
+echo 1 > /sys/class/leds/red/device/run_engine
+
+Here is another example for LP5523.
+echo 2 > /sys/bus/i2c/devices/xxxx/select_engine
+echo 1 > /sys/class/firmware/lp5523/loading
+echo "9d80400004ff05ff437f0000" > /sys/class/firmware/lp5523/data
+echo 0 > /sys/class/firmware/lp5523/loading
+echo 1 > /sys/bus/i2c/devices/xxxx/run_engine
+
+As soon as 'loading' is set to 0, registered callback is called.
+Inside the callback, the selected engine is loaded and memory is updated.
+To run programmed pattern, 'run_engine' attribute should be enabled.
+
+( 'run_engine' and 'firmware_cb' )
+The sequence of running the program data is common.
+But each device has own specific register addresses for commands.
+To support this, 'run_engine' and 'firmware_cb' are configurable in each driver.
+run_engine : Control the selected engine
+firmware_cb : The callback function after loading the firmware is done.
+ Chip specific commands for loading and updating program memory.
+
+( Predefined pattern data )
+
+Without the firmware interface, LP55xx driver provides another method for
+loading a LED pattern. That is 'predefined' pattern.
+A predefined pattern is defined in the platform data and load it(or them)
+via the sysfs if needed.
+To use the predefined pattern concept, 'patterns' and 'num_patterns' should be
+configured.
+
+ Example of predefined pattern data:
+
+ /* mode_1: blinking data */
+ static const u8 mode_1[] = {
+ 0x40, 0x00, 0x60, 0x00, 0x40, 0xFF, 0x60, 0x00,
+ };
+
+ /* mode_2: always on */
+ static const u8 mode_2[] = { 0x40, 0xFF, };
+
+ struct lp55xx_predef_pattern board_led_patterns[] = {
+ {
+ .r = mode_1,
+ .size_r = ARRAY_SIZE(mode_1),
+ },
+ {
+ .b = mode_2,
+ .size_b = ARRAY_SIZE(mode_2),
+ },
+ }
+
+ struct lp55xx_platform_data lp5562_pdata = {
+ ...
+ .patterns = board_led_patterns,
+ .num_patterns = ARRAY_SIZE(board_led_patterns),
+ };
+
+Then, mode_1 and mode_2 can be run via through the sysfs.
+
+ echo 1 > /sys/bus/i2c/devices/xxxx/led_pattern # red blinking LED pattern
+ echo 2 > /sys/bus/i2c/devices/xxxx/led_pattern # blue LED always on
+
+To stop running pattern,
+ echo 0 > /sys/bus/i2c/devices/xxxx/led_pattern
diff --git a/Documentation/lockstat.txt b/Documentation/lockstat.txt
index cef00d4..dd2f7b2 100644
--- a/Documentation/lockstat.txt
+++ b/Documentation/lockstat.txt
@@ -65,7 +65,7 @@
- CONFIGURATION
-Lock statistics are enabled via CONFIG_LOCK_STATS.
+Lock statistics are enabled via CONFIG_LOCK_STAT.
- USAGE
diff --git a/Documentation/m68k/kernel-options.txt b/Documentation/m68k/kernel-options.txt
index 97d45f2..eaf32a1 100644
--- a/Documentation/m68k/kernel-options.txt
+++ b/Documentation/m68k/kernel-options.txt
@@ -80,8 +80,6 @@
/dev/sdd: -> 0x0830 (forth SCSI disk)
/dev/sde: -> 0x0840 (fifth SCSI disk)
/dev/fd : -> 0x0200 (floppy disk)
- /dev/xda: -> 0x0c00 (first XT disk, unused in Linux/m68k)
- /dev/xdb: -> 0x0c40 (second XT disk, unused in Linux/m68k)
The name must be followed by a decimal number, that stands for the
partition number. Internally, the value of the number is just
diff --git a/Documentation/magic-number.txt b/Documentation/magic-number.txt
index 82761a3..76d80a6 100644
--- a/Documentation/magic-number.txt
+++ b/Documentation/magic-number.txt
@@ -122,7 +122,7 @@
COW_MAGIC 0x4f4f4f4d cow_header_v1 arch/um/drivers/ubd_user.c
I810_CARD_MAGIC 0x5072696E i810_card sound/oss/i810_audio.c
TRIDENT_CARD_MAGIC 0x5072696E trident_card sound/oss/trident.c
-ROUTER_MAGIC 0x524d4157 wan_device include/linux/wanrouter.h
+ROUTER_MAGIC 0x524d4157 wan_device [in wanrouter.h pre 3.9]
SCC_MAGIC 0x52696368 gs_port drivers/char/scc.h
SAVEKMSG_MAGIC1 0x53415645 savekmsg arch/*/amiga/config.c
GDA_MAGIC 0x58464552 gda arch/mips/include/asm/sn/gda.h
diff --git a/Documentation/md.txt b/Documentation/md.txt
index 993fba3..fbb2fcb 100644
--- a/Documentation/md.txt
+++ b/Documentation/md.txt
@@ -119,7 +119,7 @@
The array is started with the RUN_ARRAY ioctl.
Once started, new devices can be added. They should have an
-appropriate superblock written to them, and then passed be in with
+appropriate superblock written to them, and then be passed in with
ADD_NEW_DISK.
Devices that have failed or are not yet active can be detached from an
@@ -131,7 +131,7 @@
-------------------------------------------------------------
An array can be 'created' by describing the array (level, chunksize
-etc) in a SET_ARRAY_INFO ioctl. This must has major_version==0 and
+etc) in a SET_ARRAY_INFO ioctl. This must have major_version==0 and
raid_disks != 0.
Then uninitialized devices can be added with ADD_NEW_DISK. The
@@ -426,7 +426,7 @@
offset
This gives the location in the device (in sectors from the
start) where data from the array will be stored. Any part of
- the device before this offset us not touched, unless it is
+ the device before this offset is not touched, unless it is
used for storing metadata (Formats 1.1 and 1.2).
size
@@ -440,7 +440,7 @@
When the device is not 'in_sync', this records the number of
sectors from the start of the device which are known to be
correct. This is normally zero, but during a recovery
- operation is will steadily increase, and if the recovery is
+ operation it will steadily increase, and if the recovery is
interrupted, restoring this value can cause recovery to
avoid repeating the earlier blocks. With v1.x metadata, this
value is saved and restored automatically.
@@ -468,7 +468,7 @@
-An active md device will also contain and entry for each active device
+An active md device will also contain an entry for each active device
in the array. These are named
rdNN
@@ -482,7 +482,7 @@
-Active md devices for levels that support data redundancy (1,4,5,6)
+Active md devices for levels that support data redundancy (1,4,5,6,10)
also have
sync_action
@@ -494,7 +494,7 @@
failed/missing device
idle - nothing is happening
check - A full check of redundancy was requested and is
- happening. This reads all block and checks
+ happening. This reads all blocks and checks
them. A repair may also happen for some raid
levels.
repair - A full check and repair is happening. This is
@@ -522,7 +522,7 @@
degraded
This contains a count of the number of devices by which the
- arrays is degraded. So an optimal array with show '0'. A
+ arrays is degraded. So an optimal array will show '0'. A
single failed/missing drive will show '1', etc.
This file responds to select/poll, any increase or decrease
in the count of missing devices will trigger an event.
@@ -566,13 +566,6 @@
when it reaches the current sync_max (below) and possibly at
other times.
- sync_max
- This is a number of sectors at which point a resync/recovery
- process will pause. When a resync is active, the value can
- only ever be increased, never decreased. The value of 'max'
- effectively disables the limit.
-
-
sync_speed
This shows the current actual speed, in K/sec, of the current
sync_action. It is averaged over the last 30 seconds.
@@ -593,6 +586,12 @@
that number to reach sync_max. Then you can either increase
"sync_max", or can write 'idle' to "sync_action".
+ The value of 'max' for "sync_max" effectively disables the limit.
+ When a resync is active, the value can only ever be increased,
+ never decreased.
+ The value of '0' is the minimum for "sync_min".
+
+
Each active md device may also have attributes specific to the
personality module that manages it.
diff --git a/Documentation/media-framework.txt b/Documentation/media-framework.txt
index 8028754..f552a75 100644
--- a/Documentation/media-framework.txt
+++ b/Documentation/media-framework.txt
@@ -18,7 +18,7 @@
Discovering a device internal topology, and configuring it at runtime, is one
of the goals of the media framework. To achieve this, hardware devices are
-modeled as an oriented graph of building blocks called entities connected
+modelled as an oriented graph of building blocks called entities connected
through pads.
An entity is a basic media hardware building block. It can correspond to
@@ -265,7 +265,7 @@
media_entity_find_link(struct media_pad *source,
struct media_pad *sink);
- media_entity_remote_source(struct media_pad *pad);
+ media_entity_remote_pad(struct media_pad *pad);
Refer to the kerneldoc documentation for more information.
@@ -336,7 +336,7 @@
be identical for all nested calls to the function.
media_entity_pipeline_start() may return an error. In that case, it will
-clean up any the changes it did by itself.
+clean up any of the changes it did by itself.
When stopping the stream, drivers must notify the entities with
diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
index 3c4e1b3..fa5d8a9 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -1685,6 +1685,7 @@
xchg();
cmpxchg();
+ atomic_xchg();
atomic_cmpxchg();
atomic_inc_return();
atomic_dec_return();
diff --git a/Documentation/metag/00-INDEX b/Documentation/metag/00-INDEX
new file mode 100644
index 0000000..db11c51
--- /dev/null
+++ b/Documentation/metag/00-INDEX
@@ -0,0 +1,4 @@
+00-INDEX
+ - this file
+kernel-ABI.txt
+ - Documents metag ABI details
diff --git a/Documentation/metag/kernel-ABI.txt b/Documentation/metag/kernel-ABI.txt
new file mode 100644
index 0000000..6282166
--- /dev/null
+++ b/Documentation/metag/kernel-ABI.txt
@@ -0,0 +1,256 @@
+ ==========================
+ KERNEL ABIS FOR METAG ARCH
+ ==========================
+
+This document describes the Linux ABIs for the metag architecture, and has the
+following sections:
+
+ (*) Outline of registers
+ (*) Userland registers
+ (*) Kernel registers
+ (*) System call ABI
+ (*) Calling conventions
+
+
+====================
+OUTLINE OF REGISTERS
+====================
+
+The main Meta core registers are arranged in units:
+
+ UNIT Type DESCRIPTION GP EXT PRIV GLOBAL
+ ======= ======= =============== ======= ======= ======= =======
+ CT Special Control unit
+ D0 General Data unit 0 0-7 8-15 16-31 16-31
+ D1 General Data unit 1 0-7 8-15 16-31 16-31
+ A0 General Address unit 0 0-3 4-7 8-15 8-15
+ A1 General Address unit 1 0-3 4-7 8-15 8-15
+ PC Special PC unit 0 1
+ PORT Special Ports
+ TR Special Trigger unit 0-7
+ TT Special Trace unit 0-5
+ FX General FP unit 0-15
+
+GP registers form part of the main context.
+
+Extended context registers (EXT) may not be present on all hardware threads and
+can be context switched if support is enabled and the appropriate bits are set
+in e.g. the D0.8 register to indicate what extended state to preserve.
+
+Global registers are shared between threads and are privilege protected.
+
+See arch/metag/include/asm/metag_regs.h for definitions relating to core
+registers and the fields and bits they contain. See the TRMs for further details
+about special registers.
+
+Several special registers are preserved in the main context, these are the
+interesting ones:
+
+ REG (ALIAS) PURPOSE
+ ======================= ===============================================
+ CT.1 (TXMODE) Processor mode bits (particularly for DSP)
+ CT.2 (TXSTATUS) Condition flags and LSM_STEP (MGET/MSET step)
+ CT.3 (TXRPT) Branch repeat counter
+ PC.0 (PC) Program counter
+
+Some of the general registers have special purposes in the ABI and therefore
+have aliases:
+
+ D0 REG (ALIAS) PURPOSE D1 REG (ALIAS) PURPOSE
+ =============== =============== =============== =======================
+ D0.0 (D0Re0) 32bit result D1.0 (D1Re0) Top half of 64bit result
+ D0.1 (D0Ar6) Argument 6 D1.1 (D1Ar5) Argument 5
+ D0.2 (D0Ar4) Argument 4 D1.2 (D1Ar3) Argument 3
+ D0.3 (D0Ar2) Argument 2 D1.3 (D1Ar1) Argument 1
+ D0.4 (D0FrT) Frame temp D1.4 (D1RtP) Return pointer
+ D0.5 Call preserved D1.5 Call preserved
+ D0.6 Call preserved D1.6 Call preserved
+ D0.7 Call preserved D1.7 Call preserved
+
+ A0 REG (ALIAS) PURPOSE A1 REG (ALIAS) PURPOSE
+ =============== =============== =============== =======================
+ A0.0 (A0StP) Stack pointer A1.0 (A1GbP) Global base pointer
+ A0.1 (A0FrP) Frame pointer A1.1 (A1LbP) Local base pointer
+ A0.2 A1.2
+ A0.3 A1.3
+
+
+==================
+USERLAND REGISTERS
+==================
+
+All the general purpose D0, D1, A0, A1 registers are preserved when entering the
+kernel (including asynchronous events such as interrupts and timer ticks) except
+the following which have special purposes in the ABI:
+
+ REGISTERS WHEN STATUS PURPOSE
+ =============== ======= =============== ===============================
+ D0.8 DSP Preserved ECH, determines what extended
+ DSP state to preserve.
+ A0.0 (A0StP) ALWAYS Preserved Stack >= A0StP may be clobbered
+ at any time by the creation of a
+ signal frame.
+ A1.0 (A1GbP) SMP Clobbered Used as temporary for loading
+ kernel stack pointer and saving
+ core context.
+ A0.15 !SMP Protected Stores kernel stack pointer.
+ A1.15 ALWAYS Protected Stores kernel base pointer.
+
+On UP A0.15 is used to store the kernel stack pointer for storing the userland
+context. A0.15 is global between hardware threads though which means it cannot
+be used on SMP for this purpose. Since no protected local registers are
+available A1GbP is reserved for use as a temporary to allow a percpu stack
+pointer to be loaded for storing the rest of the context.
+
+
+================
+KERNEL REGISTERS
+================
+
+When in the kernel the following registers have special purposes in the ABI:
+
+ REGISTERS WHEN STATUS PURPOSE
+ =============== ======= =============== ===============================
+ A0.0 (A0StP) ALWAYS Preserved Stack >= A0StP may be clobbered
+ at any time by the creation of
+ an irq signal frame.
+ A1.0 (A1GbP) ALWAYS Preserved Reserved (kernel base pointer).
+
+
+===============
+SYSTEM CALL ABI
+===============
+
+When a system call is made, the following registers are effective:
+
+ REGISTERS CALL RETURN
+ =============== ======================= ===============================
+ D0.0 (D0Re0) Return value (or -errno)
+ D1.0 (D1Re0) System call number Clobbered
+ D0.1 (D0Ar6) Syscall arg #6 Preserved
+ D1.1 (D1Ar5) Syscall arg #5 Preserved
+ D0.2 (D0Ar4) Syscall arg #4 Preserved
+ D1.2 (D1Ar3) Syscall arg #3 Preserved
+ D0.3 (D0Ar2) Syscall arg #2 Preserved
+ D1.3 (D1Ar1) Syscall arg #1 Preserved
+
+Due to the limited number of argument registers and some system calls with badly
+aligned 64-bit arguments, 64-bit values are always packed in consecutive
+arguments, even if this is contrary to the normal calling conventions (where the
+two halves would go in a matching pair of data registers).
+
+For example fadvise64_64 usually has the signature:
+
+ long sys_fadvise64_64(i32 fd, i64 offs, i64 len, i32 advice);
+
+But for metag fadvise64_64 is wrapped so that the 64-bit arguments are packed:
+
+ long sys_fadvise64_64_metag(i32 fd, i32 offs_lo,
+ i32 offs_hi, i32 len_lo,
+ i32 len_hi, i32 advice)
+
+So the arguments are packed in the registers like this:
+
+ D0 REG (ALIAS) VALUE D1 REG (ALIAS) VALUE
+ =============== =============== =============== =======================
+ D0.1 (D0Ar6) advice D1.1 (D1Ar5) hi(len)
+ D0.2 (D0Ar4) lo(len) D1.2 (D1Ar3) hi(offs)
+ D0.3 (D0Ar2) lo(offs) D1.3 (D1Ar1) fd
+
+
+===================
+CALLING CONVENTIONS
+===================
+
+These calling conventions apply to both user and kernel code. The stack grows
+from low addresses to high addresses in the metag ABI. The stack pointer (A0StP)
+should always point to the next free address on the stack and should at all
+times be 64-bit aligned. The following registers are effective at the point of a
+call:
+
+ REGISTERS CALL RETURN
+ =============== ======================= ===============================
+ D0.0 (D0Re0) 32bit return value
+ D1.0 (D1Re0) Upper half of 64bit return value
+ D0.1 (D0Ar6) 32bit argument #6 Clobbered
+ D1.1 (D1Ar5) 32bit argument #5 Clobbered
+ D0.2 (D0Ar4) 32bit argument #4 Clobbered
+ D1.2 (D1Ar3) 32bit argument #3 Clobbered
+ D0.3 (D0Ar2) 32bit argument #2 Clobbered
+ D1.3 (D1Ar1) 32bit argument #1 Clobbered
+ D0.4 (D0FrT) Clobbered
+ D1.4 (D1RtP) Return pointer Clobbered
+ D{0-1}.{5-7} Preserved
+ A0.0 (A0StP) Stack pointer Preserved
+ A1.0 (A0GbP) Preserved
+ A0.1 (A0FrP) Frame pointer Preserved
+ A1.1 (A0LbP) Preserved
+ A{0-1},{2-3} Clobbered
+
+64-bit arguments are placed in matching pairs of registers (i.e. the same
+register number in both D0 and D1 units), with the least significant half in D0
+and the most significant half in D1, leaving a gap where necessary. Further
+arguments are stored on the stack in reverse order (earlier arguments at higher
+addresses):
+
+ ADDRESS 0 1 2 3 4 5 6 7
+ =============== ===== ===== ===== ===== ===== ===== ===== =====
+ A0StP -->
+ A0StP-0x08 32bit argument #8 32bit argument #7
+ A0StP-0x10 32bit argument #10 32bit argument #9
+
+Function prologues tend to look a bit like this:
+
+ /* If frame pointer in use, move it to frame temp register so it can be
+ easily pushed onto stack */
+ MOV D0FrT,A0FrP
+
+ /* If frame pointer in use, set it to stack pointer */
+ ADD A0FrP,A0StP,#0
+
+ /* Preserve D0FrT, D1RtP, D{0-1}.{5-7} on stack, incrementing A0StP */
+ MSETL [A0StP++],D0FrT,D0.5,D0.6,D0.7
+
+ /* Allocate some stack space for local variables */
+ ADD A0StP,A0StP,#0x10
+
+At this point the stack would look like this:
+
+ ADDRESS 0 1 2 3 4 5 6 7
+ =============== ===== ===== ===== ===== ===== ===== ===== =====
+ A0StP -->
+ A0StP-0x08
+ A0StP-0x10
+ A0StP-0x18 Old D0.7 Old D1.7
+ A0StP-0x20 Old D0.6 Old D1.6
+ A0StP-0x28 Old D0.5 Old D1.5
+ A0FrP --> Old A0FrP (frame ptr) Old D1RtP (return ptr)
+ A0FrP-0x08 32bit argument #8 32bit argument #7
+ A0FrP-0x10 32bit argument #10 32bit argument #9
+
+Function epilogues tend to differ depending on the use of a frame pointer. An
+example of a frame pointer epilogue:
+
+ /* Restore D0FrT, D1RtP, D{0-1}.{5-7} from stack, incrementing A0FrP */
+ MGETL D0FrT,D0.5,D0.6,D0.7,[A0FrP++]
+ /* Restore stack pointer to where frame pointer was before increment */
+ SUB A0StP,A0FrP,#0x20
+ /* Restore frame pointer from frame temp */
+ MOV A0FrP,D0FrT
+ /* Return to caller via restored return pointer */
+ MOV PC,D1RtP
+
+If the function hasn't touched the frame pointer, MGETL cannot be safely used
+with A0StP as it always increments and that would expose the stack to clobbering
+by interrupts (kernel) or signals (user). Therefore it's common to see the MGETL
+split into separate GETL instructions:
+
+ /* Restore D0FrT, D1RtP, D{0-1}.{5-7} from stack */
+ GETL D0FrT,D1RtP,[A0StP+#-0x30]
+ GETL D0.5,D1.5,[A0StP+#-0x28]
+ GETL D0.6,D1.6,[A0StP+#-0x20]
+ GETL D0.7,D1.7,[A0StP+#-0x18]
+ /* Restore stack pointer */
+ SUB A0StP,A0StP,#0x30
+ /* Return to caller via restored return pointer */
+ MOV PC,D1RtP
diff --git a/Documentation/misc-devices/mei/mei-client-bus.txt b/Documentation/misc-devices/mei/mei-client-bus.txt
new file mode 100644
index 0000000..f83910a
--- /dev/null
+++ b/Documentation/misc-devices/mei/mei-client-bus.txt
@@ -0,0 +1,138 @@
+Intel(R) Management Engine (ME) Client bus API
+===============================================
+
+
+Rationale
+=========
+MEI misc character device is useful for dedicated applications to send and receive
+data to the many FW appliance found in Intel's ME from the user space.
+However for some of the ME functionalities it make sense to leverage existing software
+stack and expose them through existing kernel subsystems.
+
+In order to plug seamlessly into the kernel device driver model we add kernel virtual
+bus abstraction on top of the MEI driver. This allows implementing linux kernel drivers
+for the various MEI features as a stand alone entities found in their respective subsystem.
+Existing device drivers can even potentially be re-used by adding an MEI CL bus layer to
+the existing code.
+
+
+MEI CL bus API
+===========
+A driver implementation for an MEI Client is very similar to existing bus
+based device drivers. The driver registers itself as an MEI CL bus driver through
+the mei_cl_driver structure:
+
+struct mei_cl_driver {
+ struct device_driver driver;
+ const char *name;
+
+ const struct mei_cl_device_id *id_table;
+
+ int (*probe)(struct mei_cl_device *dev, const struct mei_cl_id *id);
+ int (*remove)(struct mei_cl_device *dev);
+};
+
+struct mei_cl_id {
+ char name[MEI_NAME_SIZE];
+ kernel_ulong_t driver_info;
+};
+
+The mei_cl_id structure allows the driver to bind itself against a device name.
+
+To actually register a driver on the ME Client bus one must call the mei_cl_add_driver()
+API. This is typically called at module init time.
+
+Once registered on the ME Client bus, a driver will typically try to do some I/O on
+this bus and this should be done through the mei_cl_send() and mei_cl_recv()
+routines. The latter is synchronous (blocks and sleeps until data shows up).
+In order for drivers to be notified of pending events waiting for them (e.g.
+an Rx event) they can register an event handler through the
+mei_cl_register_event_cb() routine. Currently only the MEI_EVENT_RX event
+will trigger an event handler call and the driver implementation is supposed
+to call mei_recv() from the event handler in order to fetch the pending
+received buffers.
+
+
+Example
+=======
+As a theoretical example let's pretend the ME comes with a "contact" NFC IP.
+The driver init and exit routines for this device would look like:
+
+#define CONTACT_DRIVER_NAME "contact"
+
+static struct mei_cl_device_id contact_mei_cl_tbl[] = {
+ { CONTACT_DRIVER_NAME, },
+
+ /* required last entry */
+ { }
+};
+MODULE_DEVICE_TABLE(mei_cl, contact_mei_cl_tbl);
+
+static struct mei_cl_driver contact_driver = {
+ .id_table = contact_mei_tbl,
+ .name = CONTACT_DRIVER_NAME,
+
+ .probe = contact_probe,
+ .remove = contact_remove,
+};
+
+static int contact_init(void)
+{
+ int r;
+
+ r = mei_cl_driver_register(&contact_driver);
+ if (r) {
+ pr_err(CONTACT_DRIVER_NAME ": driver registration failed\n");
+ return r;
+ }
+
+ return 0;
+}
+
+static void __exit contact_exit(void)
+{
+ mei_cl_driver_unregister(&contact_driver);
+}
+
+module_init(contact_init);
+module_exit(contact_exit);
+
+And the driver's simplified probe routine would look like that:
+
+int contact_probe(struct mei_cl_device *dev, struct mei_cl_device_id *id)
+{
+ struct contact_driver *contact;
+
+ [...]
+ mei_cl_enable_device(dev);
+
+ mei_cl_register_event_cb(dev, contact_event_cb, contact);
+
+ return 0;
+ }
+
+In the probe routine the driver first enable the MEI device and then registers
+an ME bus event handler which is as close as it can get to registering a
+threaded IRQ handler.
+The handler implementation will typically call some I/O routine depending on
+the pending events:
+
+#define MAX_NFC_PAYLOAD 128
+
+static void contact_event_cb(struct mei_cl_device *dev, u32 events,
+ void *context)
+{
+ struct contact_driver *contact = context;
+
+ if (events & BIT(MEI_EVENT_RX)) {
+ u8 payload[MAX_NFC_PAYLOAD];
+ int payload_size;
+
+ payload_size = mei_recv(dev, payload, MAX_NFC_PAYLOAD);
+ if (payload_size <= 0)
+ return;
+
+ /* Hook to the NFC subsystem */
+ nfc_hci_recv_frame(contact->hdev, payload, payload_size);
+ }
+}
diff --git a/Documentation/misc-devices/mei/mei.txt b/Documentation/misc-devices/mei/mei.txt
index 6ec7029..15bba1a 100644
--- a/Documentation/misc-devices/mei/mei.txt
+++ b/Documentation/misc-devices/mei/mei.txt
@@ -120,7 +120,7 @@
Notes:
max_msg_length (MTU) in client properties describes the maximum
data that can be sent or received. (e.g. if MTU=2K, can send
- requests up to bytes 2k and received responses upto 2k bytes).
+ requests up to bytes 2k and received responses up to 2k bytes).
Intel ME Applications:
==============
diff --git a/Documentation/mmc/mmc-dev-attrs.txt b/Documentation/mmc/mmc-dev-attrs.txt
index 0d98fac..189bab0 100644
--- a/Documentation/mmc/mmc-dev-attrs.txt
+++ b/Documentation/mmc/mmc-dev-attrs.txt
@@ -22,6 +22,7 @@
manfid Manufacturer ID (from CID Register)
name Product Name (from CID Register)
oemid OEM/Application ID (from CID Register)
+ prv Product Revision (from CID Register) (SD and MMCv4 only)
serial Product Serial Number (from CID Register)
erase_size Erase group size
preferred_erase_size Preferred erase size
diff --git a/Documentation/namespaces/resource-control.txt b/Documentation/namespaces/resource-control.txt
new file mode 100644
index 0000000..abc13c3
--- /dev/null
+++ b/Documentation/namespaces/resource-control.txt
@@ -0,0 +1,14 @@
+There are a lot of kinds of objects in the kernel that don't have
+individual limits or that have limits that are ineffective when a set
+of processes is allowed to switch user ids. With user namespaces
+enabled in a kernel for people who don't trust their users or their
+users programs to play nice this problems becomes more acute.
+
+Therefore it is recommended that memory control groups be enabled in
+kernels that enable user namespaces, and it is further recommended
+that userspace configure memory control groups to limit how much
+memory user's they don't trust to play nice can use.
+
+Memory control groups can be configured by installing the libcgroup
+package present on most distros editing /etc/cgrules.conf,
+/etc/cgconfig.conf and setting up libpam-cgroup.
diff --git a/Documentation/networking/.gitignore b/Documentation/networking/.gitignore
index 286a568..e69de29 100644
--- a/Documentation/networking/.gitignore
+++ b/Documentation/networking/.gitignore
@@ -1 +0,0 @@
-ifenslave
diff --git a/Documentation/networking/00-INDEX b/Documentation/networking/00-INDEX
index 2cc3c77..32dfbd9 100644
--- a/Documentation/networking/00-INDEX
+++ b/Documentation/networking/00-INDEX
@@ -52,8 +52,6 @@
- the Digital EtherWORKS DE4?? and DE5?? PCI Ethernet driver
decnet.txt
- info on using the DECnet networking layer in Linux.
-depca.txt
- - the Digital DEPCA/EtherWORKS DE1?? and DE2?? LANCE Ethernet driver
dl2k.txt
- README for D-Link DL2000-based Gigabit Ethernet Adapters (dl2k.ko).
dm9000.txt
@@ -72,8 +70,6 @@
- README for the Intel Gigabit Ethernet Driver (e1000e).
eql.txt
- serial IP load balancing
-ewrk3.txt
- - the Digital EtherWORKS 3 DE203/4/5 Ethernet driver
fib_trie.txt
- Level Compressed Trie (LC-trie) notes: a structure for routing.
filter.txt
@@ -92,8 +88,6 @@
- Gianfar Ethernet Driver.
ieee802154.txt
- Linux IEEE 802.15.4 implementation, API and drivers
-ifenslave.c
- - Configure network interfaces for parallel routing (bonding).
igb.txt
- README for the Intel Gigabit Ethernet Driver (igb).
igbvf.txt
@@ -126,8 +120,6 @@
- the Apple or Farallon LocalTalk PC card driver
mac80211-injection.txt
- HOWTO use packet injection with mac80211
-multicast.txt
- - Behaviour of cards under Multicast
multiqueue.txt
- HOWTO for multiqueue network device support.
netconsole.txt
diff --git a/Documentation/networking/DLINK.txt b/Documentation/networking/DLINK.txt
deleted file mode 100644
index 55d2443..0000000
--- a/Documentation/networking/DLINK.txt
+++ /dev/null
@@ -1,203 +0,0 @@
-Released 1994-06-13
-
-
- CONTENTS:
-
- 1. Introduction.
- 2. License.
- 3. Files in this release.
- 4. Installation.
- 5. Problems and tuning.
- 6. Using the drivers with earlier releases.
- 7. Acknowledgments.
-
-
- 1. INTRODUCTION.
-
- This is a set of Ethernet drivers for the D-Link DE-600/DE-620
- pocket adapters, for the parallel port on a Linux based machine.
- Some adapter "clones" will also work. Xircom is _not_ a clone...
- These drivers _can_ be used as loadable modules,
- and were developed for use on Linux 1.1.13 and above.
- For use on Linux 1.0.X, or earlier releases, see below.
-
- I have used these drivers for NFS, ftp, telnet and X-clients on
- remote machines. Transmissions with ftp seems to work as
- good as can be expected (i.e. > 80k bytes/sec) from a
- parallel port...:-) Receive speeds will be about 60-80% of this.
- Depending on your machine, somewhat higher speeds can be achieved.
-
- All comments/fixes to Bjorn Ekwall (bj0rn@blox.se).
-
-
- 2. LICENSE.
-
- This program is free software; you can redistribute it
- and/or modify it under the terms of the GNU General Public
- License as published by the Free Software Foundation; either
- version 2, or (at your option) any later version.
-
- This program is distributed in the hope that it will be
- useful, but WITHOUT ANY WARRANTY; without even the implied
- warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
- PURPOSE. See the GNU General Public License for more
- details.
-
- You should have received a copy of the GNU General Public
- License along with this program; if not, write to the Free
- Software Foundation, Inc., 675 Mass Ave, Cambridge, MA
- 02139, USA.
-
-
- 3. FILES IN THIS RELEASE.
-
- README.DLINK This file.
- de600.c The Source (may it be with You :-) for the DE-600
- de620.c ditto for the DE-620
- de620.h Macros for de620.c
-
- If you are upgrading from the d-link tar release, there will
- also be a "dlink-patches" file that will patch Linux 1.1.18:
- linux/drivers/net/Makefile
- linux/drivers/net/CONFIG
- linux/drivers/net/MODULES
- linux/drivers/net/Space.c
- linux/config.in
- Apply the patch by:
- "cd /usr/src; patch -p0 < linux/drivers/net/dlink-patches"
- The old source, "linux/drivers/net/d_link.c", can be removed.
-
-
- 4. INSTALLATION.
-
- o Get the latest net binaries, according to current net.wisdom.
-
- o Read the NET-2 and Ethernet HOWTOs and modify your setup.
-
- o If your parallel port has a strange address or irq,
- modify "linux/drivers/net/CONFIG" accordingly, or adjust
- the parameters in the "tuning" section in the sources.
-
- If you are going to use the drivers as loadable modules, do _not_
- enable them while doing "make config", but instead make sure that
- the drivers are included in "linux/drivers/net/MODULES".
-
- If you are _not_ going to use the driver(s) as loadable modules,
- but instead have them included in the kernel, remember to enable
- the drivers while doing "make config".
-
- o To include networking and DE600/DE620 support in your kernel:
- # cd /linux
- (as modules:)
- # make config (answer yes on CONFIG_NET and CONFIG_INET)
- (else included in the kernel:)
- # make config (answer yes on CONFIG _NET, _INET and _DE600 or _DE620)
- # make clean
- # make zImage (or whatever magic you usually do)
-
- o I use lilo to boot multiple kernels, so that I at least
- can have one working kernel :-). If you do too, append
- these lines to /etc/lilo/config:
-
- image = /linux/zImage
- label = newlinux
- root = /dev/hda2 (or whatever YOU have...)
-
- # /etc/lilo/install
-
- o Do "sync" and reboot the new kernel with a D-Link
- DE-600/DE-620 pocket adapter connected.
-
- o The adapter can be configured with ifconfig eth?
- where the actual number is decided by the kernel
- when the drivers are initialized.
-
-
- 5. "PROBLEMS" AND TUNING,
-
- o If you see error messages from the driver, and if the traffic
- stops on the adapter, try to do "ifconfig" and "route" once
- more, just as in "rc.inet1". This should take care of most
- problems, including effects from power loss, or adapters that
- aren't connected to the printer port in some way or another.
- You can somewhat change the behaviour by enabling/disabling
- the macro SHUTDOWN_WHEN_LOST in the "tuning" section.
- For the DE-600 there is another macro, CHECK_LOST_DE600,
- that you might want to read about in the "tuning" section.
-
- o Some machines have trouble handling the parallel port and
- the adapter at high speed. If you experience problems:
-
- DE-600:
- - The adapter is not recognized at boot, i.e. an Ethernet
- address of 00:80:c8:... is not shown, try to add another
- "; SLOW_DOWN_IO"
- at DE600_SLOW_DOWN in the "tuning" section. As a last resort,
- uncomment: "#define REALLY_SLOW_IO" (see <asm/io.h> for hints).
-
- - You experience "timeout" messages: first try to add another
- "; SLOW_DOWN_IO"
- at DE600_SLOW_DOWN in the "tuning" section, _then_ try to
- increase the value (original value: 5) at
- "if (tickssofar < 5)" near line 422.
-
- DE-620:
- - Your parallel port might be "sluggish". To cater for
- this, there are the macros LOWSPEED and READ_DELAY/WRITE_DELAY
- in the "tuning" section. Your first step should be to enable
- LOWSPEED, and after that you can "tune" the XXX_DELAY values.
-
- o If the adapter _is_ recognized at boot but you get messages
- about "Network Unreachable", then the problem is probably
- _not_ with the driver. Check your net configuration instead
- (ifconfig and route) in "rc.inet1".
-
- o There is some rudimentary support for debugging, look at
- the source. Use "-DDE600_DEBUG=3" or "-DDE620_DEBUG=3"
- when compiling, or include it in "linux/drivers/net/CONFIG".
- IF YOU HAVE PROBLEMS YOU CAN'T SOLVE: PLEASE COMPILE THE DRIVER
- WITH DEBUGGING ENABLED, AND SEND ME THE RESULTING OUTPUT!
-
-
- 6. USING THE DRIVERS WITH EARLIER RELEASES.
-
- The later 1.1.X releases of the Linux kernel include some
- changes in the networking layer (a.k.a. NET3). This affects
- these drivers in a few places. The hints that follow are
- _not_ tested by me, since I don't have the disk space to keep
- all releases on-line.
- Known needed changes to date:
- - release patchfile: some patches will fail, but they should
- be easy to apply "by hand", since they are trivial.
- (Space.c: d_link_init() is now called de600_probe())
- - de600.c: change "mark_bh(NET_BH)" to "mark_bh(INET_BH)".
- - de620.c: (maybe) change the code around "netif_rx(skb);" to be
- similar to the code around "dev_rint(...)" in de600.c
-
-
- 7. ACKNOWLEDGMENTS.
-
- These drivers wouldn't have been done without the base
- (and support) from Ross Biro, and D-Link Systems Inc.
- The driver relies upon GPL-ed source from D-Link Systems Inc.
- and from Russel Nelson at Crynwr Software <nelson@crynwr.com>.
-
- Additional input also from:
- Donald Becker <becker@super.org>, Alan Cox <A.Cox@swansea.ac.uk>
- and Fred N. van Kempen <waltje@uWalt.NL.Mugnet.ORG>
-
- DE-600 alpha release primary victim^H^H^H^H^H^Htester:
- - Erik Proper <erikp@cs.kun.nl>.
- Good input also from several users, most notably
- - Mark Burton <markb@ordern.demon.co.uk>.
-
- DE-620 alpha release victims^H^H^H^H^H^H^Htesters:
- - J. Joshua Kopper <kopper@rtsg.mot.com>
- - Olav Kvittem <Olav.Kvittem@uninett.no>
- - Germano Caronni <caronni@nessie.cs.id.ethz.ch>
- - Jeremy Fitzhardinge <jeremy@suite.sw.oz.au>
-
-
- Happy hacking!
-
- Bjorn Ekwall == bj0rn@blox.se
diff --git a/Documentation/networking/LICENSE.qlcnic b/Documentation/networking/LICENSE.qlcnic
index e7fb2c6..2ae3b64 100644
--- a/Documentation/networking/LICENSE.qlcnic
+++ b/Documentation/networking/LICENSE.qlcnic
@@ -1,4 +1,4 @@
-Copyright (c) 2009-2011 QLogic Corporation
+Copyright (c) 2009-2013 QLogic Corporation
QLogic Linux qlcnic NIC Driver
You may modify and redistribute the device driver code under the
diff --git a/Documentation/networking/Makefile b/Documentation/networking/Makefile
index 24c308d..0aa1ac9 100644
--- a/Documentation/networking/Makefile
+++ b/Documentation/networking/Makefile
@@ -1,11 +1,6 @@
# kbuild trick to avoid linker error. Can be omitted if a module is built.
obj- := dummy.o
-# List of programs to build
-hostprogs-y := ifenslave
-
-HOSTCFLAGS_ifenslave.o += -I$(objtree)/usr/include
-
# Tell kbuild to always build the programs
always := $(hostprogs-y)
diff --git a/Documentation/networking/arcnet.txt b/Documentation/networking/arcnet.txt
index 9ff5795..aff97f4 100644
--- a/Documentation/networking/arcnet.txt
+++ b/Documentation/networking/arcnet.txt
@@ -70,9 +70,10 @@
There are archives of the mailing list at:
http://epistolary.org/mailman/listinfo.cgi/arcnet
-The people on linux-net@vger.kernel.org have also been known to be very
-helpful, especially when we're talking about ALPHA Linux kernels that may or
-may not work right in the first place.
+The people on linux-net@vger.kernel.org (now defunct, replaced by
+netdev@vger.kernel.org) have also been known to be very helpful, especially
+when we're talking about ALPHA Linux kernels that may or may not work right
+in the first place.
Other Drivers and Info
diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt
index 10a015c..87bbcfe 100644
--- a/Documentation/networking/bonding.txt
+++ b/Documentation/networking/bonding.txt
@@ -104,8 +104,7 @@
==============================
Most popular distro kernels ship with the bonding driver
-already available as a module and the ifenslave user level control
-program installed and ready for use. If your distro does not, or you
+already available as a module. If your distro does not, or you
have need to compile bonding from source (e.g., configuring and
installing a mainline kernel from kernel.org), you'll need to perform
the following steps:
@@ -124,46 +123,13 @@
driver as module since it is currently the only way to pass parameters
to the driver or configure more than one bonding device.
- Build and install the new kernel and modules, then continue
-below to install ifenslave.
+ Build and install the new kernel and modules.
-1.2 Install ifenslave Control Utility
+1.2 Bonding Control Utility
-------------------------------------
- The ifenslave user level control program is included in the
-kernel source tree, in the file Documentation/networking/ifenslave.c.
-It is generally recommended that you use the ifenslave that
-corresponds to the kernel that you are using (either from the same
-source tree or supplied with the distro), however, ifenslave
-executables from older kernels should function (but features newer
-than the ifenslave release are not supported). Running an ifenslave
-that is newer than the kernel is not supported, and may or may not
-work.
-
- To install ifenslave, do the following:
-
-# gcc -Wall -O -I/usr/src/linux/include ifenslave.c -o ifenslave
-# cp ifenslave /sbin/ifenslave
-
- If your kernel source is not in "/usr/src/linux," then replace
-"/usr/src/linux/include" in the above with the location of your kernel
-source include directory.
-
- You may wish to back up any existing /sbin/ifenslave, or, for
-testing or informal use, tag the ifenslave to the kernel version
-(e.g., name the ifenslave executable /sbin/ifenslave-2.6.10).
-
-IMPORTANT NOTE:
-
- If you omit the "-I" or specify an incorrect directory, you
-may end up with an ifenslave that is incompatible with the kernel
-you're trying to build it for. Some distros (e.g., Red Hat from 7.1
-onwards) do not have /usr/include/linux symbolically linked to the
-default kernel source include directory.
-
-SECOND IMPORTANT NOTE:
- If you plan to configure bonding using sysfs or using the
-/etc/network/interfaces file, you do not need to use ifenslave.
+ It is recommended to configure bonding via iproute2 (netlink)
+or sysfs, the old ifenslave control utility is obsolete.
2. Bonding Driver Options
=========================
@@ -337,6 +303,12 @@
such a situation, validation of backup slaves must be
disabled.
+ The validation of ARP requests on backup slaves is mainly
+ helping bonding to decide which slaves are more likely to
+ work in case of the active slave failure, it doesn't really
+ guarantee that the backup slave will work if it's selected
+ as the next active slave.
+
This option is useful in network configurations in which
multiple bonding hosts are concurrently issuing ARPs to one or
more targets beyond a common switch. Should the link between
@@ -349,6 +321,25 @@
This option was added in bonding version 3.1.0.
+arp_all_targets
+
+ Specifies the quantity of arp_ip_targets that must be reachable
+ in order for the ARP monitor to consider a slave as being up.
+ This option affects only active-backup mode for slaves with
+ arp_validation enabled.
+
+ Possible values are:
+
+ any or 0
+
+ consider the slave up only when any of the arp_ip_targets
+ is reachable
+
+ all or 1
+
+ consider the slave up only when all of the arp_ip_targets
+ are reachable
+
downdelay
Specifies the time, in milliseconds, to wait before disabling
@@ -851,7 +842,7 @@
==============================
You can configure bonding using either your distro's network
-initialization scripts, or manually using either ifenslave or the
+initialization scripts, or manually using either iproute2 or the
sysfs interface. Distros generally use one of three packages for the
network initialization scripts: initscripts, sysconfig or interfaces.
Recent versions of these packages have support for bonding, while older
@@ -1160,7 +1151,7 @@
those instances, see the "Configuring Multiple Bonds Manually" section,
below.
-3.3 Configuring Bonding Manually with Ifenslave
+3.3 Configuring Bonding Manually with iproute2
-----------------------------------------------
This section applies to distros whose network initialization
@@ -1171,7 +1162,7 @@
The general method for these systems is to place the bonding
module parameters into a config file in /etc/modprobe.d/ (as
appropriate for the installed distro), then add modprobe and/or
-ifenslave commands to the system's global init script. The name of
+`ip link` commands to the system's global init script. The name of
the global init script differs; for sysconfig, it is
/etc/init.d/boot.local and for initscripts it is /etc/rc.d/rc.local.
@@ -1183,8 +1174,8 @@
modprobe bonding mode=balance-alb miimon=100
modprobe e100
ifconfig bond0 192.168.1.1 netmask 255.255.255.0 up
-ifenslave bond0 eth0
-ifenslave bond0 eth1
+ip link set eth0 master bond0
+ip link set eth1 master bond0
Replace the example bonding module parameters and bond0
network configuration (IP address, netmask, etc) with the appropriate
diff --git a/Documentation/networking/cs89x0.txt b/Documentation/networking/cs89x0.txt
index c725d33..0e19018 100644
--- a/Documentation/networking/cs89x0.txt
+++ b/Documentation/networking/cs89x0.txt
@@ -36,7 +36,6 @@
4.1 Compiling the Driver as a Loadable Module
4.2 Compiling the driver to support memory mode
4.3 Compiling the driver to support Rx DMA
- 4.4 Compiling the Driver into the Kernel
5.0 TESTING AND TROUBLESHOOTING
5.1 Known Defects and Limitations
@@ -364,84 +363,6 @@
series. DMA support is now unconditionally part of the driver. It is
enabled by the 'use_dma=1' module option.
-4.4 COMPILING THE DRIVER INTO THE KERNEL
-
-If your Linux distribution already has support for the cs89x0 driver
-then simply copy the source file to the /usr/src/linux/drivers/net
-directory to replace the original ones and run the make utility to
-rebuild the kernel. See Step 3 for rebuilding the kernel.
-
-If your Linux does not include the cs89x0 driver, you need to edit three
-configuration files, copy the source file to the /usr/src/linux/drivers/net
-directory, and then run the make utility to rebuild the kernel.
-
-1. Edit the following configuration files by adding the statements as
-indicated. (When possible, try to locate the added text to the section of the
-file containing similar statements).
-
-
-a.) In /usr/src/linux/drivers/net/Config.in, add:
-
-tristate 'CS89x0 support' CONFIG_CS89x0
-
-Example:
-
- if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then
- tristate 'ICL EtherTeam 16i/32 support' CONFIG_ETH16I
- fi
-
- tristate 'CS89x0 support' CONFIG_CS89x0
-
- tristate 'NE2000/NE1000 support' CONFIG_NE2000
- if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then
- tristate 'NI5210 support' CONFIG_NI52
-
-
-b.) In /usr/src/linux/drivers/net/Makefile, add the following lines:
-
-ifeq ($(CONFIG_CS89x0),y)
-L_OBJS += cs89x0.o
-else
- ifeq ($(CONFIG_CS89x0),m)
- M_OBJS += cs89x0.o
- endif
-endif
-
-
-c.) In /linux/drivers/net/Space.c file, add the line:
-
-extern int cs89x0_probe(struct device *dev);
-
-
-Example:
-
- extern int ultra_probe(struct device *dev);
- extern int wd_probe(struct device *dev);
- extern int el2_probe(struct device *dev);
-
- extern int cs89x0_probe(struct device *dev);
-
- extern int ne_probe(struct device *dev);
- extern int hp_probe(struct device *dev);
- extern int hp_plus_probe(struct device *dev);
-
-
-Also add:
-
- #ifdef CONFIG_CS89x0
- { cs89x0_probe,0 },
- #endif
-
-
-2.) Copy the driver source files (cs89x0.c and cs89x0.h)
-into the /usr/src/linux/drivers/net directory.
-
-
-3.) Go to /usr/src/linux directory and run 'make config' followed by 'make'
-(or make bzImage) to rebuild the kernel.
-
-4.) Use the DOS 'setup' utility to disable plug and play on the NIC.
-
5.0 TESTING AND TROUBLESHOOTING
===============================================================================
diff --git a/Documentation/networking/depca.txt b/Documentation/networking/depca.txt
deleted file mode 100644
index 24c6b26..0000000
--- a/Documentation/networking/depca.txt
+++ /dev/null
@@ -1,92 +0,0 @@
-
-DE10x
-=====
-
-Memory Addresses:
-
- SW1 SW2 SW3 SW4
-64K on on on on d0000 dbfff
- off on on on c0000 cbfff
- off off on on e0000 ebfff
-
-32K on on off on d8000 dbfff
- off on off on c8000 cbfff
- off off off on e8000 ebfff
-
-DBR ROM on on dc000 dffff
- off on cc000 cffff
- off off ec000 effff
-
-Note that the 2K mode is set by SW3/SW4 on/off or off/off. Address
-assignment is through the RBSA register.
-
-I/O Address:
- SW5
-0x300 on
-0x200 off
-
-Remote Boot:
- SW6
-Disable on
-Enable off
-
-Remote Boot Timeout:
- SW7
-2.5min on
-30s off
-
-IRQ:
- SW8 SW9 SW10 SW11 SW12
-2 on off off off off
-3 off on off off off
-4 off off on off off
-5 off off off on off
-7 off off off off on
-
-DE20x
-=====
-
-Memory Size:
-
- SW3 SW4
-64K on on
-32K off on
-2K on off
-2K off off
-
-Start Addresses:
-
- SW1 SW2 SW3 SW4
-64K on on on on c0000 cffff
- on off on on d0000 dffff
- off on on on e0000 effff
-
-32K on on off off c8000 cffff
- on off off off d8000 dffff
- off on off off e8000 effff
-
-Illegal off off - - - -
-
-I/O Address:
- SW5
-0x300 on
-0x200 off
-
-Remote Boot:
- SW6
-Disable on
-Enable off
-
-Remote Boot Timeout:
- SW7
-2.5min on
-30s off
-
-IRQ:
- SW8 SW9 SW10 SW11 SW12
-5 on off off off off
-9 off on off off off
-10 off off on off off
-11 off off off on off
-15 off off off off on
-
diff --git a/Documentation/networking/ewrk3.txt b/Documentation/networking/ewrk3.txt
deleted file mode 100644
index 90e9e5f..0000000
--- a/Documentation/networking/ewrk3.txt
+++ /dev/null
@@ -1,46 +0,0 @@
-The EtherWORKS 3 driver in this distribution is designed to work with all
-kernels > 1.1.33 (approx) and includes tools in the 'ewrk3tools'
-subdirectory to allow set up of the card, similar to the MSDOS
-'NICSETUP.EXE' tools provided on the DOS drivers disk (type 'make' in that
-subdirectory to make the tools).
-
-The supported cards are DE203, DE204 and DE205. All other cards are NOT
-supported - refer to 'depca.c' for running the LANCE based network cards and
-'de4x5.c' for the DIGITAL Semiconductor PCI chip based adapters from
-Digital.
-
-The ability to load this driver as a loadable module has been included and
-used extensively during the driver development (to save those long reboot
-sequences). To utilise this ability, you have to do 8 things:
-
- 0) have a copy of the loadable modules code installed on your system.
- 1) copy ewrk3.c from the /linux/drivers/net directory to your favourite
- temporary directory.
- 2) edit the source code near line 1898 to reflect the I/O address and
- IRQ you're using.
- 3) compile ewrk3.c, but include -DMODULE in the command line to ensure
- that the correct bits are compiled (see end of source code).
- 4) if you are wanting to add a new card, goto 5. Otherwise, recompile a
- kernel with the ewrk3 configuration turned off and reboot.
- 5) insmod ewrk3.o
- [Alan Cox: Changed this so you can insmod ewrk3.o irq=x io=y]
- [Adam Kropelin: Multiple cards now supported by irq=x1,x2 io=y1,y2]
- 6) run the net startup bits for your new eth?? interface manually
- (usually /etc/rc.inet[12] at boot time).
- 7) enjoy!
-
- Note that autoprobing is not allowed in loadable modules - the system is
- already up and running and you're messing with interrupts.
-
- To unload a module, turn off the associated interface
- 'ifconfig eth?? down' then 'rmmod ewrk3'.
-
-The performance we've achieved so far has been measured through the 'ttcp'
-tool at 975kB/s. This measures the total TCP stack performance which
-includes the card, so don't expect to get much nearer the 1.25MB/s
-theoretical Ethernet rate.
-
-
-Enjoy!
-
-Dave
diff --git a/Documentation/networking/filter.txt b/Documentation/networking/filter.txt
index bbf2005..cdb3e40 100644
--- a/Documentation/networking/filter.txt
+++ b/Documentation/networking/filter.txt
@@ -17,12 +17,12 @@
LSF is much simpler than BPF. One does not have to worry about
devices or anything like that. You simply create your filter
-code, send it to the kernel via the SO_ATTACH_FILTER ioctl and
+code, send it to the kernel via the SO_ATTACH_FILTER option and
if your filter code passes the kernel check on it, you then
immediately begin filtering data on that socket.
You can also detach filters from your socket via the
-SO_DETACH_FILTER ioctl. This will probably not be used much
+SO_DETACH_FILTER option. This will probably not be used much
since when you close a socket that has a filter on it the
filter is automagically removed. The other less common case
may be adding a different filter on the same socket where you had another
@@ -31,12 +31,19 @@
filter has passed the checks, otherwise if it fails the old filter
will remain on that socket.
+SO_LOCK_FILTER option allows to lock the filter attached to a
+socket. Once set, a filter cannot be removed or changed. This allows
+one process to setup a socket, attach a filter, lock it then drop
+privileges and be assured that the filter will be kept until the
+socket is closed.
+
Examples
========
Ioctls-
setsockopt(sockfd, SOL_SOCKET, SO_ATTACH_FILTER, &Filter, sizeof(Filter));
setsockopt(sockfd, SOL_SOCKET, SO_DETACH_FILTER, &value, sizeof(value));
+setsockopt(sockfd, SOL_SOCKET, SO_LOCK_FILTER, &value, sizeof(value));
See the BSD bpf.4 manpage and the BSD Packet Filter paper written by
Steven McCanne and Van Jacobson of Lawrence Berkeley Laboratory.
diff --git a/Documentation/networking/ieee802154.txt b/Documentation/networking/ieee802154.txt
index 703cf43..09eb573 100644
--- a/Documentation/networking/ieee802154.txt
+++ b/Documentation/networking/ieee802154.txt
@@ -5,7 +5,7 @@
Introduction
============
The IEEE 802.15.4 working group focuses on standartization of bottom
-two layers: Medium Accsess Control (MAC) and Physical (PHY). And there
+two layers: Medium Access Control (MAC) and Physical (PHY). And there
are mainly two options available for upper layers:
- ZigBee - proprietary protocol from ZigBee Alliance
- 6LowPAN - IPv6 networking over low rate personal area networks
@@ -71,8 +71,9 @@
store info in the skb->data on your own.
To hook the MLME interface you have to populate the ml_priv field of your
-net_device with a pointer to struct ieee802154_mlme_ops instance. All fields are
-required.
+net_device with a pointer to struct ieee802154_mlme_ops instance. The fields
+assoc_req, assoc_resp, disassoc_req, start_req, and scan_req are optional.
+All other fields are required.
We provide an example of simple HardMAC driver at drivers/ieee802154/fakehard.c
diff --git a/Documentation/networking/ifenslave.c b/Documentation/networking/ifenslave.c
deleted file mode 100644
index ac5debb..0000000
--- a/Documentation/networking/ifenslave.c
+++ /dev/null
@@ -1,1105 +0,0 @@
-/* Mode: C;
- * ifenslave.c: Configure network interfaces for parallel routing.
- *
- * This program controls the Linux implementation of running multiple
- * network interfaces in parallel.
- *
- * Author: Donald Becker <becker@cesdis.gsfc.nasa.gov>
- * Copyright 1994-1996 Donald Becker
- *
- * This program is free software; you can redistribute it
- * and/or modify it under the terms of the GNU General Public
- * License as published by the Free Software Foundation.
- *
- * The author may be reached as becker@CESDIS.gsfc.nasa.gov, or C/O
- * Center of Excellence in Space Data and Information Sciences
- * Code 930.5, Goddard Space Flight Center, Greenbelt MD 20771
- *
- * Changes :
- * - 2000/10/02 Willy Tarreau <willy at meta-x.org> :
- * - few fixes. Master's MAC address is now correctly taken from
- * the first device when not previously set ;
- * - detach support : call BOND_RELEASE to detach an enslaved interface.
- * - give a mini-howto from command-line help : # ifenslave -h
- *
- * - 2001/02/16 Chad N. Tindel <ctindel at ieee dot org> :
- * - Master is now brought down before setting the MAC address. In
- * the 2.4 kernel you can't change the MAC address while the device is
- * up because you get EBUSY.
- *
- * - 2001/09/13 Takao Indoh <indou dot takao at jp dot fujitsu dot com>
- * - Added the ability to change the active interface on a mode 1 bond
- * at runtime.
- *
- * - 2001/10/23 Chad N. Tindel <ctindel at ieee dot org> :
- * - No longer set the MAC address of the master. The bond device will
- * take care of this itself
- * - Try the SIOC*** versions of the bonding ioctls before using the
- * old versions
- * - 2002/02/18 Erik Habbinga <erik_habbinga @ hp dot com> :
- * - ifr2.ifr_flags was not initialized in the hwaddr_notset case,
- * SIOCGIFFLAGS now called before hwaddr_notset test
- *
- * - 2002/10/31 Tony Cureington <tony.cureington * hp_com> :
- * - If the master does not have a hardware address when the first slave
- * is enslaved, the master is assigned the hardware address of that
- * slave - there is a comment in bonding.c stating "ifenslave takes
- * care of this now." This corrects the problem of slaves having
- * different hardware addresses in active-backup mode when
- * multiple interfaces are specified on a single ifenslave command
- * (ifenslave bond0 eth0 eth1).
- *
- * - 2003/03/18 - Tsippy Mendelson <tsippy.mendelson at intel dot com> and
- * Shmulik Hen <shmulik.hen at intel dot com>
- * - Moved setting the slave's mac address and openning it, from
- * the application to the driver. This enables support of modes
- * that need to use the unique mac address of each slave.
- * The driver also takes care of closing the slave and restoring its
- * original mac address upon release.
- * In addition, block possibility of enslaving before the master is up.
- * This prevents putting the system in an undefined state.
- *
- * - 2003/05/01 - Amir Noam <amir.noam at intel dot com>
- * - Added ABI version control to restore compatibility between
- * new/old ifenslave and new/old bonding.
- * - Prevent adding an adapter that is already a slave.
- * Fixes the problem of stalling the transmission and leaving
- * the slave in a down state.
- *
- * - 2003/05/01 - Shmulik Hen <shmulik.hen at intel dot com>
- * - Prevent enslaving if the bond device is down.
- * Fixes the problem of leaving the system in unstable state and
- * halting when trying to remove the module.
- * - Close socket on all abnormal exists.
- * - Add versioning scheme that follows that of the bonding driver.
- * current version is 1.0.0 as a base line.
- *
- * - 2003/05/22 - Jay Vosburgh <fubar at us dot ibm dot com>
- * - ifenslave -c was broken; it's now fixed
- * - Fixed problem with routes vanishing from master during enslave
- * processing.
- *
- * - 2003/05/27 - Amir Noam <amir.noam at intel dot com>
- * - Fix backward compatibility issues:
- * For drivers not using ABI versions, slave was set down while
- * it should be left up before enslaving.
- * Also, master was not set down and the default set_mac_address()
- * would fail and generate an error message in the system log.
- * - For opt_c: slave should not be set to the master's setting
- * while it is running. It was already set during enslave. To
- * simplify things, it is now handled separately.
- *
- * - 2003/12/01 - Shmulik Hen <shmulik.hen at intel dot com>
- * - Code cleanup and style changes
- * set version to 1.1.0
- */
-
-#define APP_VERSION "1.1.0"
-#define APP_RELDATE "December 1, 2003"
-#define APP_NAME "ifenslave"
-
-static char *version =
-APP_NAME ".c:v" APP_VERSION " (" APP_RELDATE ")\n"
-"o Donald Becker (becker@cesdis.gsfc.nasa.gov).\n"
-"o Detach support added on 2000/10/02 by Willy Tarreau (willy at meta-x.org).\n"
-"o 2.4 kernel support added on 2001/02/16 by Chad N. Tindel\n"
-" (ctindel at ieee dot org).\n";
-
-static const char *usage_msg =
-"Usage: ifenslave [-f] <master-if> <slave-if> [<slave-if>...]\n"
-" ifenslave -d <master-if> <slave-if> [<slave-if>...]\n"
-" ifenslave -c <master-if> <slave-if>\n"
-" ifenslave --help\n";
-
-static const char *help_msg =
-"\n"
-" To create a bond device, simply follow these three steps :\n"
-" - ensure that the required drivers are properly loaded :\n"
-" # modprobe bonding ; modprobe <3c59x|eepro100|pcnet32|tulip|...>\n"
-" - assign an IP address to the bond device :\n"
-" # ifconfig bond0 <addr> netmask <mask> broadcast <bcast>\n"
-" - attach all the interfaces you need to the bond device :\n"
-" # ifenslave [{-f|--force}] bond0 eth0 [eth1 [eth2]...]\n"
-" If bond0 didn't have a MAC address, it will take eth0's. Then, all\n"
-" interfaces attached AFTER this assignment will get the same MAC addr.\n"
-" (except for ALB/TLB modes)\n"
-"\n"
-" To set the bond device down and automatically release all the slaves :\n"
-" # ifconfig bond0 down\n"
-"\n"
-" To detach a dead interface without setting the bond device down :\n"
-" # ifenslave {-d|--detach} bond0 eth0 [eth1 [eth2]...]\n"
-"\n"
-" To change active slave :\n"
-" # ifenslave {-c|--change-active} bond0 eth0\n"
-"\n"
-" To show master interface info\n"
-" # ifenslave bond0\n"
-"\n"
-" To show all interfaces info\n"
-" # ifenslave {-a|--all-interfaces}\n"
-"\n"
-" To be more verbose\n"
-" # ifenslave {-v|--verbose} ...\n"
-"\n"
-" # ifenslave {-u|--usage} Show usage\n"
-" # ifenslave {-V|--version} Show version\n"
-" # ifenslave {-h|--help} This message\n"
-"\n";
-
-#include <unistd.h>
-#include <stdlib.h>
-#include <stdio.h>
-#include <ctype.h>
-#include <string.h>
-#include <errno.h>
-#include <fcntl.h>
-#include <getopt.h>
-#include <sys/types.h>
-#include <sys/socket.h>
-#include <sys/ioctl.h>
-#include <linux/if.h>
-#include <net/if_arp.h>
-#include <linux/if_ether.h>
-#include <linux/if_bonding.h>
-#include <linux/sockios.h>
-
-typedef unsigned long long u64; /* hack, so we may include kernel's ethtool.h */
-typedef __uint32_t u32; /* ditto */
-typedef __uint16_t u16; /* ditto */
-typedef __uint8_t u8; /* ditto */
-#include <linux/ethtool.h>
-
-struct option longopts[] = {
- /* { name has_arg *flag val } */
- {"all-interfaces", 0, 0, 'a'}, /* Show all interfaces. */
- {"change-active", 0, 0, 'c'}, /* Change the active slave. */
- {"detach", 0, 0, 'd'}, /* Detach a slave interface. */
- {"force", 0, 0, 'f'}, /* Force the operation. */
- {"help", 0, 0, 'h'}, /* Give help */
- {"usage", 0, 0, 'u'}, /* Give usage */
- {"verbose", 0, 0, 'v'}, /* Report each action taken. */
- {"version", 0, 0, 'V'}, /* Emit version information. */
- { 0, 0, 0, 0}
-};
-
-/* Command-line flags. */
-unsigned int
-opt_a = 0, /* Show-all-interfaces flag. */
-opt_c = 0, /* Change-active-slave flag. */
-opt_d = 0, /* Detach a slave interface. */
-opt_f = 0, /* Force the operation. */
-opt_h = 0, /* Help */
-opt_u = 0, /* Usage */
-opt_v = 0, /* Verbose flag. */
-opt_V = 0; /* Version */
-
-int skfd = -1; /* AF_INET socket for ioctl() calls.*/
-int abi_ver = 0; /* userland - kernel ABI version */
-int hwaddr_set = 0; /* Master's hwaddr is set */
-int saved_errno;
-
-struct ifreq master_mtu, master_flags, master_hwaddr;
-struct ifreq slave_mtu, slave_flags, slave_hwaddr;
-
-struct dev_ifr {
- struct ifreq *req_ifr;
- char *req_name;
- int req_type;
-};
-
-struct dev_ifr master_ifra[] = {
- {&master_mtu, "SIOCGIFMTU", SIOCGIFMTU},
- {&master_flags, "SIOCGIFFLAGS", SIOCGIFFLAGS},
- {&master_hwaddr, "SIOCGIFHWADDR", SIOCGIFHWADDR},
- {NULL, "", 0}
-};
-
-struct dev_ifr slave_ifra[] = {
- {&slave_mtu, "SIOCGIFMTU", SIOCGIFMTU},
- {&slave_flags, "SIOCGIFFLAGS", SIOCGIFFLAGS},
- {&slave_hwaddr, "SIOCGIFHWADDR", SIOCGIFHWADDR},
- {NULL, "", 0}
-};
-
-static void if_print(char *ifname);
-static int get_drv_info(char *master_ifname);
-static int get_if_settings(char *ifname, struct dev_ifr ifra[]);
-static int get_slave_flags(char *slave_ifname);
-static int set_master_hwaddr(char *master_ifname, struct sockaddr *hwaddr);
-static int set_slave_hwaddr(char *slave_ifname, struct sockaddr *hwaddr);
-static int set_slave_mtu(char *slave_ifname, int mtu);
-static int set_if_flags(char *ifname, short flags);
-static int set_if_up(char *ifname, short flags);
-static int set_if_down(char *ifname, short flags);
-static int clear_if_addr(char *ifname);
-static int set_if_addr(char *master_ifname, char *slave_ifname);
-static int change_active(char *master_ifname, char *slave_ifname);
-static int enslave(char *master_ifname, char *slave_ifname);
-static int release(char *master_ifname, char *slave_ifname);
-#define v_print(fmt, args...) \
- if (opt_v) \
- fprintf(stderr, fmt, ## args )
-
-int main(int argc, char *argv[])
-{
- char **spp, *master_ifname, *slave_ifname;
- int c, i, rv;
- int res = 0;
- int exclusive = 0;
-
- while ((c = getopt_long(argc, argv, "acdfhuvV", longopts, 0)) != EOF) {
- switch (c) {
- case 'a': opt_a++; exclusive++; break;
- case 'c': opt_c++; exclusive++; break;
- case 'd': opt_d++; exclusive++; break;
- case 'f': opt_f++; exclusive++; break;
- case 'h': opt_h++; exclusive++; break;
- case 'u': opt_u++; exclusive++; break;
- case 'v': opt_v++; break;
- case 'V': opt_V++; exclusive++; break;
-
- case '?':
- fprintf(stderr, "%s", usage_msg);
- res = 2;
- goto out;
- }
- }
-
- /* options check */
- if (exclusive > 1) {
- fprintf(stderr, "%s", usage_msg);
- res = 2;
- goto out;
- }
-
- if (opt_v || opt_V) {
- printf("%s", version);
- if (opt_V) {
- res = 0;
- goto out;
- }
- }
-
- if (opt_u) {
- printf("%s", usage_msg);
- res = 0;
- goto out;
- }
-
- if (opt_h) {
- printf("%s", usage_msg);
- printf("%s", help_msg);
- res = 0;
- goto out;
- }
-
- /* Open a basic socket */
- if ((skfd = socket(AF_INET, SOCK_DGRAM, 0)) < 0) {
- perror("socket");
- res = 1;
- goto out;
- }
-
- if (opt_a) {
- if (optind == argc) {
- /* No remaining args */
- /* show all interfaces */
- if_print((char *)NULL);
- goto out;
- } else {
- /* Just show usage */
- fprintf(stderr, "%s", usage_msg);
- res = 2;
- goto out;
- }
- }
-
- /* Copy the interface name */
- spp = argv + optind;
- master_ifname = *spp++;
-
- if (master_ifname == NULL) {
- fprintf(stderr, "%s", usage_msg);
- res = 2;
- goto out;
- }
-
- /* exchange abi version with bonding module */
- res = get_drv_info(master_ifname);
- if (res) {
- fprintf(stderr,
- "Master '%s': Error: handshake with driver failed. "
- "Aborting\n",
- master_ifname);
- goto out;
- }
-
- slave_ifname = *spp++;
-
- if (slave_ifname == NULL) {
- if (opt_d || opt_c) {
- fprintf(stderr, "%s", usage_msg);
- res = 2;
- goto out;
- }
-
- /* A single arg means show the
- * configuration for this interface
- */
- if_print(master_ifname);
- goto out;
- }
-
- res = get_if_settings(master_ifname, master_ifra);
- if (res) {
- /* Probably a good reason not to go on */
- fprintf(stderr,
- "Master '%s': Error: get settings failed: %s. "
- "Aborting\n",
- master_ifname, strerror(res));
- goto out;
- }
-
- /* check if master is indeed a master;
- * if not then fail any operation
- */
- if (!(master_flags.ifr_flags & IFF_MASTER)) {
- fprintf(stderr,
- "Illegal operation; the specified interface '%s' "
- "is not a master. Aborting\n",
- master_ifname);
- res = 1;
- goto out;
- }
-
- /* check if master is up; if not then fail any operation */
- if (!(master_flags.ifr_flags & IFF_UP)) {
- fprintf(stderr,
- "Illegal operation; the specified master interface "
- "'%s' is not up.\n",
- master_ifname);
- res = 1;
- goto out;
- }
-
- /* Only for enslaving */
- if (!opt_c && !opt_d) {
- sa_family_t master_family = master_hwaddr.ifr_hwaddr.sa_family;
- unsigned char *hwaddr =
- (unsigned char *)master_hwaddr.ifr_hwaddr.sa_data;
-
- /* The family '1' is ARPHRD_ETHER for ethernet. */
- if (master_family != 1 && !opt_f) {
- fprintf(stderr,
- "Illegal operation: The specified master "
- "interface '%s' is not ethernet-like.\n "
- "This program is designed to work with "
- "ethernet-like network interfaces.\n "
- "Use the '-f' option to force the "
- "operation.\n",
- master_ifname);
- res = 1;
- goto out;
- }
-
- /* Check master's hw addr */
- for (i = 0; i < 6; i++) {
- if (hwaddr[i] != 0) {
- hwaddr_set = 1;
- break;
- }
- }
-
- if (hwaddr_set) {
- v_print("current hardware address of master '%s' "
- "is %2.2x:%2.2x:%2.2x:%2.2x:%2.2x:%2.2x, "
- "type %d\n",
- master_ifname,
- hwaddr[0], hwaddr[1],
- hwaddr[2], hwaddr[3],
- hwaddr[4], hwaddr[5],
- master_family);
- }
- }
-
- /* Accepts only one slave */
- if (opt_c) {
- /* change active slave */
- res = get_slave_flags(slave_ifname);
- if (res) {
- fprintf(stderr,
- "Slave '%s': Error: get flags failed. "
- "Aborting\n",
- slave_ifname);
- goto out;
- }
- res = change_active(master_ifname, slave_ifname);
- if (res) {
- fprintf(stderr,
- "Master '%s', Slave '%s': Error: "
- "Change active failed\n",
- master_ifname, slave_ifname);
- }
- } else {
- /* Accept multiple slaves */
- do {
- if (opt_d) {
- /* detach a slave interface from the master */
- rv = get_slave_flags(slave_ifname);
- if (rv) {
- /* Can't work with this slave. */
- /* remember the error and skip it*/
- fprintf(stderr,
- "Slave '%s': Error: get flags "
- "failed. Skipping\n",
- slave_ifname);
- res = rv;
- continue;
- }
- rv = release(master_ifname, slave_ifname);
- if (rv) {
- fprintf(stderr,
- "Master '%s', Slave '%s': Error: "
- "Release failed\n",
- master_ifname, slave_ifname);
- res = rv;
- }
- } else {
- /* attach a slave interface to the master */
- rv = get_if_settings(slave_ifname, slave_ifra);
- if (rv) {
- /* Can't work with this slave. */
- /* remember the error and skip it*/
- fprintf(stderr,
- "Slave '%s': Error: get "
- "settings failed: %s. "
- "Skipping\n",
- slave_ifname, strerror(rv));
- res = rv;
- continue;
- }
- rv = enslave(master_ifname, slave_ifname);
- if (rv) {
- fprintf(stderr,
- "Master '%s', Slave '%s': Error: "
- "Enslave failed\n",
- master_ifname, slave_ifname);
- res = rv;
- }
- }
- } while ((slave_ifname = *spp++) != NULL);
- }
-
-out:
- if (skfd >= 0) {
- close(skfd);
- }
-
- return res;
-}
-
-static short mif_flags;
-
-/* Get the inteface configuration from the kernel. */
-static int if_getconfig(char *ifname)
-{
- struct ifreq ifr;
- int metric, mtu; /* Parameters of the master interface. */
- struct sockaddr dstaddr, broadaddr, netmask;
- unsigned char *hwaddr;
-
- strcpy(ifr.ifr_name, ifname);
- if (ioctl(skfd, SIOCGIFFLAGS, &ifr) < 0)
- return -1;
- mif_flags = ifr.ifr_flags;
- printf("The result of SIOCGIFFLAGS on %s is %x.\n",
- ifname, ifr.ifr_flags);
-
- strcpy(ifr.ifr_name, ifname);
- if (ioctl(skfd, SIOCGIFADDR, &ifr) < 0)
- return -1;
- printf("The result of SIOCGIFADDR is %2.2x.%2.2x.%2.2x.%2.2x.\n",
- ifr.ifr_addr.sa_data[0], ifr.ifr_addr.sa_data[1],
- ifr.ifr_addr.sa_data[2], ifr.ifr_addr.sa_data[3]);
-
- strcpy(ifr.ifr_name, ifname);
- if (ioctl(skfd, SIOCGIFHWADDR, &ifr) < 0)
- return -1;
-
- /* Gotta convert from 'char' to unsigned for printf(). */
- hwaddr = (unsigned char *)ifr.ifr_hwaddr.sa_data;
- printf("The result of SIOCGIFHWADDR is type %d "
- "%2.2x:%2.2x:%2.2x:%2.2x:%2.2x:%2.2x.\n",
- ifr.ifr_hwaddr.sa_family, hwaddr[0], hwaddr[1],
- hwaddr[2], hwaddr[3], hwaddr[4], hwaddr[5]);
-
- strcpy(ifr.ifr_name, ifname);
- if (ioctl(skfd, SIOCGIFMETRIC, &ifr) < 0) {
- metric = 0;
- } else
- metric = ifr.ifr_metric;
- printf("The result of SIOCGIFMETRIC is %d\n", metric);
-
- strcpy(ifr.ifr_name, ifname);
- if (ioctl(skfd, SIOCGIFMTU, &ifr) < 0)
- mtu = 0;
- else
- mtu = ifr.ifr_mtu;
- printf("The result of SIOCGIFMTU is %d\n", mtu);
-
- strcpy(ifr.ifr_name, ifname);
- if (ioctl(skfd, SIOCGIFDSTADDR, &ifr) < 0) {
- memset(&dstaddr, 0, sizeof(struct sockaddr));
- } else
- dstaddr = ifr.ifr_dstaddr;
-
- strcpy(ifr.ifr_name, ifname);
- if (ioctl(skfd, SIOCGIFBRDADDR, &ifr) < 0) {
- memset(&broadaddr, 0, sizeof(struct sockaddr));
- } else
- broadaddr = ifr.ifr_broadaddr;
-
- strcpy(ifr.ifr_name, ifname);
- if (ioctl(skfd, SIOCGIFNETMASK, &ifr) < 0) {
- memset(&netmask, 0, sizeof(struct sockaddr));
- } else
- netmask = ifr.ifr_netmask;
-
- return 0;
-}
-
-static void if_print(char *ifname)
-{
- char buff[1024];
- struct ifconf ifc;
- struct ifreq *ifr;
- int i;
-
- if (ifname == (char *)NULL) {
- ifc.ifc_len = sizeof(buff);
- ifc.ifc_buf = buff;
- if (ioctl(skfd, SIOCGIFCONF, &ifc) < 0) {
- perror("SIOCGIFCONF failed");
- return;
- }
-
- ifr = ifc.ifc_req;
- for (i = ifc.ifc_len / sizeof(struct ifreq); --i >= 0; ifr++) {
- if (if_getconfig(ifr->ifr_name) < 0) {
- fprintf(stderr,
- "%s: unknown interface.\n",
- ifr->ifr_name);
- continue;
- }
-
- if (((mif_flags & IFF_UP) == 0) && !opt_a) continue;
- /*ife_print(&ife);*/
- }
- } else {
- if (if_getconfig(ifname) < 0) {
- fprintf(stderr,
- "%s: unknown interface.\n", ifname);
- }
- }
-}
-
-static int get_drv_info(char *master_ifname)
-{
- struct ifreq ifr;
- struct ethtool_drvinfo info;
- char *endptr;
-
- memset(&ifr, 0, sizeof(ifr));
- strncpy(ifr.ifr_name, master_ifname, IFNAMSIZ);
- ifr.ifr_data = (caddr_t)&info;
-
- info.cmd = ETHTOOL_GDRVINFO;
- strncpy(info.driver, "ifenslave", 32);
- snprintf(info.fw_version, 32, "%d", BOND_ABI_VERSION);
-
- if (ioctl(skfd, SIOCETHTOOL, &ifr) < 0) {
- if (errno == EOPNOTSUPP) {
- goto out;
- }
-
- saved_errno = errno;
- v_print("Master '%s': Error: get bonding info failed %s\n",
- master_ifname, strerror(saved_errno));
- return 1;
- }
-
- abi_ver = strtoul(info.fw_version, &endptr, 0);
- if (*endptr) {
- v_print("Master '%s': Error: got invalid string as an ABI "
- "version from the bonding module\n",
- master_ifname);
- return 1;
- }
-
-out:
- v_print("ABI ver is %d\n", abi_ver);
-
- return 0;
-}
-
-static int change_active(char *master_ifname, char *slave_ifname)
-{
- struct ifreq ifr;
- int res = 0;
-
- if (!(slave_flags.ifr_flags & IFF_SLAVE)) {
- fprintf(stderr,
- "Illegal operation: The specified slave interface "
- "'%s' is not a slave\n",
- slave_ifname);
- return 1;
- }
-
- strncpy(ifr.ifr_name, master_ifname, IFNAMSIZ);
- strncpy(ifr.ifr_slave, slave_ifname, IFNAMSIZ);
- if ((ioctl(skfd, SIOCBONDCHANGEACTIVE, &ifr) < 0) &&
- (ioctl(skfd, BOND_CHANGE_ACTIVE_OLD, &ifr) < 0)) {
- saved_errno = errno;
- v_print("Master '%s': Error: SIOCBONDCHANGEACTIVE failed: "
- "%s\n",
- master_ifname, strerror(saved_errno));
- res = 1;
- }
-
- return res;
-}
-
-static int enslave(char *master_ifname, char *slave_ifname)
-{
- struct ifreq ifr;
- int res = 0;
-
- if (slave_flags.ifr_flags & IFF_SLAVE) {
- fprintf(stderr,
- "Illegal operation: The specified slave interface "
- "'%s' is already a slave\n",
- slave_ifname);
- return 1;
- }
-
- res = set_if_down(slave_ifname, slave_flags.ifr_flags);
- if (res) {
- fprintf(stderr,
- "Slave '%s': Error: bring interface down failed\n",
- slave_ifname);
- return res;
- }
-
- if (abi_ver < 2) {
- /* Older bonding versions would panic if the slave has no IP
- * address, so get the IP setting from the master.
- */
- set_if_addr(master_ifname, slave_ifname);
- } else {
- res = clear_if_addr(slave_ifname);
- if (res) {
- fprintf(stderr,
- "Slave '%s': Error: clear address failed\n",
- slave_ifname);
- return res;
- }
- }
-
- if (master_mtu.ifr_mtu != slave_mtu.ifr_mtu) {
- res = set_slave_mtu(slave_ifname, master_mtu.ifr_mtu);
- if (res) {
- fprintf(stderr,
- "Slave '%s': Error: set MTU failed\n",
- slave_ifname);
- return res;
- }
- }
-
- if (hwaddr_set) {
- /* Master already has an hwaddr
- * so set it's hwaddr to the slave
- */
- if (abi_ver < 1) {
- /* The driver is using an old ABI, so
- * the application sets the slave's
- * hwaddr
- */
- res = set_slave_hwaddr(slave_ifname,
- &(master_hwaddr.ifr_hwaddr));
- if (res) {
- fprintf(stderr,
- "Slave '%s': Error: set hw address "
- "failed\n",
- slave_ifname);
- goto undo_mtu;
- }
-
- /* For old ABI the application needs to bring the
- * slave back up
- */
- res = set_if_up(slave_ifname, slave_flags.ifr_flags);
- if (res) {
- fprintf(stderr,
- "Slave '%s': Error: bring interface "
- "down failed\n",
- slave_ifname);
- goto undo_slave_mac;
- }
- }
- /* The driver is using a new ABI,
- * so the driver takes care of setting
- * the slave's hwaddr and bringing
- * it up again
- */
- } else {
- /* No hwaddr for master yet, so
- * set the slave's hwaddr to it
- */
- if (abi_ver < 1) {
- /* For old ABI, the master needs to be
- * down before setting its hwaddr
- */
- res = set_if_down(master_ifname, master_flags.ifr_flags);
- if (res) {
- fprintf(stderr,
- "Master '%s': Error: bring interface "
- "down failed\n",
- master_ifname);
- goto undo_mtu;
- }
- }
-
- res = set_master_hwaddr(master_ifname,
- &(slave_hwaddr.ifr_hwaddr));
- if (res) {
- fprintf(stderr,
- "Master '%s': Error: set hw address "
- "failed\n",
- master_ifname);
- goto undo_mtu;
- }
-
- if (abi_ver < 1) {
- /* For old ABI, bring the master
- * back up
- */
- res = set_if_up(master_ifname, master_flags.ifr_flags);
- if (res) {
- fprintf(stderr,
- "Master '%s': Error: bring interface "
- "up failed\n",
- master_ifname);
- goto undo_master_mac;
- }
- }
-
- hwaddr_set = 1;
- }
-
- /* Do the real thing */
- strncpy(ifr.ifr_name, master_ifname, IFNAMSIZ);
- strncpy(ifr.ifr_slave, slave_ifname, IFNAMSIZ);
- if ((ioctl(skfd, SIOCBONDENSLAVE, &ifr) < 0) &&
- (ioctl(skfd, BOND_ENSLAVE_OLD, &ifr) < 0)) {
- saved_errno = errno;
- v_print("Master '%s': Error: SIOCBONDENSLAVE failed: %s\n",
- master_ifname, strerror(saved_errno));
- res = 1;
- }
-
- if (res) {
- goto undo_master_mac;
- }
-
- return 0;
-
-/* rollback (best effort) */
-undo_master_mac:
- set_master_hwaddr(master_ifname, &(master_hwaddr.ifr_hwaddr));
- hwaddr_set = 0;
- goto undo_mtu;
-undo_slave_mac:
- set_slave_hwaddr(slave_ifname, &(slave_hwaddr.ifr_hwaddr));
-undo_mtu:
- set_slave_mtu(slave_ifname, slave_mtu.ifr_mtu);
- return res;
-}
-
-static int release(char *master_ifname, char *slave_ifname)
-{
- struct ifreq ifr;
- int res = 0;
-
- if (!(slave_flags.ifr_flags & IFF_SLAVE)) {
- fprintf(stderr,
- "Illegal operation: The specified slave interface "
- "'%s' is not a slave\n",
- slave_ifname);
- return 1;
- }
-
- strncpy(ifr.ifr_name, master_ifname, IFNAMSIZ);
- strncpy(ifr.ifr_slave, slave_ifname, IFNAMSIZ);
- if ((ioctl(skfd, SIOCBONDRELEASE, &ifr) < 0) &&
- (ioctl(skfd, BOND_RELEASE_OLD, &ifr) < 0)) {
- saved_errno = errno;
- v_print("Master '%s': Error: SIOCBONDRELEASE failed: %s\n",
- master_ifname, strerror(saved_errno));
- return 1;
- } else if (abi_ver < 1) {
- /* The driver is using an old ABI, so we'll set the interface
- * down to avoid any conflicts due to same MAC/IP
- */
- res = set_if_down(slave_ifname, slave_flags.ifr_flags);
- if (res) {
- fprintf(stderr,
- "Slave '%s': Error: bring interface "
- "down failed\n",
- slave_ifname);
- }
- }
-
- /* set to default mtu */
- set_slave_mtu(slave_ifname, 1500);
-
- return res;
-}
-
-static int get_if_settings(char *ifname, struct dev_ifr ifra[])
-{
- int i;
- int res = 0;
-
- for (i = 0; ifra[i].req_ifr; i++) {
- strncpy(ifra[i].req_ifr->ifr_name, ifname, IFNAMSIZ);
- res = ioctl(skfd, ifra[i].req_type, ifra[i].req_ifr);
- if (res < 0) {
- saved_errno = errno;
- v_print("Interface '%s': Error: %s failed: %s\n",
- ifname, ifra[i].req_name,
- strerror(saved_errno));
-
- return saved_errno;
- }
- }
-
- return 0;
-}
-
-static int get_slave_flags(char *slave_ifname)
-{
- int res = 0;
-
- strncpy(slave_flags.ifr_name, slave_ifname, IFNAMSIZ);
- res = ioctl(skfd, SIOCGIFFLAGS, &slave_flags);
- if (res < 0) {
- saved_errno = errno;
- v_print("Slave '%s': Error: SIOCGIFFLAGS failed: %s\n",
- slave_ifname, strerror(saved_errno));
- } else {
- v_print("Slave %s: flags %04X.\n",
- slave_ifname, slave_flags.ifr_flags);
- }
-
- return res;
-}
-
-static int set_master_hwaddr(char *master_ifname, struct sockaddr *hwaddr)
-{
- unsigned char *addr = (unsigned char *)hwaddr->sa_data;
- struct ifreq ifr;
- int res = 0;
-
- strncpy(ifr.ifr_name, master_ifname, IFNAMSIZ);
- memcpy(&(ifr.ifr_hwaddr), hwaddr, sizeof(struct sockaddr));
- res = ioctl(skfd, SIOCSIFHWADDR, &ifr);
- if (res < 0) {
- saved_errno = errno;
- v_print("Master '%s': Error: SIOCSIFHWADDR failed: %s\n",
- master_ifname, strerror(saved_errno));
- return res;
- } else {
- v_print("Master '%s': hardware address set to "
- "%2.2x:%2.2x:%2.2x:%2.2x:%2.2x:%2.2x.\n",
- master_ifname, addr[0], addr[1], addr[2],
- addr[3], addr[4], addr[5]);
- }
-
- return res;
-}
-
-static int set_slave_hwaddr(char *slave_ifname, struct sockaddr *hwaddr)
-{
- unsigned char *addr = (unsigned char *)hwaddr->sa_data;
- struct ifreq ifr;
- int res = 0;
-
- strncpy(ifr.ifr_name, slave_ifname, IFNAMSIZ);
- memcpy(&(ifr.ifr_hwaddr), hwaddr, sizeof(struct sockaddr));
- res = ioctl(skfd, SIOCSIFHWADDR, &ifr);
- if (res < 0) {
- saved_errno = errno;
-
- v_print("Slave '%s': Error: SIOCSIFHWADDR failed: %s\n",
- slave_ifname, strerror(saved_errno));
-
- if (saved_errno == EBUSY) {
- v_print(" The device is busy: it must be idle "
- "before running this command.\n");
- } else if (saved_errno == EOPNOTSUPP) {
- v_print(" The device does not support setting "
- "the MAC address.\n"
- " Your kernel likely does not support slave "
- "devices.\n");
- } else if (saved_errno == EINVAL) {
- v_print(" The device's address type does not match "
- "the master's address type.\n");
- }
- return res;
- } else {
- v_print("Slave '%s': hardware address set to "
- "%2.2x:%2.2x:%2.2x:%2.2x:%2.2x:%2.2x.\n",
- slave_ifname, addr[0], addr[1], addr[2],
- addr[3], addr[4], addr[5]);
- }
-
- return res;
-}
-
-static int set_slave_mtu(char *slave_ifname, int mtu)
-{
- struct ifreq ifr;
- int res = 0;
-
- ifr.ifr_mtu = mtu;
- strncpy(ifr.ifr_name, slave_ifname, IFNAMSIZ);
-
- res = ioctl(skfd, SIOCSIFMTU, &ifr);
- if (res < 0) {
- saved_errno = errno;
- v_print("Slave '%s': Error: SIOCSIFMTU failed: %s\n",
- slave_ifname, strerror(saved_errno));
- } else {
- v_print("Slave '%s': MTU set to %d.\n", slave_ifname, mtu);
- }
-
- return res;
-}
-
-static int set_if_flags(char *ifname, short flags)
-{
- struct ifreq ifr;
- int res = 0;
-
- ifr.ifr_flags = flags;
- strncpy(ifr.ifr_name, ifname, IFNAMSIZ);
-
- res = ioctl(skfd, SIOCSIFFLAGS, &ifr);
- if (res < 0) {
- saved_errno = errno;
- v_print("Interface '%s': Error: SIOCSIFFLAGS failed: %s\n",
- ifname, strerror(saved_errno));
- } else {
- v_print("Interface '%s': flags set to %04X.\n", ifname, flags);
- }
-
- return res;
-}
-
-static int set_if_up(char *ifname, short flags)
-{
- return set_if_flags(ifname, flags | IFF_UP);
-}
-
-static int set_if_down(char *ifname, short flags)
-{
- return set_if_flags(ifname, flags & ~IFF_UP);
-}
-
-static int clear_if_addr(char *ifname)
-{
- struct ifreq ifr;
- int res = 0;
-
- strncpy(ifr.ifr_name, ifname, IFNAMSIZ);
- ifr.ifr_addr.sa_family = AF_INET;
- memset(ifr.ifr_addr.sa_data, 0, sizeof(ifr.ifr_addr.sa_data));
-
- res = ioctl(skfd, SIOCSIFADDR, &ifr);
- if (res < 0) {
- saved_errno = errno;
- v_print("Interface '%s': Error: SIOCSIFADDR failed: %s\n",
- ifname, strerror(saved_errno));
- } else {
- v_print("Interface '%s': address cleared\n", ifname);
- }
-
- return res;
-}
-
-static int set_if_addr(char *master_ifname, char *slave_ifname)
-{
- struct ifreq ifr;
- int res;
- unsigned char *ipaddr;
- int i;
- struct {
- char *req_name;
- char *desc;
- int g_ioctl;
- int s_ioctl;
- } ifra[] = {
- {"IFADDR", "addr", SIOCGIFADDR, SIOCSIFADDR},
- {"DSTADDR", "destination addr", SIOCGIFDSTADDR, SIOCSIFDSTADDR},
- {"BRDADDR", "broadcast addr", SIOCGIFBRDADDR, SIOCSIFBRDADDR},
- {"NETMASK", "netmask", SIOCGIFNETMASK, SIOCSIFNETMASK},
- {NULL, NULL, 0, 0},
- };
-
- for (i = 0; ifra[i].req_name; i++) {
- strncpy(ifr.ifr_name, master_ifname, IFNAMSIZ);
- res = ioctl(skfd, ifra[i].g_ioctl, &ifr);
- if (res < 0) {
- int saved_errno = errno;
-
- v_print("Interface '%s': Error: SIOCG%s failed: %s\n",
- master_ifname, ifra[i].req_name,
- strerror(saved_errno));
-
- ifr.ifr_addr.sa_family = AF_INET;
- memset(ifr.ifr_addr.sa_data, 0,
- sizeof(ifr.ifr_addr.sa_data));
- }
-
- strncpy(ifr.ifr_name, slave_ifname, IFNAMSIZ);
- res = ioctl(skfd, ifra[i].s_ioctl, &ifr);
- if (res < 0) {
- int saved_errno = errno;
-
- v_print("Interface '%s': Error: SIOCS%s failed: %s\n",
- slave_ifname, ifra[i].req_name,
- strerror(saved_errno));
-
- }
-
- ipaddr = (unsigned char *)ifr.ifr_addr.sa_data;
- v_print("Interface '%s': set IP %s to %d.%d.%d.%d\n",
- slave_ifname, ifra[i].desc,
- ipaddr[0], ipaddr[1], ipaddr[2], ipaddr[3]);
- }
-
- return 0;
-}
-
-/*
- * Local variables:
- * version-control: t
- * kept-new-versions: 5
- * c-indent-level: 4
- * c-basic-offset: 4
- * tab-width: 4
- * compile-command: "gcc -Wall -Wstrict-prototypes -O -I/usr/src/linux/include ifenslave.c -o ifenslave"
- * End:
- */
-
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index dd52d51..1074290 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -26,6 +26,11 @@
Maximum number of routes allowed in the kernel. Increase
this when using large numbers of interfaces and/or routes.
+neigh/default/gc_thresh1 - INTEGER
+ Minimum number of entries to keep. Garbage collector will not
+ purge entries if there are fewer than this number.
+ Default: 128
+
neigh/default/gc_thresh3 - INTEGER
Maximum number of neighbor entries allowed. Increase this
when using large numbers of interfaces and when communicating
@@ -36,7 +41,7 @@
The maximum number of bytes which may be used by packets
queued for each unresolved address by other network layers.
(added in linux 3.3)
- Seting negative value is meaningless and will retrun error.
+ Setting negative value is meaningless and will return error.
Default: 65536 Bytes(64KB)
neigh/default/unres_qlen - INTEGER
@@ -125,17 +130,6 @@
Defaults to 128. See also tcp_max_syn_backlog for additional tuning
for TCP sockets.
-tcp_abc - INTEGER
- Controls Appropriate Byte Count (ABC) defined in RFC3465.
- ABC is a way of increasing congestion window (cwnd) more slowly
- in response to partial acknowledgments.
- Possible values are:
- 0 increase cwnd once per acknowledgment (no ABC)
- 1 increase cwnd once per acknowledgment of full sized segment
- 2 allow increase cwnd by two if acknowledgment is
- of two segments to compensate for delayed acknowledgments.
- Default: 0 (off)
-
tcp_abort_on_overflow - BOOLEAN
If listening service is too slow to accept new connections,
reset them. Default state is FALSE. It means that if overflow
@@ -181,14 +175,6 @@
is inherited.
[see setsockopt(listenfd, SOL_TCP, TCP_CONGESTION, "name" ...) ]
-tcp_cookie_size - INTEGER
- Default size of TCP Cookie Transactions (TCPCT) option, that may be
- overridden on a per socket basis by the TCPCT socket option.
- Values greater than the maximum (16) are interpreted as the maximum.
- Values greater than zero and less than the minimum (8) are interpreted
- as the minimum. Odd values are interpreted as the next even value.
- Default: 0 (off).
-
tcp_dsack - BOOLEAN
Allows TCP to send "duplicate" SACKs.
@@ -196,7 +182,9 @@
Enable Early Retransmit (ER), per RFC 5827. ER lowers the threshold
for triggering fast retransmit when the amount of outstanding data is
small and when no previously unsent data can be transmitted (such
- that limited transmit could be used).
+ that limited transmit could be used). Also controls the use of
+ Tail loss probe (TLP) that converts RTOs occurring due to tail
+ losses into fast recovery (draft-dukkipati-tcpm-tcp-loss-probe-01).
Possible values:
0 disables ER
1 enables ER
@@ -204,7 +192,9 @@
by a fourth of RTT. This mitigates connection falsely
recovers when network has a small degree of reordering
(less than 3 packets).
- Default: 2
+ 3 enables delayed ER and TLP.
+ 4 enables TLP only.
+ Default: 3
tcp_ecn - INTEGER
Control use of Explicit Congestion Notification (ECN) by TCP.
@@ -214,8 +204,9 @@
congestion before having to drop packets.
Possible values are:
0 Disable ECN. Neither initiate nor accept ECN.
- 1 Always request ECN on outgoing connection attempts.
- 2 Enable ECN when requested by incomming connections
+ 1 Enable ECN when requested by incoming connections and
+ also request ECN on outgoing connection attempts.
+ 2 Enable ECN when requested by incoming connections
but do not request ECN on outgoing connections.
Default: 2
@@ -234,36 +225,13 @@
Default: 60 seconds
tcp_frto - INTEGER
- Enables Forward RTO-Recovery (F-RTO) defined in RFC4138.
+ Enables Forward RTO-Recovery (F-RTO) defined in RFC5682.
F-RTO is an enhanced recovery algorithm for TCP retransmission
- timeouts. It is particularly beneficial in wireless environments
- where packet loss is typically due to random radio interference
- rather than intermediate router congestion. F-RTO is sender-side
- only modification. Therefore it does not require any support from
- the peer.
+ timeouts. It is particularly beneficial in networks where the
+ RTT fluctuates (e.g., wireless). F-RTO is sender-side only
+ modification. It does not require any support from the peer.
- If set to 1, basic version is enabled. 2 enables SACK enhanced
- F-RTO if flow uses SACK. The basic version can be used also when
- SACK is in use though scenario(s) with it exists where F-RTO
- interacts badly with the packet counting of the SACK enabled TCP
- flow.
-
-tcp_frto_response - INTEGER
- When F-RTO has detected that a TCP retransmission timeout was
- spurious (i.e, the timeout would have been avoided had TCP set a
- longer retransmission timeout), TCP has several options what to do
- next. Possible values are:
- 0 Rate halving based; a smooth and conservative response,
- results in halved cwnd and ssthresh after one RTT
- 1 Very conservative response; not recommended because even
- though being valid, it interacts poorly with the rest of
- Linux TCP, halves cwnd and ssthresh immediately
- 2 Aggressive response; undoes congestion control measures
- that are now known to be unnecessary (ignoring the
- possibility of a lost retransmission that would require
- TCP to be more cautious), cwnd and ssthresh are restored
- to the values prior timeout
- Default: 0 (rate halving based)
+ By default it's enabled with a non-zero value. 0 disables F-RTO.
tcp_keepalive_time - INTEGER
How often TCP sends out keepalive messages when keepalive is enabled.
@@ -452,10 +420,10 @@
for a passive TCP connection will happen after 63seconds.
tcp_syncookies - BOOLEAN
- Only valid when the kernel was compiled with CONFIG_SYNCOOKIES
+ Only valid when the kernel was compiled with CONFIG_SYN_COOKIES
Send out syncookies when the syn backlog queue of a socket
overflows. This is to prevent against the common 'SYN flood attack'
- Default: FALSE
+ Default: 1
Note, that syncookies is fallback facility.
It MUST NOT be used to help highly loaded servers to stand
@@ -503,7 +471,7 @@
tcp_syn_retries - INTEGER
Number of times initial SYNs for an active TCP connection attempt
will be retransmitted. Should not be higher than 255. Default value
- is 6, which corresponds to 63seconds till the last restransmission
+ is 6, which corresponds to 63seconds till the last retransmission
with the current initial RTO of 1second. With this the final timeout
for an active TCP connection attempt will happen after 127seconds.
@@ -717,6 +685,15 @@
occurs.
Default: 0
+ip_early_demux - BOOLEAN
+ Optimize input packet processing down to one demux for
+ certain kinds of local sockets. Currently we only do this
+ for established TCP sockets.
+
+ It may add an additional cost for pure routing workloads that
+ reduces overall throughput, in such case you should disable it.
+ Default: 1
+
icmp_echo_ignore_all - BOOLEAN
If set non-zero, then the kernel will ignore all ICMP ECHO
requests sent to it.
@@ -761,7 +738,7 @@
frames. Such violations are normally logged via a kernel warning.
If this is set to TRUE, the kernel will not give such warnings, which
will avoid log file clutter.
- Default: FALSE
+ Default: 1
icmp_errors_use_inbound_ifaddr - BOOLEAN
@@ -1331,6 +1308,12 @@
race condition where the sender deletes the cached link-layer address
prior to receiving a response to a previous solicitation."
+ndisc_notify - BOOLEAN
+ Define mode for notification of address and device changes.
+ 0 - (default): do nothing
+ 1 - Generate unsolicited neighbour advertisements when device is brought
+ up or hardware address changes.
+
icmp/*:
ratelimit - INTEGER
Limit the maximal rates for sending ICMPv6 packets.
@@ -1530,7 +1513,7 @@
* sha1
* none
Ability to assign md5 or sha1 as the selected alg is predicated on the
- configuarion of those algorithms at build time (CONFIG_CRYPTO_MD5 and
+ configuration of those algorithms at build time (CONFIG_CRYPTO_MD5 and
CONFIG_CRYPTO_SHA1).
Default: Dependent on configuration. MD5 if available, else SHA1 if
@@ -1548,7 +1531,7 @@
blocking.
1: rcvbuf space is per association
- 0: recbuf space is per socket
+ 0: rcvbuf space is per socket
Default: 0
diff --git a/Documentation/networking/ipvs-sysctl.txt b/Documentation/networking/ipvs-sysctl.txt
index f2a2488..7a3c047 100644
--- a/Documentation/networking/ipvs-sysctl.txt
+++ b/Documentation/networking/ipvs-sysctl.txt
@@ -15,6 +15,13 @@
enabled and the variable is automatically set to 2, otherwise
the strategy is disabled and the variable is set to 1.
+backup_only - BOOLEAN
+ 0 - disabled (default)
+ not 0 - enabled
+
+ If set, disable the director function while the server is
+ in backup mode to avoid packet loops for DR/TUN methods.
+
conntrack - BOOLEAN
0 - disabled (default)
not 0 - enabled
@@ -174,6 +181,19 @@
always be the same as the original route so it is an optimisation
to disable snat_reroute and avoid the recalculation.
+sync_persist_mode - INTEGER
+ default 0
+
+ Controls the synchronisation of connections when using persistence
+
+ 0: All types of connections are synchronised
+ 1: Attempt to reduce the synchronisation traffic depending on
+ the connection type. For persistent services avoid synchronisation
+ for normal connections, do it only for persistence templates.
+ In such case, for TCP and SCTP it may need enabling sloppy_tcp and
+ sloppy_sctp flags on backup servers. For non-persistent services
+ such optimization is not applied, mode 0 is assumed.
+
sync_version - INTEGER
default 1
diff --git a/Documentation/networking/multicast.txt b/Documentation/networking/multicast.txt
deleted file mode 100644
index b06c8c69..0000000
--- a/Documentation/networking/multicast.txt
+++ /dev/null
@@ -1,63 +0,0 @@
-Behaviour of Cards Under Multicast
-==================================
-
-This is how they currently behave, not what the hardware can do--for example,
-the Lance driver doesn't use its filter, even though the code for loading
-it is in the DEC Lance-based driver.
-
-The following are requirements for multicasting
------------------------------------------------
-AppleTalk Multicast hardware filtering not important but
- avoid cards only doing promisc
-IP-Multicast Multicast hardware filters really help
-IP-MRoute AllMulti hardware filters are of no help
-
-
-Board Multicast AllMulti Promisc Filter
-------------------------------------------------------------------------
-3c501 YES YES YES Software
-3c503 YES YES YES Hardware
-3c505 YES NO YES Hardware
-3c507 NO NO NO N/A
-3c509 YES YES YES Software
-3c59x YES YES YES Software
-ac3200 YES YES YES Hardware
-apricot YES PROMISC YES Hardware
-arcnet NO NO NO N/A
-at1700 PROMISC PROMISC YES Software
-atp PROMISC PROMISC YES Software
-cs89x0 YES YES YES Software
-de4x5 YES YES YES Hardware
-de600 NO NO NO N/A
-de620 PROMISC PROMISC YES Software
-depca YES PROMISC YES Hardware
-dmfe YES YES YES Software(*)
-e2100 YES YES YES Hardware
-eepro YES PROMISC YES Hardware
-eexpress NO NO NO N/A
-ewrk3 YES PROMISC YES Hardware
-hp-plus YES YES YES Hardware
-hp YES YES YES Hardware
-hp100 YES YES YES Hardware
-ibmtr NO NO NO N/A
-ioc3-eth YES YES YES Hardware
-lance YES YES YES Software(#)
-ne YES YES YES Hardware
-ni52 <------------------ Buggy ------------------>
-ni65 YES YES YES Software(#)
-seeq NO NO NO N/A
-sgiseek <------------------ Buggy ------------------>
-smc-ultra YES YES YES Hardware
-sunlance YES YES YES Hardware
-tulip YES YES YES Hardware
-wavelan YES PROMISC YES Hardware
-wd YES YES YES Hardware
-xirc2ps_cs YES YES YES Hardware
-znet YES YES YES Software
-
-
-PROMISC = This multicast mode is in fact promiscuous mode. Avoid using
-cards who go PROMISC on any multicast in a multicast kernel.
-
-(#) = Hardware multicast support is not used yet.
-(*) = Hardware support for Davicom 9132 chipset only.
diff --git a/Documentation/networking/netconsole.txt b/Documentation/networking/netconsole.txt
index 2e9e0ae2..a5d574a 100644
--- a/Documentation/networking/netconsole.txt
+++ b/Documentation/networking/netconsole.txt
@@ -1,9 +1,10 @@
started by Ingo Molnar <mingo@redhat.com>, 2001.09.17
2.6 port and netpoll api by Matt Mackall <mpm@selenic.com>, Sep 9 2003
+IPv6 support by Cong Wang <xiyou.wangcong@gmail.com>, Jan 1 2013
Please send bug reports to Matt Mackall <mpm@selenic.com>
-and Satyam Sharma <satyam.sharma@gmail.com>
+Satyam Sharma <satyam.sharma@gmail.com>, and Cong Wang <xiyou.wangcong@gmail.com>
Introduction:
=============
@@ -41,6 +42,10 @@
insmod netconsole netconsole=@/,@10.0.0.2/
+ or using IPv6
+
+ insmod netconsole netconsole=@/,@fd00:1:2:3::1/
+
It also supports logging to multiple remote agents by specifying
parameters for the multiple agents separated by semicolons and the
complete string enclosed in "quotes", thusly:
diff --git a/Documentation/networking/netlink_mmap.txt b/Documentation/networking/netlink_mmap.txt
new file mode 100644
index 0000000..5333788
--- /dev/null
+++ b/Documentation/networking/netlink_mmap.txt
@@ -0,0 +1,339 @@
+This file documents how to use memory mapped I/O with netlink.
+
+Author: Patrick McHardy <kaber@trash.net>
+
+Overview
+--------
+
+Memory mapped netlink I/O can be used to increase throughput and decrease
+overhead of unicast receive and transmit operations. Some netlink subsystems
+require high throughput, these are mainly the netfilter subsystems
+nfnetlink_queue and nfnetlink_log, but it can also help speed up large
+dump operations of f.i. the routing database.
+
+Memory mapped netlink I/O used two circular ring buffers for RX and TX which
+are mapped into the processes address space.
+
+The RX ring is used by the kernel to directly construct netlink messages into
+user-space memory without copying them as done with regular socket I/O,
+additionally as long as the ring contains messages no recvmsg() or poll()
+syscalls have to be issued by user-space to get more message.
+
+The TX ring is used to process messages directly from user-space memory, the
+kernel processes all messages contained in the ring using a single sendmsg()
+call.
+
+Usage overview
+--------------
+
+In order to use memory mapped netlink I/O, user-space needs three main changes:
+
+- ring setup
+- conversion of the RX path to get messages from the ring instead of recvmsg()
+- conversion of the TX path to construct messages into the ring
+
+Ring setup is done using setsockopt() to provide the ring parameters to the
+kernel, then a call to mmap() to map the ring into the processes address space:
+
+- setsockopt(fd, SOL_NETLINK, NETLINK_RX_RING, ¶ms, sizeof(params));
+- setsockopt(fd, SOL_NETLINK, NETLINK_TX_RING, ¶ms, sizeof(params));
+- ring = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0)
+
+Usage of either ring is optional, but even if only the RX ring is used the
+mapping still needs to be writable in order to update the frame status after
+processing.
+
+Conversion of the reception path involves calling poll() on the file
+descriptor, once the socket is readable the frames from the ring are
+processsed in order until no more messages are available, as indicated by
+a status word in the frame header.
+
+On kernel side, in order to make use of memory mapped I/O on receive, the
+originating netlink subsystem needs to support memory mapped I/O, otherwise
+it will use an allocated socket buffer as usual and the contents will be
+ copied to the ring on transmission, nullifying most of the performance gains.
+Dumps of kernel databases automatically support memory mapped I/O.
+
+Conversion of the transmit path involves changing message construction to
+use memory from the TX ring instead of (usually) a buffer declared on the
+stack and setting up the frame header approriately. Optionally poll() can
+be used to wait for free frames in the TX ring.
+
+Structured and definitions for using memory mapped I/O are contained in
+<linux/netlink.h>.
+
+RX and TX rings
+----------------
+
+Each ring contains a number of continuous memory blocks, containing frames of
+fixed size dependent on the parameters used for ring setup.
+
+Ring: [ block 0 ]
+ [ frame 0 ]
+ [ frame 1 ]
+ [ block 1 ]
+ [ frame 2 ]
+ [ frame 3 ]
+ ...
+ [ block n ]
+ [ frame 2 * n ]
+ [ frame 2 * n + 1 ]
+
+The blocks are only visible to the kernel, from the point of view of user-space
+the ring just contains the frames in a continuous memory zone.
+
+The ring parameters used for setting up the ring are defined as follows:
+
+struct nl_mmap_req {
+ unsigned int nm_block_size;
+ unsigned int nm_block_nr;
+ unsigned int nm_frame_size;
+ unsigned int nm_frame_nr;
+};
+
+Frames are grouped into blocks, where each block is a continuous region of memory
+and holds nm_block_size / nm_frame_size frames. The total number of frames in
+the ring is nm_frame_nr. The following invariants hold:
+
+- frames_per_block = nm_block_size / nm_frame_size
+
+- nm_frame_nr = frames_per_block * nm_block_nr
+
+Some parameters are constrained, specifically:
+
+- nm_block_size must be a multiple of the architectures memory page size.
+ The getpagesize() function can be used to get the page size.
+
+- nm_frame_size must be equal or larger to NL_MMAP_HDRLEN, IOW a frame must be
+ able to hold at least the frame header
+
+- nm_frame_size must be smaller or equal to nm_block_size
+
+- nm_frame_size must be a multiple of NL_MMAP_MSG_ALIGNMENT
+
+- nm_frame_nr must equal the actual number of frames as specified above.
+
+When the kernel can't allocate physically continuous memory for a ring block,
+it will fall back to use physically discontinuous memory. This might affect
+performance negatively, in order to avoid this the nm_frame_size parameter
+should be chosen to be as small as possible for the required frame size and
+the number of blocks should be increased instead.
+
+Ring frames
+------------
+
+Each frames contain a frame header, consisting of a synchronization word and some
+meta-data, and the message itself.
+
+Frame: [ header message ]
+
+The frame header is defined as follows:
+
+struct nl_mmap_hdr {
+ unsigned int nm_status;
+ unsigned int nm_len;
+ __u32 nm_group;
+ /* credentials */
+ __u32 nm_pid;
+ __u32 nm_uid;
+ __u32 nm_gid;
+};
+
+- nm_status is used for synchronizing processing between the kernel and user-
+ space and specifies ownership of the frame as well as the operation to perform
+
+- nm_len contains the length of the message contained in the data area
+
+- nm_group specified the destination multicast group of message
+
+- nm_pid, nm_uid and nm_gid contain the netlink pid, UID and GID of the sending
+ process. These values correspond to the data available using SOCK_PASSCRED in
+ the SCM_CREDENTIALS cmsg.
+
+The possible values in the status word are:
+
+- NL_MMAP_STATUS_UNUSED:
+ RX ring: frame belongs to the kernel and contains no message
+ for user-space. Approriate action is to invoke poll()
+ to wait for new messages.
+
+ TX ring: frame belongs to user-space and can be used for
+ message construction.
+
+- NL_MMAP_STATUS_RESERVED:
+ RX ring only: frame is currently used by the kernel for message
+ construction and contains no valid message yet.
+ Appropriate action is to invoke poll() to wait for
+ new messages.
+
+- NL_MMAP_STATUS_VALID:
+ RX ring: frame contains a valid message. Approriate action is
+ to process the message and release the frame back to
+ the kernel by setting the status to
+ NL_MMAP_STATUS_UNUSED or queue the frame by setting the
+ status to NL_MMAP_STATUS_SKIP.
+
+ TX ring: the frame contains a valid message from user-space to
+ be processed by the kernel. After completing processing
+ the kernel will release the frame back to user-space by
+ setting the status to NL_MMAP_STATUS_UNUSED.
+
+- NL_MMAP_STATUS_COPY:
+ RX ring only: a message is ready to be processed but could not be
+ stored in the ring, either because it exceeded the
+ frame size or because the originating subsystem does
+ not support memory mapped I/O. Appropriate action is
+ to invoke recvmsg() to receive the message and release
+ the frame back to the kernel by setting the status to
+ NL_MMAP_STATUS_UNUSED.
+
+- NL_MMAP_STATUS_SKIP:
+ RX ring only: user-space queued the message for later processing, but
+ processed some messages following it in the ring. The
+ kernel should skip this frame when looking for unused
+ frames.
+
+The data area of a frame begins at a offset of NL_MMAP_HDRLEN relative to the
+frame header.
+
+TX limitations
+--------------
+
+Kernel processing usually involves validation of the message received by
+user-space, then processing its contents. The kernel must assure that
+userspace is not able to modify the message contents after they have been
+validated. In order to do so, the message is copied from the ring frame
+to an allocated buffer if either of these conditions is false:
+
+- only a single mapping of the ring exists
+- the file descriptor is not shared between processes
+
+This means that for threaded programs, the kernel will fall back to copying.
+
+Example
+-------
+
+Ring setup:
+
+ unsigned int block_size = 16 * getpagesize();
+ struct nl_mmap_req req = {
+ .nm_block_size = block_size,
+ .nm_block_nr = 64,
+ .nm_frame_size = 16384,
+ .nm_frame_nr = 64 * block_size / 16384,
+ };
+ unsigned int ring_size;
+ void *rx_ring, *tx_ring;
+
+ /* Configure ring parameters */
+ if (setsockopt(fd, NETLINK_RX_RING, &req, sizeof(req)) < 0)
+ exit(1);
+ if (setsockopt(fd, NETLINK_TX_RING, &req, sizeof(req)) < 0)
+ exit(1)
+
+ /* Calculate size of each invididual ring */
+ ring_size = req.nm_block_nr * req.nm_block_size;
+
+ /* Map RX/TX rings. The TX ring is located after the RX ring */
+ rx_ring = mmap(NULL, 2 * ring_size, PROT_READ | PROT_WRITE,
+ MAP_SHARED, fd, 0);
+ if ((long)rx_ring == -1L)
+ exit(1);
+ tx_ring = rx_ring + ring_size:
+
+Message reception:
+
+This example assumes some ring parameters of the ring setup are available.
+
+ unsigned int frame_offset = 0;
+ struct nl_mmap_hdr *hdr;
+ struct nlmsghdr *nlh;
+ unsigned char buf[16384];
+ ssize_t len;
+
+ while (1) {
+ struct pollfd pfds[1];
+
+ pfds[0].fd = fd;
+ pfds[0].events = POLLIN | POLLERR;
+ pfds[0].revents = 0;
+
+ if (poll(pfds, 1, -1) < 0 && errno != -EINTR)
+ exit(1);
+
+ /* Check for errors. Error handling omitted */
+ if (pfds[0].revents & POLLERR)
+ <handle error>
+
+ /* If no new messages, poll again */
+ if (!(pfds[0].revents & POLLIN))
+ continue;
+
+ /* Process all frames */
+ while (1) {
+ /* Get next frame header */
+ hdr = rx_ring + frame_offset;
+
+ if (hdr->nm_status == NL_MMAP_STATUS_VALID) {
+ /* Regular memory mapped frame */
+ nlh = (void *)hdr + NL_MMAP_HDRLEN;
+ len = hdr->nm_len;
+
+ /* Release empty message immediately. May happen
+ * on error during message construction.
+ */
+ if (len == 0)
+ goto release;
+ } else if (hdr->nm_status == NL_MMAP_STATUS_COPY) {
+ /* Frame queued to socket receive queue */
+ len = recv(fd, buf, sizeof(buf), MSG_DONTWAIT);
+ if (len <= 0)
+ break;
+ nlh = buf;
+ } else
+ /* No more messages to process, continue polling */
+ break;
+
+ process_msg(nlh);
+release:
+ /* Release frame back to the kernel */
+ hdr->nm_status = NL_MMAP_STATUS_UNUSED;
+
+ /* Advance frame offset to next frame */
+ frame_offset = (frame_offset + frame_size) % ring_size;
+ }
+ }
+
+Message transmission:
+
+This example assumes some ring parameters of the ring setup are available.
+A single message is constructed and transmitted, to send multiple messages
+at once they would be constructed in consecutive frames before a final call
+to sendto().
+
+ unsigned int frame_offset = 0;
+ struct nl_mmap_hdr *hdr;
+ struct nlmsghdr *nlh;
+ struct sockaddr_nl addr = {
+ .nl_family = AF_NETLINK,
+ };
+
+ hdr = tx_ring + frame_offset;
+ if (hdr->nm_status != NL_MMAP_STATUS_UNUSED)
+ /* No frame available. Use poll() to avoid. */
+ exit(1);
+
+ nlh = (void *)hdr + NL_MMAP_HDRLEN;
+
+ /* Build message */
+ build_message(nlh);
+
+ /* Fill frame header: length and status need to be set */
+ hdr->nm_len = nlh->nlmsg_len;
+ hdr->nm_status = NL_MMAP_STATUS_VALID;
+
+ if (sendto(fd, NULL, 0, 0, &addr, sizeof(addr)) < 0)
+ exit(1);
+
+ /* Advance frame offset to next frame */
+ frame_offset = (frame_offset + frame_size) % ring_size;
diff --git a/Documentation/networking/nf_conntrack-sysctl.txt b/Documentation/networking/nf_conntrack-sysctl.txt
new file mode 100644
index 0000000..70da508
--- /dev/null
+++ b/Documentation/networking/nf_conntrack-sysctl.txt
@@ -0,0 +1,176 @@
+/proc/sys/net/netfilter/nf_conntrack_* Variables:
+
+nf_conntrack_acct - BOOLEAN
+ 0 - disabled (default)
+ not 0 - enabled
+
+ Enable connection tracking flow accounting. 64-bit byte and packet
+ counters per flow are added.
+
+nf_conntrack_buckets - INTEGER (read-only)
+ Size of hash table. If not specified as parameter during module
+ loading, the default size is calculated by dividing total memory
+ by 16384 to determine the number of buckets but the hash table will
+ never have fewer than 32 or more than 16384 buckets.
+
+nf_conntrack_checksum - BOOLEAN
+ 0 - disabled
+ not 0 - enabled (default)
+
+ Verify checksum of incoming packets. Packets with bad checksums are
+ in INVALID state. If this is enabled, such packets will not be
+ considered for connection tracking.
+
+nf_conntrack_count - INTEGER (read-only)
+ Number of currently allocated flow entries.
+
+nf_conntrack_events - BOOLEAN
+ 0 - disabled
+ not 0 - enabled (default)
+
+ If this option is enabled, the connection tracking code will
+ provide userspace with connection tracking events via ctnetlink.
+
+nf_conntrack_events_retry_timeout - INTEGER (seconds)
+ default 15
+
+ This option is only relevant when "reliable connection tracking
+ events" are used. Normally, ctnetlink is "lossy", that is,
+ events are normally dropped when userspace listeners can't keep up.
+
+ Userspace can request "reliable event mode". When this mode is
+ active, the conntrack will only be destroyed after the event was
+ delivered. If event delivery fails, the kernel periodically
+ re-tries to send the event to userspace.
+
+ This is the maximum interval the kernel should use when re-trying
+ to deliver the destroy event.
+
+ A higher number means there will be fewer delivery retries and it
+ will take longer for a backlog to be processed.
+
+nf_conntrack_expect_max - INTEGER
+ Maximum size of expectation table. Default value is
+ nf_conntrack_buckets / 256. Minimum is 1.
+
+nf_conntrack_frag6_high_thresh - INTEGER
+ default 262144
+
+ Maximum memory used to reassemble IPv6 fragments. When
+ nf_conntrack_frag6_high_thresh bytes of memory is allocated for this
+ purpose, the fragment handler will toss packets until
+ nf_conntrack_frag6_low_thresh is reached.
+
+nf_conntrack_frag6_low_thresh - INTEGER
+ default 196608
+
+ See nf_conntrack_frag6_low_thresh
+
+nf_conntrack_frag6_timeout - INTEGER (seconds)
+ default 60
+
+ Time to keep an IPv6 fragment in memory.
+
+nf_conntrack_generic_timeout - INTEGER (seconds)
+ default 600
+
+ Default for generic timeout. This refers to layer 4 unknown/unsupported
+ protocols.
+
+nf_conntrack_helper - BOOLEAN
+ 0 - disabled
+ not 0 - enabled (default)
+
+ Enable automatic conntrack helper assignment.
+
+nf_conntrack_icmp_timeout - INTEGER (seconds)
+ default 30
+
+ Default for ICMP timeout.
+
+nf_conntrack_icmpv6_timeout - INTEGER (seconds)
+ default 30
+
+ Default for ICMP6 timeout.
+
+nf_conntrack_log_invalid - INTEGER
+ 0 - disable (default)
+ 1 - log ICMP packets
+ 6 - log TCP packets
+ 17 - log UDP packets
+ 33 - log DCCP packets
+ 41 - log ICMPv6 packets
+ 136 - log UDPLITE packets
+ 255 - log packets of any protocol
+
+ Log invalid packets of a type specified by value.
+
+nf_conntrack_max - INTEGER
+ Size of connection tracking table. Default value is
+ nf_conntrack_buckets value * 4.
+
+nf_conntrack_tcp_be_liberal - BOOLEAN
+ 0 - disabled (default)
+ not 0 - enabled
+
+ Be conservative in what you do, be liberal in what you accept from others.
+ If it's non-zero, we mark only out of window RST segments as INVALID.
+
+nf_conntrack_tcp_loose - BOOLEAN
+ 0 - disabled
+ not 0 - enabled (default)
+
+ If it is set to zero, we disable picking up already established
+ connections.
+
+nf_conntrack_tcp_max_retrans - INTEGER
+ default 3
+
+ Maximum number of packets that can be retransmitted without
+ received an (acceptable) ACK from the destination. If this number
+ is reached, a shorter timer will be started.
+
+nf_conntrack_tcp_timeout_close - INTEGER (seconds)
+ default 10
+
+nf_conntrack_tcp_timeout_close_wait - INTEGER (seconds)
+ default 60
+
+nf_conntrack_tcp_timeout_established - INTEGER (seconds)
+ default 432000 (5 days)
+
+nf_conntrack_tcp_timeout_fin_wait - INTEGER (seconds)
+ default 120
+
+nf_conntrack_tcp_timeout_last_ack - INTEGER (seconds)
+ default 30
+
+nf_conntrack_tcp_timeout_max_retrans - INTEGER (seconds)
+ default 300
+
+nf_conntrack_tcp_timeout_syn_recv - INTEGER (seconds)
+ default 60
+
+nf_conntrack_tcp_timeout_syn_sent - INTEGER (seconds)
+ default 120
+
+nf_conntrack_tcp_timeout_time_wait - INTEGER (seconds)
+ default 120
+
+nf_conntrack_tcp_timeout_unacknowledged - INTEGER (seconds)
+ default 300
+
+nf_conntrack_timestamp - BOOLEAN
+ 0 - disabled (default)
+ not 0 - enabled
+
+ Enable connection tracking flow timestamping.
+
+nf_conntrack_udp_timeout - INTEGER (seconds)
+ default 30
+
+nf_conntrack_udp_timeout_stream2 - INTEGER (seconds)
+ default 180
+
+ This extended timeout will be used in case there is an UDP stream
+ detected.
diff --git a/Documentation/networking/operstates.txt b/Documentation/networking/operstates.txt
index 1a77a3c..9769457 100644
--- a/Documentation/networking/operstates.txt
+++ b/Documentation/networking/operstates.txt
@@ -88,6 +88,10 @@
packets. The name 'carrier' and the inversion are historical, think of
it as lower layer.
+Note that for certain kind of soft-devices, which are not managing any
+real hardware, there is possible to set this bit from userpsace.
+One should use TVL IFLA_CARRIER to do so.
+
netif_carrier_ok() can be used to query that bit.
__LINK_STATE_DORMANT, maps to IFF_DORMANT:
diff --git a/Documentation/networking/packet_mmap.txt b/Documentation/networking/packet_mmap.txt
index 94444b1..8572796 100644
--- a/Documentation/networking/packet_mmap.txt
+++ b/Documentation/networking/packet_mmap.txt
@@ -685,14 +685,265 @@
}
-------------------------------------------------------------------------------
++ AF_PACKET TPACKET_V3 example
+-------------------------------------------------------------------------------
+
+AF_PACKET's TPACKET_V3 ring buffer can be configured to use non-static frame
+sizes by doing it's own memory management. It is based on blocks where polling
+works on a per block basis instead of per ring as in TPACKET_V2 and predecessor.
+
+It is said that TPACKET_V3 brings the following benefits:
+ *) ~15 - 20% reduction in CPU-usage
+ *) ~20% increase in packet capture rate
+ *) ~2x increase in packet density
+ *) Port aggregation analysis
+ *) Non static frame size to capture entire packet payload
+
+So it seems to be a good candidate to be used with packet fanout.
+
+Minimal example code by Daniel Borkmann based on Chetan Loke's lolpcap (compile
+it with gcc -Wall -O2 blob.c, and try things like "./a.out eth0", etc.):
+
+/* Written from scratch, but kernel-to-user space API usage
+ * dissected from lolpcap:
+ * Copyright 2011, Chetan Loke <loke.chetan@gmail.com>
+ * License: GPL, version 2.0
+ */
+
+#include <stdio.h>
+#include <stdlib.h>
+#include <stdint.h>
+#include <string.h>
+#include <assert.h>
+#include <net/if.h>
+#include <arpa/inet.h>
+#include <netdb.h>
+#include <poll.h>
+#include <unistd.h>
+#include <signal.h>
+#include <inttypes.h>
+#include <sys/socket.h>
+#include <sys/mman.h>
+#include <linux/if_packet.h>
+#include <linux/if_ether.h>
+#include <linux/ip.h>
+
+#ifndef likely
+# define likely(x) __builtin_expect(!!(x), 1)
+#endif
+#ifndef unlikely
+# define unlikely(x) __builtin_expect(!!(x), 0)
+#endif
+
+struct block_desc {
+ uint32_t version;
+ uint32_t offset_to_priv;
+ struct tpacket_hdr_v1 h1;
+};
+
+struct ring {
+ struct iovec *rd;
+ uint8_t *map;
+ struct tpacket_req3 req;
+};
+
+static unsigned long packets_total = 0, bytes_total = 0;
+static sig_atomic_t sigint = 0;
+
+static void sighandler(int num)
+{
+ sigint = 1;
+}
+
+static int setup_socket(struct ring *ring, char *netdev)
+{
+ int err, i, fd, v = TPACKET_V3;
+ struct sockaddr_ll ll;
+ unsigned int blocksiz = 1 << 22, framesiz = 1 << 11;
+ unsigned int blocknum = 64;
+
+ fd = socket(AF_PACKET, SOCK_RAW, htons(ETH_P_ALL));
+ if (fd < 0) {
+ perror("socket");
+ exit(1);
+ }
+
+ err = setsockopt(fd, SOL_PACKET, PACKET_VERSION, &v, sizeof(v));
+ if (err < 0) {
+ perror("setsockopt");
+ exit(1);
+ }
+
+ memset(&ring->req, 0, sizeof(ring->req));
+ ring->req.tp_block_size = blocksiz;
+ ring->req.tp_frame_size = framesiz;
+ ring->req.tp_block_nr = blocknum;
+ ring->req.tp_frame_nr = (blocksiz * blocknum) / framesiz;
+ ring->req.tp_retire_blk_tov = 60;
+ ring->req.tp_feature_req_word = TP_FT_REQ_FILL_RXHASH;
+
+ err = setsockopt(fd, SOL_PACKET, PACKET_RX_RING, &ring->req,
+ sizeof(ring->req));
+ if (err < 0) {
+ perror("setsockopt");
+ exit(1);
+ }
+
+ ring->map = mmap(NULL, ring->req.tp_block_size * ring->req.tp_block_nr,
+ PROT_READ | PROT_WRITE, MAP_SHARED | MAP_LOCKED, fd, 0);
+ if (ring->map == MAP_FAILED) {
+ perror("mmap");
+ exit(1);
+ }
+
+ ring->rd = malloc(ring->req.tp_block_nr * sizeof(*ring->rd));
+ assert(ring->rd);
+ for (i = 0; i < ring->req.tp_block_nr; ++i) {
+ ring->rd[i].iov_base = ring->map + (i * ring->req.tp_block_size);
+ ring->rd[i].iov_len = ring->req.tp_block_size;
+ }
+
+ memset(&ll, 0, sizeof(ll));
+ ll.sll_family = PF_PACKET;
+ ll.sll_protocol = htons(ETH_P_ALL);
+ ll.sll_ifindex = if_nametoindex(netdev);
+ ll.sll_hatype = 0;
+ ll.sll_pkttype = 0;
+ ll.sll_halen = 0;
+
+ err = bind(fd, (struct sockaddr *) &ll, sizeof(ll));
+ if (err < 0) {
+ perror("bind");
+ exit(1);
+ }
+
+ return fd;
+}
+
+static void display(struct tpacket3_hdr *ppd)
+{
+ struct ethhdr *eth = (struct ethhdr *) ((uint8_t *) ppd + ppd->tp_mac);
+ struct iphdr *ip = (struct iphdr *) ((uint8_t *) eth + ETH_HLEN);
+
+ if (eth->h_proto == htons(ETH_P_IP)) {
+ struct sockaddr_in ss, sd;
+ char sbuff[NI_MAXHOST], dbuff[NI_MAXHOST];
+
+ memset(&ss, 0, sizeof(ss));
+ ss.sin_family = PF_INET;
+ ss.sin_addr.s_addr = ip->saddr;
+ getnameinfo((struct sockaddr *) &ss, sizeof(ss),
+ sbuff, sizeof(sbuff), NULL, 0, NI_NUMERICHOST);
+
+ memset(&sd, 0, sizeof(sd));
+ sd.sin_family = PF_INET;
+ sd.sin_addr.s_addr = ip->daddr;
+ getnameinfo((struct sockaddr *) &sd, sizeof(sd),
+ dbuff, sizeof(dbuff), NULL, 0, NI_NUMERICHOST);
+
+ printf("%s -> %s, ", sbuff, dbuff);
+ }
+
+ printf("rxhash: 0x%x\n", ppd->hv1.tp_rxhash);
+}
+
+static void walk_block(struct block_desc *pbd, const int block_num)
+{
+ int num_pkts = pbd->h1.num_pkts, i;
+ unsigned long bytes = 0;
+ struct tpacket3_hdr *ppd;
+
+ ppd = (struct tpacket3_hdr *) ((uint8_t *) pbd +
+ pbd->h1.offset_to_first_pkt);
+ for (i = 0; i < num_pkts; ++i) {
+ bytes += ppd->tp_snaplen;
+ display(ppd);
+
+ ppd = (struct tpacket3_hdr *) ((uint8_t *) ppd +
+ ppd->tp_next_offset);
+ }
+
+ packets_total += num_pkts;
+ bytes_total += bytes;
+}
+
+static void flush_block(struct block_desc *pbd)
+{
+ pbd->h1.block_status = TP_STATUS_KERNEL;
+}
+
+static void teardown_socket(struct ring *ring, int fd)
+{
+ munmap(ring->map, ring->req.tp_block_size * ring->req.tp_block_nr);
+ free(ring->rd);
+ close(fd);
+}
+
+int main(int argc, char **argp)
+{
+ int fd, err;
+ socklen_t len;
+ struct ring ring;
+ struct pollfd pfd;
+ unsigned int block_num = 0, blocks = 64;
+ struct block_desc *pbd;
+ struct tpacket_stats_v3 stats;
+
+ if (argc != 2) {
+ fprintf(stderr, "Usage: %s INTERFACE\n", argp[0]);
+ return EXIT_FAILURE;
+ }
+
+ signal(SIGINT, sighandler);
+
+ memset(&ring, 0, sizeof(ring));
+ fd = setup_socket(&ring, argp[argc - 1]);
+ assert(fd > 0);
+
+ memset(&pfd, 0, sizeof(pfd));
+ pfd.fd = fd;
+ pfd.events = POLLIN | POLLERR;
+ pfd.revents = 0;
+
+ while (likely(!sigint)) {
+ pbd = (struct block_desc *) ring.rd[block_num].iov_base;
+
+ if ((pbd->h1.block_status & TP_STATUS_USER) == 0) {
+ poll(&pfd, 1, -1);
+ continue;
+ }
+
+ walk_block(pbd, block_num);
+ flush_block(pbd);
+ block_num = (block_num + 1) % blocks;
+ }
+
+ len = sizeof(stats);
+ err = getsockopt(fd, SOL_PACKET, PACKET_STATISTICS, &stats, &len);
+ if (err < 0) {
+ perror("getsockopt");
+ exit(1);
+ }
+
+ fflush(stdout);
+ printf("\nReceived %u packets, %lu bytes, %u dropped, freeze_q_cnt: %u\n",
+ stats.tp_packets, bytes_total, stats.tp_drops,
+ stats.tp_freeze_q_cnt);
+
+ teardown_socket(&ring, fd);
+ return 0;
+}
+
+-------------------------------------------------------------------------------
+ PACKET_TIMESTAMP
-------------------------------------------------------------------------------
The PACKET_TIMESTAMP setting determines the source of the timestamp in
-the packet meta information. If your NIC is capable of timestamping
-packets in hardware, you can request those hardware timestamps to used.
-Note: you may need to enable the generation of hardware timestamps with
-SIOCSHWTSTAMP.
+the packet meta information for mmap(2)ed RX_RING and TX_RINGs. If your
+NIC is capable of timestamping packets in hardware, you can request those
+hardware timestamps to be used. Note: you may need to enable the generation
+of hardware timestamps with SIOCSHWTSTAMP (see related information from
+Documentation/networking/timestamping.txt).
PACKET_TIMESTAMP accepts the same integer bit field as
SO_TIMESTAMPING. However, only the SOF_TIMESTAMPING_SYS_HARDWARE
@@ -704,8 +955,36 @@
req |= SOF_TIMESTAMPING_SYS_HARDWARE;
setsockopt(fd, SOL_PACKET, PACKET_TIMESTAMP, (void *) &req, sizeof(req))
-If PACKET_TIMESTAMP is not set, a software timestamp generated inside
-the networking stack is used (the behavior before this setting was added).
+For the mmap(2)ed ring buffers, such timestamps are stored in the
+tpacket{,2,3}_hdr structure's tp_sec and tp_{n,u}sec members. To determine
+what kind of timestamp has been reported, the tp_status field is binary |'ed
+with the following possible bits ...
+
+ TP_STATUS_TS_SYS_HARDWARE
+ TP_STATUS_TS_RAW_HARDWARE
+ TP_STATUS_TS_SOFTWARE
+
+... that are equivalent to its SOF_TIMESTAMPING_* counterparts. For the
+RX_RING, if none of those 3 are set (i.e. PACKET_TIMESTAMP is not set),
+then this means that a software fallback was invoked *within* PF_PACKET's
+processing code (less precise).
+
+Getting timestamps for the TX_RING works as follows: i) fill the ring frames,
+ii) call sendto() e.g. in blocking mode, iii) wait for status of relevant
+frames to be updated resp. the frame handed over to the application, iv) walk
+through the frames to pick up the individual hw/sw timestamps.
+
+Only (!) if transmit timestamping is enabled, then these bits are combined
+with binary | with TP_STATUS_AVAILABLE, so you must check for that in your
+application (e.g. !(tp_status & (TP_STATUS_SEND_REQUEST | TP_STATUS_SENDING))
+in a first step to see if the frame belongs to the application, and then
+one can extract the type of timestamp in a second step from tp_status)!
+
+If you don't care about them, thus having it disabled, checking for
+TP_STATUS_AVAILABLE resp. TP_STATUS_WRONG_FORMAT is sufficient. If in the
+TX_RING part only TP_STATUS_AVAILABLE is set, then the tp_sec and tp_{n,u}sec
+members do not contain a valid value. For TX_RINGs, by default no timestamp
+is generated!
See include/linux/net_tstamp.h and Documentation/networking/timestamping
for more information on hardware timestamps.
diff --git a/Documentation/networking/phy.txt b/Documentation/networking/phy.txt
index 95e5f59..d5b1a39 100644
--- a/Documentation/networking/phy.txt
+++ b/Documentation/networking/phy.txt
@@ -103,7 +103,7 @@
Now, to connect, just call this function:
- phydev = phy_connect(dev, phy_name, &adjust_link, flags, interface);
+ phydev = phy_connect(dev, phy_name, &adjust_link, interface);
phydev is a pointer to the phy_device structure which represents the PHY. If
phy_connect is successful, it will return the pointer. dev, here, is the
@@ -113,7 +113,9 @@
current state, though the PHY will not yet be truly operational at this
point.
- flags is a u32 which can optionally contain phy-specific flags.
+ PHY-specific flags should be set in phydev->dev_flags prior to the call
+ to phy_connect() such that the underlying PHY driver can check for flags
+ and perform specific operations based on them.
This is useful if the system has put hardware restrictions on
the PHY/controller, of which the PHY needs to be aware.
@@ -185,11 +187,10 @@
start, or disables then frees them for stop.
struct phy_device * phy_attach(struct net_device *dev, const char *phy_id,
- u32 flags, phy_interface_t interface);
+ phy_interface_t interface);
Attaches a network device to a particular PHY, binding the PHY to a generic
- driver if none was found during bus initialization. Passes in
- any phy-specific flags as needed.
+ driver if none was found during bus initialization.
int phy_start_aneg(struct phy_device *phydev);
diff --git a/Documentation/networking/scaling.txt b/Documentation/networking/scaling.txt
index 579994a..ca6977f 100644
--- a/Documentation/networking/scaling.txt
+++ b/Documentation/networking/scaling.txt
@@ -163,6 +163,64 @@
RPS might be beneficial if the rps_cpus for each queue are the ones that
share the same memory domain as the interrupting CPU for that queue.
+==== RPS Flow Limit
+
+RPS scales kernel receive processing across CPUs without introducing
+reordering. The trade-off to sending all packets from the same flow
+to the same CPU is CPU load imbalance if flows vary in packet rate.
+In the extreme case a single flow dominates traffic. Especially on
+common server workloads with many concurrent connections, such
+behavior indicates a problem such as a misconfiguration or spoofed
+source Denial of Service attack.
+
+Flow Limit is an optional RPS feature that prioritizes small flows
+during CPU contention by dropping packets from large flows slightly
+ahead of those from small flows. It is active only when an RPS or RFS
+destination CPU approaches saturation. Once a CPU's input packet
+queue exceeds half the maximum queue length (as set by sysctl
+net.core.netdev_max_backlog), the kernel starts a per-flow packet
+count over the last 256 packets. If a flow exceeds a set ratio (by
+default, half) of these packets when a new packet arrives, then the
+new packet is dropped. Packets from other flows are still only
+dropped once the input packet queue reaches netdev_max_backlog.
+No packets are dropped when the input packet queue length is below
+the threshold, so flow limit does not sever connections outright:
+even large flows maintain connectivity.
+
+== Interface
+
+Flow limit is compiled in by default (CONFIG_NET_FLOW_LIMIT), but not
+turned on. It is implemented for each CPU independently (to avoid lock
+and cache contention) and toggled per CPU by setting the relevant bit
+in sysctl net.core.flow_limit_cpu_bitmap. It exposes the same CPU
+bitmap interface as rps_cpus (see above) when called from procfs:
+
+ /proc/sys/net/core/flow_limit_cpu_bitmap
+
+Per-flow rate is calculated by hashing each packet into a hashtable
+bucket and incrementing a per-bucket counter. The hash function is
+the same that selects a CPU in RPS, but as the number of buckets can
+be much larger than the number of CPUs, flow limit has finer-grained
+identification of large flows and fewer false positives. The default
+table has 4096 buckets. This value can be modified through sysctl
+
+ net.core.flow_limit_table_len
+
+The value is only consulted when a new table is allocated. Modifying
+it does not update active tables.
+
+== Suggested Configuration
+
+Flow limit is useful on systems with many concurrent connections,
+where a single connection taking up 50% of a CPU indicates a problem.
+In such environments, enable the feature on all CPUs that handle
+network rx interrupts (as set in /proc/irq/N/smp_affinity).
+
+The feature depends on the input packet queue length to exceed
+the flow limit threshold (50%) + the flow history length (256).
+Setting net.core.netdev_max_backlog to either 1000 or 10000
+performed well in experiments.
+
RFS: Receive Flow Steering
==========================
diff --git a/Documentation/networking/stmmac.txt b/Documentation/networking/stmmac.txt
index f9fa6db..654d2e5 100644
--- a/Documentation/networking/stmmac.txt
+++ b/Documentation/networking/stmmac.txt
@@ -1,6 +1,6 @@
STMicroelectronics 10/100/1000 Synopsys Ethernet driver
-Copyright (C) 2007-2010 STMicroelectronics Ltd
+Copyright (C) 2007-2013 STMicroelectronics Ltd
Author: Giuseppe Cavallaro <peppe.cavallaro@st.com>
This is the driver for the MAC 10/100/1000 on-chip Ethernet controllers
@@ -10,7 +10,7 @@
(i.e. 7xxx/5xxx SoCs), SPEAr (arm), Loongson1B (mips) and XLINX XC2V3000
FF1152AMT0221 D1215994A VIRTEX FPGA board.
-DWC Ether MAC 10/100/1000 Universal version 3.60a (and older) and DWC Ether
+DWC Ether MAC 10/100/1000 Universal version 3.70a (and older) and DWC Ether
MAC 10/100 Universal version 4.0 have been used for developing this driver.
This driver supports both the platform bus and PCI.
@@ -32,6 +32,8 @@
watchdog: transmit timeout (in milliseconds);
flow_ctrl: Flow control ability [on/off];
pause: Flow Control Pause Time;
+ eee_timer: tx EEE timer;
+ chain_mode: select chain mode instead of ring.
3) Command line options
Driver parameters can be also passed in command line by using:
@@ -164,12 +166,12 @@
o bus_setup: perform HW setup of the bus. For example, on some ST platforms
this field is used to configure the AMBA bridge to generate more
efficient STBus traffic.
- o init/exit: callbacks used for calling a custom initialisation;
+ o init/exit: callbacks used for calling a custom initialization;
this is sometime necessary on some platforms (e.g. ST boxes)
where the HW needs to have set some PIO lines or system cfg
registers.
o custom_cfg/custom_data: this is a custom configuration that can be passed
- while initialising the resources.
+ while initializing the resources.
o bsp_priv: another private poiter.
For MDIO bus The we have:
@@ -273,6 +275,8 @@
o norm_desc.c: functions for handling normal descriptors;
o chain_mode.c/ring_mode.c:: functions to manage RING/CHAINED modes;
o mmc_core.c/mmc.h: Management MAC Counters;
+ o stmmac_hwtstamp.c: HW timestamp support for PTP
+ o stmmac_ptp.c: PTP 1588 clock
5) Debug Information
@@ -326,6 +330,35 @@
that enable and disable the LPI mode when there is nothing to be
transmitted.
-7) TODO:
+7) Extended descriptors
+The extended descriptors give us information about the receive Ethernet payload
+when it is carrying PTP packets or TCP/UDP/ICMP over IP.
+These are not available on GMAC Synopsys chips older than the 3.50.
+At probe time the driver will decide if these can be actually used.
+This support also is mandatory for PTPv2 because the extra descriptors 6 and 7
+are used for saving the hardware timestamps.
+
+8) Precision Time Protocol (PTP)
+The driver supports the IEEE 1588-2002, Precision Time Protocol (PTP),
+which enables precise synchronization of clocks in measurement and
+control systems implemented with technologies such as network
+communication.
+
+In addition to the basic timestamp features mentioned in IEEE 1588-2002
+Timestamps, new GMAC cores support the advanced timestamp features.
+IEEE 1588-2008 that can be enabled when configure the Kernel.
+
+9) SGMII/RGMII supports
+New GMAC devices provide own way to manage RGMII/SGMII.
+This information is available at run-time by looking at the
+HW capability register. This means that the stmmac can manage
+auto-negotiation and link status w/o using the PHYLIB stuff
+In fact, the HW provides a subset of extended registers to
+restart the ANE, verify Full/Half duplex mode and Speed.
+Also thanks to these registers it is possible to look at the
+Auto-negotiated Link Parter Ability.
+
+10) TODO:
o XGMAC is not supported.
- o Add the PTP - precision time protocol
+ o Complete the TBI & RTBI support.
+ o extened VLAN support for 3.70a SYNP GMAC.
diff --git a/Documentation/networking/tuntap.txt b/Documentation/networking/tuntap.txt
index c0aab98..949d5dc 100644
--- a/Documentation/networking/tuntap.txt
+++ b/Documentation/networking/tuntap.txt
@@ -105,6 +105,83 @@
Proto [2 bytes]
Raw protocol(IP, IPv6, etc) frame.
+ 3.3 Multiqueue tuntap interface:
+
+ From version 3.8, Linux supports multiqueue tuntap which can uses multiple
+ file descriptors (queues) to parallelize packets sending or receiving. The
+ device allocation is the same as before, and if user wants to create multiple
+ queues, TUNSETIFF with the same device name must be called many times with
+ IFF_MULTI_QUEUE flag.
+
+ char *dev should be the name of the device, queues is the number of queues to
+ be created, fds is used to store and return the file descriptors (queues)
+ created to the caller. Each file descriptor were served as the interface of a
+ queue which could be accessed by userspace.
+
+ #include <linux/if.h>
+ #include <linux/if_tun.h>
+
+ int tun_alloc_mq(char *dev, int queues, int *fds)
+ {
+ struct ifreq ifr;
+ int fd, err, i;
+
+ if (!dev)
+ return -1;
+
+ memset(&ifr, 0, sizeof(ifr));
+ /* Flags: IFF_TUN - TUN device (no Ethernet headers)
+ * IFF_TAP - TAP device
+ *
+ * IFF_NO_PI - Do not provide packet information
+ * IFF_MULTI_QUEUE - Create a queue of multiqueue device
+ */
+ ifr.ifr_flags = IFF_TAP | IFF_NO_PI | IFF_MULTI_QUEUE;
+ strcpy(ifr.ifr_name, dev);
+
+ for (i = 0; i < queues; i++) {
+ if ((fd = open("/dev/net/tun", O_RDWR)) < 0)
+ goto err;
+ err = ioctl(fd, TUNSETIFF, (void *)&ifr);
+ if (err) {
+ close(fd);
+ goto err;
+ }
+ fds[i] = fd;
+ }
+
+ return 0;
+ err:
+ for (--i; i >= 0; i--)
+ close(fds[i]);
+ return err;
+ }
+
+ A new ioctl(TUNSETQUEUE) were introduced to enable or disable a queue. When
+ calling it with IFF_DETACH_QUEUE flag, the queue were disabled. And when
+ calling it with IFF_ATTACH_QUEUE flag, the queue were enabled. The queue were
+ enabled by default after it was created through TUNSETIFF.
+
+ fd is the file descriptor (queue) that we want to enable or disable, when
+ enable is true we enable it, otherwise we disable it
+
+ #include <linux/if.h>
+ #include <linux/if_tun.h>
+
+ int tun_set_queue(int fd, int enable)
+ {
+ struct ifreq ifr;
+
+ memset(&ifr, 0, sizeof(ifr));
+
+ if (enable)
+ ifr.ifr_flags = IFF_ATTACH_QUEUE;
+ else
+ ifr.ifr_flags = IFF_DETACH_QUEUE;
+
+ return ioctl(fd, TUNSETQUEUE, (void *)&ifr);
+ }
+
Universal TUN/TAP device driver Frequently Asked Question.
1. What platforms are supported by TUN/TAP driver ?
diff --git a/Documentation/networking/vortex.txt b/Documentation/networking/vortex.txt
index b4038ff..9a8041d 100644
--- a/Documentation/networking/vortex.txt
+++ b/Documentation/networking/vortex.txt
@@ -359,7 +359,7 @@
- OK, it's a driver problem.
You need to generate a report. Typically this is an email to the
- maintainer and/or linux-net@vger.kernel.org. The maintainer's
+ maintainer and/or netdev@vger.kernel.org. The maintainer's
email address will be in the driver source or in the MAINTAINERS file.
- The contents of your report will vary a lot depending upon the
diff --git a/Documentation/nfc/nfc-hci.txt b/Documentation/nfc/nfc-hci.txt
index 89a339c..0686c9e 100644
--- a/Documentation/nfc/nfc-hci.txt
+++ b/Documentation/nfc/nfc-hci.txt
@@ -17,10 +17,12 @@
HCI registers as an nfc device with NFC Core. Requests coming from userspace are
routed through netlink sockets to NFC Core and then to HCI. From this point,
they are translated in a sequence of HCI commands sent to the HCI layer in the
-host controller (the chip). The sending context blocks while waiting for the
-response to arrive.
+host controller (the chip). Commands can be executed synchronously (the sending
+context blocks waiting for response) or asynchronously (the response is returned
+from HCI Rx context).
HCI events can also be received from the host controller. They will be handled
-and a translation will be forwarded to NFC Core as needed.
+and a translation will be forwarded to NFC Core as needed. There are hooks to
+let the HCI driver handle proprietary events or override standard behavior.
HCI uses 2 execution contexts:
- one for executing commands : nfc_hci_msg_tx_work(). Only one command
can be executing at any given moment.
@@ -33,6 +35,8 @@
support proprietary gates. This is the reason why the driver will pass a list
of proprietary gates that must be part of the session. HCI will ensure all
those gates have pipes connected when the hci device is set up.
+In case the chip supports pre-opened gates and pseudo-static pipes, the driver
+can pass that information to HCI core.
HCI Gates and Pipes
-------------------
@@ -46,6 +50,13 @@
Driver interface
----------------
+A driver is generally written in two parts : the physical link management and
+the HCI management. This makes it easier to maintain a driver for a chip that
+can be connected using various phy (i2c, spi, ...)
+
+HCI Management
+--------------
+
A driver would normally register itself with HCI and provide the following
entry points:
@@ -53,58 +64,113 @@
int (*open)(struct nfc_hci_dev *hdev);
void (*close)(struct nfc_hci_dev *hdev);
int (*hci_ready) (struct nfc_hci_dev *hdev);
- int (*xmit)(struct nfc_hci_dev *hdev, struct sk_buff *skb);
- int (*start_poll)(struct nfc_hci_dev *hdev, u32 protocols);
- int (*target_from_gate)(struct nfc_hci_dev *hdev, u8 gate,
- struct nfc_target *target);
+ int (*xmit) (struct nfc_hci_dev *hdev, struct sk_buff *skb);
+ int (*start_poll) (struct nfc_hci_dev *hdev,
+ u32 im_protocols, u32 tm_protocols);
+ int (*dep_link_up)(struct nfc_hci_dev *hdev, struct nfc_target *target,
+ u8 comm_mode, u8 *gb, size_t gb_len);
+ int (*dep_link_down)(struct nfc_hci_dev *hdev);
+ int (*target_from_gate) (struct nfc_hci_dev *hdev, u8 gate,
+ struct nfc_target *target);
int (*complete_target_discovered) (struct nfc_hci_dev *hdev, u8 gate,
struct nfc_target *target);
- int (*data_exchange) (struct nfc_hci_dev *hdev,
- struct nfc_target *target,
- struct sk_buff *skb, struct sk_buff **res_skb);
+ int (*im_transceive) (struct nfc_hci_dev *hdev,
+ struct nfc_target *target, struct sk_buff *skb,
+ data_exchange_cb_t cb, void *cb_context);
+ int (*tm_send)(struct nfc_hci_dev *hdev, struct sk_buff *skb);
int (*check_presence)(struct nfc_hci_dev *hdev,
struct nfc_target *target);
+ int (*event_received)(struct nfc_hci_dev *hdev, u8 gate, u8 event,
+ struct sk_buff *skb);
};
- open() and close() shall turn the hardware on and off.
- hci_ready() is an optional entry point that is called right after the hci
session has been set up. The driver can use it to do additional initialization
that must be performed using HCI commands.
-- xmit() shall simply write a frame to the chip.
+- xmit() shall simply write a frame to the physical link.
- start_poll() is an optional entrypoint that shall set the hardware in polling
mode. This must be implemented only if the hardware uses proprietary gates or a
mechanism slightly different from the HCI standard.
+- dep_link_up() is called after a p2p target has been detected, to finish
+the p2p connection setup with hardware parameters that need to be passed back
+to nfc core.
+- dep_link_down() is called to bring the p2p link down.
- target_from_gate() is an optional entrypoint to return the nfc protocols
corresponding to a proprietary gate.
- complete_target_discovered() is an optional entry point to let the driver
perform additional proprietary processing necessary to auto activate the
discovered target.
-- data_exchange() must be implemented by the driver if proprietary HCI commands
+- im_transceive() must be implemented by the driver if proprietary HCI commands
are required to send data to the tag. Some tag types will require custom
commands, others can be written to using the standard HCI commands. The driver
can check the tag type and either do proprietary processing, or return 1 to ask
-for standard processing.
+for standard processing. The data exchange command itself must be sent
+asynchronously.
+- tm_send() is called to send data in the case of a p2p connection
- check_presence() is an optional entry point that will be called regularly
by the core to check that an activated tag is still in the field. If this is
not implemented, the core will not be able to push tag_lost events to the user
space
+- event_received() is called to handle an event coming from the chip. Driver
+can handle the event or return 1 to let HCI attempt standard processing.
On the rx path, the driver is responsible to push incoming HCP frames to HCI
using nfc_hci_recv_frame(). HCI will take care of re-aggregation and handling
This must be done from a context that can sleep.
-SHDLC
------
+PHY Management
+--------------
-Most chips use shdlc to ensure integrity and delivery ordering of the HCP
-frames between the host controller (the chip) and hosts (entities connected
-to the chip, like the cpu). In order to simplify writing the driver, an shdlc
-layer is available for use by the driver.
-When used, the driver actually registers with shdlc, and shdlc will register
-with HCI. HCI sees shdlc as the driver and thus send its HCP frames
-through shdlc->xmit.
-SHDLC adds a new execution context (nfc_shdlc_sm_work()) to run its state
-machine and handle both its rx and tx path.
+The physical link (i2c, ...) management is defined by the following struture:
+
+struct nfc_phy_ops {
+ int (*write)(void *dev_id, struct sk_buff *skb);
+ int (*enable)(void *dev_id);
+ void (*disable)(void *dev_id);
+};
+
+enable(): turn the phy on (power on), make it ready to transfer data
+disable(): turn the phy off
+write(): Send a data frame to the chip. Note that to enable higher
+layers such as an llc to store the frame for re-emission, this function must
+not alter the skb. It must also not return a positive result (return 0 for
+success, negative for failure).
+
+Data coming from the chip shall be sent directly to nfc_hci_recv_frame().
+
+LLC
+---
+
+Communication between the CPU and the chip often requires some link layer
+protocol. Those are isolated as modules managed by the HCI layer. There are
+currently two modules : nop (raw transfert) and shdlc.
+A new llc must implement the following functions:
+
+struct nfc_llc_ops {
+ void *(*init) (struct nfc_hci_dev *hdev, xmit_to_drv_t xmit_to_drv,
+ rcv_to_hci_t rcv_to_hci, int tx_headroom,
+ int tx_tailroom, int *rx_headroom, int *rx_tailroom,
+ llc_failure_t llc_failure);
+ void (*deinit) (struct nfc_llc *llc);
+ int (*start) (struct nfc_llc *llc);
+ int (*stop) (struct nfc_llc *llc);
+ void (*rcv_from_drv) (struct nfc_llc *llc, struct sk_buff *skb);
+ int (*xmit_from_hci) (struct nfc_llc *llc, struct sk_buff *skb);
+};
+
+- init() : allocate and init your private storage
+- deinit() : cleanup
+- start() : establish the logical connection
+- stop () : terminate the logical connection
+- rcv_from_drv() : handle data coming from the chip, going to HCI
+- xmit_from_hci() : handle data sent by HCI, going to the chip
+
+The llc must be registered with nfc before it can be used. Do that by
+calling nfc_llc_register(const char *name, struct nfc_llc_ops *ops);
+
+Again, note that the llc does not handle the physical link. It is thus very
+easy to mix any physical link with any llc for a given chip driver.
Included Drivers
----------------
@@ -117,10 +183,12 @@
The execution contexts are the following:
- IRQ handler (IRQH):
-fast, cannot sleep. stores incoming frames into an shdlc rx queue
+fast, cannot sleep. sends incoming frames to HCI where they are passed to
+the current llc. In case of shdlc, the frame is queued in shdlc rx queue.
- SHDLC State Machine worker (SMW)
-handles shdlc rx & tx queues. Dispatches HCI cmd responses.
+Only when llc_shdlc is used: handles shdlc rx & tx queues.
+Dispatches HCI cmd responses.
- HCI Tx Cmd worker (MSGTXWQ)
Serializes execution of HCI commands. Completes execution in case of response
@@ -166,6 +234,15 @@
callback that was provided by nfc_hci_msg_tx_work() when it sent the command.
The completion callback will then wake the syscall context.
+It is also possible to execute the command asynchronously using this API:
+
+static int nfc_hci_execute_cmd_async(struct nfc_hci_dev *hdev, u8 pipe, u8 cmd,
+ const u8 *param, size_t param_len,
+ data_exchange_cb_t cb, void *cb_context)
+
+The workflow is the same, except that the API call returns immediately, and
+the callback will be called with the result from the SMW context.
+
Workflow receiving an HCI event or command
------------------------------------------
diff --git a/Documentation/nfc/nfc-pn544.txt b/Documentation/nfc/nfc-pn544.txt
index 2fcac9f..b36ca14 100644
--- a/Documentation/nfc/nfc-pn544.txt
+++ b/Documentation/nfc/nfc-pn544.txt
@@ -1,32 +1,15 @@
Kernel driver for the NXP Semiconductors PN544 Near Field
Communication chip
-Author: Jari Vanhala
-Contact: Matti Aaltonen (matti.j.aaltonen at nokia.com)
-
General
-------
The PN544 is an integrated transmission module for contactless
communication. The driver goes under drives/nfc/ and is compiled as a
-module named "pn544". It registers a misc device and creates a device
-file named "/dev/pn544".
+module named "pn544".
Host Interfaces: I2C, SPI and HSU, this driver supports currently only I2C.
-The Interface
--------------
-
-The driver offers a sysfs interface for a hardware test and an IOCTL
-interface for selecting between two operating modes. There are read,
-write and poll functions for transferring messages. The two operating
-modes are the normal (HCI) mode and the firmware update mode.
-
-PN544 is controlled by sending messages from the userspace to the
-chip. The main function of the driver is just to pass those messages
-without caring about the message content.
-
-
Protocols
---------
@@ -47,68 +30,3 @@
For the ETSI HCI specification see
http://www.etsi.org/WebSite/Technologies/ProtocolSpecification.aspx
-
-The Hardware Test
------------------
-
-The idea of the test is that it can performed by reading from the
-corresponding sysfs file. The test is implemented in the board file
-and it should test that PN544 can be put into the firmware update
-mode. If the test is not implemented the sysfs file does not get
-created.
-
-Example:
-> cat /sys/module/pn544/drivers/i2c\:pn544/3-002b/nfc_test
-1
-
-Normal Operation
-----------------
-
-PN544 is powered up when the device file is opened, otherwise it's
-turned off. Only one instance can use the device at a time.
-
-Userspace applications control PN544 with HCI messages. The hardware
-sends an interrupt when data is available for reading. Data is
-physically read when the read function is called by a userspace
-application. Poll() checks the read interrupt state. Configuration and
-self testing are also done from the userspace using read and write.
-
-Example platform data:
-
-static int rx71_pn544_nfc_request_resources(struct i2c_client *client)
-{
- /* Get and setup the HW resources for the device */
-}
-
-static void rx71_pn544_nfc_free_resources(void)
-{
- /* Release the HW resources */
-}
-
-static void rx71_pn544_nfc_enable(int fw)
-{
- /* Turn the device on */
-}
-
-static int rx71_pn544_nfc_test(void)
-{
- /*
- * Put the device into the FW update mode
- * and then back to the normal mode.
- * Check the behavior and return one on success,
- * zero on failure.
- */
-}
-
-static void rx71_pn544_nfc_disable(void)
-{
- /* turn the power off */
-}
-
-static struct pn544_nfc_platform_data rx71_nfc_data = {
- .request_resources = rx71_pn544_nfc_request_resources,
- .free_resources = rx71_pn544_nfc_free_resources,
- .enable = rx71_pn544_nfc_enable,
- .test = rx71_pn544_nfc_test,
- .disable = rx71_pn544_nfc_disable,
-};
diff --git a/Documentation/parisc/registers b/Documentation/parisc/registers
index dd3cadd..10c7d17 100644
--- a/Documentation/parisc/registers
+++ b/Documentation/parisc/registers
@@ -78,6 +78,14 @@
TOC enable bit 1
=========================================================================
+
+The PA-RISC architecture defines 7 registers as "shadow registers".
+Those are used in RETURN FROM INTERRUPTION AND RESTORE instruction to reduce
+the state save and restore time by eliminating the need for general register
+(GR) saves and restores in interruption handlers.
+Shadow registers are the GRs 1, 8, 9, 16, 17, 24, and 25.
+
+=========================================================================
Register usage notes, originally from John Marvin, with some additional
notes from Randolph Chung.
diff --git a/Documentation/pinctrl.txt b/Documentation/pinctrl.txt
index da40efb..052e13a 100644
--- a/Documentation/pinctrl.txt
+++ b/Documentation/pinctrl.txt
@@ -203,15 +203,8 @@
stable value when nothing is driving the rail it is connected to, or when it's
unconnected.
-Pin configuration can be programmed either using the explicit APIs described
-immediately below, or by adding configuration entries into the mapping table;
-see section "Board/machine configuration" below.
-
-For example, a platform may do the following to pull up a pin to VDD:
-
-#include <linux/pinctrl/consumer.h>
-
-ret = pin_config_set("foo-dev", "FOO_GPIO_PIN", PLATFORM_X_PULL_UP);
+Pin configuration can be programmed by adding configuration entries into the
+mapping table; see section "Board/machine configuration" below.
The format and meaning of the configuration parameter, PLATFORM_X_PULL_UP
above, is entirely defined by the pin controller driver.
@@ -298,7 +291,7 @@
controller we need a mapping so that the pin control subsystem can figure out
which pin controller handles control of a certain GPIO pin. Since a single
pin controller may be muxing several GPIO ranges (typically SoCs that have
-one set of pins but internally several GPIO silicon blocks, each modeled as
+one set of pins but internally several GPIO silicon blocks, each modelled as
a struct gpio_chip) any number of GPIO ranges can be added to a pin controller
instance like this:
@@ -350,6 +343,23 @@
- GPIO range : [48 .. 55]
- pin range : [64 .. 71]
+The above examples assume the mapping between the GPIOs and pins is
+linear. If the mapping is sparse or haphazard, an array of arbitrary pin
+numbers can be encoded in the range like this:
+
+static const unsigned range_pins[] = { 14, 1, 22, 17, 10, 8, 6, 2 };
+
+static struct pinctrl_gpio_range gpio_range = {
+ .name = "chip",
+ .id = 0,
+ .base = 32,
+ .pins = &range_pins,
+ .npins = ARRAY_SIZE(range_pins),
+ .gc = &chip;
+};
+
+In this case the pin_base property will be ignored.
+
When GPIO-specific functions in the pin control subsystem are called, these
ranges will be used to look up the appropriate pin controller by inspecting
and matching the pin to the pin ranges across all controllers. When a
@@ -357,9 +367,9 @@
will be called on that specific pin controller.
For all functionalities dealing with pin biasing, pin muxing etc, the pin
-controller subsystem will subtract the range's .base offset from the passed
-in gpio number, and add the ranges's .pin_base offset to retrive a pin number.
-After that, the subsystem passes it on to the pin control driver, so the driver
+controller subsystem will look up the corresponding pin number from the passed
+in gpio number, and use the range's internals to retrive a pin number. After
+that, the subsystem passes it on to the pin control driver, so the driver
will get an pin number into its handled number range. Further it is also passed
the range ID value, so that the pin controller knows which range it should
deal with.
@@ -368,6 +378,7 @@
section 2.1 of Documentation/devicetree/bindings/gpio/gpio.txt on how to bind
pinctrl and gpio drivers.
+
PINMUX interfaces
=================
@@ -736,6 +747,13 @@
Pin control interaction with the GPIO subsystem
===============================================
+Note that the following implies that the use case is to use a certain pin
+from the Linux kernel using the API in <linux/gpio.h> with gpio_request()
+and similar functions. There are cases where you may be using something
+that your datasheet calls "GPIO mode" but actually is just an electrical
+configuration for a certain device. See the section below named
+"GPIO mode pitfalls" for more details on this scenario.
+
The public pinmux API contains two functions named pinctrl_request_gpio()
and pinctrl_free_gpio(). These two functions shall *ONLY* be called from
gpiolib-based drivers as part of their gpio_request() and
@@ -774,6 +792,111 @@
special GPIO-handler is registered.
+GPIO mode pitfalls
+==================
+
+Sometime the developer may be confused by a datasheet talking about a pin
+being possible to set into "GPIO mode". It appears that what hardware
+engineers mean with "GPIO mode" is not necessarily the use case that is
+implied in the kernel interface <linux/gpio.h>: a pin that you grab from
+kernel code and then either listen for input or drive high/low to
+assert/deassert some external line.
+
+Rather hardware engineers think that "GPIO mode" means that you can
+software-control a few electrical properties of the pin that you would
+not be able to control if the pin was in some other mode, such as muxed in
+for a device.
+
+Example: a pin is usually muxed in to be used as a UART TX line. But during
+system sleep, we need to put this pin into "GPIO mode" and ground it.
+
+If you make a 1-to-1 map to the GPIO subsystem for this pin, you may start
+to think that you need to come up with something real complex, that the
+pin shall be used for UART TX and GPIO at the same time, that you will grab
+a pin control handle and set it to a certain state to enable UART TX to be
+muxed in, then twist it over to GPIO mode and use gpio_direction_output()
+to drive it low during sleep, then mux it over to UART TX again when you
+wake up and maybe even gpio_request/gpio_free as part of this cycle. This
+all gets very complicated.
+
+The solution is to not think that what the datasheet calls "GPIO mode"
+has to be handled by the <linux/gpio.h> interface. Instead view this as
+a certain pin config setting. Look in e.g. <linux/pinctrl/pinconf-generic.h>
+and you find this in the documentation:
+
+ PIN_CONFIG_OUTPUT: this will configure the pin in output, use argument
+ 1 to indicate high level, argument 0 to indicate low level.
+
+So it is perfectly possible to push a pin into "GPIO mode" and drive the
+line low as part of the usual pin control map. So for example your UART
+driver may look like this:
+
+#include <linux/pinctrl/consumer.h>
+
+struct pinctrl *pinctrl;
+struct pinctrl_state *pins_default;
+struct pinctrl_state *pins_sleep;
+
+pins_default = pinctrl_lookup_state(uap->pinctrl, PINCTRL_STATE_DEFAULT);
+pins_sleep = pinctrl_lookup_state(uap->pinctrl, PINCTRL_STATE_SLEEP);
+
+/* Normal mode */
+retval = pinctrl_select_state(pinctrl, pins_default);
+/* Sleep mode */
+retval = pinctrl_select_state(pinctrl, pins_sleep);
+
+And your machine configuration may look like this:
+--------------------------------------------------
+
+static unsigned long uart_default_mode[] = {
+ PIN_CONF_PACKED(PIN_CONFIG_DRIVE_PUSH_PULL, 0),
+};
+
+static unsigned long uart_sleep_mode[] = {
+ PIN_CONF_PACKED(PIN_CONFIG_OUTPUT, 0),
+};
+
+static struct pinctrl_map __initdata pinmap[] = {
+ PIN_MAP_MUX_GROUP("uart", PINCTRL_STATE_DEFAULT, "pinctrl-foo",
+ "u0_group", "u0"),
+ PIN_MAP_CONFIGS_PIN("uart", PINCTRL_STATE_DEFAULT, "pinctrl-foo",
+ "UART_TX_PIN", uart_default_mode),
+ PIN_MAP_MUX_GROUP("uart", PINCTRL_STATE_SLEEP, "pinctrl-foo",
+ "u0_group", "gpio-mode"),
+ PIN_MAP_CONFIGS_PIN("uart", PINCTRL_STATE_SLEEP, "pinctrl-foo",
+ "UART_TX_PIN", uart_sleep_mode),
+};
+
+foo_init(void) {
+ pinctrl_register_mappings(pinmap, ARRAY_SIZE(pinmap));
+}
+
+Here the pins we want to control are in the "u0_group" and there is some
+function called "u0" that can be enabled on this group of pins, and then
+everything is UART business as usual. But there is also some function
+named "gpio-mode" that can be mapped onto the same pins to move them into
+GPIO mode.
+
+This will give the desired effect without any bogus interaction with the
+GPIO subsystem. It is just an electrical configuration used by that device
+when going to sleep, it might imply that the pin is set into something the
+datasheet calls "GPIO mode" but that is not the point: it is still used
+by that UART device to control the pins that pertain to that very UART
+driver, putting them into modes needed by the UART. GPIO in the Linux
+kernel sense are just some 1-bit line, and is a different use case.
+
+How the registers are poked to attain the push/pull and output low
+configuration and the muxing of the "u0" or "gpio-mode" group onto these
+pins is a question for the driver.
+
+Some datasheets will be more helpful and refer to the "GPIO mode" as
+"low power mode" rather than anything to do with GPIO. This often means
+the same thing electrically speaking, but in this latter case the
+software engineers will usually quickly identify that this is some
+specific muxing/configuration rather than anything related to the GPIO
+API.
+
+
Board/machine configuration
==================================
@@ -972,6 +1095,18 @@
Pin control requests from drivers
=================================
+When a device driver is about to probe the device core will automatically
+attempt to issue pinctrl_get_select_default() on these devices.
+This way driver writers do not need to add any of the boilerplate code
+of the type found below. However when doing fine-grained state selection
+and not using the "default" state, you may have to do some device driver
+handling of the pinctrl handles and states.
+
+So if you just want to put the pins for a certain device into the default
+state and be done with it, there is nothing you need to do besides
+providing the proper mapping table. The device core will take care of
+the rest.
+
Generally it is discouraged to let individual drivers get and enable pin
control. So if possible, handle the pin control in platform code or some other
place where you have access to all the affected struct device * pointers. In
@@ -1097,13 +1232,13 @@
mux in and bias pins in a certain way before the GPIO subsystems starts to
deal with them.
-The above can be hidden: using pinctrl hogs, the pin control driver may be
-setting up the config and muxing for the pins when it is probing,
-nevertheless orthogonal to the GPIO subsystem.
+The above can be hidden: using the device core, the pinctrl core may be
+setting up the config and muxing for the pins right before the device is
+probing, nevertheless orthogonal to the GPIO subsystem.
But there are also situations where it makes sense for the GPIO subsystem
-to communicate directly with with the pinctrl subsystem, using the latter
-as a back-end. This is when the GPIO driver may call out to the functions
+to communicate directly with the pinctrl subsystem, using the latter as a
+back-end. This is when the GPIO driver may call out to the functions
described in the section "Pin control interaction with the GPIO subsystem"
above. This only involves per-pin multiplexing, and will be completely
hidden behind the gpio_*() function namespace. In this case, the driver
diff --git a/Documentation/power/devices.txt b/Documentation/power/devices.txt
index 504dfe4..a66c982 100644
--- a/Documentation/power/devices.txt
+++ b/Documentation/power/devices.txt
@@ -268,7 +268,7 @@
System Power Management Phases
------------------------------
Suspending or resuming the system is done in several phases. Different phases
-are used for standby or memory sleep states ("suspend-to-RAM") and the
+are used for freeze, standby, and memory sleep states ("suspend-to-RAM") and the
hibernation state ("suspend-to-disk"). Each phase involves executing callbacks
for every device before the next phase begins. Not all busses or classes
support all these callbacks and not all drivers use all the callbacks. The
@@ -309,7 +309,8 @@
Entering System Suspend
-----------------------
-When the system goes into the standby or memory sleep state, the phases are:
+When the system goes into the freeze, standby or memory sleep state,
+the phases are:
prepare, suspend, suspend_late, suspend_noirq.
@@ -368,7 +369,7 @@
Leaving System Suspend
----------------------
-When resuming from standby or memory sleep, the phases are:
+When resuming from freeze, standby or memory sleep, the phases are:
resume_noirq, resume_early, resume, complete.
@@ -433,8 +434,8 @@
Entering Hibernation
--------------------
-Hibernating the system is more complicated than putting it into the standby or
-memory sleep state, because it involves creating and saving a system image.
+Hibernating the system is more complicated than putting it into the other
+sleep states, because it involves creating and saving a system image.
Therefore there are more phases for hibernation, with a different set of
callbacks. These phases always run after tasks have been frozen and memory has
been freed.
@@ -485,8 +486,8 @@
At this point the system image is saved, and the devices then need to be
prepared for the upcoming system shutdown. This is much like suspending them
-before putting the system into the standby or memory sleep state, and the phases
-are similar.
+before putting the system into the freeze, standby or memory sleep state,
+and the phases are similar.
9. The prepare phase is discussed above.
diff --git a/Documentation/power/freezing-of-tasks.txt b/Documentation/power/freezing-of-tasks.txt
index 6ec291e..85894d8 100644
--- a/Documentation/power/freezing-of-tasks.txt
+++ b/Documentation/power/freezing-of-tasks.txt
@@ -223,3 +223,8 @@
only after the entire suspend/hibernation sequence is complete.
So, to summarize, use [un]lock_system_sleep() instead of directly using
mutex_[un]lock(&pm_mutex). That would prevent freezing failures.
+
+V. Miscellaneous
+/sys/power/pm_freeze_timeout controls how long it will cost at most to freeze
+all user space processes or all freezable kernel threads, in unit of millisecond.
+The default value is 20000, with range of unsigned integer.
diff --git a/Documentation/power/interface.txt b/Documentation/power/interface.txt
index c537834..f1f0f59a 100644
--- a/Documentation/power/interface.txt
+++ b/Documentation/power/interface.txt
@@ -7,8 +7,8 @@
is mounted at /sys).
/sys/power/state controls system power state. Reading from this file
-returns what states are supported, which is hard-coded to 'standby'
-(Power-On Suspend), 'mem' (Suspend-to-RAM), and 'disk'
+returns what states are supported, which is hard-coded to 'freeze',
+'standby' (Power-On Suspend), 'mem' (Suspend-to-RAM), and 'disk'
(Suspend-to-Disk).
Writing to this file one of those strings causes the system to
diff --git a/Documentation/power/notifiers.txt b/Documentation/power/notifiers.txt
index c2a4a34..a81fa25 100644
--- a/Documentation/power/notifiers.txt
+++ b/Documentation/power/notifiers.txt
@@ -15,8 +15,10 @@
The subsystems or drivers having such needs can register suspend notifiers that
will be called upon the following events by the PM core:
-PM_HIBERNATION_PREPARE The system is going to hibernate or suspend, tasks will
- be frozen immediately.
+PM_HIBERNATION_PREPARE The system is going to hibernate, tasks will be frozen
+ immediately. This is different from PM_SUSPEND_PREPARE
+ below because here we do additional work between notifiers
+ and drivers freezing.
PM_POST_HIBERNATION The system memory state has been restored from a
hibernation image or an error occurred during
diff --git a/Documentation/power/opp.txt b/Documentation/power/opp.txt
index 3035d00..425c51d 100644
--- a/Documentation/power/opp.txt
+++ b/Documentation/power/opp.txt
@@ -1,6 +1,5 @@
-*=============*
-* OPP Library *
-*=============*
+Operating Performance Points (OPP) Library
+==========================================
(C) 2009-2010 Nishanth Menon <nm@ti.com>, Texas Instruments Incorporated
@@ -16,15 +15,31 @@
1. Introduction
===============
+1.1 What is an Operating Performance Point (OPP)?
+
Complex SoCs of today consists of a multiple sub-modules working in conjunction.
In an operational system executing varied use cases, not all modules in the SoC
need to function at their highest performing frequency all the time. To
facilitate this, sub-modules in a SoC are grouped into domains, allowing some
-domains to run at lower voltage and frequency while other domains are loaded
-more. The set of discrete tuples consisting of frequency and voltage pairs that
+domains to run at lower voltage and frequency while other domains run at
+voltage/frequency pairs that are higher.
+
+The set of discrete tuples consisting of frequency and voltage pairs that
the device will support per domain are called Operating Performance Points or
OPPs.
+As an example:
+Let us consider an MPU device which supports the following:
+{300MHz at minimum voltage of 1V}, {800MHz at minimum voltage of 1.2V},
+{1GHz at minimum voltage of 1.3V}
+
+We can represent these as three OPPs as the following {Hz, uV} tuples:
+{300000000, 1000000}
+{800000000, 1200000}
+{1000000000, 1300000}
+
+1.2 Operating Performance Points Library
+
OPP library provides a set of helper functions to organize and query the OPP
information. The library is located in drivers/base/power/opp.c and the header
is located in include/linux/opp.h. OPP library can be enabled by enabling
diff --git a/Documentation/power/pm_qos_interface.txt b/Documentation/power/pm_qos_interface.txt
index 79a2a58..4836320 100644
--- a/Documentation/power/pm_qos_interface.txt
+++ b/Documentation/power/pm_qos_interface.txt
@@ -7,7 +7,7 @@
Two different PM QoS frameworks are available:
1. PM QoS classes for cpu_dma_latency, network_latency, network_throughput.
2. the per-device PM QoS framework provides the API to manage the per-device latency
-constraints.
+constraints and PM QoS flags.
Each parameters have defined units:
* latency: usec
@@ -86,13 +86,17 @@
node.
-2. PM QoS per-device latency framework
+2. PM QoS per-device latency and flags framework
-For each device a list of performance requests is maintained along with
-an aggregated target value. The aggregated target value is updated with
-changes to the request list or elements of the list. Typically the
-aggregated target value is simply the max or min of the request values held
-in the parameter list elements.
+For each device, there are two lists of PM QoS requests. One is maintained
+along with the aggregated target of latency value and the other is for PM QoS
+flags. Values are updated in response to changes of the request list.
+
+Target latency value is simply the minimum of the request values held in the
+parameter list elements. The PM QoS flags aggregate value is a gather (bitwise
+OR) of all list elements' values. Two device PM QoS flags are defined currently:
+PM_QOS_FLAG_NO_POWER_OFF and PM_QOS_FLAG_REMOTE_WAKEUP.
+
Note: the aggregated target value is implemented as an atomic variable so that
reading the aggregated value does not require any locking mechanism.
@@ -119,6 +123,38 @@
s32 dev_pm_qos_read_value(device):
Returns the aggregated value for a given device's constraints list.
+enum pm_qos_flags_status dev_pm_qos_flags(device, mask)
+Check PM QoS flags of the given device against the given mask of flags.
+The meaning of the return values is as follows:
+ PM_QOS_FLAGS_ALL: All flags from the mask are set
+ PM_QOS_FLAGS_SOME: Some flags from the mask are set
+ PM_QOS_FLAGS_NONE: No flags from the mask are set
+ PM_QOS_FLAGS_UNDEFINED: The device's PM QoS structure has not been
+ initialized or the list of requests is empty.
+
+int dev_pm_qos_add_ancestor_request(dev, handle, value)
+Add a PM QoS request for the first direct ancestor of the given device whose
+power.ignore_children flag is unset.
+
+int dev_pm_qos_expose_latency_limit(device, value)
+Add a request to the device's PM QoS list of latency constraints and create
+a sysfs attribute pm_qos_resume_latency_us under the device's power directory
+allowing user space to manipulate that request.
+
+void dev_pm_qos_hide_latency_limit(device)
+Drop the request added by dev_pm_qos_expose_latency_limit() from the device's
+PM QoS list of latency constraints and remove sysfs attribute pm_qos_resume_latency_us
+from the device's power directory.
+
+int dev_pm_qos_expose_flags(device, value)
+Add a request to the device's PM QoS list of flags and create sysfs attributes
+pm_qos_no_power_off and pm_qos_remote_wakeup under the device's power directory
+allowing user space to change these flags' value.
+
+void dev_pm_qos_hide_flags(device)
+Drop the request added by dev_pm_qos_expose_flags() from the device's PM QoS list
+of flags and remove sysfs attributes pm_qos_no_power_off and pm_qos_remote_wakeup
+under the device's power directory.
Notification mechanisms:
The per-device PM QoS framework has 2 different and distinct notification trees:
diff --git a/Documentation/power/runtime_pm.txt b/Documentation/power/runtime_pm.txt
index 4abe83e..71d8fe4 100644
--- a/Documentation/power/runtime_pm.txt
+++ b/Documentation/power/runtime_pm.txt
@@ -144,8 +144,12 @@
(or driver) in question, but the expected and recommended action is to check
if the device can be suspended (i.e. if all of the conditions necessary for
suspending the device are satisfied) and to queue up a suspend request for the
-device in that case. The value returned by this callback is ignored by the PM
-core.
+device in that case. If there is no idle callback, or if the callback returns
+0, then the PM core will attempt to carry out a runtime suspend of the device;
+in essence, it will call pm_runtime_suspend() directly. To prevent this (for
+example, if the callback routine has started a delayed suspend), the routine
+should return a non-zero value. Negative error return codes are ignored by the
+PM core.
The helper functions provided by the PM core, described in Section 4, guarantee
that the following constraints are met with respect to runtime PM callbacks for
@@ -301,9 +305,10 @@
removing the device from device hierarchy
int pm_runtime_idle(struct device *dev);
- - execute the subsystem-level idle callback for the device; returns 0 on
- success or error code on failure, where -EINPROGRESS means that
- ->runtime_idle() is already being executed
+ - execute the subsystem-level idle callback for the device; returns an
+ error code on failure, where -EINPROGRESS means that ->runtime_idle() is
+ already being executed; if there is no callback or the callback returns 0
+ then run pm_runtime_suspend(dev) and return its result
int pm_runtime_suspend(struct device *dev);
- execute the subsystem-level suspend callback for the device; returns 0 on
@@ -426,6 +431,10 @@
'power.runtime_error' is set or 'power.disable_depth' is greater than
zero)
+ bool pm_runtime_active(struct device *dev);
+ - return true if the device's runtime PM status is 'active' or its
+ 'power.disable_depth' field is not equal to zero, or false otherwise
+
bool pm_runtime_suspended(struct device *dev);
- return true if the device's runtime PM status is 'suspended' and its
'power.disable_depth' field is equal to zero, or false otherwise
@@ -642,12 +651,13 @@
* During system suspend it calls pm_runtime_get_noresume() and
pm_runtime_barrier() for every device right before executing the
subsystem-level .suspend() callback for it. In addition to that it calls
- pm_runtime_disable() for every device right after executing the
- subsystem-level .suspend() callback for it.
+ __pm_runtime_disable() with 'false' as the second argument for every device
+ right before executing the subsystem-level .suspend_late() callback for it.
* During system resume it calls pm_runtime_enable() and pm_runtime_put_sync()
- for every device right before and right after executing the subsystem-level
- .resume() callback for it, respectively.
+ for every device right after executing the subsystem-level .resume_early()
+ callback and right after executing the subsystem-level .resume() callback
+ for it, respectively.
7. Generic subsystem callbacks
@@ -655,11 +665,6 @@
management callbacks provided by the PM core, defined in
driver/base/power/generic_ops.c:
- int pm_generic_runtime_idle(struct device *dev);
- - invoke the ->runtime_idle() callback provided by the driver of this
- device, if defined, and call pm_runtime_suspend() for this device if the
- return value is 0 or the callback is not defined
-
int pm_generic_runtime_suspend(struct device *dev);
- invoke the ->runtime_suspend() callback provided by the driver of this
device and return its result, or return -EINVAL if not defined
diff --git a/Documentation/power/states.txt b/Documentation/power/states.txt
index 4416b28..442d43d 100644
--- a/Documentation/power/states.txt
+++ b/Documentation/power/states.txt
@@ -2,12 +2,26 @@
System Power Management States
-The kernel supports three power management states generically, though
-each is dependent on platform support code to implement the low-level
-details for each state. This file describes each state, what they are
+The kernel supports four power management states generically, though
+one is generic and the other three are dependent on platform support
+code to implement the low-level details for each state.
+This file describes each state, what they are
commonly called, what ACPI state they map to, and what string to write
to /sys/power/state to enter that state
+state: Freeze / Low-Power Idle
+ACPI state: S0
+String: "freeze"
+
+This state is a generic, pure software, light-weight, low-power state.
+It allows more energy to be saved relative to idle by freezing user
+space and putting all I/O devices into low-power states (possibly
+lower-power than available at run time), such that the processors can
+spend more time in their idle states.
+This state can be used for platforms without Standby/Suspend-to-RAM
+support, or it can be used in addition to Suspend-to-RAM (memory sleep)
+to provide reduced resume latency.
+
State: Standby / Power-On Suspend
ACPI State: S1
@@ -22,9 +36,6 @@
also offers low power savings, but low resume latency. Not all devices
support D1, and those that don't are left on.
-A transition from Standby to the On state should take about 1-2
-seconds.
-
State: Suspend-to-RAM
ACPI State: S3
@@ -42,9 +53,6 @@
For at least ACPI, STR requires some minimal boot-strapping code to
resume the system from STR. This may be true on other platforms.
-A transition from Suspend-to-RAM to the On state should take about
-3-5 seconds.
-
State: Suspend-to-disk
ACPI State: S4
@@ -74,7 +82,3 @@
down offers greater savings, and allows this mechanism to work on any
system. However, entering a real low-power state allows the user to
trigger wake up events (e.g. pressing a key or opening a laptop lid).
-
-A transition from Suspend-to-Disk to the On state should take about 30
-seconds, though it's typically a bit more with the current
-implementation.
diff --git a/Documentation/power/video_extension.txt b/Documentation/power/video_extension.txt
deleted file mode 100644
index b2f9b15..0000000
--- a/Documentation/power/video_extension.txt
+++ /dev/null
@@ -1,37 +0,0 @@
-ACPI video extensions
-~~~~~~~~~~~~~~~~~~~~~
-
-This driver implement the ACPI Extensions For Display Adapters for
-integrated graphics devices on motherboard, as specified in ACPI 2.0
-Specification, Appendix B, allowing to perform some basic control like
-defining the video POST device, retrieving EDID information or to
-setup a video output, etc. Note that this is an ref. implementation
-only. It may or may not work for your integrated video device.
-
-Interfaces exposed to userland through /proc/acpi/video:
-
-VGA/info : display the supported video bus device capability like Video ROM, CRT/LCD/TV.
-VGA/ROM : Used to get a copy of the display devices' ROM data (up to 4k).
-VGA/POST_info : Used to determine what options are implemented.
-VGA/POST : Used to get/set POST device.
-VGA/DOS : Used to get/set ownership of output switching:
- Please refer ACPI spec B.4.1 _DOS
-VGA/CRT : CRT output
-VGA/LCD : LCD output
-VGA/TVO : TV output
-VGA/*/brightness : Used to get/set brightness of output device
-
-Notify event through /proc/acpi/event:
-
-#define ACPI_VIDEO_NOTIFY_SWITCH 0x80
-#define ACPI_VIDEO_NOTIFY_PROBE 0x81
-#define ACPI_VIDEO_NOTIFY_CYCLE 0x82
-#define ACPI_VIDEO_NOTIFY_NEXT_OUTPUT 0x83
-#define ACPI_VIDEO_NOTIFY_PREV_OUTPUT 0x84
-
-#define ACPI_VIDEO_NOTIFY_CYCLE_BRIGHTNESS 0x82
-#define ACPI_VIDEO_NOTIFY_INC_BRIGHTNESS 0x83
-#define ACPI_VIDEO_NOTIFY_DEC_BRIGHTNESS 0x84
-#define ACPI_VIDEO_NOTIFY_ZERO_BRIGHTNESS 0x85
-#define ACPI_VIDEO_NOTIFY_DISPLAY_OFF 0x86
-
diff --git a/Documentation/powerpc/00-INDEX b/Documentation/powerpc/00-INDEX
index 5620fb5..05026ce 100644
--- a/Documentation/powerpc/00-INDEX
+++ b/Documentation/powerpc/00-INDEX
@@ -14,10 +14,8 @@
- IBM "Hypervisor Virtual Console Server" Installation Guide
mpc52xx.txt
- Linux 2.6.x on MPC52xx family
-sound.txt
- - info on sound support under Linux/PPC
-zImage_layout.txt
- - info on the kernel images for Linux/PPC
+pmu-ebb.txt
+ - Description of the API for using the PMU with Event Based Branches.
qe_firmware.txt
- describes the layout of firmware binaries for the Freescale QUICC
Engine and the code that parses and uploads the microcode therein.
diff --git a/Documentation/powerpc/cpu_features.txt b/Documentation/powerpc/cpu_features.txt
index ffa4183..ae09df8 100644
--- a/Documentation/powerpc/cpu_features.txt
+++ b/Documentation/powerpc/cpu_features.txt
@@ -11,10 +11,10 @@
sleep modes.
Detection of the feature set is simple. A list of processors can be found in
-arch/ppc/kernel/cputable.c. The PVR register is masked and compared with each
-value in the list. If a match is found, the cpu_features of cur_cpu_spec is
-assigned to the feature bitmask for this processor and a __setup_cpu function
-is called.
+arch/powerpc/kernel/cputable.c. The PVR register is masked and compared with
+each value in the list. If a match is found, the cpu_features of cur_cpu_spec
+is assigned to the feature bitmask for this processor and a __setup_cpu
+function is called.
C code may test 'cur_cpu_spec[smp_processor_id()]->cpu_features' for a
particular feature bit. This is done in quite a few places, for example
@@ -51,6 +51,6 @@
The END_FTR_SECTION macros are implemented by storing information about this
code in the '__ftr_fixup' ELF section. When do_cpu_ftr_fixups
-(arch/ppc/kernel/misc.S) is invoked, it will iterate over the records in
+(arch/powerpc/kernel/misc.S) is invoked, it will iterate over the records in
__ftr_fixup, and if the required feature is not present it will loop writing
nop's from each BEGIN_FTR_SECTION to END_FTR_SECTION.
diff --git a/Documentation/powerpc/pmu-ebb.txt b/Documentation/powerpc/pmu-ebb.txt
new file mode 100644
index 0000000..73cd163
--- /dev/null
+++ b/Documentation/powerpc/pmu-ebb.txt
@@ -0,0 +1,137 @@
+PMU Event Based Branches
+========================
+
+Event Based Branches (EBBs) are a feature which allows the hardware to
+branch directly to a specified user space address when certain events occur.
+
+The full specification is available in Power ISA v2.07:
+
+ https://www.power.org/documentation/power-isa-version-2-07/
+
+One type of event for which EBBs can be configured is PMU exceptions. This
+document describes the API for configuring the Power PMU to generate EBBs,
+using the Linux perf_events API.
+
+
+Terminology
+-----------
+
+Throughout this document we will refer to an "EBB event" or "EBB events". This
+just refers to a struct perf_event which has set the "EBB" flag in its
+attr.config. All events which can be configured on the hardware PMU are
+possible "EBB events".
+
+
+Background
+----------
+
+When a PMU EBB occurs it is delivered to the currently running process. As such
+EBBs can only sensibly be used by programs for self-monitoring.
+
+It is a feature of the perf_events API that events can be created on other
+processes, subject to standard permission checks. This is also true of EBB
+events, however unless the target process enables EBBs (via mtspr(BESCR)) no
+EBBs will ever be delivered.
+
+This makes it possible for a process to enable EBBs for itself, but not
+actually configure any events. At a later time another process can come along
+and attach an EBB event to the process, which will then cause EBBs to be
+delivered to the first process. It's not clear if this is actually useful.
+
+
+When the PMU is configured for EBBs, all PMU interrupts are delivered to the
+user process. This means once an EBB event is scheduled on the PMU, no non-EBB
+events can be configured. This means that EBB events can not be run
+concurrently with regular 'perf' commands, or any other perf events.
+
+It is however safe to run 'perf' commands on a process which is using EBBs. The
+kernel will in general schedule the EBB event, and perf will be notified that
+its events could not run.
+
+The exclusion between EBB events and regular events is implemented using the
+existing "pinned" and "exclusive" attributes of perf_events. This means EBB
+events will be given priority over other events, unless they are also pinned.
+If an EBB event and a regular event are both pinned, then whichever is enabled
+first will be scheduled and the other will be put in error state. See the
+section below titled "Enabling an EBB event" for more information.
+
+
+Creating an EBB event
+---------------------
+
+To request that an event is counted using EBB, the event code should have bit
+63 set.
+
+EBB events must be created with a particular, and restrictive, set of
+attributes - this is so that they interoperate correctly with the rest of the
+perf_events subsystem.
+
+An EBB event must be created with the "pinned" and "exclusive" attributes set.
+Note that if you are creating a group of EBB events, only the leader can have
+these attributes set.
+
+An EBB event must NOT set any of the "inherit", "sample_period", "freq" or
+"enable_on_exec" attributes.
+
+An EBB event must be attached to a task. This is specified to perf_event_open()
+by passing a pid value, typically 0 indicating the current task.
+
+All events in a group must agree on whether they want EBB. That is all events
+must request EBB, or none may request EBB.
+
+EBB events must specify the PMC they are to be counted on. This ensures
+userspace is able to reliably determine which PMC the event is scheduled on.
+
+
+Enabling an EBB event
+---------------------
+
+Once an EBB event has been successfully opened, it must be enabled with the
+perf_events API. This can be achieved either via the ioctl() interface, or the
+prctl() interface.
+
+However, due to the design of the perf_events API, enabling an event does not
+guarantee that it has been scheduled on the PMU. To ensure that the EBB event
+has been scheduled on the PMU, you must perform a read() on the event. If the
+read() returns EOF, then the event has not been scheduled and EBBs are not
+enabled.
+
+This behaviour occurs because the EBB event is pinned and exclusive. When the
+EBB event is enabled it will force all other non-pinned events off the PMU. In
+this case the enable will be successful. However if there is already an event
+pinned on the PMU then the enable will not be successful.
+
+
+Reading an EBB event
+--------------------
+
+It is possible to read() from an EBB event. However the results are
+meaningless. Because interrupts are being delivered to the user process the
+kernel is not able to count the event, and so will return a junk value.
+
+
+Closing an EBB event
+--------------------
+
+When an EBB event is finished with, you can close it using close() as for any
+regular event. If this is the last EBB event the PMU will be deconfigured and
+no further PMU EBBs will be delivered.
+
+
+EBB Handler
+-----------
+
+The EBB handler is just regular userspace code, however it must be written in
+the style of an interrupt handler. When the handler is entered all registers
+are live (possibly) and so must be saved somehow before the handler can invoke
+other code.
+
+It's up to the program how to handle this. For C programs a relatively simple
+option is to create an interrupt frame on the stack and save registers there.
+
+Fork
+----
+
+EBB events are not inherited across fork. If the child process wishes to use
+EBBs it should open a new event for itself. Similarly the EBB state in
+BESCR/EBBHR/EBBRR is cleared across fork().
diff --git a/Documentation/powerpc/ptrace.txt b/Documentation/powerpc/ptrace.txt
index f2a7a39..99c5ce8 100644
--- a/Documentation/powerpc/ptrace.txt
+++ b/Documentation/powerpc/ptrace.txt
@@ -40,6 +40,7 @@
#define PPC_DEBUG_FEATURE_INSN_BP_MASK 0x2
#define PPC_DEBUG_FEATURE_DATA_BP_RANGE 0x4
#define PPC_DEBUG_FEATURE_DATA_BP_MASK 0x8
+#define PPC_DEBUG_FEATURE_DATA_BP_DAWR 0x10
2. PTRACE_SETHWDEBUG
diff --git a/Documentation/powerpc/sound.txt b/Documentation/powerpc/sound.txt
deleted file mode 100644
index df23d95..0000000
--- a/Documentation/powerpc/sound.txt
+++ /dev/null
@@ -1,81 +0,0 @@
- Information about PowerPC Sound support
-=====================================================================
-
-Please mail me (Cort Dougan, cort@fsmlabs.com) if you have questions,
-comments or corrections.
-
-Last Change: 6.16.99
-
-This just covers sound on the PReP and CHRP systems for now and later
-will contain information on the PowerMac's.
-
-Sound on PReP has been tested and is working with the PowerStack and IBM
-Power Series onboard sound systems which are based on the cs4231(2) chip.
-The sound options when doing the make config are a bit different from
-the default, though.
-
-The I/O base, irq and dma lines that you enter during the make config
-are ignored and are set when booting according to the machine type.
-This is so that one binary can be used for Motorola and IBM machines
-which use different values and isn't allowed by the driver, so things
-are hacked together in such a way as to allow this information to be
-set automatically on boot.
-
-1. Motorola PowerStack PReP machines
-
- Enable support for "Crystal CS4232 based (PnP) cards" and for the
- Microsoft Sound System. The MSS isn't used, but some of the routines
- that the CS4232 driver uses are in it.
-
- Although the options you set are ignored and determined automatically
- on boot these are included for information only:
-
- (830) CS4232 audio I/O base 530, 604, E80 or F40
- (10) CS4232 audio IRQ 5, 7, 9, 11, 12 or 15
- (6) CS4232 audio DMA 0, 1 or 3
- (7) CS4232 second (duplex) DMA 0, 1 or 3
-
- This will allow simultaneous record and playback, as 2 different dma
- channels are used.
-
- The sound will be all left channel and very low volume since the
- auxiliary input isn't muted by default. I had the changes necessary
- for this in the kernel but the sound driver maintainer didn't want
- to include them since it wasn't common in other machines. To fix this
- you need to mute it using a mixer utility of some sort (if you find one
- please let me know) or by patching the driver yourself and recompiling.
-
- There is a problem on the PowerStack 2's (PowerStack Pro's) using a
- different irq/drq than the kernel expects. Unfortunately, I don't know
- which irq/drq it is so if anyone knows please email me.
-
- Midi is not supported since the cs4232 driver doesn't support midi yet.
-
-2. IBM PowerPersonal PReP machines
-
- I've only tested sound on the Power Personal Series of IBM workstations
- so if you try it on others please let me know the result. I'm especially
- interested in the 43p's sound system, which I know nothing about.
-
- Enable support for "Crystal CS4232 based (PnP) cards" and for the
- Microsoft Sound System. The MSS isn't used, but some of the routines
- that the CS4232 driver uses are in it.
-
- Although the options you set are ignored and determined automatically
- on boot these are included for information only:
-
- (530) CS4232 audio I/O base 530, 604, E80 or F40
- (5) CS4232 audio IRQ 5, 7, 9, 11, 12 or 15
- (1) CS4232 audio DMA 0, 1 or 3
- (7) CS4232 second (duplex) DMA 0, 1 or 3
- (330) CS4232 MIDI I/O base 330, 370, 3B0 or 3F0
- (9) CS4232 MIDI IRQ 5, 7, 9, 11, 12 or 15
-
- This setup does _NOT_ allow for recording yet.
-
- Midi is not supported since the cs4232 driver doesn't support midi yet.
-
-2. IBM CHRP
-
- I have only tested this on the 43P-150. Build the kernel with the cs4232
- set as a module and load the module with irq=9 dma=1 dma2=2 io=0x550
diff --git a/Documentation/powerpc/transactional_memory.txt b/Documentation/powerpc/transactional_memory.txt
new file mode 100644
index 0000000..dc23e58
--- /dev/null
+++ b/Documentation/powerpc/transactional_memory.txt
@@ -0,0 +1,198 @@
+Transactional Memory support
+============================
+
+POWER kernel support for this feature is currently limited to supporting
+its use by user programs. It is not currently used by the kernel itself.
+
+This file aims to sum up how it is supported by Linux and what behaviour you
+can expect from your user programs.
+
+
+Basic overview
+==============
+
+Hardware Transactional Memory is supported on POWER8 processors, and is a
+feature that enables a different form of atomic memory access. Several new
+instructions are presented to delimit transactions; transactions are
+guaranteed to either complete atomically or roll back and undo any partial
+changes.
+
+A simple transaction looks like this:
+
+begin_move_money:
+ tbegin
+ beq abort_handler
+
+ ld r4, SAVINGS_ACCT(r3)
+ ld r5, CURRENT_ACCT(r3)
+ subi r5, r5, 1
+ addi r4, r4, 1
+ std r4, SAVINGS_ACCT(r3)
+ std r5, CURRENT_ACCT(r3)
+
+ tend
+
+ b continue
+
+abort_handler:
+ ... test for odd failures ...
+
+ /* Retry the transaction if it failed because it conflicted with
+ * someone else: */
+ b begin_move_money
+
+
+The 'tbegin' instruction denotes the start point, and 'tend' the end point.
+Between these points the processor is in 'Transactional' state; any memory
+references will complete in one go if there are no conflicts with other
+transactional or non-transactional accesses within the system. In this
+example, the transaction completes as though it were normal straight-line code
+IF no other processor has touched SAVINGS_ACCT(r3) or CURRENT_ACCT(r3); an
+atomic move of money from the current account to the savings account has been
+performed. Even though the normal ld/std instructions are used (note no
+lwarx/stwcx), either *both* SAVINGS_ACCT(r3) and CURRENT_ACCT(r3) will be
+updated, or neither will be updated.
+
+If, in the meantime, there is a conflict with the locations accessed by the
+transaction, the transaction will be aborted by the CPU. Register and memory
+state will roll back to that at the 'tbegin', and control will continue from
+'tbegin+4'. The branch to abort_handler will be taken this second time; the
+abort handler can check the cause of the failure, and retry.
+
+Checkpointed registers include all GPRs, FPRs, VRs/VSRs, LR, CCR/CR, CTR, FPCSR
+and a few other status/flag regs; see the ISA for details.
+
+Causes of transaction aborts
+============================
+
+- Conflicts with cache lines used by other processors
+- Signals
+- Context switches
+- See the ISA for full documentation of everything that will abort transactions.
+
+
+Syscalls
+========
+
+Performing syscalls from within transaction is not recommended, and can lead
+to unpredictable results.
+
+Syscalls do not by design abort transactions, but beware: The kernel code will
+not be running in transactional state. The effect of syscalls will always
+remain visible, but depending on the call they may abort your transaction as a
+side-effect, read soon-to-be-aborted transactional data that should not remain
+invisible, etc. If you constantly retry a transaction that constantly aborts
+itself by calling a syscall, you'll have a livelock & make no progress.
+
+Simple syscalls (e.g. sigprocmask()) "could" be OK. Even things like write()
+from, say, printf() should be OK as long as the kernel does not access any
+memory that was accessed transactionally.
+
+Consider any syscalls that happen to work as debug-only -- not recommended for
+production use. Best to queue them up till after the transaction is over.
+
+
+Signals
+=======
+
+Delivery of signals (both sync and async) during transactions provides a second
+thread state (ucontext/mcontext) to represent the second transactional register
+state. Signal delivery 'treclaim's to capture both register states, so signals
+abort transactions. The usual ucontext_t passed to the signal handler
+represents the checkpointed/original register state; the signal appears to have
+arisen at 'tbegin+4'.
+
+If the sighandler ucontext has uc_link set, a second ucontext has been
+delivered. For future compatibility the MSR.TS field should be checked to
+determine the transactional state -- if so, the second ucontext in uc->uc_link
+represents the active transactional registers at the point of the signal.
+
+For 64-bit processes, uc->uc_mcontext.regs->msr is a full 64-bit MSR and its TS
+field shows the transactional mode.
+
+For 32-bit processes, the mcontext's MSR register is only 32 bits; the top 32
+bits are stored in the MSR of the second ucontext, i.e. in
+uc->uc_link->uc_mcontext.regs->msr. The top word contains the transactional
+state TS.
+
+However, basic signal handlers don't need to be aware of transactions
+and simply returning from the handler will deal with things correctly:
+
+Transaction-aware signal handlers can read the transactional register state
+from the second ucontext. This will be necessary for crash handlers to
+determine, for example, the address of the instruction causing the SIGSEGV.
+
+Example signal handler:
+
+ void crash_handler(int sig, siginfo_t *si, void *uc)
+ {
+ ucontext_t *ucp = uc;
+ ucontext_t *transactional_ucp = ucp->uc_link;
+
+ if (ucp_link) {
+ u64 msr = ucp->uc_mcontext.regs->msr;
+ /* May have transactional ucontext! */
+#ifndef __powerpc64__
+ msr |= ((u64)transactional_ucp->uc_mcontext.regs->msr) << 32;
+#endif
+ if (MSR_TM_ACTIVE(msr)) {
+ /* Yes, we crashed during a transaction. Oops. */
+ fprintf(stderr, "Transaction to be restarted at 0x%llx, but "
+ "crashy instruction was at 0x%llx\n",
+ ucp->uc_mcontext.regs->nip,
+ transactional_ucp->uc_mcontext.regs->nip);
+ }
+ }
+
+ fix_the_problem(ucp->dar);
+ }
+
+When in an active transaction that takes a signal, we need to be careful with
+the stack. It's possible that the stack has moved back up after the tbegin.
+The obvious case here is when the tbegin is called inside a function that
+returns before a tend. In this case, the stack is part of the checkpointed
+transactional memory state. If we write over this non transactionally or in
+suspend, we are in trouble because if we get a tm abort, the program counter and
+stack pointer will be back at the tbegin but our in memory stack won't be valid
+anymore.
+
+To avoid this, when taking a signal in an active transaction, we need to use
+the stack pointer from the checkpointed state, rather than the speculated
+state. This ensures that the signal context (written tm suspended) will be
+written below the stack required for the rollback. The transaction is aborted
+becuase of the treclaim, so any memory written between the tbegin and the
+signal will be rolled back anyway.
+
+For signals taken in non-TM or suspended mode, we use the
+normal/non-checkpointed stack pointer.
+
+
+Failure cause codes used by kernel
+==================================
+
+These are defined in <asm/reg.h>, and distinguish different reasons why the
+kernel aborted a transaction:
+
+ TM_CAUSE_RESCHED Thread was rescheduled.
+ TM_CAUSE_TLBI Software TLB invalide.
+ TM_CAUSE_FAC_UNAV FP/VEC/VSX unavailable trap.
+ TM_CAUSE_SYSCALL Currently unused; future syscalls that must abort
+ transactions for consistency will use this.
+ TM_CAUSE_SIGNAL Signal delivered.
+ TM_CAUSE_MISC Currently unused.
+ TM_CAUSE_ALIGNMENT Alignment fault.
+ TM_CAUSE_EMULATE Emulation that touched memory.
+
+These can be checked by the user program's abort handler as TEXASR[0:7]. If
+bit 7 is set, it indicates that the error is consider persistent. For example
+a TM_CAUSE_ALIGNMENT will be persistent while a TM_CAUSE_RESCHED will not.q
+
+GDB
+===
+
+GDB and ptrace are not currently TM-aware. If one stops during a transaction,
+it looks like the transaction has just started (the checkpointed state is
+presented). The transaction cannot then be continued and will take the failure
+handler route. Furthermore, the transactional 2nd register state will be
+inaccessible. GDB can currently be used on programs using TM, but not sensibly
+in parts within transactions.
diff --git a/Documentation/powerpc/zImage_layout.txt b/Documentation/powerpc/zImage_layout.txt
deleted file mode 100644
index 048e015..0000000
--- a/Documentation/powerpc/zImage_layout.txt
+++ /dev/null
@@ -1,47 +0,0 @@
- Information about the Linux/PPC kernel images
-=====================================================================
-
-Please mail me (Cort Dougan, cort@fsmlabs.com) if you have questions,
-comments or corrections.
-
-This document is meant to answer several questions I've had about how
-the PReP system boots and how Linux/PPC interacts with that mechanism.
-It would be nice if we could have information on how other architectures
-boot here as well. If you have anything to contribute, please
-let me know.
-
-
-1. PReP boot file
-
- This is the file necessary to boot PReP systems from floppy or
- hard drive. The firmware reads the PReP partition table entry
- and will load the image accordingly.
-
- To boot the zImage, copy it onto a floppy with dd if=zImage of=/dev/fd0h1440
- or onto a PReP hard drive partition with dd if=zImage of=/dev/sda4
- assuming you've created a PReP partition (type 0x41) with fdisk on
- /dev/sda4.
-
- The layout of the image format is:
-
- 0x0 +------------+
- | | PReP partition table entry
- | |
- 0x400 +------------+
- | | Bootstrap program code + data
- | |
- | |
- +------------+
- | | compressed kernel, elf header removed
- +------------+
- | | initrd (if loaded)
- +------------+
- | | Elf section table for bootstrap program
- +------------+
-
-
-2. MBX boot file
-
- The MBX boards can load an elf image, and relocate it to the
- proper location in memory - it copies the image to the location it was
- linked at.
diff --git a/Documentation/printk-formats.txt b/Documentation/printk-formats.txt
index 8ffb274..3e8cb73 100644
--- a/Documentation/printk-formats.txt
+++ b/Documentation/printk-formats.txt
@@ -17,6 +17,8 @@
%pF versatile_init+0x0/0x110
%pf versatile_init
%pS versatile_init+0x0/0x110
+ %pSR versatile_init+0x9/0x110
+ (with __builtin_extract_return_addr() translation)
%ps versatile_init
%pB prev_fn_of_versatile_init+0x88/0x88
@@ -53,6 +55,14 @@
For printing struct resources. The 'R' and 'r' specifiers result in a
printed resource with ('R') or without ('r') a decoded flags member.
+Physical addresses:
+
+ %pa 0x01234567 or 0x0123456789abcdef
+
+ For printing a phys_addr_t type (and its derivatives, such as
+ resource_size_t) which can vary based on build options, regardless of
+ the width of the CPU data path. Passed by reference.
+
Raw buffer as a hex string:
%*ph 00 01 02 ... 3f
%*phC 00:01:02: ... :3f
@@ -111,6 +121,38 @@
print a compressed IPv6 address as described by
http://tools.ietf.org/html/rfc5952
+IPv4/IPv6 addresses (generic, with port, flowinfo, scope):
+
+ %pIS 1.2.3.4 or 0001:0002:0003:0004:0005:0006:0007:0008
+ %piS 001.002.003.004 or 00010002000300040005000600070008
+ %pISc 1.2.3.4 or 1:2:3:4:5:6:7:8
+ %pISpc 1.2.3.4:12345 or [1:2:3:4:5:6:7:8]:12345
+ %p[Ii]S[pfschnbl]
+
+ For printing an IP address without the need to distinguish whether it's
+ of type AF_INET or AF_INET6, a pointer to a valid 'struct sockaddr',
+ specified through 'IS' or 'iS', can be passed to this format specifier.
+
+ The additional 'p', 'f', and 's' specifiers are used to specify port
+ (IPv4, IPv6), flowinfo (IPv6) and scope (IPv6). Ports have a ':' prefix,
+ flowinfo a '/' and scope a '%', each followed by the actual value.
+
+ In case of an IPv6 address the compressed IPv6 address as described by
+ http://tools.ietf.org/html/rfc5952 is being used if the additional
+ specifier 'c' is given. The IPv6 address is surrounded by '[', ']' in
+ case of additional specifiers 'p', 'f' or 's' as suggested by
+ https://tools.ietf.org/html/draft-ietf-6man-text-addr-representation-07
+
+ In case of IPv4 addresses, the additional 'h', 'n', 'b', and 'l'
+ specifiers can be used as well and are ignored in case of an IPv6
+ address.
+
+ Further examples:
+
+ %pISfc 1.2.3.4 or [1:2:3:4:5:6:7:8]/123456789
+ %pISsc 1.2.3.4 or [1:2:3:4:5:6:7:8]%1234567890
+ %pISpfc 1.2.3.4:12345 or [1:2:3:4:5:6:7:8]:12345/123456789
+
UUID/GUID addresses:
%pUb 00010203-0405-0607-0809-0a0b0c0d0e0f
@@ -150,9 +192,9 @@
printk("%lld", (long long)s64_var);
If <type> is dependent on a config option for its size (e.g., sector_t,
-blkcnt_t, phys_addr_t, resource_size_t) or is architecture-dependent
-for its size (e.g., tcflag_t), use a format specifier of its largest
-possible type and explicitly cast to it. Example:
+blkcnt_t) or is architecture-dependent for its size (e.g., tcflag_t), use a
+format specifier of its largest possible type and explicitly cast to it.
+Example:
printk("test: sector number/total blocks: %llu/%llu\n",
(unsigned long long)sector, (unsigned long long)blockcount);
@@ -162,5 +204,5 @@
Thank you for your cooperation and attention.
-By Randy Dunlap <rdunlap@xenotime.net> and
+By Randy Dunlap <rdunlap@infradead.org> and
Andrew Murray <amurray@mpc-data.co.uk>
diff --git a/Documentation/pwm.txt b/Documentation/pwm.txt
index 7d2b4c9..1039b68 100644
--- a/Documentation/pwm.txt
+++ b/Documentation/pwm.txt
@@ -45,6 +45,43 @@
To start/stop toggling the PWM output use pwm_enable()/pwm_disable().
+Using PWMs with the sysfs interface
+-----------------------------------
+
+If CONFIG_SYSFS is enabled in your kernel configuration a simple sysfs
+interface is provided to use the PWMs from userspace. It is exposed at
+/sys/class/pwm/. Each probed PWM controller/chip will be exported as
+pwmchipN, where N is the base of the PWM chip. Inside the directory you
+will find:
+
+npwm - The number of PWM channels this chip supports (read-only).
+
+export - Exports a PWM channel for use with sysfs (write-only).
+
+unexport - Unexports a PWM channel from sysfs (write-only).
+
+The PWM channels are numbered using a per-chip index from 0 to npwm-1.
+
+When a PWM channel is exported a pwmX directory will be created in the
+pwmchipN directory it is associated with, where X is the number of the
+channel that was exported. The following properties will then be available:
+
+period - The total period of the PWM signal (read/write).
+ Value is in nanoseconds and is the sum of the active and inactive
+ time of the PWM.
+
+duty_cycle - The active time of the PWM signal (read/write).
+ Value is in nanoseconds and must be less than the period.
+
+polarity - Changes the polarity of the PWM signal (read/write).
+ Writes to this property only work if the PWM chip supports changing
+ the polarity. The polarity can only be changed if the PWM is not
+ enabled. Value is the string "normal" or "inversed".
+
+enable - Enable/disable the PWM signal (read/write).
+ 0 - disabled
+ 1 - enabled
+
Implementing a PWM driver
-------------------------
diff --git a/Documentation/rapidio/rapidio.txt b/Documentation/rapidio/rapidio.txt
index c75694b..717f5aa 100644
--- a/Documentation/rapidio/rapidio.txt
+++ b/Documentation/rapidio/rapidio.txt
@@ -73,39 +73,175 @@
ports that form the same network. It also contains a pointer to the default
master port that is used to communicate with devices within the network.
+2.5 Device Drivers
+
+RapidIO device-specific drivers follow Linux Kernel Driver Model and are
+intended to support specific RapidIO devices attached to the RapidIO network.
+
+2.6 Subsystem Interfaces
+
+RapidIO interconnect specification defines features that may be used to provide
+one or more common service layers for all participating RapidIO devices. These
+common services may act separately from device-specific drivers or be used by
+device-specific drivers. Example of such service provider is the RIONET driver
+which implements Ethernet-over-RapidIO interface. Because only one driver can be
+registered for a device, all common RapidIO services have to be registered as
+subsystem interfaces. This allows to have multiple common services attached to
+the same device without blocking attachment of a device-specific driver.
+
3. Subsystem Initialization
---------------------------
In order to initialize the RapidIO subsystem, a platform must initialize and
register at least one master port within the RapidIO network. To register mport
-within the subsystem controller driver initialization code calls function
-rio_register_mport() for each available master port. After all active master
-ports are registered with a RapidIO subsystem, the rio_init_mports() routine
-is called to perform enumeration and discovery.
+within the subsystem controller driver's initialization code calls function
+rio_register_mport() for each available master port.
-In the current PowerPC-based implementation a subsys_initcall() is specified to
-perform controller initialization and mport registration. At the end it directly
-calls rio_init_mports() to execute RapidIO enumeration and discovery.
+After all active master ports are registered with a RapidIO subsystem,
+an enumeration and/or discovery routine may be called automatically or
+by user-space command.
+
+RapidIO subsystem can be configured to be built as a statically linked or
+modular component of the kernel (see details below).
4. Enumeration and Discovery
----------------------------
-When rio_init_mports() is called it scans a list of registered master ports and
-calls an enumeration or discovery routine depending on the configured role of a
-master port: host or agent.
+4.1 Overview
+------------
+
+RapidIO subsystem configuration options allow users to build enumeration and
+discovery methods as statically linked components or loadable modules.
+An enumeration/discovery method implementation and available input parameters
+define how any given method can be attached to available RapidIO mports:
+simply to all available mports OR individually to the specified mport device.
+
+Depending on selected enumeration/discovery build configuration, there are
+several methods to initiate an enumeration and/or discovery process:
+
+ (a) Statically linked enumeration and discovery process can be started
+ automatically during kernel initialization time using corresponding module
+ parameters. This was the original method used since introduction of RapidIO
+ subsystem. Now this method relies on enumerator module parameter which is
+ 'rio-scan.scan' for existing basic enumeration/discovery method.
+ When automatic start of enumeration/discovery is used a user has to ensure
+ that all discovering endpoints are started before the enumerating endpoint
+ and are waiting for enumeration to be completed.
+ Configuration option CONFIG_RAPIDIO_DISC_TIMEOUT defines time that discovering
+ endpoint waits for enumeration to be completed. If the specified timeout
+ expires the discovery process is terminated without obtaining RapidIO network
+ information. NOTE: a timed out discovery process may be restarted later using
+ a user-space command as it is described below (if the given endpoint was
+ enumerated successfully).
+
+ (b) Statically linked enumeration and discovery process can be started by
+ a command from user space. This initiation method provides more flexibility
+ for a system startup compared to the option (a) above. After all participating
+ endpoints have been successfully booted, an enumeration process shall be
+ started first by issuing a user-space command, after an enumeration is
+ completed a discovery process can be started on all remaining endpoints.
+
+ (c) Modular enumeration and discovery process can be started by a command from
+ user space. After an enumeration/discovery module is loaded, a network scan
+ process can be started by issuing a user-space command.
+ Similar to the option (b) above, an enumerator has to be started first.
+
+ (d) Modular enumeration and discovery process can be started by a module
+ initialization routine. In this case an enumerating module shall be loaded
+ first.
+
+When a network scan process is started it calls an enumeration or discovery
+routine depending on the configured role of a master port: host or agent.
Enumeration is performed by a master port if it is configured as a host port by
-assigning a host device ID greater than or equal to zero. A host device ID is
-assigned to a master port through the kernel command line parameter "riohdid=",
-or can be configured in a platform-specific manner. If the host device ID for
-a specific master port is set to -1, the discovery process will be performed
-for it.
+assigning a host destination ID greater than or equal to zero. The host
+destination ID can be assigned to a master port using various methods depending
+on RapidIO subsystem build configuration:
+
+ (a) For a statically linked RapidIO subsystem core use command line parameter
+ "rapidio.hdid=" with a list of destination ID assignments in order of mport
+ device registration. For example, in a system with two RapidIO controllers
+ the command line parameter "rapidio.hdid=-1,7" will result in assignment of
+ the host destination ID=7 to the second RapidIO controller, while the first
+ one will be assigned destination ID=-1.
+
+ (b) If the RapidIO subsystem core is built as a loadable module, in addition
+ to the method shown above, the host destination ID(s) can be specified using
+ traditional methods of passing module parameter "hdid=" during its loading:
+ - from command line: "modprobe rapidio hdid=-1,7", or
+ - from modprobe configuration file using configuration command "options",
+ like in this example: "options rapidio hdid=-1,7". An example of modprobe
+ configuration file is provided in the section below.
+
+ NOTES:
+ (i) if "hdid=" parameter is omitted all available mport will be assigned
+ destination ID = -1;
+ (ii) the "hdid=" parameter in systems with multiple mports can have
+ destination ID assignments omitted from the end of list (default = -1).
+
+If the host device ID for a specific master port is set to -1, the discovery
+process will be performed for it.
The enumeration and discovery routines use RapidIO maintenance transactions
to access the configuration space of devices.
-The enumeration process is implemented according to the enumeration algorithm
-outlined in the RapidIO Interconnect Specification: Annex I [1].
+NOTE: If RapidIO switch-specific device drivers are built as loadable modules
+they must be loaded before enumeration/discovery process starts.
+This requirement is cased by the fact that enumeration/discovery methods invoke
+vendor-specific callbacks on early stages.
+
+4.2 Automatic Start of Enumeration and Discovery
+------------------------------------------------
+
+Automatic enumeration/discovery start method is applicable only to built-in
+enumeration/discovery RapidIO configuration selection. To enable automatic
+enumeration/discovery start by existing basic enumerator method set use boot
+command line parameter "rio-scan.scan=1".
+
+This configuration requires synchronized start of all RapidIO endpoints that
+form a network which will be enumerated/discovered. Discovering endpoints have
+to be started before an enumeration starts to ensure that all RapidIO
+controllers have been initialized and are ready to be discovered. Configuration
+parameter CONFIG_RAPIDIO_DISC_TIMEOUT defines time (in seconds) which
+a discovering endpoint will wait for enumeration to be completed.
+
+When automatic enumeration/discovery start is selected, basic method's
+initialization routine calls rio_init_mports() to perform enumeration or
+discovery for all known mport devices.
+
+Depending on RapidIO network size and configuration this automatic
+enumeration/discovery start method may be difficult to use due to the
+requirement for synchronized start of all endpoints.
+
+4.3 User-space Start of Enumeration and Discovery
+-------------------------------------------------
+
+User-space start of enumeration and discovery can be used with built-in and
+modular build configurations. For user-space controlled start RapidIO subsystem
+creates the sysfs write-only attribute file '/sys/bus/rapidio/scan'. To initiate
+an enumeration or discovery process on specific mport device, a user needs to
+write mport_ID (not RapidIO destination ID) into that file. The mport_ID is a
+sequential number (0 ... RIO_MAX_MPORTS) assigned during mport device
+registration. For example for machine with single RapidIO controller, mport_ID
+for that controller always will be 0.
+
+To initiate RapidIO enumeration/discovery on all available mports a user may
+write '-1' (or RIO_MPORT_ANY) into the scan attribute file.
+
+4.4 Basic Enumeration Method
+----------------------------
+
+This is an original enumeration/discovery method which is available since
+first release of RapidIO subsystem code. The enumeration process is
+implemented according to the enumeration algorithm outlined in the RapidIO
+Interconnect Specification: Annex I [1].
+
+This method can be configured as statically linked or loadable module.
+The method's single parameter "scan" allows to trigger the enumeration/discovery
+process from module initialization routine.
+
+This enumeration/discovery method can be started only once and does not support
+unloading if it is built as a module.
The enumeration process traverses the network using a recursive depth-first
algorithm. When a new device is found, the enumerator takes ownership of that
@@ -160,7 +296,49 @@
an agent skips RapidIO discovery and continues with remaining kernel
initialization.
-5. References
+4.5 Adding New Enumeration/Discovery Method
+-------------------------------------------
+
+RapidIO subsystem code organization allows addition of new enumeration/discovery
+methods as new configuration options without significant impact to to the core
+RapidIO code.
+
+A new enumeration/discovery method has to be attached to one or more mport
+devices before an enumeration/discovery process can be started. Normally,
+method's module initialization routine calls rio_register_scan() to attach
+an enumerator to a specified mport device (or devices). The basic enumerator
+implementation demonstrates this process.
+
+4.6 Using Loadable RapidIO Switch Drivers
+-----------------------------------------
+
+In the case when RapidIO switch drivers are built as loadable modules a user
+must ensure that they are loaded before the enumeration/discovery starts.
+This process can be automated by specifying pre- or post- dependencies in the
+RapidIO-specific modprobe configuration file as shown in the example below.
+
+ File /etc/modprobe.d/rapidio.conf:
+ ----------------------------------
+
+ # Configure RapidIO subsystem modules
+
+ # Set enumerator host destination ID (overrides kernel command line option)
+ options rapidio hdid=-1,2
+
+ # Load RapidIO switch drivers immediately after rapidio core module was loaded
+ softdep rapidio post: idt_gen2 idtcps tsi57x
+
+ # OR :
+
+ # Load RapidIO switch drivers just before rio-scan enumerator module is loaded
+ softdep rio-scan pre: idt_gen2 idtcps tsi57x
+
+ --------------------------
+
+NOTE: In the example above, one of "softdep" commands must be removed or
+commented out to keep required module loading sequence.
+
+A. References
-------------
[1] RapidIO Trade Association. RapidIO Interconnect Specifications.
diff --git a/Documentation/rapidio/sysfs.txt b/Documentation/rapidio/sysfs.txt
index 97f71ce..271438c 100644
--- a/Documentation/rapidio/sysfs.txt
+++ b/Documentation/rapidio/sysfs.txt
@@ -40,6 +40,7 @@
(see 4.1 for switch specific details)
lprev - returns name of previous device (switch) on the path to the device
that that owns this attribute
+ modalias - returns the device modalias
In addition to the files listed above, each device has a binary attribute file
that allows read/write access to the device configuration registers using
@@ -88,3 +89,20 @@
IDT_GEN2:
errlog - reads contents of device error log until it is empty.
+
+
+5. RapidIO Bus Attributes
+-------------------------
+
+RapidIO bus subdirectory /sys/bus/rapidio implements the following bus-specific
+attribute:
+
+ scan - allows to trigger enumeration discovery process from user space. This
+ is a write-only attribute. To initiate an enumeration or discovery
+ process on specific mport device, a user needs to write mport_ID (not
+ RapidIO destination ID) into this file. The mport_ID is a sequential
+ number (0 ... RIO_MAX_MPORTS) assigned to the mport device.
+ For example, for a machine with a single RapidIO controller, mport_ID
+ for that controller always will be 0.
+ To initiate RapidIO enumeration/discovery on all available mports
+ a user must write '-1' (or RIO_MPORT_ANY) into this attribute file.
diff --git a/Documentation/rpmsg.txt b/Documentation/rpmsg.txt
index 409d9f9..f7edc3a 100644
--- a/Documentation/rpmsg.txt
+++ b/Documentation/rpmsg.txt
@@ -236,7 +236,7 @@
return 0;
}
-static void __devexit rpmsg_sample_remove(struct rpmsg_channel *rpdev)
+static void rpmsg_sample_remove(struct rpmsg_channel *rpdev)
{
dev_info(&rpdev->dev, "rpmsg sample client driver is removed\n");
}
@@ -253,7 +253,7 @@
.id_table = rpmsg_driver_sample_id_table,
.probe = rpmsg_sample_probe,
.callback = rpmsg_sample_cb,
- .remove = __devexit_p(rpmsg_sample_remove),
+ .remove = rpmsg_sample_remove,
};
static int __init init(void)
diff --git a/Documentation/rt-mutex-design.txt b/Documentation/rt-mutex-design.txt
index 33ed800..a5bcd7f 100644
--- a/Documentation/rt-mutex-design.txt
+++ b/Documentation/rt-mutex-design.txt
@@ -384,7 +384,7 @@
__rt_mutex_adjust_prio examines the result of rt_mutex_getprio, and if the
result does not equal the task's current priority, then rt_mutex_setprio
is called to adjust the priority of the task to the new priority.
-Note that rt_mutex_setprio is defined in kernel/sched.c to implement the
+Note that rt_mutex_setprio is defined in kernel/sched/core.c to implement the
actual change in priority.
It is interesting to note that __rt_mutex_adjust_prio can either increase
diff --git a/Documentation/rtc.txt b/Documentation/rtc.txt
index 32aa400..596b60c 100644
--- a/Documentation/rtc.txt
+++ b/Documentation/rtc.txt
@@ -153,9 +153,10 @@
time: RTC-provided time
wakealarm: The time at which the clock will generate a system wakeup
event. This is a one shot wakeup event, so must be reset
- after wake if a daily wakeup is required. Format is either
- seconds since the epoch or, if there's a leading +, seconds
- in the future.
+ after wake if a daily wakeup is required. Format is seconds since
+ the epoch by default, or if there's a leading +, seconds in the
+ future, or if there is a leading +=, seconds ahead of the current
+ alarm.
IOCTL INTERFACE
---------------
diff --git a/Documentation/s390/CommonIO b/Documentation/s390/CommonIO
index d378cba..6e0f63f3 100644
--- a/Documentation/s390/CommonIO
+++ b/Documentation/s390/CommonIO
@@ -8,9 +8,9 @@
Enable logging of debug information in case of ccw device timeouts.
-* cio_ignore = {all} |
- {<device> | <range of devices>} |
- {!<device> | !<range of devices>}
+* cio_ignore = device[,device[,..]]
+
+ device := {all | [!]ipldev | [!]condev | [!]<devno> | [!]<devno>-<devno>}
The given devices will be ignored by the common I/O-layer; no detection
and device sensing will be done on any of those devices. The subchannel to
@@ -24,8 +24,10 @@
device numbers (0xabcd or abcd, for 2.4 backward compatibility). If you
give a device number 0xabcd, it will be interpreted as 0.0.abcd.
- You can use the 'all' keyword to ignore all devices.
- The '!' operator will cause the I/O-layer to _not_ ignore a device.
+ You can use the 'all' keyword to ignore all devices. The 'ipldev' and 'condev'
+ keywords can be used to refer to the CCW based boot device and CCW console
+ device respectively (these are probably useful only when combined with the '!'
+ operator). The '!' operator will cause the I/O-layer to _not_ ignore a device.
The command line is parsed from left to right.
For example,
diff --git a/Documentation/s390/s390dbf.txt b/Documentation/s390/s390dbf.txt
index ae66f9b..fcaf0b4 100644
--- a/Documentation/s390/s390dbf.txt
+++ b/Documentation/s390/s390dbf.txt
@@ -143,7 +143,8 @@
Return Value: none
-Description: frees memory for a debug log
+Description: frees memory for a debug log and removes all registered debug
+ views.
Must not be called within an interrupt handler
---------------------------------------------------------------------------
diff --git a/Documentation/scheduler/sched-domains.txt b/Documentation/scheduler/sched-domains.txt
index 443f0c7..4af80b1 100644
--- a/Documentation/scheduler/sched-domains.txt
+++ b/Documentation/scheduler/sched-domains.txt
@@ -25,7 +25,7 @@
load of each of its member CPUs, and only when the load of a group becomes
out of balance are tasks moved between groups.
-In kernel/sched.c, trigger_load_balance() is run periodically on each CPU
+In kernel/sched/core.c, trigger_load_balance() is run periodically on each CPU
through scheduler_tick(). It raises a softirq after the next regularly scheduled
rebalancing event for the current runqueue has arrived. The actual load
balancing workhorse, run_rebalance_domains()->rebalance_domains(), is then run
@@ -62,7 +62,7 @@
the specifics and what to tune.
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
+while using the generic domain builder in kernel/sched/core.c if they wish to
retain the traditional SMT->SMP->NUMA topology (or some subset of that). This
can be done by #define'ing ARCH_HASH_SCHED_TUNE.
diff --git a/Documentation/scsi/ChangeLog.megaraid_sas b/Documentation/scsi/ChangeLog.megaraid_sas
index da03146..cc92ca8 100644
--- a/Documentation/scsi/ChangeLog.megaraid_sas
+++ b/Documentation/scsi/ChangeLog.megaraid_sas
@@ -1,3 +1,34 @@
+Release Date : Wed. May 15, 2013 17:00:00 PST 2013 -
+ (emaild-id:megaraidlinux@lsi.com)
+ Adam Radford
+ Kashyap Desai
+ Sumit Saxena
+Current Version : 06.600.18.00-rc1
+Old Version : 06.506.00.00-rc1
+ 1. Return DID_ERROR for scsi io, when controller is in critical h/w error.
+ 2. Fix the interrupt mask for Gen2 controller.
+ 3. Update balance count in driver to be in sync of firmware.
+ 4. Free event detail memory without device ID check.
+ 5. Set IO request timeout value provided by OS timeout for Tape devices.
+ 6. Add support for MegaRAID Fury (device ID-0x005f) 12Gb/s controllers.
+ 7. Add support to display Customer branding details in syslog.
+ 8. Set IoFlags to enable Fast Path for JBODs for Invader/Fury(12 Gb/s)
+ controllers.
+ 9. Add support for Extended MSI-x vectors for Invader and Fury(12Gb/s
+ HBA).
+ 10.Add support for Uneven Span PRL11.
+ 11.Add support to differentiate between iMR and MR Firmware.
+ 12.Version and Changelog update.
+-------------------------------------------------------------------------------
+Release Date : Sat. Feb 9, 2013 17:00:00 PST 2013 -
+ (emaild-id:megaraidlinux@lsi.com)
+ Adam Radford
+Current Version : 06.506.00.00-rc1
+Old Version : 06.504.01.00-rc1
+ 1. Add 4k FastPath DIF support.
+ 2. Dont load DevHandle unless FastPath enabled.
+ 3. Version and Changelog update.
+-------------------------------------------------------------------------------
Release Date : Mon. Oct 1, 2012 17:00:00 PST 2012 -
(emaild-id:megaraidlinux@lsi.com)
Adam Radford
diff --git a/Documentation/scsi/LICENSE.qla2xxx b/Documentation/scsi/LICENSE.qla2xxx
index 27a91cf..5020b7b 100644
--- a/Documentation/scsi/LICENSE.qla2xxx
+++ b/Documentation/scsi/LICENSE.qla2xxx
@@ -1,4 +1,4 @@
-Copyright (c) 2003-2012 QLogic Corporation
+Copyright (c) 2003-2013 QLogic Corporation
QLogic Linux FC-FCoE Driver
This program includes a device driver for Linux 3.x.
diff --git a/Documentation/security/Smack.txt b/Documentation/security/Smack.txt
index 8a177e4..7a2d30c 100644
--- a/Documentation/security/Smack.txt
+++ b/Documentation/security/Smack.txt
@@ -117,6 +117,17 @@
ambient
This contains the Smack label applied to unlabeled network
packets.
+change-rule
+ This interface allows modification of existing access control rules.
+ The format accepted on write is:
+ "%s %s %s %s"
+ where the first string is the subject label, the second the
+ object label, the third the access to allow and the fourth the
+ access to deny. The access strings may contain only the characters
+ "rwxat-". If a rule for a given subject and object exists it will be
+ modified by enabling the permissions in the third string and disabling
+ those in the fourth string. If there is no such rule it will be
+ created using the access specified in the third and the fourth strings.
cipso
This interface allows a specific CIPSO header to be assigned
to a Smack label. The format accepted on write is:
diff --git a/Documentation/serial/00-INDEX b/Documentation/serial/00-INDEX
index f7b0c7d..1f1b22f 100644
--- a/Documentation/serial/00-INDEX
+++ b/Documentation/serial/00-INDEX
@@ -16,8 +16,6 @@
- info about RS485 structures and support in the kernel.
specialix.txt
- info on hardware/driver for specialix IO8+ multiport serial card.
-stallion.txt
- - info on using the Stallion multiport serial driver.
sx.txt
- info on the Specialix SX/SI multiport serial driver.
tty.txt
diff --git a/Documentation/serial/driver b/Documentation/serial/driver
index 0a25a91..067c47d 100644
--- a/Documentation/serial/driver
+++ b/Documentation/serial/driver
@@ -133,6 +133,16 @@
Interrupts: locally disabled.
This call must not sleep
+ send_xchar(port,ch)
+ Transmit a high priority character, even if the port is stopped.
+ This is used to implement XON/XOFF flow control and tcflow(). If
+ the serial driver does not implement this function, the tty core
+ will append the character to the circular buffer and then call
+ start_tx() / stop_tx() to flush the data out.
+
+ Locking: none.
+ Interrupts: caller dependent.
+
stop_rx(port)
Stop receiving characters; the port is in the process of
being closed.
@@ -242,9 +252,8 @@
pm(port,state,oldstate)
Perform any power management related activities on the specified
- port. State indicates the new state (defined by ACPI D0-D3),
- oldstate indicates the previous state. Essentially, D0 means
- fully on, D3 means powered down.
+ port. State indicates the new state (defined by
+ enum uart_pm_state), oldstate indicates the previous state.
This function should not be used to grab any resources.
@@ -255,6 +264,10 @@
Locking: none.
Interrupts: caller dependent.
+ set_wake(port,state)
+ Enable/disable power management wakeup on serial activity. Not
+ currently implemented.
+
type(port)
Return a pointer to a string constant describing the specified
port, or return NULL, in which case the string 'unknown' is
@@ -307,6 +320,31 @@
Locking: none.
Interrupts: caller dependent.
+ poll_init(port)
+ Called by kgdb to perform the minimal hardware initialization needed
+ to support poll_put_char() and poll_get_char(). Unlike ->startup()
+ this should not request interrupts.
+
+ Locking: tty_mutex and tty_port->mutex taken.
+ Interrupts: n/a.
+
+ poll_put_char(port,ch)
+ Called by kgdb to write a single character directly to the serial
+ port. It can and should block until there is space in the TX FIFO.
+
+ Locking: none.
+ Interrupts: caller dependent.
+ This call must not sleep
+
+ poll_get_char(port)
+ Called by kgdb to read a single character directly from the serial
+ port. If data is available, it should be returned; otherwise
+ the function should return NO_POLL_CHAR immediately.
+
+ Locking: none.
+ Interrupts: caller dependent.
+ This call must not sleep
+
Other functions
---------------
diff --git a/Documentation/serial/stallion.txt b/Documentation/serial/stallion.txt
deleted file mode 100644
index 4d798c0..0000000
--- a/Documentation/serial/stallion.txt
+++ /dev/null
@@ -1,392 +0,0 @@
-* NOTE - This is an unmaintained driver. Lantronix, which bought Stallion
-technologies, is not active in driver maintenance, and they have no information
-on when or if they will have a 2.6 driver.
-
-James Nelson <james4765@gmail.com> - 12-12-2004
-
-Stallion Multiport Serial Driver Readme
----------------------------------------
-
-Copyright (C) 1994-1999, Stallion Technologies.
-
-Version: 5.5.1
-Date: 28MAR99
-
-
-
-1. INTRODUCTION
-
-There are two drivers that work with the different families of Stallion
-multiport serial boards. One is for the Stallion smart boards - that is
-EasyIO, EasyConnection 8/32 and EasyConnection 8/64-PCI, the other for
-the true Stallion intelligent multiport boards - EasyConnection 8/64
-(ISA, EISA), EasyConnection/RA-PCI, ONboard and Brumby.
-
-If you are using any of the Stallion intelligent multiport boards (Brumby,
-ONboard, EasyConnection 8/64 (ISA, EISA), EasyConnection/RA-PCI) with
-Linux you will need to get the driver utility package. This contains a
-firmware loader and the firmware images necessary to make the devices operate.
-
-The Stallion Technologies ftp site, ftp.stallion.com, will always have
-the latest version of the driver utility package.
-
-ftp://ftp.stallion.com/drivers/ata5/Linux/ata-linux-550.tar.gz
-
-As of the printing of this document the latest version of the driver
-utility package is 5.5.0. If a later version is now available then you
-should use the latest version.
-
-If you are using the EasyIO, EasyConnection 8/32 or EasyConnection 8/64-PCI
-boards then you don't need this package, although it does have a serial stats
-display program.
-
-If you require DIP switch settings, or EISA configuration files, or any
-other information related to Stallion boards then have a look at Stallion's
-web pages at http://www.stallion.com.
-
-
-
-2. INSTALLATION
-
-The drivers can be used as loadable modules or compiled into the kernel.
-You can choose which when doing a "config" on the kernel.
-
-All ISA, and EISA boards that you want to use need to be configured into
-the driver(s). All PCI boards will be automatically detected when you load
-the driver - so they do not need to be entered into the driver(s)
-configuration structure. Note that kernel PCI support is required to use PCI
-boards.
-
-There are two methods of configuring ISA and EISA boards into the drivers.
-If using the driver as a loadable module then the simplest method is to pass
-the driver configuration as module arguments. The other method is to modify
-the driver source to add configuration lines for each board in use.
-
-If you have pre-built Stallion driver modules then the module argument
-configuration method should be used. A lot of Linux distributions come with
-pre-built driver modules in /lib/modules/X.Y.Z/misc for the kernel in use.
-That makes things pretty simple to get going.
-
-
-2.1 MODULE DRIVER CONFIGURATION:
-
-The simplest configuration for modules is to use the module load arguments
-to configure any ISA or EISA boards. PCI boards are automatically
-detected, so do not need any additional configuration at all.
-
-If using EasyIO, EasyConnection 8/32 ISA, or EasyConnection 8/63-PCI
-boards then use the "stallion" driver module, Otherwise if you are using
-an EasyConnection 8/64 ISA or EISA, EasyConnection/RA-PCI, ONboard,
-Brumby or original Stallion board then use the "istallion" driver module.
-
-Typically to load up the smart board driver use:
-
- modprobe stallion
-
-This will load the EasyIO and EasyConnection 8/32 driver. It will output a
-message to say that it loaded and print the driver version number. It will
-also print out whether it found the configured boards or not. These messages
-may not appear on the console, but typically are always logged to
-/var/adm/messages or /var/log/syslog files - depending on how the klogd and
-syslogd daemons are setup on your system.
-
-To load the intelligent board driver use:
-
- modprobe istallion
-
-It will output similar messages to the smart board driver.
-
-If not using an auto-detectable board type (that is a PCI board) then you
-will also need to supply command line arguments to the modprobe command
-when loading the driver. The general form of the configuration argument is
-
- board?=<name>[,<ioaddr>[,<addr>][,<irq>]]
-
-where:
-
- board? -- specifies the arbitrary board number of this board,
- can be in the range 0 to 3.
-
- name -- textual name of this board. The board name is the common
- board name, or any "shortened" version of that. The board
- type number may also be used here.
-
- ioaddr -- specifies the I/O address of this board. This argument is
- optional, but should generally be specified.
-
- addr -- optional second address argument. Some board types require
- a second I/O address, some require a memory address. The
- exact meaning of this argument depends on the board type.
-
- irq -- optional IRQ line used by this board.
-
-Up to 4 board configuration arguments can be specified on the load line.
-Here is some examples:
-
- modprobe stallion board0=easyio,0x2a0,5
-
-This configures an EasyIO board as board 0 at I/O address 0x2a0 and IRQ 5.
-
- modprobe istallion board3=ec8/64,0x2c0,0xcc000
-
-This configures an EasyConnection 8/64 ISA as board 3 at I/O address 0x2c0 at
-memory address 0xcc000.
-
- modprobe stallion board1=ec8/32-at,0x2a0,0x280,10
-
-This configures an EasyConnection 8/32 ISA board at primary I/O address 0x2a0,
-secondary address 0x280 and IRQ 10.
-
-You will probably want to enter this module load and configuration information
-into your system startup scripts so that the drivers are loaded and configured
-on each system boot. Typically configuration files are put in the
-/etc/modprobe.d/ directory.
-
-
-2.2 STATIC DRIVER CONFIGURATION:
-
-For static driver configuration you need to modify the driver source code.
-Entering ISA and EISA boards into the driver(s) configuration structure
-involves editing the driver(s) source file. It's pretty easy if you follow
-the instructions below. Both drivers can support up to 4 boards. The smart
-card driver (the stallion.c driver) supports any combination of EasyIO and
-EasyConnection 8/32 boards (up to a total of 4). The intelligent driver
-supports any combination of ONboards, Brumbys, Stallions and EasyConnection
-8/64 (ISA and EISA) boards (up to a total of 4).
-
-To set up the driver(s) for the boards that you want to use you need to
-edit the appropriate driver file and add configuration entries.
-
-If using EasyIO or EasyConnection 8/32 ISA boards,
- In drivers/char/stallion.c:
- - find the definition of the stl_brdconf array (of structures)
- near the top of the file
- - modify this to match the boards you are going to install
- (the comments before this structure should help)
- - save and exit
-
-If using ONboard, Brumby, Stallion or EasyConnection 8/64 (ISA or EISA)
-boards,
- In drivers/char/istallion.c:
- - find the definition of the stli_brdconf array (of structures)
- near the top of the file
- - modify this to match the boards you are going to install
- (the comments before this structure should help)
- - save and exit
-
-Once you have set up the board configurations then you are ready to build
-the kernel or modules.
-
-When the new kernel is booted, or the loadable module loaded then the
-driver will emit some kernel trace messages about whether the configured
-boards were detected or not. Depending on how your system logger is set
-up these may come out on the console, or just be logged to
-/var/adm/messages or /var/log/syslog. You should check the messages to
-confirm that all is well.
-
-
-2.3 SHARING INTERRUPTS
-
-It is possible to share interrupts between multiple EasyIO and
-EasyConnection 8/32 boards in an EISA system. To do this you must be using
-static driver configuration, modifying the driver source code to add driver
-configuration. Then a couple of extra things are required:
-
-1. When entering the board resources into the stallion.c file you need to
- mark the boards as using level triggered interrupts. Do this by replacing
- the "0" entry at field position 6 (the last field) in the board
- configuration structure with a "1". (This is the structure that defines
- the board type, I/O locations, etc. for each board). All boards that are
- sharing an interrupt must be set this way, and each board should have the
- same interrupt number specified here as well. Now build the module or
- kernel as you would normally.
-
-2. When physically installing the boards into the system you must enter
- the system EISA configuration utility. You will need to install the EISA
- configuration files for *all* the EasyIO and EasyConnection 8/32 boards
- that are sharing interrupts. The Stallion EasyIO and EasyConnection 8/32
- EISA configuration files required are supplied by Stallion Technologies
- on the EASY Utilities floppy diskette (usually supplied in the box with
- the board when purchased. If not, you can pick it up from Stallion's FTP
- site, ftp.stallion.com). You will need to edit the board resources to
- choose level triggered interrupts, and make sure to set each board's
- interrupt to the same IRQ number.
-
-You must complete both the above steps for this to work. When you reboot
-or load the driver your EasyIO and EasyConnection 8/32 boards will be
-sharing interrupts.
-
-
-2.4 USING HIGH SHARED MEMORY
-
-The EasyConnection 8/64-EI, ONboard and Stallion boards are capable of
-using shared memory addresses above the usual 640K - 1Mb range. The ONboard
-ISA and the Stallion boards can be programmed to use memory addresses up to
-16Mb (the ISA bus addressing limit), and the EasyConnection 8/64-EI and
-ONboard/E can be programmed for memory addresses up to 4Gb (the EISA bus
-addressing limit).
-
-The higher than 1Mb memory addresses are fully supported by this driver.
-Just enter the address as you normally would for a lower than 1Mb address
-(in the driver's board configuration structure).
-
-
-
-2.5 TROUBLE SHOOTING
-
-If a board is not found by the driver but is actually in the system then the
-most likely problem is that the I/O address is wrong. Change the module load
-argument for the loadable module form. Or change it in the driver stallion.c
-or istallion.c configuration structure and rebuild the kernel or modules, or
-change it on the board.
-
-On EasyIO and EasyConnection 8/32 boards the IRQ is software programmable, so
-if there is a conflict you may need to change the IRQ used for a board. There
-are no interrupts to worry about for ONboard, Brumby or EasyConnection 8/64
-(ISA and EISA) boards. The memory region on EasyConnection 8/64 and
-ONboard boards is software programmable, but not on the Brumby boards.
-
-
-
-3. USING THE DRIVERS
-
-3.1 INTELLIGENT DRIVER OPERATION
-
-The intelligent boards also need to have their "firmware" code downloaded
-to them. This is done via a user level application supplied in the driver
-utility package called "stlload". Compile this program wherever you dropped
-the package files, by typing "make". In its simplest form you can then type
-
- ./stlload -i cdk.sys
-
-in this directory and that will download board 0 (assuming board 0 is an
-EasyConnection 8/64 or EasyConnection/RA board). To download to an
-ONboard, Brumby or Stallion do:
-
- ./stlload -i 2681.sys
-
-Normally you would want all boards to be downloaded as part of the standard
-system startup. To achieve this, add one of the lines above into the
-/etc/rc.d/rc.S or /etc/rc.d/rc.serial file. To download each board just add
-the "-b <brd-number>" option to the line. You will need to download code for
-every board. You should probably move the stlload program into a system
-directory, such as /usr/sbin. Also, the default location of the cdk.sys image
-file in the stlload down-loader is /usr/lib/stallion. Create that directory
-and put the cdk.sys and 2681.sys files in it. (It's a convenient place to put
-them anyway). As an example your /etc/rc.d/rc.S file might have the
-following lines added to it (if you had 3 boards):
-
- /usr/sbin/stlload -b 0 -i /usr/lib/stallion/cdk.sys
- /usr/sbin/stlload -b 1 -i /usr/lib/stallion/2681.sys
- /usr/sbin/stlload -b 2 -i /usr/lib/stallion/2681.sys
-
-The image files cdk.sys and 2681.sys are specific to the board types. The
-cdk.sys will only function correctly on an EasyConnection 8/64 board. Similarly
-the 2681.sys image fill only operate on ONboard, Brumby and Stallion boards.
-If you load the wrong image file into a board it will fail to start up, and
-of course the ports will not be operational!
-
-If you are using the modularized version of the driver you might want to put
-the modprobe calls in the startup script as well (before the download lines
-obviously).
-
-
-3.2 USING THE SERIAL PORTS
-
-Once the driver is installed you will need to setup some device nodes to
-access the serial ports. The simplest method is to use the /dev/MAKEDEV program.
-It will automatically create device entries for Stallion boards. This will
-create the normal serial port devices as /dev/ttyE# where# is the port number
-starting from 0. A bank of 64 minor device numbers is allocated to each board,
-so the first port on the second board is port 64,etc. A set of callout type
-devices may also be created. They are created as the devices /dev/cue# where #
-is the same as for the ttyE devices.
-
-For the most part the Stallion driver tries to emulate the standard PC system
-COM ports and the standard Linux serial driver. The idea is that you should
-be able to use Stallion board ports and COM ports interchangeably without
-modifying anything but the device name. Anything that doesn't work like that
-should be considered a bug in this driver!
-
-If you look at the driver code you will notice that it is fairly closely
-based on the Linux serial driver (linux/drivers/char/serial.c). This is
-intentional, obviously this is the easiest way to emulate its behavior!
-
-Since this driver tries to emulate the standard serial ports as much as
-possible, most system utilities should work as they do for the standard
-COM ports. Most importantly "stty" works as expected and "setserial" can
-also be used (excepting the ability to auto-configure the I/O and IRQ
-addresses of boards). Higher baud rates are supported in the usual fashion
-through setserial or using the CBAUDEX extensions. Note that the EasyIO and
-EasyConnection (all types) support at least 57600 and 115200 baud. The newer
-EasyConnection XP modules and new EasyIO boards support 230400 and 460800
-baud as well. The older boards including ONboard and Brumby support a
-maximum baud rate of 38400.
-
-If you are unfamiliar with how to use serial ports, then get the Serial-HOWTO
-by Greg Hankins. It will explain everything you need to know!
-
-
-
-4. NOTES
-
-You can use both drivers at once if you have a mix of board types installed
-in a system. However to do this you will need to change the major numbers
-used by one of the drivers. Currently both drivers use major numbers 24, 25
-and 28 for their devices. Change one driver to use some other major numbers,
-and then modify the mkdevnods script to make device nodes based on those new
-major numbers. For example, you could change the istallion.c driver to use
-major numbers 60, 61 and 62. You will also need to create device nodes with
-different names for the ports, for example ttyF# and cuf#.
-
-The original Stallion board is no longer supported by Stallion Technologies.
-Although it is known to work with the istallion driver.
-
-Finding a free physical memory address range can be a problem. The older
-boards like the Stallion and ONboard need large areas (64K or even 128K), so
-they can be very difficult to get into a system. If you have 16 Mb of RAM
-then you have no choice but to put them somewhere in the 640K -> 1Mb range.
-ONboards require 64K, so typically 0xd0000 is good, or 0xe0000 on some
-systems. If you have an original Stallion board, "V4.0" or Rev.O, then you
-need a 64K memory address space, so again 0xd0000 and 0xe0000 are good.
-Older Stallion boards are a much bigger problem. They need 128K of address
-space and must be on a 128K boundary. If you don't have a VGA card then
-0xc0000 might be usable - there is really no other place you can put them
-below 1Mb.
-
-Both the ONboard and old Stallion boards can use higher memory addresses as
-well, but you must have less than 16Mb of RAM to be able to use them. Usual
-high memory addresses used include 0xec0000 and 0xf00000.
-
-The Brumby boards only require 16Kb of address space, so you can usually
-squeeze them in somewhere. Common addresses are 0xc8000, 0xcc000, or in
-the 0xd0000 range. EasyConnection 8/64 boards are even better, they only
-require 4Kb of address space, again usually 0xc8000, 0xcc000 or 0xd0000
-are good.
-
-If you are using an EasyConnection 8/64-EI or ONboard/E then usually the
-0xd0000 or 0xe0000 ranges are the best options below 1Mb. If neither of
-them can be used then the high memory support to use the really high address
-ranges is the best option. Typically the 2Gb range is convenient for them,
-and gets them well out of the way.
-
-The ports of the EasyIO-8M board do not have DCD or DTR signals. So these
-ports cannot be used as real modem devices. Generally, when using these
-ports you should only use the cueX devices.
-
-The driver utility package contains a couple of very useful programs. One
-is a serial port statistics collection and display program - very handy
-for solving serial port problems. The other is an extended option setting
-program that works with the intelligent boards.
-
-
-
-5. DISCLAIMER
-
-The information contained in this document is believed to be accurate and
-reliable. However, no responsibility is assumed by Stallion Technologies
-Pty. Ltd. for its use, nor any infringements of patents or other rights
-of third parties resulting from its use. Stallion Technologies reserves
-the right to modify the design of its products and will endeavour to change
-the information in manuals and accompanying documentation accordingly.
-
diff --git a/Documentation/sound/alsa/ALSA-Configuration.txt b/Documentation/sound/alsa/ALSA-Configuration.txt
index b9cfd33..95731a0 100644
--- a/Documentation/sound/alsa/ALSA-Configuration.txt
+++ b/Documentation/sound/alsa/ALSA-Configuration.txt
@@ -911,7 +911,7 @@
models depending on the codec chip. The list of available models
is found in HD-Audio-Models.txt
- The model name "genric" is treated as a special case. When this
+ The model name "generic" is treated as a special case. When this
model is given, the driver uses the generic codec parser without
"codec-patch". It's sometimes good for testing and debugging.
diff --git a/Documentation/sound/alsa/HD-Audio-Models.txt b/Documentation/sound/alsa/HD-Audio-Models.txt
index 16dfe57..809d72b 100644
--- a/Documentation/sound/alsa/HD-Audio-Models.txt
+++ b/Documentation/sound/alsa/HD-Audio-Models.txt
@@ -21,39 +21,42 @@
==========
inv-dmic Inverted internal mic workaround
-ALC269/270/275/276/280/282
+ALC269/270/275/276/28x/29x
======
- laptop-amic Laptops with analog-mic input
- laptop-dmic Laptops with digital-mic input
- alc269-dmic Enable ALC269(VA) digital mic workaround
- alc271-dmic Enable ALC271X digital mic workaround
- inv-dmic Inverted internal mic workaround
- lenovo-dock Enables docking station I/O for some Lenovos
+ laptop-amic Laptops with analog-mic input
+ laptop-dmic Laptops with digital-mic input
+ alc269-dmic Enable ALC269(VA) digital mic workaround
+ alc271-dmic Enable ALC271X digital mic workaround
+ inv-dmic Inverted internal mic workaround
+ lenovo-dock Enables docking station I/O for some Lenovos
+ dell-headset-multi Headset jack, which can also be used as mic-in
+ dell-headset-dock Headset jack (without mic-in), and also dock I/O
-ALC662/663/272
+ALC66x/67x/892
==============
- mario Chromebook mario model fixup
- asus-mode1 ASUS
- asus-mode2 ASUS
- asus-mode3 ASUS
- asus-mode4 ASUS
- asus-mode5 ASUS
- asus-mode6 ASUS
- asus-mode7 ASUS
- asus-mode8 ASUS
- inv-dmic Inverted internal mic workaround
+ mario Chromebook mario model fixup
+ asus-mode1 ASUS
+ asus-mode2 ASUS
+ asus-mode3 ASUS
+ asus-mode4 ASUS
+ asus-mode5 ASUS
+ asus-mode6 ASUS
+ asus-mode7 ASUS
+ asus-mode8 ASUS
+ inv-dmic Inverted internal mic workaround
+ dell-headset-multi Headset jack, which can also be used as mic-in
ALC680
======
N/A
-ALC882/883/885/888/889
+ALC88x/898/1150
======================
acer-aspire-4930g Acer Aspire 4930G/5930G/6530G/6930G/7730G
acer-aspire-8930g Acer Aspire 8330G/6935G
acer-aspire Acer Aspire others
- inv-dmic Inverted internal mic workaround
- no-primary-hp VAIO Z workaround (for fixed speaker DAC)
+ inv-dmic Inverted internal mic workaround
+ no-primary-hp VAIO Z/VGC-LN51JGB workaround (for fixed speaker DAC)
ALC861/660
==========
diff --git a/Documentation/sound/alsa/HD-Audio.txt b/Documentation/sound/alsa/HD-Audio.txt
index 7813c06..c3c912d 100644
--- a/Documentation/sound/alsa/HD-Audio.txt
+++ b/Documentation/sound/alsa/HD-Audio.txt
@@ -176,14 +176,14 @@
yes, pretty often broken. It sets up wrong values and screws up the
driver.
-The preset model is provided basically to overcome such a situation.
-When the matching preset model is found in the white-list, the driver
-assumes the static configuration of that preset and builds the mixer
-elements and PCM streams based on the static information. Thus, if
-you have a newer machine with a slightly different PCI SSID from the
-existing one, you may have a good chance to re-use the same model.
-You can pass the `model` option to specify the preset model instead of
-PCI SSID look-up.
+The preset model (or recently called as "fix-up") is provided
+basically to overcome such a situation. When the matching preset
+model is found in the white-list, the driver assumes the static
+configuration of that preset with the correct pin setup, etc.
+Thus, if you have a newer machine with a slightly different PCI SSID
+(or codec SSID) from the existing one, you may have a good chance to
+re-use the same model. You can pass the `model` option to specify the
+preset model instead of PCI (and codec-) SSID look-up.
What `model` option values are available depends on the codec chip.
Check your codec chip from the codec proc file (see "Codec Proc-File"
@@ -199,17 +199,12 @@
different `model` option values. If you have any luck, some of them
might suit with your device well.
-Some codecs such as ALC880 have a special model option `model=test`.
-This configures the driver to provide as many mixer controls as
-possible for every single pin feature except for the unsolicited
-events (and maybe some other specials). Adjust each mixer element and
-try the I/O in the way of trial-and-error until figuring out the whole
-I/O pin mappings.
+There are a few special model option values:
+- when 'nofixup' is passed, the device-specific fixups in the codec
+ parser are skipped.
+- when `generic` is passed, the codec-specific parser is skipped and
+ only the generic parser is used.
-Note that `model=generic` has a special meaning. It means to use the
-generic parser regardless of the codec. Usually the codec-specific
-parser is much better than the generic parser (as now). Thus this
-option is more about the debugging purpose.
Speaker and Headphone Output
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -387,9 +382,8 @@
(separated with a space).
hints::
Shows / stores hint strings for codec parsers for any use.
- Its format is `key = value`. For example, passing `hp_detect = yes`
- to IDT/STAC codec parser will result in the disablement of the
- headphone detection.
+ Its format is `key = value`. For example, passing `jack_detect = no`
+ will disable the jack detection of the machine completely.
init_pin_configs::
Shows the initial pin default config values set by BIOS.
driver_pin_configs::
@@ -421,6 +415,63 @@
------------------------------------------------------------------------
+Hint Strings
+~~~~~~~~~~~~
+The codec parser have several switches and adjustment knobs for
+matching better with the actual codec or device behavior. Many of
+them can be adjusted dynamically via "hints" strings as mentioned in
+the section above. For example, by passing `jack_detect = no` string
+via sysfs or a patch file, you can disable the jack detection, thus
+the codec parser will skip the features like auto-mute or mic
+auto-switch. As a boolean value, either `yes`, `no`, `true`, `false`,
+`1` or `0` can be passed.
+
+The generic parser supports the following hints:
+
+- jack_detect (bool): specify whether the jack detection is available
+ at all on this machine; default true
+- inv_jack_detect (bool): indicates that the jack detection logic is
+ inverted
+- trigger_sense (bool): indicates that the jack detection needs the
+ explicit call of AC_VERB_SET_PIN_SENSE verb
+- inv_eapd (bool): indicates that the EAPD is implemented in the
+ inverted logic
+- pcm_format_first (bool): sets the PCM format before the stream tag
+ and channel ID
+- sticky_stream (bool): keep the PCM format, stream tag and ID as long
+ as possible; default true
+- spdif_status_reset (bool): reset the SPDIF status bits at each time
+ the SPDIF stream is set up
+- pin_amp_workaround (bool): the output pin may have multiple amp
+ values
+- single_adc_amp (bool): ADCs can have only single input amps
+- auto_mute (bool): enable/disable the headphone auto-mute feature;
+ default true
+- auto_mic (bool): enable/disable the mic auto-switch feature; default
+ true
+- line_in_auto_switch (bool): enable/disable the line-in auto-switch
+ feature; default false
+- need_dac_fix (bool): limits the DACs depending on the channel count
+- primary_hp (bool): probe headphone jacks as the primary outputs;
+ default true
+- multi_cap_vol (bool): provide multiple capture volumes
+- inv_dmic_split (bool): provide split internal mic volume/switch for
+ phase-inverted digital mics
+- indep_hp (bool): provide the independent headphone PCM stream and
+ the corresponding mixer control, if available
+- add_stereo_mix_input (bool): add the stereo mix (analog-loopback
+ mix) to the input mux if available
+- add_jack_modes (bool): add "xxx Jack Mode" enum controls to each
+ I/O jack for allowing to change the headphone amp and mic bias VREF
+ capabilities
+- power_down_unused (bool): power down the unused widgets
+- add_hp_mic (bool): add the headphone to capture source if possible
+- hp_mic_detect (bool): enable/disable the hp/mic shared input for a
+ single built-in mic case; default true
+- mixer_nid (int): specifies the widget NID of the analog-loopback
+ mixer
+
+
Early Patching
~~~~~~~~~~~~~~
When CONFIG_SND_HDA_PATCH_LOADER=y is set, you can pass a "patch" as a
@@ -445,7 +496,7 @@
0x20 0x400 0xff
[hint]
- hp_detect = yes
+ jack_detect = no
------------------------------------------------------------------------
The file needs to have a line `[codec]`. The next line should contain
@@ -531,6 +582,13 @@
power-saving. See /sys/module/snd_hda_intel/parameters/power_save to
check the current value. If it's non-zero, the feature is turned on.
+The recent kernel supports the runtime PM for the HD-audio controller
+chip, too. It means that the HD-audio controller is also powered up /
+down dynamically. The feature is enabled only for certain controller
+chips like Intel LynxPoint. You can enable/disable this feature
+forcibly by setting `power_save_controller` option, which is also
+available at /sys/module/snd_hda_intel/parameters directory.
+
Tracepoints
~~~~~~~~~~~
@@ -587,8 +645,9 @@
- git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
The master branch or for-next branches can be used as the main
-development branches in general while the HD-audio specific patches
-are committed in topic/hda branch.
+development branches in general while the development for the current
+and next kernels are found in for-linus and for-next branches,
+respectively.
If you are using the latest Linus tree, it'd be better to pull the
above GIT tree onto it. If you are using the older kernels, an easy
@@ -699,7 +758,11 @@
cached in the driver, and thus changing the widget amp value directly
via hda-verb won't change the mixer value.
-The hda-verb program is found in the ftp directory:
+The hda-verb program is included now in alsa-tools:
+
+- git://git.alsa-project.org/alsa-tools.git
+
+Also, the old stand-alone package is found in the ftp directory:
- ftp://ftp.suse.com/pub/people/tiwai/misc/
@@ -777,3 +840,18 @@
See README file in the tarball for more details about hda-emu
program.
+
+
+hda-jack-retask
+~~~~~~~~~~~~~~~
+hda-jack-retask is a user-friendly GUI program to manipulate the
+HD-audio pin control for jack retasking. If you have a problem about
+the jack assignment, try this program and check whether you can get
+useful results. Once when you figure out the proper pin assignment,
+it can be fixed either in the driver code statically or via passing a
+firmware patch file (see "Early Patching" section).
+
+The program is included in alsa-tools now:
+
+- git://git.alsa-project.org/alsa-tools.git
+
diff --git a/Documentation/sound/alsa/compress_offload.txt b/Documentation/sound/alsa/compress_offload.txt
index 90e9b3a..0bcc551 100644
--- a/Documentation/sound/alsa/compress_offload.txt
+++ b/Documentation/sound/alsa/compress_offload.txt
@@ -145,6 +145,52 @@
- Addition of encoding options when required (derived from OpenMAX IL)
- Addition of rateControlSupported (missing in OpenMAX AL)
+Gapless Playback
+================
+When playing thru an album, the decoders have the ability to skip the encoder
+delay and padding and directly move from one track content to another. The end
+user can perceive this as gapless playback as we dont have silence while
+switching from one track to another
+
+Also, there might be low-intensity noises due to encoding. Perfect gapless is
+difficult to reach with all types of compressed data, but works fine with most
+music content. The decoder needs to know the encoder delay and encoder padding.
+So we need to pass this to DSP. This metadata is extracted from ID3/MP4 headers
+and are not present by default in the bitstream, hence the need for a new
+interface to pass this information to the DSP. Also DSP and userspace needs to
+switch from one track to another and start using data for second track.
+
+The main additions are:
+
+- set_metadata
+This routine sets the encoder delay and encoder padding. This can be used by
+decoder to strip the silence. This needs to be set before the data in the track
+is written.
+
+- set_next_track
+This routine tells DSP that metadata and write operation sent after this would
+correspond to subsequent track
+
+- partial drain
+This is called when end of file is reached. The userspace can inform DSP that
+EOF is reached and now DSP can start skipping padding delay. Also next write
+data would belong to next track
+
+Sequence flow for gapless would be:
+- Open
+- Get caps / codec caps
+- Set params
+- Set metadata of the first track
+- Fill data of the first track
+- Trigger start
+- User-space finished sending all,
+- Indicaite next track data by sending set_next_track
+- Set metadata of the next track
+- then call partial_drain to flush most of buffer in DSP
+- Fill data of the next track
+- DSP switches to second track
+(note: order for partial_drain and write for next track can be reversed as well)
+
Not supported:
- Support for VoIP/circuit-switched calls is not the target of this
diff --git a/Documentation/sound/alsa/seq_oss.html b/Documentation/sound/alsa/seq_oss.html
index d9776cf..9663b45 100644
--- a/Documentation/sound/alsa/seq_oss.html
+++ b/Documentation/sound/alsa/seq_oss.html
@@ -285,7 +285,7 @@
<H4>
7.2.4 Close Callback</H4>
The <TT>close</TT> callback is called when this device is closed by the
-applicaion. If any private data was allocated in open callback, it must
+application. If any private data was allocated in open callback, it must
be released in the close callback. The deletion of ALSA port should be
done here, too. This callback must not be NULL.
<H4>
diff --git a/Documentation/spi/spi-summary b/Documentation/spi/spi-summary
index 7312ec1..2331eb2 100644
--- a/Documentation/spi/spi-summary
+++ b/Documentation/spi/spi-summary
@@ -345,7 +345,7 @@
},
.probe = CHIP_probe,
- .remove = __devexit_p(CHIP_remove),
+ .remove = CHIP_remove,
.suspend = CHIP_suspend,
.resume = CHIP_resume,
};
@@ -355,7 +355,7 @@
might look like this unless you're creating a device which is managing
a bus (appearing under /sys/class/spi_master).
- static int __devinit CHIP_probe(struct spi_device *spi)
+ static int CHIP_probe(struct spi_device *spi)
{
struct CHIP *chip;
struct CHIP_platform_data *pdata;
diff --git a/Documentation/spinlocks.txt b/Documentation/spinlocks.txt
index 9dbe885..97eaf57 100644
--- a/Documentation/spinlocks.txt
+++ b/Documentation/spinlocks.txt
@@ -137,7 +137,7 @@
But when you do the write-lock, you have to use the irq-safe version.
For an example of being clever with rw-locks, see the "waitqueue_lock"
-handling in kernel/sched.c - nothing ever _changes_ a wait-queue from
+handling in kernel/sched/core.c - nothing ever _changes_ a wait-queue from
within an interrupt, they only read the queue in order to know whom to
wake up. So read-locks are safe (which is good: they are very common
indeed), while write-locks need to protect themselves against interrupts.
diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
index 2907ba6..ab7d16e 100644
--- a/Documentation/sysctl/kernel.txt
+++ b/Documentation/sysctl/kernel.txt
@@ -38,6 +38,7 @@
- l2cr [ PPC only ]
- modprobe ==> Documentation/debugging-modules.txt
- modules_disabled
+- msg_next_id [ sysv ipc ]
- msgmax
- msgmnb
- msgmni
@@ -62,17 +63,19 @@
- rtsig-max
- rtsig-nr
- sem
+- sem_next_id [ sysv ipc ]
- sg-big-buff [ generic SCSI device (sg) ]
+- shm_next_id [ sysv ipc ]
- shm_rmid_forced
- shmall
- shmmax [ sysv ipc ]
- shmmni
-- softlockup_thresh
- stop-a [ SPARC only ]
- sysrq ==> Documentation/sysrq.txt
- tainted
- threads-max
- unknown_nmi_panic
+- watchdog_thresh
- version
==============================================================
@@ -320,6 +323,22 @@
==============================================================
+msg_next_id, sem_next_id, and shm_next_id:
+
+These three toggles allows to specify desired id for next allocated IPC
+object: message, semaphore or shared memory respectively.
+
+By default they are equal to -1, which means generic allocation logic.
+Possible values to set are in range {0..INT_MAX}.
+
+Notes:
+1) kernel doesn't guarantee, that new object will have desired id. So,
+it's up to userspace, how to handle an object with "wrong" id.
+2) Toggle with non-default value will be set back to -1 by kernel after
+successful IPC object allocation.
+
+==============================================================
+
nmi_watchdog:
Enables/Disables the NMI watchdog on x86 systems. When the value is
@@ -408,6 +427,32 @@
==============================================================
+perf_cpu_time_max_percent:
+
+Hints to the kernel how much CPU time it should be allowed to
+use to handle perf sampling events. If the perf subsystem
+is informed that its samples are exceeding this limit, it
+will drop its sampling frequency to attempt to reduce its CPU
+usage.
+
+Some perf sampling happens in NMIs. If these samples
+unexpectedly take too long to execute, the NMIs can become
+stacked up next to each other so much that nothing else is
+allowed to execute.
+
+0: disable the mechanism. Do not monitor or correct perf's
+ sampling rate no matter how CPU time it takes.
+
+1-100: attempt to throttle perf's sample rate to this
+ percentage of CPU. Note: the kernel calculates an
+ "expected" length of each sample event. 100 here means
+ 100% of that expected length. Even if this is set to
+ 100, you may still see sample throttling if this
+ length is exceeded. Set to 0 if you truly do not care
+ how much CPU is consumed.
+
+==============================================================
+
pid_max:
@@ -542,6 +587,19 @@
==============================================================
+shmall:
+
+This parameter sets the total amount of shared memory pages that
+can be used system wide. Hence, SHMALL should always be at least
+ceil(shmmax/PAGE_SIZE).
+
+If you are not sure what the default PAGE_SIZE is on your Linux
+system, you can run the following command:
+
+# getconf PAGE_SIZE
+
+==============================================================
+
shmmax:
This value can be used to query and set the run time limit
@@ -572,15 +630,6 @@
==============================================================
-softlockup_thresh:
-
-This value can be used to lower the softlockup tolerance threshold. The
-default threshold is 60 seconds. If a cpu is locked up for 60 seconds,
-the kernel complains. Valid values are 1-60 seconds. Setting this
-tunable to zero will disable the softlockup detection altogether.
-
-==============================================================
-
tainted:
Non-zero if the kernel has been tainted. Numeric values, which
@@ -616,3 +665,16 @@
NMI switch that most IA32 servers have fires unknown NMI up, for
example. If a system hangs up, try pressing the NMI switch.
+
+==============================================================
+
+watchdog_thresh:
+
+This value can be used to control the frequency of hrtimer and NMI
+events and the soft and hard lockup thresholds. The default threshold
+is 10 seconds.
+
+The softlockup threshold is (2 * watchdog_thresh). Setting this
+tunable to zero will disable lockup detection altogether.
+
+==============================================================
diff --git a/Documentation/sysctl/net.txt b/Documentation/sysctl/net.txt
index 98335b7..1c15043 100644
--- a/Documentation/sysctl/net.txt
+++ b/Documentation/sysctl/net.txt
@@ -1,4 +1,4 @@
-Documentation for /proc/sys/net/* kernel version 2.4.0-test11-pre4
+Documentation for /proc/sys/net/*
(c) 1999 Terrehon Bowden <terrehon@pacbell.net>
Bodo Bauer <bb@ricochet.net>
(c) 2000 Jorge Nerin <comandante@zaralinux.com>
@@ -9,10 +9,10 @@
==============================================================
This file contains the documentation for the sysctl files in
-/proc/sys/net and is valid for Linux kernel version 2.4.0-test11-pre4.
+/proc/sys/net
The interface to the networking parts of the kernel is located in
-/proc/sys/net. The following table shows all possible subdirectories.You may
+/proc/sys/net. The following table shows all possible subdirectories. You may
see only some of them, depending on your kernel's configuration.
@@ -26,7 +26,7 @@
ipv4 IP version 4 x25 X.25 protocol
ipx IPX token-ring IBM token ring
bridge Bridging decnet DEC net
- ipv6 IP version 6
+ ipv6 IP version 6 tipc TIPC
..............................................................................
1. /proc/sys/net/core - Network core options
@@ -50,6 +50,30 @@
it's a Per-CPU variable.
Default: 64
+busy_read
+----------------
+Low latency busy poll timeout for socket reads. (needs CONFIG_NET_LL_RX_POLL)
+Approximate time in us to busy loop waiting for packets on the device queue.
+This sets the default value of the SO_BUSY_POLL socket option.
+Can be set or overridden per socket by setting socket option SO_BUSY_POLL,
+which is the preferred method of enabling. If you need to enable the feature
+globally via sysctl, a value of 50 is recommended.
+Will increase power usage.
+Default: 0 (off)
+
+busy_poll
+----------------
+Low latency busy poll timeout for poll and select. (needs CONFIG_NET_LL_RX_POLL)
+Approximate time in us to busy loop waiting for events.
+Recommended value depends on the number of sockets you poll on.
+For several sockets 50, for several hundreds 100.
+For more than that you probably want to use epoll.
+Note that only sockets with SO_BUSY_POLL set will be busy polled,
+so you want to either selectively set SO_BUSY_POLL on those sockets or set
+sysctl.net.busy_read globally.
+Will increase power usage.
+Default: 0 (off)
+
rmem_default
------------
@@ -93,8 +117,7 @@
Maximum number of packets taken from all interfaces in one polling cycle (NAPI
poll). In one polling cycle interfaces which are registered to polling are
-probed in a round-robin manner. The limit of packets in one such probe can be
-set per-device via sysfs class/net/<device>/weight .
+probed in a round-robin manner.
netdev_max_backlog
------------------
@@ -201,3 +224,18 @@
The /proc/net/ipx_route table holds a list of IPX routes. For each route it
gives the destination network, the router node (or Directly) and the network
address of the router (or Connected) for internal networks.
+
+6. TIPC
+-------------------------------------------------------
+
+The TIPC protocol now has a tunable for the receive memory, similar to the
+tcp_rmem - i.e. a vector of 3 INTEGERs: (min, default, max)
+
+ # cat /proc/sys/net/tipc/tipc_rmem
+ 4252725 34021800 68043600
+ #
+
+The max value is set to CONN_OVERLOAD_LIMIT, and the default and min values
+are scaled (shifted) versions of that same value. Note that the min value
+is not at this point in time used in any meaningful way, but the triplet is
+preserved in order to be consistent with things like tcp_rmem.
diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt
index 078701f..36ecc26 100644
--- a/Documentation/sysctl/vm.txt
+++ b/Documentation/sysctl/vm.txt
@@ -18,6 +18,7 @@
Currently, these files are in /proc/sys/vm:
+- admin_reserve_kbytes
- block_dump
- compact_memory
- dirty_background_bytes
@@ -53,11 +54,41 @@
- percpu_pagelist_fraction
- stat_interval
- swappiness
+- user_reserve_kbytes
- vfs_cache_pressure
- zone_reclaim_mode
==============================================================
+admin_reserve_kbytes
+
+The amount of free memory in the system that should be reserved for users
+with the capability cap_sys_admin.
+
+admin_reserve_kbytes defaults to min(3% of free pages, 8MB)
+
+That should provide enough for the admin to log in and kill a process,
+if necessary, under the default overcommit 'guess' mode.
+
+Systems running under overcommit 'never' should increase this to account
+for the full Virtual Memory Size of programs used to recover. Otherwise,
+root may not be able to log in to recover the system.
+
+How do you calculate a minimum useful reserve?
+
+sshd or login + bash (or some other shell) + top (or ps, kill, etc.)
+
+For overcommit 'guess', we can sum resident set sizes (RSS).
+On x86_64 this is about 8MB.
+
+For overcommit 'never', we can take the max of their virtual sizes (VSZ)
+and add the sum of their RSS.
+On x86_64 this is about 128MB.
+
+Changing this takes effect whenever an application requests memory.
+
+==============================================================
+
block_dump
block_dump enables block I/O debugging when set to a nonzero value. More
@@ -479,7 +510,7 @@
will select "node" order in following case.
(1) if the DMA zone does not exist or
(2) if the DMA zone comprises greater than 50% of the available memory or
-(3) if any node's DMA zone comprises greater than 60% of its local memory and
+(3) if any node's DMA zone comprises greater than 70% of its local memory and
the amount of local memory is big enough.
Otherwise, "zone" order will be selected. Default order is recommended unless
@@ -542,6 +573,7 @@
When this flag is 2, the kernel uses a "never overcommit"
policy that attempts to prevent any overcommit of memory.
+Note that user_reserve_kbytes affects this policy.
This feature can be very useful because there are a lot of
programs that malloc() huge amounts of memory "just-in-case"
@@ -645,6 +677,24 @@
==============================================================
+- user_reserve_kbytes
+
+When overcommit_memory is set to 2, "never overommit" mode, reserve
+min(3% of current process size, user_reserve_kbytes) of free memory.
+This is intended to prevent a user from starting a single memory hogging
+process, such that they cannot recover (kill the hog).
+
+user_reserve_kbytes defaults to min(3% of the current process size, 128MB).
+
+If this is reduced to zero, then the user will be allowed to allocate
+all free memory with a single process, minus admin_reserve_kbytes.
+Any subsequent attempts to execute a command will result in
+"fork: Cannot allocate memory".
+
+Changing this takes effect whenever an application requests memory.
+
+==============================================================
+
vfs_cache_pressure
------------------
diff --git a/Documentation/sysrq.txt b/Documentation/sysrq.txt
index 2a4cdda..8cb4d78 100644
--- a/Documentation/sysrq.txt
+++ b/Documentation/sysrq.txt
@@ -129,9 +129,9 @@
* Okay, so what can I use them for?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Well, un'R'aw is very handy when your X server or a svgalib program crashes.
+Well, unraw(r) is very handy when your X server or a svgalib program crashes.
-sa'K' (Secure Access Key) is useful when you want to be sure there is no
+sak(k) (Secure Access Key) is useful when you want to be sure there is no
trojan program running at console which could grab your password
when you would try to login. It will kill all programs on given console,
thus letting you make sure that the login prompt you see is actually
@@ -143,20 +143,20 @@
useful when you want to exit a program that will not let you switch consoles.
(For example, X or a svgalib program.)
-re'B'oot is good when you're unable to shut down. But you should also 'S'ync
-and 'U'mount first.
+reboot(b) is good when you're unable to shut down. But you should also
+sync(s) and umount(u) first.
-'C'rash can be used to manually trigger a crashdump when the system is hung.
+crash(c) can be used to manually trigger a crashdump when the system is hung.
Note that this just triggers a crash if there is no dump mechanism available.
-'S'ync is great when your system is locked up, it allows you to sync your
+sync(s) is great when your system is locked up, it allows you to sync your
disks and will certainly lessen the chance of data loss and fscking. Note
that the sync hasn't taken place until you see the "OK" and "Done" appear
on the screen. (If the kernel is really in strife, you may not ever get the
OK or Done message...)
-'U'mount is basically useful in the same ways as 'S'ync. I generally 'S'ync,
-'U'mount, then re'B'oot when my system locks. It's saved me many a fsck.
+umount(u) is basically useful in the same ways as sync(s). I generally sync(s),
+umount(u), then reboot(b) when my system locks. It's saved me many a fsck.
Again, the unmount (remount read-only) hasn't taken place until you see the
"OK" and "Done" message appear on the screen.
@@ -165,11 +165,11 @@
the most urgent kernel messages from reaching your console. (They will
still be logged if syslogd/klogd are alive, though.)
-t'E'rm and k'I'll are useful if you have some sort of runaway process you
+term(e) and kill(i) are useful if you have some sort of runaway process you
are unable to kill any other way, especially if it's spawning other
processes.
-"'J'ust thaw it" is useful if your system becomes unresponsive due to a frozen
+"just thaw it(j)" is useful if your system becomes unresponsive due to a frozen
(probably root) filesystem via the FIFREEZE ioctl.
* Sometimes SysRq seems to get 'stuck' after using it, what can I do?
diff --git a/Documentation/thermal/exynos_thermal_emulation b/Documentation/thermal/exynos_thermal_emulation
new file mode 100644
index 0000000..b15efec
--- /dev/null
+++ b/Documentation/thermal/exynos_thermal_emulation
@@ -0,0 +1,53 @@
+EXYNOS EMULATION MODE
+========================
+
+Copyright (C) 2012 Samsung Electronics
+
+Written by Jonghwa Lee <jonghwa3.lee@samsung.com>
+
+Description
+-----------
+
+Exynos 4x12 (4212, 4412) and 5 series provide emulation mode for thermal management unit.
+Thermal emulation mode supports software debug for TMU's operation. User can set temperature
+manually with software code and TMU will read current temperature from user value not from
+sensor's value.
+
+Enabling CONFIG_THERMAL_EMULATION option will make this support available.
+When it's enabled, sysfs node will be created as
+/sys/devices/virtual/thermal/thermal_zone'zone id'/emul_temp.
+
+The sysfs node, 'emul_node', will contain value 0 for the initial state. When you input any
+temperature you want to update to sysfs node, it automatically enable emulation mode and
+current temperature will be changed into it.
+(Exynos also supports user changeable delay time which would be used to delay of
+ changing temperature. However, this node only uses same delay of real sensing time, 938us.)
+
+Exynos emulation mode requires synchronous of value changing and enabling. It means when you
+want to update the any value of delay or next temperature, then you have to enable emulation
+mode at the same time. (Or you have to keep the mode enabling.) If you don't, it fails to
+change the value to updated one and just use last succeessful value repeatedly. That's why
+this node gives users the right to change termerpature only. Just one interface makes it more
+simply to use.
+
+Disabling emulation mode only requires writing value 0 to sysfs node.
+
+
+TEMP 120 |
+ |
+ 100 |
+ |
+ 80 |
+ | +-----------
+ 60 | | |
+ | +-------------| |
+ 40 | | | |
+ | | | |
+ 20 | | | +----------
+ | | | | |
+ 0 |______________|_____________|__________|__________|_________
+ A A A A TIME
+ |<----->| |<----->| |<----->| |
+ | 938us | | | | | |
+emulation : 0 50 | 70 | 20 | 0
+current temp : sensor 50 70 20 sensor
diff --git a/Documentation/thermal/intel_powerclamp.txt b/Documentation/thermal/intel_powerclamp.txt
new file mode 100644
index 0000000..332de4a
--- /dev/null
+++ b/Documentation/thermal/intel_powerclamp.txt
@@ -0,0 +1,307 @@
+ =======================
+ INTEL POWERCLAMP DRIVER
+ =======================
+By: Arjan van de Ven <arjan@linux.intel.com>
+ Jacob Pan <jacob.jun.pan@linux.intel.com>
+
+Contents:
+ (*) Introduction
+ - Goals and Objectives
+
+ (*) Theory of Operation
+ - Idle Injection
+ - Calibration
+
+ (*) Performance Analysis
+ - Effectiveness and Limitations
+ - Power vs Performance
+ - Scalability
+ - Calibration
+ - Comparison with Alternative Techniques
+
+ (*) Usage and Interfaces
+ - Generic Thermal Layer (sysfs)
+ - Kernel APIs (TBD)
+
+============
+INTRODUCTION
+============
+
+Consider the situation where a system’s power consumption must be
+reduced at runtime, due to power budget, thermal constraint, or noise
+level, and where active cooling is not preferred. Software managed
+passive power reduction must be performed to prevent the hardware
+actions that are designed for catastrophic scenarios.
+
+Currently, P-states, T-states (clock modulation), and CPU offlining
+are used for CPU throttling.
+
+On Intel CPUs, C-states provide effective power reduction, but so far
+they’re only used opportunistically, based on workload. With the
+development of intel_powerclamp driver, the method of synchronizing
+idle injection across all online CPU threads was introduced. The goal
+is to achieve forced and controllable C-state residency.
+
+Test/Analysis has been made in the areas of power, performance,
+scalability, and user experience. In many cases, clear advantage is
+shown over taking the CPU offline or modulating the CPU clock.
+
+
+===================
+THEORY OF OPERATION
+===================
+
+Idle Injection
+--------------
+
+On modern Intel processors (Nehalem or later), package level C-state
+residency is available in MSRs, thus also available to the kernel.
+
+These MSRs are:
+ #define MSR_PKG_C2_RESIDENCY 0x60D
+ #define MSR_PKG_C3_RESIDENCY 0x3F8
+ #define MSR_PKG_C6_RESIDENCY 0x3F9
+ #define MSR_PKG_C7_RESIDENCY 0x3FA
+
+If the kernel can also inject idle time to the system, then a
+closed-loop control system can be established that manages package
+level C-state. The intel_powerclamp driver is conceived as such a
+control system, where the target set point is a user-selected idle
+ratio (based on power reduction), and the error is the difference
+between the actual package level C-state residency ratio and the target idle
+ratio.
+
+Injection is controlled by high priority kernel threads, spawned for
+each online CPU.
+
+These kernel threads, with SCHED_FIFO class, are created to perform
+clamping actions of controlled duty ratio and duration. Each per-CPU
+thread synchronizes its idle time and duration, based on the rounding
+of jiffies, so accumulated errors can be prevented to avoid a jittery
+effect. Threads are also bound to the CPU such that they cannot be
+migrated, unless the CPU is taken offline. In this case, threads
+belong to the offlined CPUs will be terminated immediately.
+
+Running as SCHED_FIFO and relatively high priority, also allows such
+scheme to work for both preemptable and non-preemptable kernels.
+Alignment of idle time around jiffies ensures scalability for HZ
+values. This effect can be better visualized using a Perf timechart.
+The following diagram shows the behavior of kernel thread
+kidle_inject/cpu. During idle injection, it runs monitor/mwait idle
+for a given "duration", then relinquishes the CPU to other tasks,
+until the next time interval.
+
+The NOHZ schedule tick is disabled during idle time, but interrupts
+are not masked. Tests show that the extra wakeups from scheduler tick
+have a dramatic impact on the effectiveness of the powerclamp driver
+on large scale systems (Westmere system with 80 processors).
+
+CPU0
+ ____________ ____________
+kidle_inject/0 | sleep | mwait | sleep |
+ _________| |________| |_______
+ duration
+CPU1
+ ____________ ____________
+kidle_inject/1 | sleep | mwait | sleep |
+ _________| |________| |_______
+ ^
+ |
+ |
+ roundup(jiffies, interval)
+
+Only one CPU is allowed to collect statistics and update global
+control parameters. This CPU is referred to as the controlling CPU in
+this document. The controlling CPU is elected at runtime, with a
+policy that favors BSP, taking into account the possibility of a CPU
+hot-plug.
+
+In terms of dynamics of the idle control system, package level idle
+time is considered largely as a non-causal system where its behavior
+cannot be based on the past or current input. Therefore, the
+intel_powerclamp driver attempts to enforce the desired idle time
+instantly as given input (target idle ratio). After injection,
+powerclamp moniors the actual idle for a given time window and adjust
+the next injection accordingly to avoid over/under correction.
+
+When used in a causal control system, such as a temperature control,
+it is up to the user of this driver to implement algorithms where
+past samples and outputs are included in the feedback. For example, a
+PID-based thermal controller can use the powerclamp driver to
+maintain a desired target temperature, based on integral and
+derivative gains of the past samples.
+
+
+
+Calibration
+-----------
+During scalability testing, it is observed that synchronized actions
+among CPUs become challenging as the number of cores grows. This is
+also true for the ability of a system to enter package level C-states.
+
+To make sure the intel_powerclamp driver scales well, online
+calibration is implemented. The goals for doing such a calibration
+are:
+
+a) determine the effective range of idle injection ratio
+b) determine the amount of compensation needed at each target ratio
+
+Compensation to each target ratio consists of two parts:
+
+ a) steady state error compensation
+ This is to offset the error occurring when the system can
+ enter idle without extra wakeups (such as external interrupts).
+
+ b) dynamic error compensation
+ When an excessive amount of wakeups occurs during idle, an
+ additional idle ratio can be added to quiet interrupts, by
+ slowing down CPU activities.
+
+A debugfs file is provided for the user to examine compensation
+progress and results, such as on a Westmere system.
+[jacob@nex01 ~]$ cat
+/sys/kernel/debug/intel_powerclamp/powerclamp_calib
+controlling cpu: 0
+pct confidence steady dynamic (compensation)
+0 0 0 0
+1 1 0 0
+2 1 1 0
+3 3 1 0
+4 3 1 0
+5 3 1 0
+6 3 1 0
+7 3 1 0
+8 3 1 0
+...
+30 3 2 0
+31 3 2 0
+32 3 1 0
+33 3 2 0
+34 3 1 0
+35 3 2 0
+36 3 1 0
+37 3 2 0
+38 3 1 0
+39 3 2 0
+40 3 3 0
+41 3 1 0
+42 3 2 0
+43 3 1 0
+44 3 1 0
+45 3 2 0
+46 3 3 0
+47 3 0 0
+48 3 2 0
+49 3 3 0
+
+Calibration occurs during runtime. No offline method is available.
+Steady state compensation is used only when confidence levels of all
+adjacent ratios have reached satisfactory level. A confidence level
+is accumulated based on clean data collected at runtime. Data
+collected during a period without extra interrupts is considered
+clean.
+
+To compensate for excessive amounts of wakeup during idle, additional
+idle time is injected when such a condition is detected. Currently,
+we have a simple algorithm to double the injection ratio. A possible
+enhancement might be to throttle the offending IRQ, such as delaying
+EOI for level triggered interrupts. But it is a challenge to be
+non-intrusive to the scheduler or the IRQ core code.
+
+
+CPU Online/Offline
+------------------
+Per-CPU kernel threads are started/stopped upon receiving
+notifications of CPU hotplug activities. The intel_powerclamp driver
+keeps track of clamping kernel threads, even after they are migrated
+to other CPUs, after a CPU offline event.
+
+
+=====================
+Performance Analysis
+=====================
+This section describes the general performance data collected on
+multiple systems, including Westmere (80P) and Ivy Bridge (4P, 8P).
+
+Effectiveness and Limitations
+-----------------------------
+The maximum range that idle injection is allowed is capped at 50
+percent. As mentioned earlier, since interrupts are allowed during
+forced idle time, excessive interrupts could result in less
+effectiveness. The extreme case would be doing a ping -f to generated
+flooded network interrupts without much CPU acknowledgement. In this
+case, little can be done from the idle injection threads. In most
+normal cases, such as scp a large file, applications can be throttled
+by the powerclamp driver, since slowing down the CPU also slows down
+network protocol processing, which in turn reduces interrupts.
+
+When control parameters change at runtime by the controlling CPU, it
+may take an additional period for the rest of the CPUs to catch up
+with the changes. During this time, idle injection is out of sync,
+thus not able to enter package C- states at the expected ratio. But
+this effect is minor, in that in most cases change to the target
+ratio is updated much less frequently than the idle injection
+frequency.
+
+Scalability
+-----------
+Tests also show a minor, but measurable, difference between the 4P/8P
+Ivy Bridge system and the 80P Westmere server under 50% idle ratio.
+More compensation is needed on Westmere for the same amount of
+target idle ratio. The compensation also increases as the idle ratio
+gets larger. The above reason constitutes the need for the
+calibration code.
+
+On the IVB 8P system, compared to an offline CPU, powerclamp can
+achieve up to 40% better performance per watt. (measured by a spin
+counter summed over per CPU counting threads spawned for all running
+CPUs).
+
+====================
+Usage and Interfaces
+====================
+The powerclamp driver is registered to the generic thermal layer as a
+cooling device. Currently, it’s not bound to any thermal zones.
+
+jacob@chromoly:/sys/class/thermal/cooling_device14$ grep . *
+cur_state:0
+max_state:50
+type:intel_powerclamp
+
+Example usage:
+- To inject 25% idle time
+$ sudo sh -c "echo 25 > /sys/class/thermal/cooling_device80/cur_state
+"
+
+If the system is not busy and has more than 25% idle time already,
+then the powerclamp driver will not start idle injection. Using Top
+will not show idle injection kernel threads.
+
+If the system is busy (spin test below) and has less than 25% natural
+idle time, powerclamp kernel threads will do idle injection, which
+appear running to the scheduler. But the overall system idle is still
+reflected. In this example, 24.1% idle is shown. This helps the
+system admin or user determine the cause of slowdown, when a
+powerclamp driver is in action.
+
+
+Tasks: 197 total, 1 running, 196 sleeping, 0 stopped, 0 zombie
+Cpu(s): 71.2%us, 4.7%sy, 0.0%ni, 24.1%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
+Mem: 3943228k total, 1689632k used, 2253596k free, 74960k buffers
+Swap: 4087804k total, 0k used, 4087804k free, 945336k cached
+
+ PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
+ 3352 jacob 20 0 262m 644 428 S 286 0.0 0:17.16 spin
+ 3341 root -51 0 0 0 0 D 25 0.0 0:01.62 kidle_inject/0
+ 3344 root -51 0 0 0 0 D 25 0.0 0:01.60 kidle_inject/3
+ 3342 root -51 0 0 0 0 D 25 0.0 0:01.61 kidle_inject/1
+ 3343 root -51 0 0 0 0 D 25 0.0 0:01.60 kidle_inject/2
+ 2935 jacob 20 0 696m 125m 35m S 5 3.3 0:31.11 firefox
+ 1546 root 20 0 158m 20m 6640 S 3 0.5 0:26.97 Xorg
+ 2100 jacob 20 0 1223m 88m 30m S 3 2.3 0:23.68 compiz
+
+Tests have shown that by using the powerclamp driver as a cooling
+device, a PID based userspace thermal controller can manage to
+control CPU temperature effectively, when no other thermal influence
+is added. For example, a UltraBook user can compile the kernel under
+certain temperature (below most active trip points).
diff --git a/Documentation/thermal/nouveau_thermal b/Documentation/thermal/nouveau_thermal
new file mode 100644
index 0000000..efceb78
--- /dev/null
+++ b/Documentation/thermal/nouveau_thermal
@@ -0,0 +1,81 @@
+Kernel driver nouveau
+===================
+
+Supported chips:
+* NV43+
+
+Authors: Martin Peres (mupuf) <martin.peres@labri.fr>
+
+Description
+---------
+
+This driver allows to read the GPU core temperature, drive the GPU fan and
+set temperature alarms.
+
+Currently, due to the absence of in-kernel API to access HWMON drivers, Nouveau
+cannot access any of the i2c external monitoring chips it may find. If you
+have one of those, temperature and/or fan management through Nouveau's HWMON
+interface is likely not to work. This document may then not cover your situation
+entirely.
+
+Temperature management
+--------------------
+
+Temperature is exposed under as a read-only HWMON attribute temp1_input.
+
+In order to protect the GPU from overheating, Nouveau supports 4 configurable
+temperature thresholds:
+
+ * Fan_boost: Fan speed is set to 100% when reaching this temperature;
+ * Downclock: The GPU will be downclocked to reduce its power dissipation;
+ * Critical: The GPU is put on hold to further lower power dissipation;
+ * Shutdown: Shut the computer down to protect your GPU.
+
+WARNING: Some of these thresholds may not be used by Nouveau depending
+on your chipset.
+
+The default value for these thresholds comes from the GPU's vbios. These
+thresholds can be configured thanks to the following HWMON attributes:
+
+ * Fan_boost: temp1_auto_point1_temp and temp1_auto_point1_temp_hyst;
+ * Downclock: temp1_max and temp1_max_hyst;
+ * Critical: temp1_crit and temp1_crit_hyst;
+ * Shutdown: temp1_emergency and temp1_emergency_hyst.
+
+NOTE: Remember that the values are stored as milli degrees Celcius. Don't forget
+to multiply!
+
+Fan management
+------------
+
+Not all cards have a drivable fan. If you do, then the following HWMON
+attributes should be available:
+
+ * pwm1_enable: Current fan management mode (NONE, MANUAL or AUTO);
+ * pwm1: Current PWM value (power percentage);
+ * pwm1_min: The minimum PWM speed allowed;
+ * pwm1_max: The maximum PWM speed allowed (bypassed when hitting Fan_boost);
+
+You may also have the following attribute:
+
+ * fan1_input: Speed in RPM of your fan.
+
+Your fan can be driven in different modes:
+
+ * 0: The fan is left untouched;
+ * 1: The fan can be driven in manual (use pwm1 to change the speed);
+ * 2; The fan is driven automatically depending on the temperature.
+
+NOTE: Be sure to use the manual mode if you want to drive the fan speed manually
+
+NOTE2: Not all fan management modes may be supported on all chipsets. We are
+working on it.
+
+Bug reports
+---------
+
+Thermal management on Nouveau is new and may not work on all cards. If you have
+inquiries, please ping mupuf on IRC (#nouveau, freenode).
+
+Bug reports should be filled on Freedesktop's bug tracker. Please follow
+http://nouveau.freedesktop.org/wiki/Bugs
diff --git a/Documentation/thermal/sysfs-api.txt b/Documentation/thermal/sysfs-api.txt
index 88c0233..a71bd5b 100644
--- a/Documentation/thermal/sysfs-api.txt
+++ b/Documentation/thermal/sysfs-api.txt
@@ -31,15 +31,17 @@
1. thermal sysfs driver interface functions
1.1 thermal zone device interface
-1.1.1 struct thermal_zone_device *thermal_zone_device_register(char *name,
+1.1.1 struct thermal_zone_device *thermal_zone_device_register(char *type,
int trips, int mask, void *devdata,
- struct thermal_zone_device_ops *ops)
+ struct thermal_zone_device_ops *ops,
+ const struct thermal_zone_params *tzp,
+ int passive_delay, int polling_delay))
This interface function adds a new thermal zone device (sensor) to
/sys/class/thermal folder as thermal_zone[0-*]. It tries to bind all the
thermal cooling devices registered at the same time.
- name: the thermal zone name.
+ type: the thermal zone type.
trips: the total number of trip points this thermal zone supports.
mask: Bit string: If 'n'th bit is set, then trip point 'n' is writeable.
devdata: device private data
@@ -55,6 +57,14 @@
.get_trip_type: get the type of certain trip point.
.get_trip_temp: get the temperature above which the certain trip point
will be fired.
+ .set_emul_temp: set the emulation temperature which helps in debugging
+ different threshold temperature points.
+ tzp: thermal zone platform parameters.
+ passive_delay: number of milliseconds to wait between polls when
+ performing passive cooling.
+ polling_delay: number of milliseconds to wait between polls when checking
+ whether trip points have been crossed (0 for interrupt driven systems).
+
1.1.2 void thermal_zone_device_unregister(struct thermal_zone_device *tz)
@@ -153,6 +163,7 @@
|---trip_point_[0-*]_temp: Trip point temperature
|---trip_point_[0-*]_type: Trip point type
|---trip_point_[0-*]_hyst: Hysteresis value for this trip point
+ |---emul_temp: Emulated temperature set node
Thermal cooling device sys I/F, created once it's registered:
/sys/class/thermal/cooling_device[0-*]:
@@ -252,6 +263,20 @@
Valid values: 0 (disabled) or greater than 1000
RW, Optional
+emul_temp
+ Interface to set the emulated temperature method in thermal zone
+ (sensor). After setting this temperature, the thermal zone may pass
+ this temperature to platform emulation function if registered or
+ cache it locally. This is useful in debugging different temperature
+ threshold and its associated cooling action. This is write only node
+ and writing 0 on this node should disable emulation.
+ Unit: millidegree Celsius
+ WO, Optional
+
+ WARNING: Be careful while enabling this option on production systems,
+ because userland can easily disable the thermal policy by simply
+ flooding this sysfs node with low temperature values.
+
*****************************
* Cooling device attributes *
*****************************
@@ -329,8 +354,9 @@
netlink event. Netlink socket initialization is done during the _init_
of the framework. Drivers which intend to use the notification mechanism
just need to call thermal_generate_netlink_event() with two arguments viz
-(originator, event). Typically the originator will be an integer assigned
-to a thermal_zone_device when it registers itself with the framework. The
+(originator, event). The originator is a pointer to struct thermal_zone_device
+from where the event has been originated. An integer which represents the
+thermal zone device will be used in the message to identify the zone. The
event will be one of:{THERMAL_AUX0, THERMAL_AUX1, THERMAL_CRITICAL,
THERMAL_DEV_FAULT}. Notification can be sent when the current temperature
crosses any of the configured thresholds.
@@ -349,7 +375,7 @@
{thermal_zone, cooling_device, trip_point} combination. Returns NULL
if such an instance does not exist.
-5.3:notify_thermal_framework:
+5.3:thermal_notify_framework:
This function handles the trip events from sensor drivers. It starts
throttling the cooling devices according to the policy configured.
For CRITICAL and HOT trip points, this notifies the respective drivers,
@@ -361,11 +387,3 @@
This function serves as an arbitrator to set the state of a cooling
device. It sets the cooling device to the deepest cooling state if
possible.
-
-5.5:thermal_register_governor:
-This function lets the various thermal governors to register themselves
-with the Thermal framework. At run time, depending on a zone's platform
-data, a particular governor is used for throttling.
-
-5.6:thermal_unregister_governor:
-This function unregisters a governor from the thermal framework.
diff --git a/Documentation/thermal/x86_pkg_temperature_thermal b/Documentation/thermal/x86_pkg_temperature_thermal
new file mode 100644
index 0000000..17a3a4c
--- /dev/null
+++ b/Documentation/thermal/x86_pkg_temperature_thermal
@@ -0,0 +1,47 @@
+Kernel driver: x86_pkg_temp_thermal
+===================
+
+Supported chips:
+* x86: with package level thermal management
+(Verify using: CPUID.06H:EAX[bit 6] =1)
+
+Authors: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
+
+Reference
+---
+Intel® 64 and IA-32 Architectures Software Developer’s Manual (Jan, 2013):
+Chapter 14.6: PACKAGE LEVEL THERMAL MANAGEMENT
+
+Description
+---------
+
+This driver register CPU digital temperature package level sensor as a thermal
+zone with maximum two user mode configurable trip points. Number of trip points
+depends on the capability of the package. Once the trip point is violated,
+user mode can receive notification via thermal notification mechanism and can
+take any action to control temperature.
+
+
+Threshold management
+--------------------
+Each package will register as a thermal zone under /sys/class/thermal.
+Example:
+/sys/class/thermal/thermal_zone1
+
+This contains two trip points:
+- trip_point_0_temp
+- trip_point_1_temp
+
+User can set any temperature between 0 to TJ-Max temperature. Temperature units
+are in milli-degree Celsius. Refer to "Documentation/thermal/sysfs-api.txt" for
+thermal sys-fs details.
+
+Any value other than 0 in these trip points, can trigger thermal notifications.
+Setting 0, stops sending thermal notifications.
+
+Thermal notifications: To get kobject-uevent notifications, set the thermal zone
+policy to "user_space". For example: echo -n "user_space" > policy
+
+
+
+
diff --git a/Documentation/this_cpu_ops.txt b/Documentation/this_cpu_ops.txt
new file mode 100644
index 0000000..1a4ce7e
--- /dev/null
+++ b/Documentation/this_cpu_ops.txt
@@ -0,0 +1,205 @@
+this_cpu operations
+-------------------
+
+this_cpu operations are a way of optimizing access to per cpu
+variables associated with the *currently* executing processor through
+the use of segment registers (or a dedicated register where the cpu
+permanently stored the beginning of the per cpu area for a specific
+processor).
+
+The this_cpu operations add a per cpu variable offset to the processor
+specific percpu base and encode that operation in the instruction
+operating on the per cpu variable.
+
+This means there are no atomicity issues between the calculation of
+the offset and the operation on the data. Therefore it is not
+necessary to disable preempt or interrupts to ensure that the
+processor is not changed between the calculation of the address and
+the operation on the data.
+
+Read-modify-write operations are of particular interest. Frequently
+processors have special lower latency instructions that can operate
+without the typical synchronization overhead but still provide some
+sort of relaxed atomicity guarantee. The x86 for example can execute
+RMV (Read Modify Write) instructions like inc/dec/cmpxchg without the
+lock prefix and the associated latency penalty.
+
+Access to the variable without the lock prefix is not synchronized but
+synchronization is not necessary since we are dealing with per cpu
+data specific to the currently executing processor. Only the current
+processor should be accessing that variable and therefore there are no
+concurrency issues with other processors in the system.
+
+On x86 the fs: or the gs: segment registers contain the base of the
+per cpu area. It is then possible to simply use the segment override
+to relocate a per cpu relative address to the proper per cpu area for
+the processor. So the relocation to the per cpu base is encoded in the
+instruction via a segment register prefix.
+
+For example:
+
+ DEFINE_PER_CPU(int, x);
+ int z;
+
+ z = this_cpu_read(x);
+
+results in a single instruction
+
+ mov ax, gs:[x]
+
+instead of a sequence of calculation of the address and then a fetch
+from that address which occurs with the percpu operations. Before
+this_cpu_ops such sequence also required preempt disable/enable to
+prevent the kernel from moving the thread to a different processor
+while the calculation is performed.
+
+The main use of the this_cpu operations has been to optimize counter
+operations.
+
+ this_cpu_inc(x)
+
+results in the following single instruction (no lock prefix!)
+
+ inc gs:[x]
+
+instead of the following operations required if there is no segment
+register.
+
+ int *y;
+ int cpu;
+
+ cpu = get_cpu();
+ y = per_cpu_ptr(&x, cpu);
+ (*y)++;
+ put_cpu();
+
+Note that these operations can only be used on percpu data that is
+reserved for a specific processor. Without disabling preemption in the
+surrounding code this_cpu_inc() will only guarantee that one of the
+percpu counters is correctly incremented. However, there is no
+guarantee that the OS will not move the process directly before or
+after the this_cpu instruction is executed. In general this means that
+the value of the individual counters for each processor are
+meaningless. The sum of all the per cpu counters is the only value
+that is of interest.
+
+Per cpu variables are used for performance reasons. Bouncing cache
+lines can be avoided if multiple processors concurrently go through
+the same code paths. Since each processor has its own per cpu
+variables no concurrent cacheline updates take place. The price that
+has to be paid for this optimization is the need to add up the per cpu
+counters when the value of the counter is needed.
+
+
+Special operations:
+-------------------
+
+ y = this_cpu_ptr(&x)
+
+Takes the offset of a per cpu variable (&x !) and returns the address
+of the per cpu variable that belongs to the currently executing
+processor. this_cpu_ptr avoids multiple steps that the common
+get_cpu/put_cpu sequence requires. No processor number is
+available. Instead the offset of the local per cpu area is simply
+added to the percpu offset.
+
+
+
+Per cpu variables and offsets
+-----------------------------
+
+Per cpu variables have *offsets* to the beginning of the percpu
+area. They do not have addresses although they look like that in the
+code. Offsets cannot be directly dereferenced. The offset must be
+added to a base pointer of a percpu area of a processor in order to
+form a valid address.
+
+Therefore the use of x or &x outside of the context of per cpu
+operations is invalid and will generally be treated like a NULL
+pointer dereference.
+
+In the context of per cpu operations
+
+ x is a per cpu variable. Most this_cpu operations take a cpu
+ variable.
+
+ &x is the *offset* a per cpu variable. this_cpu_ptr() takes
+ the offset of a per cpu variable which makes this look a bit
+ strange.
+
+
+
+Operations on a field of a per cpu structure
+--------------------------------------------
+
+Let's say we have a percpu structure
+
+ struct s {
+ int n,m;
+ };
+
+ DEFINE_PER_CPU(struct s, p);
+
+
+Operations on these fields are straightforward
+
+ this_cpu_inc(p.m)
+
+ z = this_cpu_cmpxchg(p.m, 0, 1);
+
+
+If we have an offset to struct s:
+
+ struct s __percpu *ps = &p;
+
+ z = this_cpu_dec(ps->m);
+
+ z = this_cpu_inc_return(ps->n);
+
+
+The calculation of the pointer may require the use of this_cpu_ptr()
+if we do not make use of this_cpu ops later to manipulate fields:
+
+ struct s *pp;
+
+ pp = this_cpu_ptr(&p);
+
+ pp->m--;
+
+ z = pp->n++;
+
+
+Variants of this_cpu ops
+-------------------------
+
+this_cpu ops are interrupt safe. Some architecture do not support
+these per cpu local operations. In that case the operation must be
+replaced by code that disables interrupts, then does the operations
+that are guaranteed to be atomic and then reenable interrupts. Doing
+so is expensive. If there are other reasons why the scheduler cannot
+change the processor we are executing on then there is no reason to
+disable interrupts. For that purpose the __this_cpu operations are
+provided. For example.
+
+ __this_cpu_inc(x);
+
+Will increment x and will not fallback to code that disables
+interrupts on platforms that cannot accomplish atomicity through
+address relocation and a Read-Modify-Write operation in the same
+instruction.
+
+
+
+&this_cpu_ptr(pp)->n vs this_cpu_ptr(&pp->n)
+--------------------------------------------
+
+The first operation takes the offset and forms an address and then
+adds the offset of the n field.
+
+The second one first adds the two offsets and then does the
+relocation. IMHO the second form looks cleaner and has an easier time
+with (). The second form also is consistent with the way
+this_cpu_read() and friends are used.
+
+
+Christoph Lameter, April 3rd, 2013
diff --git a/Documentation/timers/NO_HZ.txt b/Documentation/timers/NO_HZ.txt
new file mode 100644
index 0000000..8869758
--- /dev/null
+++ b/Documentation/timers/NO_HZ.txt
@@ -0,0 +1,328 @@
+ NO_HZ: Reducing Scheduling-Clock Ticks
+
+
+This document describes Kconfig options and boot parameters that can
+reduce the number of scheduling-clock interrupts, thereby improving energy
+efficiency and reducing OS jitter. Reducing OS jitter is important for
+some types of computationally intensive high-performance computing (HPC)
+applications and for real-time applications.
+
+There are three main ways of managing scheduling-clock interrupts
+(also known as "scheduling-clock ticks" or simply "ticks"):
+
+1. Never omit scheduling-clock ticks (CONFIG_HZ_PERIODIC=y or
+ CONFIG_NO_HZ=n for older kernels). You normally will -not-
+ want to choose this option.
+
+2. Omit scheduling-clock ticks on idle CPUs (CONFIG_NO_HZ_IDLE=y or
+ CONFIG_NO_HZ=y for older kernels). This is the most common
+ approach, and should be the default.
+
+3. Omit scheduling-clock ticks on CPUs that are either idle or that
+ have only one runnable task (CONFIG_NO_HZ_FULL=y). Unless you
+ are running realtime applications or certain types of HPC
+ workloads, you will normally -not- want this option.
+
+These three cases are described in the following three sections, followed
+by a third section on RCU-specific considerations and a fourth and final
+section listing known issues.
+
+
+NEVER OMIT SCHEDULING-CLOCK TICKS
+
+Very old versions of Linux from the 1990s and the very early 2000s
+are incapable of omitting scheduling-clock ticks. It turns out that
+there are some situations where this old-school approach is still the
+right approach, for example, in heavy workloads with lots of tasks
+that use short bursts of CPU, where there are very frequent idle
+periods, but where these idle periods are also quite short (tens or
+hundreds of microseconds). For these types of workloads, scheduling
+clock interrupts will normally be delivered any way because there
+will frequently be multiple runnable tasks per CPU. In these cases,
+attempting to turn off the scheduling clock interrupt will have no effect
+other than increasing the overhead of switching to and from idle and
+transitioning between user and kernel execution.
+
+This mode of operation can be selected using CONFIG_HZ_PERIODIC=y (or
+CONFIG_NO_HZ=n for older kernels).
+
+However, if you are instead running a light workload with long idle
+periods, failing to omit scheduling-clock interrupts will result in
+excessive power consumption. This is especially bad on battery-powered
+devices, where it results in extremely short battery lifetimes. If you
+are running light workloads, you should therefore read the following
+section.
+
+In addition, if you are running either a real-time workload or an HPC
+workload with short iterations, the scheduling-clock interrupts can
+degrade your applications performance. If this describes your workload,
+you should read the following two sections.
+
+
+OMIT SCHEDULING-CLOCK TICKS FOR IDLE CPUs
+
+If a CPU is idle, there is little point in sending it a scheduling-clock
+interrupt. After all, the primary purpose of a scheduling-clock interrupt
+is to force a busy CPU to shift its attention among multiple duties,
+and an idle CPU has no duties to shift its attention among.
+
+The CONFIG_NO_HZ_IDLE=y Kconfig option causes the kernel to avoid sending
+scheduling-clock interrupts to idle CPUs, which is critically important
+both to battery-powered devices and to highly virtualized mainframes.
+A battery-powered device running a CONFIG_HZ_PERIODIC=y kernel would
+drain its battery very quickly, easily 2-3 times as fast as would the
+same device running a CONFIG_NO_HZ_IDLE=y kernel. A mainframe running
+1,500 OS instances might find that half of its CPU time was consumed by
+unnecessary scheduling-clock interrupts. In these situations, there
+is strong motivation to avoid sending scheduling-clock interrupts to
+idle CPUs. That said, dyntick-idle mode is not free:
+
+1. It increases the number of instructions executed on the path
+ to and from the idle loop.
+
+2. On many architectures, dyntick-idle mode also increases the
+ number of expensive clock-reprogramming operations.
+
+Therefore, systems with aggressive real-time response constraints often
+run CONFIG_HZ_PERIODIC=y kernels (or CONFIG_NO_HZ=n for older kernels)
+in order to avoid degrading from-idle transition latencies.
+
+An idle CPU that is not receiving scheduling-clock interrupts is said to
+be "dyntick-idle", "in dyntick-idle mode", "in nohz mode", or "running
+tickless". The remainder of this document will use "dyntick-idle mode".
+
+There is also a boot parameter "nohz=" that can be used to disable
+dyntick-idle mode in CONFIG_NO_HZ_IDLE=y kernels by specifying "nohz=off".
+By default, CONFIG_NO_HZ_IDLE=y kernels boot with "nohz=on", enabling
+dyntick-idle mode.
+
+
+OMIT SCHEDULING-CLOCK TICKS FOR CPUs WITH ONLY ONE RUNNABLE TASK
+
+If a CPU has only one runnable task, there is little point in sending it
+a scheduling-clock interrupt because there is no other task to switch to.
+Note that omitting scheduling-clock ticks for CPUs with only one runnable
+task implies also omitting them for idle CPUs.
+
+The CONFIG_NO_HZ_FULL=y Kconfig option causes the kernel to avoid
+sending scheduling-clock interrupts to CPUs with a single runnable task,
+and such CPUs are said to be "adaptive-ticks CPUs". This is important
+for applications with aggressive real-time response constraints because
+it allows them to improve their worst-case response times by the maximum
+duration of a scheduling-clock interrupt. It is also important for
+computationally intensive short-iteration workloads: If any CPU is
+delayed during a given iteration, all the other CPUs will be forced to
+wait idle while the delayed CPU finishes. Thus, the delay is multiplied
+by one less than the number of CPUs. In these situations, there is
+again strong motivation to avoid sending scheduling-clock interrupts.
+
+By default, no CPU will be an adaptive-ticks CPU. The "nohz_full="
+boot parameter specifies the adaptive-ticks CPUs. For example,
+"nohz_full=1,6-8" says that CPUs 1, 6, 7, and 8 are to be adaptive-ticks
+CPUs. Note that you are prohibited from marking all of the CPUs as
+adaptive-tick CPUs: At least one non-adaptive-tick CPU must remain
+online to handle timekeeping tasks in order to ensure that system calls
+like gettimeofday() returns accurate values on adaptive-tick CPUs.
+(This is not an issue for CONFIG_NO_HZ_IDLE=y because there are no
+running user processes to observe slight drifts in clock rate.)
+Therefore, the boot CPU is prohibited from entering adaptive-ticks
+mode. Specifying a "nohz_full=" mask that includes the boot CPU will
+result in a boot-time error message, and the boot CPU will be removed
+from the mask.
+
+Alternatively, the CONFIG_NO_HZ_FULL_ALL=y Kconfig parameter specifies
+that all CPUs other than the boot CPU are adaptive-ticks CPUs. This
+Kconfig parameter will be overridden by the "nohz_full=" boot parameter,
+so that if both the CONFIG_NO_HZ_FULL_ALL=y Kconfig parameter and
+the "nohz_full=1" boot parameter is specified, the boot parameter will
+prevail so that only CPU 1 will be an adaptive-ticks CPU.
+
+Finally, adaptive-ticks CPUs must have their RCU callbacks offloaded.
+This is covered in the "RCU IMPLICATIONS" section below.
+
+Normally, a CPU remains in adaptive-ticks mode as long as possible.
+In particular, transitioning to kernel mode does not automatically change
+the mode. Instead, the CPU will exit adaptive-ticks mode only if needed,
+for example, if that CPU enqueues an RCU callback.
+
+Just as with dyntick-idle mode, the benefits of adaptive-tick mode do
+not come for free:
+
+1. CONFIG_NO_HZ_FULL selects CONFIG_NO_HZ_COMMON, so you cannot run
+ adaptive ticks without also running dyntick idle. This dependency
+ extends down into the implementation, so that all of the costs
+ of CONFIG_NO_HZ_IDLE are also incurred by CONFIG_NO_HZ_FULL.
+
+2. The user/kernel transitions are slightly more expensive due
+ to the need to inform kernel subsystems (such as RCU) about
+ the change in mode.
+
+3. POSIX CPU timers on adaptive-tick CPUs may miss their deadlines
+ (perhaps indefinitely) because they currently rely on
+ scheduling-tick interrupts. This will likely be fixed in
+ one of two ways: (1) Prevent CPUs with POSIX CPU timers from
+ entering adaptive-tick mode, or (2) Use hrtimers or other
+ adaptive-ticks-immune mechanism to cause the POSIX CPU timer to
+ fire properly.
+
+4. If there are more perf events pending than the hardware can
+ accommodate, they are normally round-robined so as to collect
+ all of them over time. Adaptive-tick mode may prevent this
+ round-robining from happening. This will likely be fixed by
+ preventing CPUs with large numbers of perf events pending from
+ entering adaptive-tick mode.
+
+5. Scheduler statistics for adaptive-tick CPUs may be computed
+ slightly differently than those for non-adaptive-tick CPUs.
+ This might in turn perturb load-balancing of real-time tasks.
+
+6. The LB_BIAS scheduler feature is disabled by adaptive ticks.
+
+Although improvements are expected over time, adaptive ticks is quite
+useful for many types of real-time and compute-intensive applications.
+However, the drawbacks listed above mean that adaptive ticks should not
+(yet) be enabled by default.
+
+
+RCU IMPLICATIONS
+
+There are situations in which idle CPUs cannot be permitted to
+enter either dyntick-idle mode or adaptive-tick mode, the most
+common being when that CPU has RCU callbacks pending.
+
+The CONFIG_RCU_FAST_NO_HZ=y Kconfig option may be used to cause such CPUs
+to enter dyntick-idle mode or adaptive-tick mode anyway. In this case,
+a timer will awaken these CPUs every four jiffies in order to ensure
+that the RCU callbacks are processed in a timely fashion.
+
+Another approach is to offload RCU callback processing to "rcuo" kthreads
+using the CONFIG_RCU_NOCB_CPU=y Kconfig option. The specific CPUs to
+offload may be selected via several methods:
+
+1. One of three mutually exclusive Kconfig options specify a
+ build-time default for the CPUs to offload:
+
+ a. The CONFIG_RCU_NOCB_CPU_NONE=y Kconfig option results in
+ no CPUs being offloaded.
+
+ b. The CONFIG_RCU_NOCB_CPU_ZERO=y Kconfig option causes
+ CPU 0 to be offloaded.
+
+ c. The CONFIG_RCU_NOCB_CPU_ALL=y Kconfig option causes all
+ CPUs to be offloaded. Note that the callbacks will be
+ offloaded to "rcuo" kthreads, and that those kthreads
+ will in fact run on some CPU. However, this approach
+ gives fine-grained control on exactly which CPUs the
+ callbacks run on, along with their scheduling priority
+ (including the default of SCHED_OTHER), and it further
+ allows this control to be varied dynamically at runtime.
+
+2. The "rcu_nocbs=" kernel boot parameter, which takes a comma-separated
+ list of CPUs and CPU ranges, for example, "1,3-5" selects CPUs 1,
+ 3, 4, and 5. The specified CPUs will be offloaded in addition to
+ any CPUs specified as offloaded by CONFIG_RCU_NOCB_CPU_ZERO=y or
+ CONFIG_RCU_NOCB_CPU_ALL=y. This means that the "rcu_nocbs=" boot
+ parameter has no effect for kernels built with RCU_NOCB_CPU_ALL=y.
+
+The offloaded CPUs will never queue RCU callbacks, and therefore RCU
+never prevents offloaded CPUs from entering either dyntick-idle mode
+or adaptive-tick mode. That said, note that it is up to userspace to
+pin the "rcuo" kthreads to specific CPUs if desired. Otherwise, the
+scheduler will decide where to run them, which might or might not be
+where you want them to run.
+
+
+KNOWN ISSUES
+
+o Dyntick-idle slows transitions to and from idle slightly.
+ In practice, this has not been a problem except for the most
+ aggressive real-time workloads, which have the option of disabling
+ dyntick-idle mode, an option that most of them take. However,
+ some workloads will no doubt want to use adaptive ticks to
+ eliminate scheduling-clock interrupt latencies. Here are some
+ options for these workloads:
+
+ a. Use PMQOS from userspace to inform the kernel of your
+ latency requirements (preferred).
+
+ b. On x86 systems, use the "idle=mwait" boot parameter.
+
+ c. On x86 systems, use the "intel_idle.max_cstate=" to limit
+ ` the maximum C-state depth.
+
+ d. On x86 systems, use the "idle=poll" boot parameter.
+ However, please note that use of this parameter can cause
+ your CPU to overheat, which may cause thermal throttling
+ to degrade your latencies -- and that this degradation can
+ be even worse than that of dyntick-idle. Furthermore,
+ this parameter effectively disables Turbo Mode on Intel
+ CPUs, which can significantly reduce maximum performance.
+
+o Adaptive-ticks slows user/kernel transitions slightly.
+ This is not expected to be a problem for computationally intensive
+ workloads, which have few such transitions. Careful benchmarking
+ will be required to determine whether or not other workloads
+ are significantly affected by this effect.
+
+o Adaptive-ticks does not do anything unless there is only one
+ runnable task for a given CPU, even though there are a number
+ of other situations where the scheduling-clock tick is not
+ needed. To give but one example, consider a CPU that has one
+ runnable high-priority SCHED_FIFO task and an arbitrary number
+ of low-priority SCHED_OTHER tasks. In this case, the CPU is
+ required to run the SCHED_FIFO task until it either blocks or
+ some other higher-priority task awakens on (or is assigned to)
+ this CPU, so there is no point in sending a scheduling-clock
+ interrupt to this CPU. However, the current implementation
+ nevertheless sends scheduling-clock interrupts to CPUs having a
+ single runnable SCHED_FIFO task and multiple runnable SCHED_OTHER
+ tasks, even though these interrupts are unnecessary.
+
+ And even when there are multiple runnable tasks on a given CPU,
+ there is little point in interrupting that CPU until the current
+ running task's timeslice expires, which is almost always way
+ longer than the time of the next scheduling-clock interrupt.
+
+ Better handling of these sorts of situations is future work.
+
+o A reboot is required to reconfigure both adaptive idle and RCU
+ callback offloading. Runtime reconfiguration could be provided
+ if needed, however, due to the complexity of reconfiguring RCU at
+ runtime, there would need to be an earthshakingly good reason.
+ Especially given that you have the straightforward option of
+ simply offloading RCU callbacks from all CPUs and pinning them
+ where you want them whenever you want them pinned.
+
+o Additional configuration is required to deal with other sources
+ of OS jitter, including interrupts and system-utility tasks
+ and processes. This configuration normally involves binding
+ interrupts and tasks to particular CPUs.
+
+o Some sources of OS jitter can currently be eliminated only by
+ constraining the workload. For example, the only way to eliminate
+ OS jitter due to global TLB shootdowns is to avoid the unmapping
+ operations (such as kernel module unload operations) that
+ result in these shootdowns. For another example, page faults
+ and TLB misses can be reduced (and in some cases eliminated) by
+ using huge pages and by constraining the amount of memory used
+ by the application. Pre-faulting the working set can also be
+ helpful, especially when combined with the mlock() and mlockall()
+ system calls.
+
+o Unless all CPUs are idle, at least one CPU must keep the
+ scheduling-clock interrupt going in order to support accurate
+ timekeeping.
+
+o If there might potentially be some adaptive-ticks CPUs, there
+ will be at least one CPU keeping the scheduling-clock interrupt
+ going, even if all CPUs are otherwise idle.
+
+ Better handling of this situation is ongoing work.
+
+o Some process-handling operations still require the occasional
+ scheduling-clock tick. These operations include calculating CPU
+ load, maintaining sched average, computing CFS entity vruntime,
+ computing avenrun, and carrying out load balancing. They are
+ currently accommodated by scheduling-clock tick every second
+ or so. On-going work will eliminate the need even for these
+ infrequent scheduling-clock ticks.
diff --git a/Documentation/trace/events-nmi.txt b/Documentation/trace/events-nmi.txt
new file mode 100644
index 0000000..c03c8c8
--- /dev/null
+++ b/Documentation/trace/events-nmi.txt
@@ -0,0 +1,43 @@
+NMI Trace Events
+
+These events normally show up here:
+
+ /sys/kernel/debug/tracing/events/nmi
+
+--
+
+nmi_handler:
+
+You might want to use this tracepoint if you suspect that your
+NMI handlers are hogging large amounts of CPU time. The kernel
+will warn if it sees long-running handlers:
+
+ INFO: NMI handler took too long to run: 9.207 msecs
+
+and this tracepoint will allow you to drill down and get some
+more details.
+
+Let's say you suspect that perf_event_nmi_handler() is causing
+you some problems and you only want to trace that handler
+specifically. You need to find its address:
+
+ $ grep perf_event_nmi_handler /proc/kallsyms
+ ffffffff81625600 t perf_event_nmi_handler
+
+Let's also say you are only interested in when that function is
+really hogging a lot of CPU time, like a millisecond at a time.
+Note that the kernel's output is in milliseconds, but the input
+to the filter is in nanoseconds! You can filter on 'delta_ns':
+
+cd /sys/kernel/debug/tracing/events/nmi/nmi_handler
+echo 'handler==0xffffffff81625600 && delta_ns>1000000' > filter
+echo 1 > enable
+
+Your output would then look like:
+
+$ cat /sys/kernel/debug/tracing/trace_pipe
+<idle>-0 [000] d.h3 505.397558: nmi_handler: perf_event_nmi_handler() delta_ns: 3236765 handled: 1
+<idle>-0 [000] d.h3 505.805893: nmi_handler: perf_event_nmi_handler() delta_ns: 3174234 handled: 1
+<idle>-0 [000] d.h3 506.158206: nmi_handler: perf_event_nmi_handler() delta_ns: 3084642 handled: 1
+<idle>-0 [000] d.h3 506.334346: nmi_handler: perf_event_nmi_handler() delta_ns: 3080351 handled: 1
+
diff --git a/Documentation/trace/events-power.txt b/Documentation/trace/events-power.txt
index cf794af..3bd33b8 100644
--- a/Documentation/trace/events-power.txt
+++ b/Documentation/trace/events-power.txt
@@ -17,7 +17,7 @@
1. Power state switch events
============================
-1.1 New trace API
+1.1 Trace API
-----------------
A 'cpu' event class gathers the CPU-related events: cpuidle and
@@ -41,31 +41,6 @@
space tools which are using it to detect the end of the current state, and so to
correctly draw the states diagrams and to calculate accurate statistics etc.
-1.2 DEPRECATED trace API
-------------------------
-
-A new Kconfig option CONFIG_EVENT_POWER_TRACING_DEPRECATED with the default value of
-'y' has been created. This allows the legacy trace power API to be used conjointly
-with the new trace API.
-The Kconfig option, the old trace API (in include/trace/events/power.h) and the
-old trace points will disappear in a future release (namely 2.6.41).
-
-power_start "type=%lu state=%lu cpu_id=%lu"
-power_frequency "type=%lu state=%lu cpu_id=%lu"
-power_end "cpu_id=%lu"
-
-The 'type' parameter takes one of those macros:
- . POWER_NONE = 0,
- . POWER_CSTATE = 1, /* C-State */
- . POWER_PSTATE = 2, /* Frequency change or DVFS */
-
-The 'state' parameter is set depending on the type:
- . Target C-state for type=POWER_CSTATE,
- . Target frequency for type=POWER_PSTATE,
-
-power_end is used to indicate the exit of a state, corresponding to the latest
-power_start event.
-
2. Clocks events
================
The clock events are used for clock enable/disable and for
@@ -88,3 +63,34 @@
The first parameter gives the power domain name (e.g. "mpu_pwrdm").
The second parameter is the power domain target state.
+4. PM QoS events
+================
+The PM QoS events are used for QoS add/update/remove request and for
+target/flags update.
+
+pm_qos_add_request "pm_qos_class=%s value=%d"
+pm_qos_update_request "pm_qos_class=%s value=%d"
+pm_qos_remove_request "pm_qos_class=%s value=%d"
+pm_qos_update_request_timeout "pm_qos_class=%s value=%d, timeout_us=%ld"
+
+The first parameter gives the QoS class name (e.g. "CPU_DMA_LATENCY").
+The second parameter is value to be added/updated/removed.
+The third parameter is timeout value in usec.
+
+pm_qos_update_target "action=%s prev_value=%d curr_value=%d"
+pm_qos_update_flags "action=%s prev_value=0x%x curr_value=0x%x"
+
+The first parameter gives the QoS action name (e.g. "ADD_REQ").
+The second parameter is the previous QoS value.
+The third parameter is the current QoS value to update.
+
+And, there are also events used for device PM QoS add/update/remove request.
+
+dev_pm_qos_add_request "device=%s type=%s new_value=%d"
+dev_pm_qos_update_request "device=%s type=%s new_value=%d"
+dev_pm_qos_remove_request "device=%s type=%s new_value=%d"
+
+The first parameter gives the device name which tries to add/update/remove
+QoS requests.
+The second parameter gives the request type (e.g. "DEV_PM_QOS_LATENCY").
+The third parameter is value to be added/updated/removed.
diff --git a/Documentation/trace/events.txt b/Documentation/trace/events.txt
index bb24c2a0e..37732a2 100644
--- a/Documentation/trace/events.txt
+++ b/Documentation/trace/events.txt
@@ -183,13 +183,22 @@
The operators available for numeric fields are:
-==, !=, <, <=, >, >=
+==, !=, <, <=, >, >=, &
And for string fields they are:
-==, !=
+==, !=, ~
-Currently, only exact string matches are supported.
+The glob (~) only accepts a wild card character (*) at the start and or
+end of the string. For example:
+
+ prev_comm ~ "*sh"
+ prev_comm ~ "sh*"
+ prev_comm ~ "*sh*"
+
+But does not allow for it to be within the string:
+
+ prev_comm ~ "ba*sh" <-- is invalid
5.2 Setting filters
-------------------
diff --git a/Documentation/trace/ftrace.txt b/Documentation/trace/ftrace.txt
index 6f51fed..b937c6e 100644
--- a/Documentation/trace/ftrace.txt
+++ b/Documentation/trace/ftrace.txt
@@ -8,6 +8,7 @@
Reviewers: Elias Oltmanns, Randy Dunlap, Andrew Morton,
John Kacur, and David Teigland.
Written for: 2.6.28-rc2
+Updated for: 3.10
Introduction
------------
@@ -17,13 +18,16 @@
It can be used for debugging or analyzing latencies and
performance issues that take place outside of user-space.
-Although ftrace is the function tracer, it also includes an
-infrastructure that allows for other types of tracing. Some of
-the tracers that are currently in ftrace include a tracer to
-trace context switches, the time it takes for a high priority
-task to run after it was woken up, the time interrupts are
-disabled, and more (ftrace allows for tracer plugins, which
-means that the list of tracers can always grow).
+Although ftrace is typically considered the function tracer, it
+is really a frame work of several assorted tracing utilities.
+There's latency tracing to examine what occurs between interrupts
+disabled and enabled, as well as for preemption and from a time
+a task is woken to the task is actually scheduled in.
+
+One of the most common uses of ftrace is the event tracing.
+Through out the kernel is hundreds of static event points that
+can be enabled via the debugfs file system to see what is
+going on in certain parts of the kernel.
Implementation Details
@@ -61,7 +65,7 @@
That's it! (assuming that you have ftrace configured into your kernel)
-After mounting the debugfs, you can see a directory called
+After mounting debugfs, you can see a directory called
"tracing". This directory contains the control and output files
of ftrace. Here is a list of some of the key files:
@@ -84,7 +88,9 @@
This sets or displays whether writing to the trace
ring buffer is enabled. Echo 0 into this file to disable
- the tracer or 1 to enable it.
+ the tracer or 1 to enable it. Note, this only disables
+ writing to the ring buffer, the tracing overhead may
+ still be occurring.
trace:
@@ -109,7 +115,15 @@
This file lets the user control the amount of data
that is displayed in one of the above output
- files.
+ files. Options also exist to modify how a tracer
+ or events work (stack traces, timestamps, etc).
+
+ options:
+
+ This is a directory that has a file for every available
+ trace option (also in trace_options). Options may also be set
+ or cleared by writing a "1" or "0" respectively into the
+ corresponding file with the option name.
tracing_max_latency:
@@ -121,10 +135,17 @@
latency is greater than the value in this
file. (in microseconds)
+ tracing_thresh:
+
+ Some latency tracers will record a trace whenever the
+ latency is greater than the number in this file.
+ Only active when the file contains a number greater than 0.
+ (in microseconds)
+
buffer_size_kb:
This sets or displays the number of kilobytes each CPU
- buffer can hold. The tracer buffers are the same size
+ buffer holds. By default, the trace buffers are the same size
for each CPU. The displayed number is the size of the
CPU buffer and not total size of all buffers. The
trace buffers are allocated in pages (blocks of memory
@@ -133,16 +154,30 @@
than requested, the rest of the page will be used,
making the actual allocation bigger than requested.
( Note, the size may not be a multiple of the page size
- due to buffer management overhead. )
+ due to buffer management meta-data. )
- This can only be updated when the current_tracer
- is set to "nop".
+ buffer_total_size_kb:
+
+ This displays the total combined size of all the trace buffers.
+
+ free_buffer:
+
+ If a process is performing the tracing, and the ring buffer
+ should be shrunk "freed" when the process is finished, even
+ if it were to be killed by a signal, this file can be used
+ for that purpose. On close of this file, the ring buffer will
+ be resized to its minimum size. Having a process that is tracing
+ also open this file, when the process exits its file descriptor
+ for this file will be closed, and in doing so, the ring buffer
+ will be "freed".
+
+ It may also stop tracing if disable_on_free option is set.
tracing_cpumask:
This is a mask that lets the user only trace
- on specified CPUS. The format is a hex string
- representing the CPUS.
+ on specified CPUs. The format is a hex string
+ representing the CPUs.
set_ftrace_filter:
@@ -183,6 +218,261 @@
"set_ftrace_notrace". (See the section "dynamic ftrace"
below for more details.)
+ enabled_functions:
+
+ This file is more for debugging ftrace, but can also be useful
+ in seeing if any function has a callback attached to it.
+ Not only does the trace infrastructure use ftrace function
+ trace utility, but other subsystems might too. This file
+ displays all functions that have a callback attached to them
+ as well as the number of callbacks that have been attached.
+ Note, a callback may also call multiple functions which will
+ not be listed in this count.
+
+ If the callback registered to be traced by a function with
+ the "save regs" attribute (thus even more overhead), a 'R'
+ will be displayed on the same line as the function that
+ is returning registers.
+
+ function_profile_enabled:
+
+ When set it will enable all functions with either the function
+ tracer, or if enabled, the function graph tracer. It will
+ keep a histogram of the number of functions that were called
+ and if run with the function graph tracer, it will also keep
+ track of the time spent in those functions. The histogram
+ content can be displayed in the files:
+
+ trace_stats/function<cpu> ( function0, function1, etc).
+
+ trace_stats:
+
+ A directory that holds different tracing stats.
+
+ kprobe_events:
+
+ Enable dynamic trace points. See kprobetrace.txt.
+
+ kprobe_profile:
+
+ Dynamic trace points stats. See kprobetrace.txt.
+
+ max_graph_depth:
+
+ Used with the function graph tracer. This is the max depth
+ it will trace into a function. Setting this to a value of
+ one will show only the first kernel function that is called
+ from user space.
+
+ printk_formats:
+
+ This is for tools that read the raw format files. If an event in
+ the ring buffer references a string (currently only trace_printk()
+ does this), only a pointer to the string is recorded into the buffer
+ and not the string itself. This prevents tools from knowing what
+ that string was. This file displays the string and address for
+ the string allowing tools to map the pointers to what the
+ strings were.
+
+ saved_cmdlines:
+
+ Only the pid of the task is recorded in a trace event unless
+ the event specifically saves the task comm as well. Ftrace
+ makes a cache of pid mappings to comms to try to display
+ comms for events. If a pid for a comm is not listed, then
+ "<...>" is displayed in the output.
+
+ snapshot:
+
+ This displays the "snapshot" buffer and also lets the user
+ take a snapshot of the current running trace.
+ See the "Snapshot" section below for more details.
+
+ stack_max_size:
+
+ When the stack tracer is activated, this will display the
+ maximum stack size it has encountered.
+ See the "Stack Trace" section below.
+
+ stack_trace:
+
+ This displays the stack back trace of the largest stack
+ that was encountered when the stack tracer is activated.
+ See the "Stack Trace" section below.
+
+ stack_trace_filter:
+
+ This is similar to "set_ftrace_filter" but it limits what
+ functions the stack tracer will check.
+
+ trace_clock:
+
+ Whenever an event is recorded into the ring buffer, a
+ "timestamp" is added. This stamp comes from a specified
+ clock. By default, ftrace uses the "local" clock. This
+ clock is very fast and strictly per cpu, but on some
+ systems it may not be monotonic with respect to other
+ CPUs. In other words, the local clocks may not be in sync
+ with local clocks on other CPUs.
+
+ Usual clocks for tracing:
+
+ # cat trace_clock
+ [local] global counter x86-tsc
+
+ local: Default clock, but may not be in sync across CPUs
+
+ global: This clock is in sync with all CPUs but may
+ be a bit slower than the local clock.
+
+ counter: This is not a clock at all, but literally an atomic
+ counter. It counts up one by one, but is in sync
+ with all CPUs. This is useful when you need to
+ know exactly the order events occurred with respect to
+ each other on different CPUs.
+
+ uptime: This uses the jiffies counter and the time stamp
+ is relative to the time since boot up.
+
+ perf: This makes ftrace use the same clock that perf uses.
+ Eventually perf will be able to read ftrace buffers
+ and this will help out in interleaving the data.
+
+ x86-tsc: Architectures may define their own clocks. For
+ example, x86 uses its own TSC cycle clock here.
+
+ To set a clock, simply echo the clock name into this file.
+
+ echo global > trace_clock
+
+ trace_marker:
+
+ This is a very useful file for synchronizing user space
+ with events happening in the kernel. Writing strings into
+ this file will be written into the ftrace buffer.
+
+ It is useful in applications to open this file at the start
+ of the application and just reference the file descriptor
+ for the file.
+
+ void trace_write(const char *fmt, ...)
+ {
+ va_list ap;
+ char buf[256];
+ int n;
+
+ if (trace_fd < 0)
+ return;
+
+ va_start(ap, fmt);
+ n = vsnprintf(buf, 256, fmt, ap);
+ va_end(ap);
+
+ write(trace_fd, buf, n);
+ }
+
+ start:
+
+ trace_fd = open("trace_marker", WR_ONLY);
+
+ uprobe_events:
+
+ Add dynamic tracepoints in programs.
+ See uprobetracer.txt
+
+ uprobe_profile:
+
+ Uprobe statistics. See uprobetrace.txt
+
+ instances:
+
+ This is a way to make multiple trace buffers where different
+ events can be recorded in different buffers.
+ See "Instances" section below.
+
+ events:
+
+ This is the trace event directory. It holds event tracepoints
+ (also known as static tracepoints) that have been compiled
+ into the kernel. It shows what event tracepoints exist
+ and how they are grouped by system. There are "enable"
+ files at various levels that can enable the tracepoints
+ when a "1" is written to them.
+
+ See events.txt for more information.
+
+ per_cpu:
+
+ This is a directory that contains the trace per_cpu information.
+
+ per_cpu/cpu0/buffer_size_kb:
+
+ The ftrace buffer is defined per_cpu. That is, there's a separate
+ buffer for each CPU to allow writes to be done atomically,
+ and free from cache bouncing. These buffers may have different
+ size buffers. This file is similar to the buffer_size_kb
+ file, but it only displays or sets the buffer size for the
+ specific CPU. (here cpu0).
+
+ per_cpu/cpu0/trace:
+
+ This is similar to the "trace" file, but it will only display
+ the data specific for the CPU. If written to, it only clears
+ the specific CPU buffer.
+
+ per_cpu/cpu0/trace_pipe
+
+ This is similar to the "trace_pipe" file, and is a consuming
+ read, but it will only display (and consume) the data specific
+ for the CPU.
+
+ per_cpu/cpu0/trace_pipe_raw
+
+ For tools that can parse the ftrace ring buffer binary format,
+ the trace_pipe_raw file can be used to extract the data
+ from the ring buffer directly. With the use of the splice()
+ system call, the buffer data can be quickly transferred to
+ a file or to the network where a server is collecting the
+ data.
+
+ Like trace_pipe, this is a consuming reader, where multiple
+ reads will always produce different data.
+
+ per_cpu/cpu0/snapshot:
+
+ This is similar to the main "snapshot" file, but will only
+ snapshot the current CPU (if supported). It only displays
+ the content of the snapshot for a given CPU, and if
+ written to, only clears this CPU buffer.
+
+ per_cpu/cpu0/snapshot_raw:
+
+ Similar to the trace_pipe_raw, but will read the binary format
+ from the snapshot buffer for the given CPU.
+
+ per_cpu/cpu0/stats:
+
+ This displays certain stats about the ring buffer:
+
+ entries: The number of events that are still in the buffer.
+
+ overrun: The number of lost events due to overwriting when
+ the buffer was full.
+
+ commit overrun: Should always be zero.
+ This gets set if so many events happened within a nested
+ event (ring buffer is re-entrant), that it fills the
+ buffer and starts dropping events.
+
+ bytes: Bytes actually read (not overwritten).
+
+ oldest event ts: The oldest timestamp in the buffer
+
+ now ts: The current timestamp
+
+ dropped events: Events lost due to overwrite option being off.
+
+ read events: The number of events read.
The Tracers
-----------
@@ -234,11 +524,6 @@
RT tasks (as the current "wakeup" does). This is useful
for those interested in wake up timings of RT tasks.
- "hw-branch-tracer"
-
- Uses the BTS CPU feature on x86 CPUs to traces all
- branches executed.
-
"nop"
This is the "trace nothing" tracer. To remove all
@@ -261,70 +546,100 @@
--------
# tracer: function
#
-# TASK-PID CPU# TIMESTAMP FUNCTION
-# | | | | |
- bash-4251 [01] 10152.583854: path_put <-path_walk
- bash-4251 [01] 10152.583855: dput <-path_put
- bash-4251 [01] 10152.583855: _atomic_dec_and_lock <-dput
+# entries-in-buffer/entries-written: 140080/250280 #P:4
+#
+# _-----=> irqs-off
+# / _----=> need-resched
+# | / _---=> hardirq/softirq
+# || / _--=> preempt-depth
+# ||| / delay
+# TASK-PID CPU# |||| TIMESTAMP FUNCTION
+# | | | |||| | |
+ bash-1977 [000] .... 17284.993652: sys_close <-system_call_fastpath
+ bash-1977 [000] .... 17284.993653: __close_fd <-sys_close
+ bash-1977 [000] .... 17284.993653: _raw_spin_lock <-__close_fd
+ sshd-1974 [003] .... 17284.993653: __srcu_read_unlock <-fsnotify
+ bash-1977 [000] .... 17284.993654: add_preempt_count <-_raw_spin_lock
+ bash-1977 [000] ...1 17284.993655: _raw_spin_unlock <-__close_fd
+ bash-1977 [000] ...1 17284.993656: sub_preempt_count <-_raw_spin_unlock
+ bash-1977 [000] .... 17284.993657: filp_close <-__close_fd
+ bash-1977 [000] .... 17284.993657: dnotify_flush <-filp_close
+ sshd-1974 [003] .... 17284.993658: sys_select <-system_call_fastpath
--------
A header is printed with the tracer name that is represented by
-the trace. In this case the tracer is "function". Then a header
-showing the format. Task name "bash", the task PID "4251", the
-CPU that it was running on "01", the timestamp in <secs>.<usecs>
-format, the function name that was traced "path_put" and the
-parent function that called this function "path_walk". The
-timestamp is the time at which the function was entered.
+the trace. In this case the tracer is "function". Then it shows the
+number of events in the buffer as well as the total number of entries
+that were written. The difference is the number of entries that were
+lost due to the buffer filling up (250280 - 140080 = 110200 events
+lost).
+
+The header explains the content of the events. Task name "bash", the task
+PID "1977", the CPU that it was running on "000", the latency format
+(explained below), the timestamp in <secs>.<usecs> format, the
+function name that was traced "sys_close" and the parent function that
+called this function "system_call_fastpath". The timestamp is the time
+at which the function was entered.
Latency trace format
--------------------
-When the latency-format option is enabled, the trace file gives
-somewhat more information to see why a latency happened.
-Here is a typical trace.
+When the latency-format option is enabled or when one of the latency
+tracers is set, the trace file gives somewhat more information to see
+why a latency happened. Here is a typical trace.
# tracer: irqsoff
#
-irqsoff latency trace v1.1.5 on 2.6.26-rc8
---------------------------------------------------------------------
- latency: 97 us, #3/3, CPU#0 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:2)
- -----------------
- | task: swapper-0 (uid:0 nice:0 policy:0 rt_prio:0)
- -----------------
- => started at: apic_timer_interrupt
- => ended at: do_softirq
-
-# _------=> CPU#
-# / _-----=> irqs-off
-# | / _----=> need-resched
-# || / _---=> hardirq/softirq
-# ||| / _--=> preempt-depth
-# |||| /
-# ||||| delay
-# cmd pid ||||| time | caller
-# \ / ||||| \ | /
- <idle>-0 0d..1 0us+: trace_hardirqs_off_thunk (apic_timer_interrupt)
- <idle>-0 0d.s. 97us : __do_softirq (do_softirq)
- <idle>-0 0d.s1 98us : trace_hardirqs_on (do_softirq)
+# irqsoff latency trace v1.1.5 on 3.8.0-test+
+# --------------------------------------------------------------------
+# latency: 259 us, #4/4, CPU#2 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:4)
+# -----------------
+# | task: ps-6143 (uid:0 nice:0 policy:0 rt_prio:0)
+# -----------------
+# => started at: __lock_task_sighand
+# => ended at: _raw_spin_unlock_irqrestore
+#
+#
+# _------=> CPU#
+# / _-----=> irqs-off
+# | / _----=> need-resched
+# || / _---=> hardirq/softirq
+# ||| / _--=> preempt-depth
+# |||| / delay
+# cmd pid ||||| time | caller
+# \ / ||||| \ | /
+ ps-6143 2d... 0us!: trace_hardirqs_off <-__lock_task_sighand
+ ps-6143 2d..1 259us+: trace_hardirqs_on <-_raw_spin_unlock_irqrestore
+ ps-6143 2d..1 263us+: time_hardirqs_on <-_raw_spin_unlock_irqrestore
+ ps-6143 2d..1 306us : <stack trace>
+ => trace_hardirqs_on_caller
+ => trace_hardirqs_on
+ => _raw_spin_unlock_irqrestore
+ => do_task_stat
+ => proc_tgid_stat
+ => proc_single_show
+ => seq_read
+ => vfs_read
+ => sys_read
+ => system_call_fastpath
This shows that the current tracer is "irqsoff" tracing the time
-for which interrupts were disabled. It gives the trace version
-and the version of the kernel upon which this was executed on
-(2.6.26-rc8). Then it displays the max latency in microsecs (97
-us). The number of trace entries displayed and the total number
-recorded (both are three: #3/3). The type of preemption that was
-used (PREEMPT). VP, KP, SP, and HP are always zero and are
-reserved for later use. #P is the number of online CPUS (#P:2).
+for which interrupts were disabled. It gives the trace version (which
+never changes) and the version of the kernel upon which this was executed on
+(3.10). Then it displays the max latency in microseconds (259 us). The number
+of trace entries displayed and the total number (both are four: #4/4).
+VP, KP, SP, and HP are always zero and are reserved for later use.
+#P is the number of online CPUs (#P:4).
The task is the process that was running when the latency
-occurred. (swapper pid: 0).
+occurred. (ps pid: 6143).
The start and stop (the functions in which the interrupts were
disabled and enabled respectively) that caused the latencies:
- apic_timer_interrupt is where the interrupts were disabled.
- do_softirq is where they were enabled again.
+ __lock_task_sighand is where the interrupts were disabled.
+ _raw_spin_unlock_irqrestore is where they were enabled again.
The next lines after the header are the trace itself. The header
explains which is which.
@@ -367,16 +682,43 @@
The rest is the same as the 'trace' file.
+ Note, the latency tracers will usually end with a back trace
+ to easily find where the latency occurred.
trace_options
-------------
-The trace_options file is used to control what gets printed in
-the trace output. To see what is available, simply cat the file:
+The trace_options file (or the options directory) is used to control
+what gets printed in the trace output, or manipulate the tracers.
+To see what is available, simply cat the file:
cat trace_options
- print-parent nosym-offset nosym-addr noverbose noraw nohex nobin \
- noblock nostacktrace nosched-tree nouserstacktrace nosym-userobj
+print-parent
+nosym-offset
+nosym-addr
+noverbose
+noraw
+nohex
+nobin
+noblock
+nostacktrace
+trace_printk
+noftrace_preempt
+nobranch
+annotate
+nouserstacktrace
+nosym-userobj
+noprintk-msg-only
+context-info
+latency-format
+sleep-time
+graph-time
+record-cmd
+overwrite
+nodisable_on_free
+irq-info
+markers
+function-trace
To disable one of the options, echo in the option prepended with
"no".
@@ -428,13 +770,34 @@
bin - This will print out the formats in raw binary.
- block - TBD (needs update)
+ block - When set, reading trace_pipe will not block when polled.
stacktrace - This is one of the options that changes the trace
itself. When a trace is recorded, so is the stack
of functions. This allows for back traces of
trace sites.
+ trace_printk - Can disable trace_printk() from writing into the buffer.
+
+ branch - Enable branch tracing with the tracer.
+
+ annotate - It is sometimes confusing when the CPU buffers are full
+ and one CPU buffer had a lot of events recently, thus
+ a shorter time frame, were another CPU may have only had
+ a few events, which lets it have older events. When
+ the trace is reported, it shows the oldest events first,
+ and it may look like only one CPU ran (the one with the
+ oldest events). When the annotate option is set, it will
+ display when a new CPU buffer started:
+
+ <idle>-0 [001] dNs4 21169.031481: wake_up_idle_cpu <-add_timer_on
+ <idle>-0 [001] dNs4 21169.031482: _raw_spin_unlock_irqrestore <-add_timer_on
+ <idle>-0 [001] .Ns4 21169.031484: sub_preempt_count <-_raw_spin_unlock_irqrestore
+##### CPU 2 buffer started ####
+ <idle>-0 [002] .N.1 21169.031484: rcu_idle_exit <-cpu_idle
+ <idle>-0 [001] .Ns3 21169.031484: _raw_spin_unlock <-clocksource_watchdog
+ <idle>-0 [001] .Ns3 21169.031485: sub_preempt_count <-_raw_spin_unlock
+
userstacktrace - This option changes the trace. It records a
stacktrace of the current userspace thread.
@@ -451,9 +814,13 @@
a.out-1623 [000] 40874.465068: /root/a.out[+0x480] <-/root/a.out[+0
x494] <- /root/a.out[+0x4a8] <- /lib/libc-2.7.so[+0x1e1a6]
- sched-tree - trace all tasks that are on the runqueue, at
- every scheduling event. Will add overhead if
- there's a lot of tasks running at once.
+
+ printk-msg-only - When set, trace_printk()s will only show the format
+ and not their parameters (if trace_bprintk() or
+ trace_bputs() was used to save the trace_printk()).
+
+ context-info - Show only the event data. Hides the comm, PID,
+ timestamp, CPU, and other useful data.
latency-format - This option changes the trace. When
it is enabled, the trace displays
@@ -461,31 +828,61 @@
latencies, as described in "Latency
trace format".
+ sleep-time - When running function graph tracer, to include
+ the time a task schedules out in its function.
+ When enabled, it will account time the task has been
+ scheduled out as part of the function call.
+
+ graph-time - When running function graph tracer, to include the
+ time to call nested functions. When this is not set,
+ the time reported for the function will only include
+ the time the function itself executed for, not the time
+ for functions that it called.
+
+ record-cmd - When any event or tracer is enabled, a hook is enabled
+ in the sched_switch trace point to fill comm cache
+ with mapped pids and comms. But this may cause some
+ overhead, and if you only care about pids, and not the
+ name of the task, disabling this option can lower the
+ impact of tracing.
+
overwrite - This controls what happens when the trace buffer is
full. If "1" (default), the oldest events are
discarded and overwritten. If "0", then the newest
events are discarded.
+ (see per_cpu/cpu0/stats for overrun and dropped)
-ftrace_enabled
---------------
+ disable_on_free - When the free_buffer is closed, tracing will
+ stop (tracing_on set to 0).
-The following tracers (listed below) give different output
-depending on whether or not the sysctl ftrace_enabled is set. To
-set ftrace_enabled, one can either use the sysctl function or
-set it via the proc file system interface.
+ irq-info - Shows the interrupt, preempt count, need resched data.
+ When disabled, the trace looks like:
- sysctl kernel.ftrace_enabled=1
+# tracer: function
+#
+# entries-in-buffer/entries-written: 144405/9452052 #P:4
+#
+# TASK-PID CPU# TIMESTAMP FUNCTION
+# | | | | |
+ <idle>-0 [002] 23636.756054: ttwu_do_activate.constprop.89 <-try_to_wake_up
+ <idle>-0 [002] 23636.756054: activate_task <-ttwu_do_activate.constprop.89
+ <idle>-0 [002] 23636.756055: enqueue_task <-activate_task
- or
- echo 1 > /proc/sys/kernel/ftrace_enabled
+ markers - When set, the trace_marker is writable (only by root).
+ When disabled, the trace_marker will error with EINVAL
+ on write.
-To disable ftrace_enabled simply replace the '1' with '0' in the
-above commands.
-When ftrace_enabled is set the tracers will also record the
-functions that are within the trace. The descriptions of the
-tracers will also show an example with ftrace enabled.
+ function-trace - The latency tracers will enable function tracing
+ if this option is enabled (default it is). When
+ it is disabled, the latency tracers do not trace
+ functions. This keeps the overhead of the tracer down
+ when performing latency tests.
+
+ Note: Some tracers have their own options. They only appear
+ when the tracer is active.
+
irqsoff
@@ -506,95 +903,133 @@
To reset the maximum, echo 0 into tracing_max_latency. Here is
an example:
+ # echo 0 > options/function-trace
# echo irqsoff > current_tracer
- # echo latency-format > trace_options
- # echo 0 > tracing_max_latency
# echo 1 > tracing_on
+ # echo 0 > tracing_max_latency
# ls -ltr
[...]
# echo 0 > tracing_on
# cat trace
# tracer: irqsoff
#
-irqsoff latency trace v1.1.5 on 2.6.26
---------------------------------------------------------------------
- latency: 12 us, #3/3, CPU#1 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:2)
- -----------------
- | task: bash-3730 (uid:0 nice:0 policy:0 rt_prio:0)
- -----------------
- => started at: sys_setpgid
- => ended at: sys_setpgid
+# irqsoff latency trace v1.1.5 on 3.8.0-test+
+# --------------------------------------------------------------------
+# latency: 16 us, #4/4, CPU#0 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:4)
+# -----------------
+# | task: swapper/0-0 (uid:0 nice:0 policy:0 rt_prio:0)
+# -----------------
+# => started at: run_timer_softirq
+# => ended at: run_timer_softirq
+#
+#
+# _------=> CPU#
+# / _-----=> irqs-off
+# | / _----=> need-resched
+# || / _---=> hardirq/softirq
+# ||| / _--=> preempt-depth
+# |||| / delay
+# cmd pid ||||| time | caller
+# \ / ||||| \ | /
+ <idle>-0 0d.s2 0us+: _raw_spin_lock_irq <-run_timer_softirq
+ <idle>-0 0dNs3 17us : _raw_spin_unlock_irq <-run_timer_softirq
+ <idle>-0 0dNs3 17us+: trace_hardirqs_on <-run_timer_softirq
+ <idle>-0 0dNs3 25us : <stack trace>
+ => _raw_spin_unlock_irq
+ => run_timer_softirq
+ => __do_softirq
+ => call_softirq
+ => do_softirq
+ => irq_exit
+ => smp_apic_timer_interrupt
+ => apic_timer_interrupt
+ => rcu_idle_exit
+ => cpu_idle
+ => rest_init
+ => start_kernel
+ => x86_64_start_reservations
+ => x86_64_start_kernel
-# _------=> CPU#
-# / _-----=> irqs-off
-# | / _----=> need-resched
-# || / _---=> hardirq/softirq
-# ||| / _--=> preempt-depth
-# |||| /
-# ||||| delay
-# cmd pid ||||| time | caller
-# \ / ||||| \ | /
- bash-3730 1d... 0us : _write_lock_irq (sys_setpgid)
- bash-3730 1d..1 1us+: _write_unlock_irq (sys_setpgid)
- bash-3730 1d..2 14us : trace_hardirqs_on (sys_setpgid)
-
-
-Here we see that that we had a latency of 12 microsecs (which is
-very good). The _write_lock_irq in sys_setpgid disabled
-interrupts. The difference between the 12 and the displayed
-timestamp 14us occurred because the clock was incremented
+Here we see that that we had a latency of 16 microseconds (which is
+very good). The _raw_spin_lock_irq in run_timer_softirq disabled
+interrupts. The difference between the 16 and the displayed
+timestamp 25us occurred because the clock was incremented
between the time of recording the max latency and the time of
recording the function that had that latency.
-Note the above example had ftrace_enabled not set. If we set the
-ftrace_enabled, we get a much larger output:
+Note the above example had function-trace not set. If we set
+function-trace, we get a much larger output:
+
+ with echo 1 > options/function-trace
# tracer: irqsoff
#
-irqsoff latency trace v1.1.5 on 2.6.26-rc8
---------------------------------------------------------------------
- latency: 50 us, #101/101, CPU#0 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:2)
- -----------------
- | task: ls-4339 (uid:0 nice:0 policy:0 rt_prio:0)
- -----------------
- => started at: __alloc_pages_internal
- => ended at: __alloc_pages_internal
-
-# _------=> CPU#
-# / _-----=> irqs-off
-# | / _----=> need-resched
-# || / _---=> hardirq/softirq
-# ||| / _--=> preempt-depth
-# |||| /
-# ||||| delay
-# cmd pid ||||| time | caller
-# \ / ||||| \ | /
- ls-4339 0...1 0us+: get_page_from_freelist (__alloc_pages_internal)
- ls-4339 0d..1 3us : rmqueue_bulk (get_page_from_freelist)
- ls-4339 0d..1 3us : _spin_lock (rmqueue_bulk)
- ls-4339 0d..1 4us : add_preempt_count (_spin_lock)
- ls-4339 0d..2 4us : __rmqueue (rmqueue_bulk)
- ls-4339 0d..2 5us : __rmqueue_smallest (__rmqueue)
- ls-4339 0d..2 5us : __mod_zone_page_state (__rmqueue_smallest)
- ls-4339 0d..2 6us : __rmqueue (rmqueue_bulk)
- ls-4339 0d..2 6us : __rmqueue_smallest (__rmqueue)
- ls-4339 0d..2 7us : __mod_zone_page_state (__rmqueue_smallest)
- ls-4339 0d..2 7us : __rmqueue (rmqueue_bulk)
- ls-4339 0d..2 8us : __rmqueue_smallest (__rmqueue)
+# irqsoff latency trace v1.1.5 on 3.8.0-test+
+# --------------------------------------------------------------------
+# latency: 71 us, #168/168, CPU#3 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:4)
+# -----------------
+# | task: bash-2042 (uid:0 nice:0 policy:0 rt_prio:0)
+# -----------------
+# => started at: ata_scsi_queuecmd
+# => ended at: ata_scsi_queuecmd
+#
+#
+# _------=> CPU#
+# / _-----=> irqs-off
+# | / _----=> need-resched
+# || / _---=> hardirq/softirq
+# ||| / _--=> preempt-depth
+# |||| / delay
+# cmd pid ||||| time | caller
+# \ / ||||| \ | /
+ bash-2042 3d... 0us : _raw_spin_lock_irqsave <-ata_scsi_queuecmd
+ bash-2042 3d... 0us : add_preempt_count <-_raw_spin_lock_irqsave
+ bash-2042 3d..1 1us : ata_scsi_find_dev <-ata_scsi_queuecmd
+ bash-2042 3d..1 1us : __ata_scsi_find_dev <-ata_scsi_find_dev
+ bash-2042 3d..1 2us : ata_find_dev.part.14 <-__ata_scsi_find_dev
+ bash-2042 3d..1 2us : ata_qc_new_init <-__ata_scsi_queuecmd
+ bash-2042 3d..1 3us : ata_sg_init <-__ata_scsi_queuecmd
+ bash-2042 3d..1 4us : ata_scsi_rw_xlat <-__ata_scsi_queuecmd
+ bash-2042 3d..1 4us : ata_build_rw_tf <-ata_scsi_rw_xlat
[...]
- ls-4339 0d..2 46us : __rmqueue_smallest (__rmqueue)
- ls-4339 0d..2 47us : __mod_zone_page_state (__rmqueue_smallest)
- ls-4339 0d..2 47us : __rmqueue (rmqueue_bulk)
- ls-4339 0d..2 48us : __rmqueue_smallest (__rmqueue)
- ls-4339 0d..2 48us : __mod_zone_page_state (__rmqueue_smallest)
- ls-4339 0d..2 49us : _spin_unlock (rmqueue_bulk)
- ls-4339 0d..2 49us : sub_preempt_count (_spin_unlock)
- ls-4339 0d..1 50us : get_page_from_freelist (__alloc_pages_internal)
- ls-4339 0d..2 51us : trace_hardirqs_on (__alloc_pages_internal)
+ bash-2042 3d..1 67us : delay_tsc <-__delay
+ bash-2042 3d..1 67us : add_preempt_count <-delay_tsc
+ bash-2042 3d..2 67us : sub_preempt_count <-delay_tsc
+ bash-2042 3d..1 67us : add_preempt_count <-delay_tsc
+ bash-2042 3d..2 68us : sub_preempt_count <-delay_tsc
+ bash-2042 3d..1 68us+: ata_bmdma_start <-ata_bmdma_qc_issue
+ bash-2042 3d..1 71us : _raw_spin_unlock_irqrestore <-ata_scsi_queuecmd
+ bash-2042 3d..1 71us : _raw_spin_unlock_irqrestore <-ata_scsi_queuecmd
+ bash-2042 3d..1 72us+: trace_hardirqs_on <-ata_scsi_queuecmd
+ bash-2042 3d..1 120us : <stack trace>
+ => _raw_spin_unlock_irqrestore
+ => ata_scsi_queuecmd
+ => scsi_dispatch_cmd
+ => scsi_request_fn
+ => __blk_run_queue_uncond
+ => __blk_run_queue
+ => blk_queue_bio
+ => generic_make_request
+ => submit_bio
+ => submit_bh
+ => __ext3_get_inode_loc
+ => ext3_iget
+ => ext3_lookup
+ => lookup_real
+ => __lookup_hash
+ => walk_component
+ => lookup_last
+ => path_lookupat
+ => filename_lookup
+ => user_path_at_empty
+ => user_path_at
+ => vfs_fstatat
+ => vfs_stat
+ => sys_newstat
+ => system_call_fastpath
-
-Here we traced a 50 microsecond latency. But we also see all the
+Here we traced a 71 microsecond latency. But we also see all the
functions that were called during that time. Note that by
enabling function tracing, we incur an added overhead. This
overhead may extend the latency times. But nevertheless, this
@@ -614,120 +1049,122 @@
which preemption was disabled. The control of preemptoff tracer
is much like the irqsoff tracer.
+ # echo 0 > options/function-trace
# echo preemptoff > current_tracer
- # echo latency-format > trace_options
- # echo 0 > tracing_max_latency
# echo 1 > tracing_on
+ # echo 0 > tracing_max_latency
# ls -ltr
[...]
# echo 0 > tracing_on
# cat trace
# tracer: preemptoff
#
-preemptoff latency trace v1.1.5 on 2.6.26-rc8
---------------------------------------------------------------------
- latency: 29 us, #3/3, CPU#0 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:2)
- -----------------
- | task: sshd-4261 (uid:0 nice:0 policy:0 rt_prio:0)
- -----------------
- => started at: do_IRQ
- => ended at: __do_softirq
-
-# _------=> CPU#
-# / _-----=> irqs-off
-# | / _----=> need-resched
-# || / _---=> hardirq/softirq
-# ||| / _--=> preempt-depth
-# |||| /
-# ||||| delay
-# cmd pid ||||| time | caller
-# \ / ||||| \ | /
- sshd-4261 0d.h. 0us+: irq_enter (do_IRQ)
- sshd-4261 0d.s. 29us : _local_bh_enable (__do_softirq)
- sshd-4261 0d.s1 30us : trace_preempt_on (__do_softirq)
+# preemptoff latency trace v1.1.5 on 3.8.0-test+
+# --------------------------------------------------------------------
+# latency: 46 us, #4/4, CPU#1 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:4)
+# -----------------
+# | task: sshd-1991 (uid:0 nice:0 policy:0 rt_prio:0)
+# -----------------
+# => started at: do_IRQ
+# => ended at: do_IRQ
+#
+#
+# _------=> CPU#
+# / _-----=> irqs-off
+# | / _----=> need-resched
+# || / _---=> hardirq/softirq
+# ||| / _--=> preempt-depth
+# |||| / delay
+# cmd pid ||||| time | caller
+# \ / ||||| \ | /
+ sshd-1991 1d.h. 0us+: irq_enter <-do_IRQ
+ sshd-1991 1d..1 46us : irq_exit <-do_IRQ
+ sshd-1991 1d..1 47us+: trace_preempt_on <-do_IRQ
+ sshd-1991 1d..1 52us : <stack trace>
+ => sub_preempt_count
+ => irq_exit
+ => do_IRQ
+ => ret_from_intr
This has some more changes. Preemption was disabled when an
-interrupt came in (notice the 'h'), and was enabled while doing
-a softirq. (notice the 's'). But we also see that interrupts
-have been disabled when entering the preempt off section and
-leaving it (the 'd'). We do not know if interrupts were enabled
-in the mean time.
+interrupt came in (notice the 'h'), and was enabled on exit.
+But we also see that interrupts have been disabled when entering
+the preempt off section and leaving it (the 'd'). We do not know if
+interrupts were enabled in the mean time or shortly after this
+was over.
# tracer: preemptoff
#
-preemptoff latency trace v1.1.5 on 2.6.26-rc8
---------------------------------------------------------------------
- latency: 63 us, #87/87, CPU#0 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:2)
- -----------------
- | task: sshd-4261 (uid:0 nice:0 policy:0 rt_prio:0)
- -----------------
- => started at: remove_wait_queue
- => ended at: __do_softirq
-
-# _------=> CPU#
-# / _-----=> irqs-off
-# | / _----=> need-resched
-# || / _---=> hardirq/softirq
-# ||| / _--=> preempt-depth
-# |||| /
-# ||||| delay
-# cmd pid ||||| time | caller
-# \ / ||||| \ | /
- sshd-4261 0d..1 0us : _spin_lock_irqsave (remove_wait_queue)
- sshd-4261 0d..1 1us : _spin_unlock_irqrestore (remove_wait_queue)
- sshd-4261 0d..1 2us : do_IRQ (common_interrupt)
- sshd-4261 0d..1 2us : irq_enter (do_IRQ)
- sshd-4261 0d..1 2us : idle_cpu (irq_enter)
- sshd-4261 0d..1 3us : add_preempt_count (irq_enter)
- sshd-4261 0d.h1 3us : idle_cpu (irq_enter)
- sshd-4261 0d.h. 4us : handle_fasteoi_irq (do_IRQ)
+# preemptoff latency trace v1.1.5 on 3.8.0-test+
+# --------------------------------------------------------------------
+# latency: 83 us, #241/241, CPU#1 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:4)
+# -----------------
+# | task: bash-1994 (uid:0 nice:0 policy:0 rt_prio:0)
+# -----------------
+# => started at: wake_up_new_task
+# => ended at: task_rq_unlock
+#
+#
+# _------=> CPU#
+# / _-----=> irqs-off
+# | / _----=> need-resched
+# || / _---=> hardirq/softirq
+# ||| / _--=> preempt-depth
+# |||| / delay
+# cmd pid ||||| time | caller
+# \ / ||||| \ | /
+ bash-1994 1d..1 0us : _raw_spin_lock_irqsave <-wake_up_new_task
+ bash-1994 1d..1 0us : select_task_rq_fair <-select_task_rq
+ bash-1994 1d..1 1us : __rcu_read_lock <-select_task_rq_fair
+ bash-1994 1d..1 1us : source_load <-select_task_rq_fair
+ bash-1994 1d..1 1us : source_load <-select_task_rq_fair
[...]
- sshd-4261 0d.h. 12us : add_preempt_count (_spin_lock)
- sshd-4261 0d.h1 12us : ack_ioapic_quirk_irq (handle_fasteoi_irq)
- sshd-4261 0d.h1 13us : move_native_irq (ack_ioapic_quirk_irq)
- sshd-4261 0d.h1 13us : _spin_unlock (handle_fasteoi_irq)
- sshd-4261 0d.h1 14us : sub_preempt_count (_spin_unlock)
- sshd-4261 0d.h1 14us : irq_exit (do_IRQ)
- sshd-4261 0d.h1 15us : sub_preempt_count (irq_exit)
- sshd-4261 0d..2 15us : do_softirq (irq_exit)
- sshd-4261 0d... 15us : __do_softirq (do_softirq)
- sshd-4261 0d... 16us : __local_bh_disable (__do_softirq)
- sshd-4261 0d... 16us+: add_preempt_count (__local_bh_disable)
- sshd-4261 0d.s4 20us : add_preempt_count (__local_bh_disable)
- sshd-4261 0d.s4 21us : sub_preempt_count (local_bh_enable)
- sshd-4261 0d.s5 21us : sub_preempt_count (local_bh_enable)
+ bash-1994 1d..1 12us : irq_enter <-smp_apic_timer_interrupt
+ bash-1994 1d..1 12us : rcu_irq_enter <-irq_enter
+ bash-1994 1d..1 13us : add_preempt_count <-irq_enter
+ bash-1994 1d.h1 13us : exit_idle <-smp_apic_timer_interrupt
+ bash-1994 1d.h1 13us : hrtimer_interrupt <-smp_apic_timer_interrupt
+ bash-1994 1d.h1 13us : _raw_spin_lock <-hrtimer_interrupt
+ bash-1994 1d.h1 14us : add_preempt_count <-_raw_spin_lock
+ bash-1994 1d.h2 14us : ktime_get_update_offsets <-hrtimer_interrupt
[...]
- sshd-4261 0d.s6 41us : add_preempt_count (__local_bh_disable)
- sshd-4261 0d.s6 42us : sub_preempt_count (local_bh_enable)
- sshd-4261 0d.s7 42us : sub_preempt_count (local_bh_enable)
- sshd-4261 0d.s5 43us : add_preempt_count (__local_bh_disable)
- sshd-4261 0d.s5 43us : sub_preempt_count (local_bh_enable_ip)
- sshd-4261 0d.s6 44us : sub_preempt_count (local_bh_enable_ip)
- sshd-4261 0d.s5 44us : add_preempt_count (__local_bh_disable)
- sshd-4261 0d.s5 45us : sub_preempt_count (local_bh_enable)
+ bash-1994 1d.h1 35us : lapic_next_event <-clockevents_program_event
+ bash-1994 1d.h1 35us : irq_exit <-smp_apic_timer_interrupt
+ bash-1994 1d.h1 36us : sub_preempt_count <-irq_exit
+ bash-1994 1d..2 36us : do_softirq <-irq_exit
+ bash-1994 1d..2 36us : __do_softirq <-call_softirq
+ bash-1994 1d..2 36us : __local_bh_disable <-__do_softirq
+ bash-1994 1d.s2 37us : add_preempt_count <-_raw_spin_lock_irq
+ bash-1994 1d.s3 38us : _raw_spin_unlock <-run_timer_softirq
+ bash-1994 1d.s3 39us : sub_preempt_count <-_raw_spin_unlock
+ bash-1994 1d.s2 39us : call_timer_fn <-run_timer_softirq
[...]
- sshd-4261 0d.s. 63us : _local_bh_enable (__do_softirq)
- sshd-4261 0d.s1 64us : trace_preempt_on (__do_softirq)
+ bash-1994 1dNs2 81us : cpu_needs_another_gp <-rcu_process_callbacks
+ bash-1994 1dNs2 82us : __local_bh_enable <-__do_softirq
+ bash-1994 1dNs2 82us : sub_preempt_count <-__local_bh_enable
+ bash-1994 1dN.2 82us : idle_cpu <-irq_exit
+ bash-1994 1dN.2 83us : rcu_irq_exit <-irq_exit
+ bash-1994 1dN.2 83us : sub_preempt_count <-irq_exit
+ bash-1994 1.N.1 84us : _raw_spin_unlock_irqrestore <-task_rq_unlock
+ bash-1994 1.N.1 84us+: trace_preempt_on <-task_rq_unlock
+ bash-1994 1.N.1 104us : <stack trace>
+ => sub_preempt_count
+ => _raw_spin_unlock_irqrestore
+ => task_rq_unlock
+ => wake_up_new_task
+ => do_fork
+ => sys_clone
+ => stub_clone
The above is an example of the preemptoff trace with
-ftrace_enabled set. Here we see that interrupts were disabled
+function-trace set. Here we see that interrupts were not disabled
the entire time. The irq_enter code lets us know that we entered
an interrupt 'h'. Before that, the functions being traced still
show that it is not in an interrupt, but we can see from the
functions themselves that this is not the case.
-Notice that __do_softirq when called does not have a
-preempt_count. It may seem that we missed a preempt enabling.
-What really happened is that the preempt count is held on the
-thread's stack and we switched to the softirq stack (4K stacks
-in effect). The code does not copy the preempt count, but
-because interrupts are disabled, we do not need to worry about
-it. Having a tracer like this is good for letting people know
-what really happens inside the kernel.
-
-
preemptirqsoff
--------------
@@ -762,38 +1199,57 @@
Again, using this trace is much like the irqsoff and preemptoff
tracers.
+ # echo 0 > options/function-trace
# echo preemptirqsoff > current_tracer
- # echo latency-format > trace_options
- # echo 0 > tracing_max_latency
# echo 1 > tracing_on
+ # echo 0 > tracing_max_latency
# ls -ltr
[...]
# echo 0 > tracing_on
# cat trace
# tracer: preemptirqsoff
#
-preemptirqsoff latency trace v1.1.5 on 2.6.26-rc8
---------------------------------------------------------------------
- latency: 293 us, #3/3, CPU#0 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:2)
- -----------------
- | task: ls-4860 (uid:0 nice:0 policy:0 rt_prio:0)
- -----------------
- => started at: apic_timer_interrupt
- => ended at: __do_softirq
-
-# _------=> CPU#
-# / _-----=> irqs-off
-# | / _----=> need-resched
-# || / _---=> hardirq/softirq
-# ||| / _--=> preempt-depth
-# |||| /
-# ||||| delay
-# cmd pid ||||| time | caller
-# \ / ||||| \ | /
- ls-4860 0d... 0us!: trace_hardirqs_off_thunk (apic_timer_interrupt)
- ls-4860 0d.s. 294us : _local_bh_enable (__do_softirq)
- ls-4860 0d.s1 294us : trace_preempt_on (__do_softirq)
-
+# preemptirqsoff latency trace v1.1.5 on 3.8.0-test+
+# --------------------------------------------------------------------
+# latency: 100 us, #4/4, CPU#3 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:4)
+# -----------------
+# | task: ls-2230 (uid:0 nice:0 policy:0 rt_prio:0)
+# -----------------
+# => started at: ata_scsi_queuecmd
+# => ended at: ata_scsi_queuecmd
+#
+#
+# _------=> CPU#
+# / _-----=> irqs-off
+# | / _----=> need-resched
+# || / _---=> hardirq/softirq
+# ||| / _--=> preempt-depth
+# |||| / delay
+# cmd pid ||||| time | caller
+# \ / ||||| \ | /
+ ls-2230 3d... 0us+: _raw_spin_lock_irqsave <-ata_scsi_queuecmd
+ ls-2230 3...1 100us : _raw_spin_unlock_irqrestore <-ata_scsi_queuecmd
+ ls-2230 3...1 101us+: trace_preempt_on <-ata_scsi_queuecmd
+ ls-2230 3...1 111us : <stack trace>
+ => sub_preempt_count
+ => _raw_spin_unlock_irqrestore
+ => ata_scsi_queuecmd
+ => scsi_dispatch_cmd
+ => scsi_request_fn
+ => __blk_run_queue_uncond
+ => __blk_run_queue
+ => blk_queue_bio
+ => generic_make_request
+ => submit_bio
+ => submit_bh
+ => ext3_bread
+ => ext3_dir_bread
+ => htree_dirblock_to_tree
+ => ext3_htree_fill_tree
+ => ext3_readdir
+ => vfs_readdir
+ => sys_getdents
+ => system_call_fastpath
The trace_hardirqs_off_thunk is called from assembly on x86 when
@@ -802,105 +1258,158 @@
within the preemption points. We do see that it started with
preemption enabled.
-Here is a trace with ftrace_enabled set:
-
+Here is a trace with function-trace set:
# tracer: preemptirqsoff
#
-preemptirqsoff latency trace v1.1.5 on 2.6.26-rc8
---------------------------------------------------------------------
- latency: 105 us, #183/183, CPU#0 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:2)
- -----------------
- | task: sshd-4261 (uid:0 nice:0 policy:0 rt_prio:0)
- -----------------
- => started at: write_chan
- => ended at: __do_softirq
+# preemptirqsoff latency trace v1.1.5 on 3.8.0-test+
+# --------------------------------------------------------------------
+# latency: 161 us, #339/339, CPU#3 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:4)
+# -----------------
+# | task: ls-2269 (uid:0 nice:0 policy:0 rt_prio:0)
+# -----------------
+# => started at: schedule
+# => ended at: mutex_unlock
+#
+#
+# _------=> CPU#
+# / _-----=> irqs-off
+# | / _----=> need-resched
+# || / _---=> hardirq/softirq
+# ||| / _--=> preempt-depth
+# |||| / delay
+# cmd pid ||||| time | caller
+# \ / ||||| \ | /
+kworker/-59 3...1 0us : __schedule <-schedule
+kworker/-59 3d..1 0us : rcu_preempt_qs <-rcu_note_context_switch
+kworker/-59 3d..1 1us : add_preempt_count <-_raw_spin_lock_irq
+kworker/-59 3d..2 1us : deactivate_task <-__schedule
+kworker/-59 3d..2 1us : dequeue_task <-deactivate_task
+kworker/-59 3d..2 2us : update_rq_clock <-dequeue_task
+kworker/-59 3d..2 2us : dequeue_task_fair <-dequeue_task
+kworker/-59 3d..2 2us : update_curr <-dequeue_task_fair
+kworker/-59 3d..2 2us : update_min_vruntime <-update_curr
+kworker/-59 3d..2 3us : cpuacct_charge <-update_curr
+kworker/-59 3d..2 3us : __rcu_read_lock <-cpuacct_charge
+kworker/-59 3d..2 3us : __rcu_read_unlock <-cpuacct_charge
+kworker/-59 3d..2 3us : update_cfs_rq_blocked_load <-dequeue_task_fair
+kworker/-59 3d..2 4us : clear_buddies <-dequeue_task_fair
+kworker/-59 3d..2 4us : account_entity_dequeue <-dequeue_task_fair
+kworker/-59 3d..2 4us : update_min_vruntime <-dequeue_task_fair
+kworker/-59 3d..2 4us : update_cfs_shares <-dequeue_task_fair
+kworker/-59 3d..2 5us : hrtick_update <-dequeue_task_fair
+kworker/-59 3d..2 5us : wq_worker_sleeping <-__schedule
+kworker/-59 3d..2 5us : kthread_data <-wq_worker_sleeping
+kworker/-59 3d..2 5us : put_prev_task_fair <-__schedule
+kworker/-59 3d..2 6us : pick_next_task_fair <-pick_next_task
+kworker/-59 3d..2 6us : clear_buddies <-pick_next_task_fair
+kworker/-59 3d..2 6us : set_next_entity <-pick_next_task_fair
+kworker/-59 3d..2 6us : update_stats_wait_end <-set_next_entity
+ ls-2269 3d..2 7us : finish_task_switch <-__schedule
+ ls-2269 3d..2 7us : _raw_spin_unlock_irq <-finish_task_switch
+ ls-2269 3d..2 8us : do_IRQ <-ret_from_intr
+ ls-2269 3d..2 8us : irq_enter <-do_IRQ
+ ls-2269 3d..2 8us : rcu_irq_enter <-irq_enter
+ ls-2269 3d..2 9us : add_preempt_count <-irq_enter
+ ls-2269 3d.h2 9us : exit_idle <-do_IRQ
+[...]
+ ls-2269 3d.h3 20us : sub_preempt_count <-_raw_spin_unlock
+ ls-2269 3d.h2 20us : irq_exit <-do_IRQ
+ ls-2269 3d.h2 21us : sub_preempt_count <-irq_exit
+ ls-2269 3d..3 21us : do_softirq <-irq_exit
+ ls-2269 3d..3 21us : __do_softirq <-call_softirq
+ ls-2269 3d..3 21us+: __local_bh_disable <-__do_softirq
+ ls-2269 3d.s4 29us : sub_preempt_count <-_local_bh_enable_ip
+ ls-2269 3d.s5 29us : sub_preempt_count <-_local_bh_enable_ip
+ ls-2269 3d.s5 31us : do_IRQ <-ret_from_intr
+ ls-2269 3d.s5 31us : irq_enter <-do_IRQ
+ ls-2269 3d.s5 31us : rcu_irq_enter <-irq_enter
+[...]
+ ls-2269 3d.s5 31us : rcu_irq_enter <-irq_enter
+ ls-2269 3d.s5 32us : add_preempt_count <-irq_enter
+ ls-2269 3d.H5 32us : exit_idle <-do_IRQ
+ ls-2269 3d.H5 32us : handle_irq <-do_IRQ
+ ls-2269 3d.H5 32us : irq_to_desc <-handle_irq
+ ls-2269 3d.H5 33us : handle_fasteoi_irq <-handle_irq
+[...]
+ ls-2269 3d.s5 158us : _raw_spin_unlock_irqrestore <-rtl8139_poll
+ ls-2269 3d.s3 158us : net_rps_action_and_irq_enable.isra.65 <-net_rx_action
+ ls-2269 3d.s3 159us : __local_bh_enable <-__do_softirq
+ ls-2269 3d.s3 159us : sub_preempt_count <-__local_bh_enable
+ ls-2269 3d..3 159us : idle_cpu <-irq_exit
+ ls-2269 3d..3 159us : rcu_irq_exit <-irq_exit
+ ls-2269 3d..3 160us : sub_preempt_count <-irq_exit
+ ls-2269 3d... 161us : __mutex_unlock_slowpath <-mutex_unlock
+ ls-2269 3d... 162us+: trace_hardirqs_on <-mutex_unlock
+ ls-2269 3d... 186us : <stack trace>
+ => __mutex_unlock_slowpath
+ => mutex_unlock
+ => process_output
+ => n_tty_write
+ => tty_write
+ => vfs_write
+ => sys_write
+ => system_call_fastpath
-# _------=> CPU#
-# / _-----=> irqs-off
-# | / _----=> need-resched
-# || / _---=> hardirq/softirq
-# ||| / _--=> preempt-depth
-# |||| /
-# ||||| delay
-# cmd pid ||||| time | caller
-# \ / ||||| \ | /
- ls-4473 0.N.. 0us : preempt_schedule (write_chan)
- ls-4473 0dN.1 1us : _spin_lock (schedule)
- ls-4473 0dN.1 2us : add_preempt_count (_spin_lock)
- ls-4473 0d..2 2us : put_prev_task_fair (schedule)
-[...]
- ls-4473 0d..2 13us : set_normalized_timespec (ktime_get_ts)
- ls-4473 0d..2 13us : __switch_to (schedule)
- sshd-4261 0d..2 14us : finish_task_switch (schedule)
- sshd-4261 0d..2 14us : _spin_unlock_irq (finish_task_switch)
- sshd-4261 0d..1 15us : add_preempt_count (_spin_lock_irqsave)
- sshd-4261 0d..2 16us : _spin_unlock_irqrestore (hrtick_set)
- sshd-4261 0d..2 16us : do_IRQ (common_interrupt)
- sshd-4261 0d..2 17us : irq_enter (do_IRQ)
- sshd-4261 0d..2 17us : idle_cpu (irq_enter)
- sshd-4261 0d..2 18us : add_preempt_count (irq_enter)
- sshd-4261 0d.h2 18us : idle_cpu (irq_enter)
- sshd-4261 0d.h. 18us : handle_fasteoi_irq (do_IRQ)
- sshd-4261 0d.h. 19us : _spin_lock (handle_fasteoi_irq)
- sshd-4261 0d.h. 19us : add_preempt_count (_spin_lock)
- sshd-4261 0d.h1 20us : _spin_unlock (handle_fasteoi_irq)
- sshd-4261 0d.h1 20us : sub_preempt_count (_spin_unlock)
-[...]
- sshd-4261 0d.h1 28us : _spin_unlock (handle_fasteoi_irq)
- sshd-4261 0d.h1 29us : sub_preempt_count (_spin_unlock)
- sshd-4261 0d.h2 29us : irq_exit (do_IRQ)
- sshd-4261 0d.h2 29us : sub_preempt_count (irq_exit)
- sshd-4261 0d..3 30us : do_softirq (irq_exit)
- sshd-4261 0d... 30us : __do_softirq (do_softirq)
- sshd-4261 0d... 31us : __local_bh_disable (__do_softirq)
- sshd-4261 0d... 31us+: add_preempt_count (__local_bh_disable)
- sshd-4261 0d.s4 34us : add_preempt_count (__local_bh_disable)
-[...]
- sshd-4261 0d.s3 43us : sub_preempt_count (local_bh_enable_ip)
- sshd-4261 0d.s4 44us : sub_preempt_count (local_bh_enable_ip)
- sshd-4261 0d.s3 44us : smp_apic_timer_interrupt (apic_timer_interrupt)
- sshd-4261 0d.s3 45us : irq_enter (smp_apic_timer_interrupt)
- sshd-4261 0d.s3 45us : idle_cpu (irq_enter)
- sshd-4261 0d.s3 46us : add_preempt_count (irq_enter)
- sshd-4261 0d.H3 46us : idle_cpu (irq_enter)
- sshd-4261 0d.H3 47us : hrtimer_interrupt (smp_apic_timer_interrupt)
- sshd-4261 0d.H3 47us : ktime_get (hrtimer_interrupt)
-[...]
- sshd-4261 0d.H3 81us : tick_program_event (hrtimer_interrupt)
- sshd-4261 0d.H3 82us : ktime_get (tick_program_event)
- sshd-4261 0d.H3 82us : ktime_get_ts (ktime_get)
- sshd-4261 0d.H3 83us : getnstimeofday (ktime_get_ts)
- sshd-4261 0d.H3 83us : set_normalized_timespec (ktime_get_ts)
- sshd-4261 0d.H3 84us : clockevents_program_event (tick_program_event)
- sshd-4261 0d.H3 84us : lapic_next_event (clockevents_program_event)
- sshd-4261 0d.H3 85us : irq_exit (smp_apic_timer_interrupt)
- sshd-4261 0d.H3 85us : sub_preempt_count (irq_exit)
- sshd-4261 0d.s4 86us : sub_preempt_count (irq_exit)
- sshd-4261 0d.s3 86us : add_preempt_count (__local_bh_disable)
-[...]
- sshd-4261 0d.s1 98us : sub_preempt_count (net_rx_action)
- sshd-4261 0d.s. 99us : add_preempt_count (_spin_lock_irq)
- sshd-4261 0d.s1 99us+: _spin_unlock_irq (run_timer_softirq)
- sshd-4261 0d.s. 104us : _local_bh_enable (__do_softirq)
- sshd-4261 0d.s. 104us : sub_preempt_count (_local_bh_enable)
- sshd-4261 0d.s. 105us : _local_bh_enable (__do_softirq)
- sshd-4261 0d.s1 105us : trace_preempt_on (__do_softirq)
-
-
-This is a very interesting trace. It started with the preemption
-of the ls task. We see that the task had the "need_resched" bit
-set via the 'N' in the trace. Interrupts were disabled before
-the spin_lock at the beginning of the trace. We see that a
-schedule took place to run sshd. When the interrupts were
-enabled, we took an interrupt. On return from the interrupt
-handler, the softirq ran. We took another interrupt while
-running the softirq as we see from the capital 'H'.
+This is an interesting trace. It started with kworker running and
+scheduling out and ls taking over. But as soon as ls released the
+rq lock and enabled interrupts (but not preemption) an interrupt
+triggered. When the interrupt finished, it started running softirqs.
+But while the softirq was running, another interrupt triggered.
+When an interrupt is running inside a softirq, the annotation is 'H'.
wakeup
------
+One common case that people are interested in tracing is the
+time it takes for a task that is woken to actually wake up.
+Now for non Real-Time tasks, this can be arbitrary. But tracing
+it none the less can be interesting.
+
+Without function tracing:
+
+ # echo 0 > options/function-trace
+ # echo wakeup > current_tracer
+ # echo 1 > tracing_on
+ # echo 0 > tracing_max_latency
+ # chrt -f 5 sleep 1
+ # echo 0 > tracing_on
+ # cat trace
+# tracer: wakeup
+#
+# wakeup latency trace v1.1.5 on 3.8.0-test+
+# --------------------------------------------------------------------
+# latency: 15 us, #4/4, CPU#3 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:4)
+# -----------------
+# | task: kworker/3:1H-312 (uid:0 nice:-20 policy:0 rt_prio:0)
+# -----------------
+#
+# _------=> CPU#
+# / _-----=> irqs-off
+# | / _----=> need-resched
+# || / _---=> hardirq/softirq
+# ||| / _--=> preempt-depth
+# |||| / delay
+# cmd pid ||||| time | caller
+# \ / ||||| \ | /
+ <idle>-0 3dNs7 0us : 0:120:R + [003] 312:100:R kworker/3:1H
+ <idle>-0 3dNs7 1us+: ttwu_do_activate.constprop.87 <-try_to_wake_up
+ <idle>-0 3d..3 15us : __schedule <-schedule
+ <idle>-0 3d..3 15us : 0:120:R ==> [003] 312:100:R kworker/3:1H
+
+The tracer only traces the highest priority task in the system
+to avoid tracing the normal circumstances. Here we see that
+the kworker with a nice priority of -20 (not very nice), took
+just 15 microseconds from the time it woke up, to the time it
+ran.
+
+Non Real-Time tasks are not that interesting. A more interesting
+trace is to concentrate only on Real-Time tasks.
+
+wakeup_rt
+---------
+
In a Real-Time environment it is very important to know the
wakeup time it takes for the highest priority task that is woken
up to the time that it executes. This is also known as "schedule
@@ -914,124 +1423,229 @@
That is the longest latency it takes for something to happen,
and not the average. We can have a very fast scheduler that may
only have a large latency once in a while, but that would not
-work well with Real-Time tasks. The wakeup tracer was designed
+work well with Real-Time tasks. The wakeup_rt tracer was designed
to record the worst case wakeups of RT tasks. Non-RT tasks are
not recorded because the tracer only records one worst case and
tracing non-RT tasks that are unpredictable will overwrite the
-worst case latency of RT tasks.
+worst case latency of RT tasks (just run the normal wakeup
+tracer for a while to see that effect).
Since this tracer only deals with RT tasks, we will run this
slightly differently than we did with the previous tracers.
Instead of performing an 'ls', we will run 'sleep 1' under
'chrt' which changes the priority of the task.
- # echo wakeup > current_tracer
- # echo latency-format > trace_options
- # echo 0 > tracing_max_latency
+ # echo 0 > options/function-trace
+ # echo wakeup_rt > current_tracer
# echo 1 > tracing_on
+ # echo 0 > tracing_max_latency
# chrt -f 5 sleep 1
# echo 0 > tracing_on
# cat trace
# tracer: wakeup
#
-wakeup latency trace v1.1.5 on 2.6.26-rc8
---------------------------------------------------------------------
- latency: 4 us, #2/2, CPU#1 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:2)
- -----------------
- | task: sleep-4901 (uid:0 nice:0 policy:1 rt_prio:5)
- -----------------
-
-# _------=> CPU#
-# / _-----=> irqs-off
-# | / _----=> need-resched
-# || / _---=> hardirq/softirq
-# ||| / _--=> preempt-depth
-# |||| /
-# ||||| delay
-# cmd pid ||||| time | caller
-# \ / ||||| \ | /
- <idle>-0 1d.h4 0us+: try_to_wake_up (wake_up_process)
- <idle>-0 1d..4 4us : schedule (cpu_idle)
+# tracer: wakeup_rt
+#
+# wakeup_rt latency trace v1.1.5 on 3.8.0-test+
+# --------------------------------------------------------------------
+# latency: 5 us, #4/4, CPU#3 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:4)
+# -----------------
+# | task: sleep-2389 (uid:0 nice:0 policy:1 rt_prio:5)
+# -----------------
+#
+# _------=> CPU#
+# / _-----=> irqs-off
+# | / _----=> need-resched
+# || / _---=> hardirq/softirq
+# ||| / _--=> preempt-depth
+# |||| / delay
+# cmd pid ||||| time | caller
+# \ / ||||| \ | /
+ <idle>-0 3d.h4 0us : 0:120:R + [003] 2389: 94:R sleep
+ <idle>-0 3d.h4 1us+: ttwu_do_activate.constprop.87 <-try_to_wake_up
+ <idle>-0 3d..3 5us : __schedule <-schedule
+ <idle>-0 3d..3 5us : 0:120:R ==> [003] 2389: 94:R sleep
-Running this on an idle system, we see that it only took 4
-microseconds to perform the task switch. Note, since the trace
-marker in the schedule is before the actual "switch", we stop
-the tracing when the recorded task is about to schedule in. This
-may change if we add a new marker at the end of the scheduler.
+Running this on an idle system, we see that it only took 5 microseconds
+to perform the task switch. Note, since the trace point in the schedule
+is before the actual "switch", we stop the tracing when the recorded task
+is about to schedule in. This may change if we add a new marker at the
+end of the scheduler.
-Notice that the recorded task is 'sleep' with the PID of 4901
+Notice that the recorded task is 'sleep' with the PID of 2389
and it has an rt_prio of 5. This priority is user-space priority
and not the internal kernel priority. The policy is 1 for
SCHED_FIFO and 2 for SCHED_RR.
-Doing the same with chrt -r 5 and ftrace_enabled set.
+Note, that the trace data shows the internal priority (99 - rtprio).
-# tracer: wakeup
+ <idle>-0 3d..3 5us : 0:120:R ==> [003] 2389: 94:R sleep
+
+The 0:120:R means idle was running with a nice priority of 0 (120 - 20)
+and in the running state 'R'. The sleep task was scheduled in with
+2389: 94:R. That is the priority is the kernel rtprio (99 - 5 = 94)
+and it too is in the running state.
+
+Doing the same with chrt -r 5 and function-trace set.
+
+ echo 1 > options/function-trace
+
+# tracer: wakeup_rt
#
-wakeup latency trace v1.1.5 on 2.6.26-rc8
---------------------------------------------------------------------
- latency: 50 us, #60/60, CPU#1 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:2)
- -----------------
- | task: sleep-4068 (uid:0 nice:0 policy:2 rt_prio:5)
- -----------------
+# wakeup_rt latency trace v1.1.5 on 3.8.0-test+
+# --------------------------------------------------------------------
+# latency: 29 us, #85/85, CPU#3 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:4)
+# -----------------
+# | task: sleep-2448 (uid:0 nice:0 policy:1 rt_prio:5)
+# -----------------
+#
+# _------=> CPU#
+# / _-----=> irqs-off
+# | / _----=> need-resched
+# || / _---=> hardirq/softirq
+# ||| / _--=> preempt-depth
+# |||| / delay
+# cmd pid ||||| time | caller
+# \ / ||||| \ | /
+ <idle>-0 3d.h4 1us+: 0:120:R + [003] 2448: 94:R sleep
+ <idle>-0 3d.h4 2us : ttwu_do_activate.constprop.87 <-try_to_wake_up
+ <idle>-0 3d.h3 3us : check_preempt_curr <-ttwu_do_wakeup
+ <idle>-0 3d.h3 3us : resched_task <-check_preempt_curr
+ <idle>-0 3dNh3 4us : task_woken_rt <-ttwu_do_wakeup
+ <idle>-0 3dNh3 4us : _raw_spin_unlock <-try_to_wake_up
+ <idle>-0 3dNh3 4us : sub_preempt_count <-_raw_spin_unlock
+ <idle>-0 3dNh2 5us : ttwu_stat <-try_to_wake_up
+ <idle>-0 3dNh2 5us : _raw_spin_unlock_irqrestore <-try_to_wake_up
+ <idle>-0 3dNh2 6us : sub_preempt_count <-_raw_spin_unlock_irqrestore
+ <idle>-0 3dNh1 6us : _raw_spin_lock <-__run_hrtimer
+ <idle>-0 3dNh1 6us : add_preempt_count <-_raw_spin_lock
+ <idle>-0 3dNh2 7us : _raw_spin_unlock <-hrtimer_interrupt
+ <idle>-0 3dNh2 7us : sub_preempt_count <-_raw_spin_unlock
+ <idle>-0 3dNh1 7us : tick_program_event <-hrtimer_interrupt
+ <idle>-0 3dNh1 7us : clockevents_program_event <-tick_program_event
+ <idle>-0 3dNh1 8us : ktime_get <-clockevents_program_event
+ <idle>-0 3dNh1 8us : lapic_next_event <-clockevents_program_event
+ <idle>-0 3dNh1 8us : irq_exit <-smp_apic_timer_interrupt
+ <idle>-0 3dNh1 9us : sub_preempt_count <-irq_exit
+ <idle>-0 3dN.2 9us : idle_cpu <-irq_exit
+ <idle>-0 3dN.2 9us : rcu_irq_exit <-irq_exit
+ <idle>-0 3dN.2 10us : rcu_eqs_enter_common.isra.45 <-rcu_irq_exit
+ <idle>-0 3dN.2 10us : sub_preempt_count <-irq_exit
+ <idle>-0 3.N.1 11us : rcu_idle_exit <-cpu_idle
+ <idle>-0 3dN.1 11us : rcu_eqs_exit_common.isra.43 <-rcu_idle_exit
+ <idle>-0 3.N.1 11us : tick_nohz_idle_exit <-cpu_idle
+ <idle>-0 3dN.1 12us : menu_hrtimer_cancel <-tick_nohz_idle_exit
+ <idle>-0 3dN.1 12us : ktime_get <-tick_nohz_idle_exit
+ <idle>-0 3dN.1 12us : tick_do_update_jiffies64 <-tick_nohz_idle_exit
+ <idle>-0 3dN.1 13us : update_cpu_load_nohz <-tick_nohz_idle_exit
+ <idle>-0 3dN.1 13us : _raw_spin_lock <-update_cpu_load_nohz
+ <idle>-0 3dN.1 13us : add_preempt_count <-_raw_spin_lock
+ <idle>-0 3dN.2 13us : __update_cpu_load <-update_cpu_load_nohz
+ <idle>-0 3dN.2 14us : sched_avg_update <-__update_cpu_load
+ <idle>-0 3dN.2 14us : _raw_spin_unlock <-update_cpu_load_nohz
+ <idle>-0 3dN.2 14us : sub_preempt_count <-_raw_spin_unlock
+ <idle>-0 3dN.1 15us : calc_load_exit_idle <-tick_nohz_idle_exit
+ <idle>-0 3dN.1 15us : touch_softlockup_watchdog <-tick_nohz_idle_exit
+ <idle>-0 3dN.1 15us : hrtimer_cancel <-tick_nohz_idle_exit
+ <idle>-0 3dN.1 15us : hrtimer_try_to_cancel <-hrtimer_cancel
+ <idle>-0 3dN.1 16us : lock_hrtimer_base.isra.18 <-hrtimer_try_to_cancel
+ <idle>-0 3dN.1 16us : _raw_spin_lock_irqsave <-lock_hrtimer_base.isra.18
+ <idle>-0 3dN.1 16us : add_preempt_count <-_raw_spin_lock_irqsave
+ <idle>-0 3dN.2 17us : __remove_hrtimer <-remove_hrtimer.part.16
+ <idle>-0 3dN.2 17us : hrtimer_force_reprogram <-__remove_hrtimer
+ <idle>-0 3dN.2 17us : tick_program_event <-hrtimer_force_reprogram
+ <idle>-0 3dN.2 18us : clockevents_program_event <-tick_program_event
+ <idle>-0 3dN.2 18us : ktime_get <-clockevents_program_event
+ <idle>-0 3dN.2 18us : lapic_next_event <-clockevents_program_event
+ <idle>-0 3dN.2 19us : _raw_spin_unlock_irqrestore <-hrtimer_try_to_cancel
+ <idle>-0 3dN.2 19us : sub_preempt_count <-_raw_spin_unlock_irqrestore
+ <idle>-0 3dN.1 19us : hrtimer_forward <-tick_nohz_idle_exit
+ <idle>-0 3dN.1 20us : ktime_add_safe <-hrtimer_forward
+ <idle>-0 3dN.1 20us : ktime_add_safe <-hrtimer_forward
+ <idle>-0 3dN.1 20us : hrtimer_start_range_ns <-hrtimer_start_expires.constprop.11
+ <idle>-0 3dN.1 20us : __hrtimer_start_range_ns <-hrtimer_start_range_ns
+ <idle>-0 3dN.1 21us : lock_hrtimer_base.isra.18 <-__hrtimer_start_range_ns
+ <idle>-0 3dN.1 21us : _raw_spin_lock_irqsave <-lock_hrtimer_base.isra.18
+ <idle>-0 3dN.1 21us : add_preempt_count <-_raw_spin_lock_irqsave
+ <idle>-0 3dN.2 22us : ktime_add_safe <-__hrtimer_start_range_ns
+ <idle>-0 3dN.2 22us : enqueue_hrtimer <-__hrtimer_start_range_ns
+ <idle>-0 3dN.2 22us : tick_program_event <-__hrtimer_start_range_ns
+ <idle>-0 3dN.2 23us : clockevents_program_event <-tick_program_event
+ <idle>-0 3dN.2 23us : ktime_get <-clockevents_program_event
+ <idle>-0 3dN.2 23us : lapic_next_event <-clockevents_program_event
+ <idle>-0 3dN.2 24us : _raw_spin_unlock_irqrestore <-__hrtimer_start_range_ns
+ <idle>-0 3dN.2 24us : sub_preempt_count <-_raw_spin_unlock_irqrestore
+ <idle>-0 3dN.1 24us : account_idle_ticks <-tick_nohz_idle_exit
+ <idle>-0 3dN.1 24us : account_idle_time <-account_idle_ticks
+ <idle>-0 3.N.1 25us : sub_preempt_count <-cpu_idle
+ <idle>-0 3.N.. 25us : schedule <-cpu_idle
+ <idle>-0 3.N.. 25us : __schedule <-preempt_schedule
+ <idle>-0 3.N.. 26us : add_preempt_count <-__schedule
+ <idle>-0 3.N.1 26us : rcu_note_context_switch <-__schedule
+ <idle>-0 3.N.1 26us : rcu_sched_qs <-rcu_note_context_switch
+ <idle>-0 3dN.1 27us : rcu_preempt_qs <-rcu_note_context_switch
+ <idle>-0 3.N.1 27us : _raw_spin_lock_irq <-__schedule
+ <idle>-0 3dN.1 27us : add_preempt_count <-_raw_spin_lock_irq
+ <idle>-0 3dN.2 28us : put_prev_task_idle <-__schedule
+ <idle>-0 3dN.2 28us : pick_next_task_stop <-pick_next_task
+ <idle>-0 3dN.2 28us : pick_next_task_rt <-pick_next_task
+ <idle>-0 3dN.2 29us : dequeue_pushable_task <-pick_next_task_rt
+ <idle>-0 3d..3 29us : __schedule <-preempt_schedule
+ <idle>-0 3d..3 30us : 0:120:R ==> [003] 2448: 94:R sleep
-# _------=> CPU#
-# / _-----=> irqs-off
-# | / _----=> need-resched
-# || / _---=> hardirq/softirq
-# ||| / _--=> preempt-depth
-# |||| /
-# ||||| delay
-# cmd pid ||||| time | caller
-# \ / ||||| \ | /
-ksoftirq-7 1d.H3 0us : try_to_wake_up (wake_up_process)
-ksoftirq-7 1d.H4 1us : sub_preempt_count (marker_probe_cb)
-ksoftirq-7 1d.H3 2us : check_preempt_wakeup (try_to_wake_up)
-ksoftirq-7 1d.H3 3us : update_curr (check_preempt_wakeup)
-ksoftirq-7 1d.H3 4us : calc_delta_mine (update_curr)
-ksoftirq-7 1d.H3 5us : __resched_task (check_preempt_wakeup)
-ksoftirq-7 1d.H3 6us : task_wake_up_rt (try_to_wake_up)
-ksoftirq-7 1d.H3 7us : _spin_unlock_irqrestore (try_to_wake_up)
-[...]
-ksoftirq-7 1d.H2 17us : irq_exit (smp_apic_timer_interrupt)
-ksoftirq-7 1d.H2 18us : sub_preempt_count (irq_exit)
-ksoftirq-7 1d.s3 19us : sub_preempt_count (irq_exit)
-ksoftirq-7 1..s2 20us : rcu_process_callbacks (__do_softirq)
-[...]
-ksoftirq-7 1..s2 26us : __rcu_process_callbacks (rcu_process_callbacks)
-ksoftirq-7 1d.s2 27us : _local_bh_enable (__do_softirq)
-ksoftirq-7 1d.s2 28us : sub_preempt_count (_local_bh_enable)
-ksoftirq-7 1.N.3 29us : sub_preempt_count (ksoftirqd)
-ksoftirq-7 1.N.2 30us : _cond_resched (ksoftirqd)
-ksoftirq-7 1.N.2 31us : __cond_resched (_cond_resched)
-ksoftirq-7 1.N.2 32us : add_preempt_count (__cond_resched)
-ksoftirq-7 1.N.2 33us : schedule (__cond_resched)
-ksoftirq-7 1.N.2 33us : add_preempt_count (schedule)
-ksoftirq-7 1.N.3 34us : hrtick_clear (schedule)
-ksoftirq-7 1dN.3 35us : _spin_lock (schedule)
-ksoftirq-7 1dN.3 36us : add_preempt_count (_spin_lock)
-ksoftirq-7 1d..4 37us : put_prev_task_fair (schedule)
-ksoftirq-7 1d..4 38us : update_curr (put_prev_task_fair)
-[...]
-ksoftirq-7 1d..5 47us : _spin_trylock (tracing_record_cmdline)
-ksoftirq-7 1d..5 48us : add_preempt_count (_spin_trylock)
-ksoftirq-7 1d..6 49us : _spin_unlock (tracing_record_cmdline)
-ksoftirq-7 1d..6 49us : sub_preempt_count (_spin_unlock)
-ksoftirq-7 1d..4 50us : schedule (__cond_resched)
+This isn't that big of a trace, even with function tracing enabled,
+so I included the entire trace.
-The interrupt went off while running ksoftirqd. This task runs
-at SCHED_OTHER. Why did not we see the 'N' set early? This may
-be a harmless bug with x86_32 and 4K stacks. On x86_32 with 4K
-stacks configured, the interrupt and softirq run with their own
-stack. Some information is held on the top of the task's stack
-(need_resched and preempt_count are both stored there). The
-setting of the NEED_RESCHED bit is done directly to the task's
-stack, but the reading of the NEED_RESCHED is done by looking at
-the current stack, which in this case is the stack for the hard
-interrupt. This hides the fact that NEED_RESCHED has been set.
-We do not see the 'N' until we switch back to the task's
-assigned stack.
+The interrupt went off while when the system was idle. Somewhere
+before task_woken_rt() was called, the NEED_RESCHED flag was set,
+this is indicated by the first occurrence of the 'N' flag.
+
+Latency tracing and events
+--------------------------
+As function tracing can induce a much larger latency, but without
+seeing what happens within the latency it is hard to know what
+caused it. There is a middle ground, and that is with enabling
+events.
+
+ # echo 0 > options/function-trace
+ # echo wakeup_rt > current_tracer
+ # echo 1 > events/enable
+ # echo 1 > tracing_on
+ # echo 0 > tracing_max_latency
+ # chrt -f 5 sleep 1
+ # echo 0 > tracing_on
+ # cat trace
+# tracer: wakeup_rt
+#
+# wakeup_rt latency trace v1.1.5 on 3.8.0-test+
+# --------------------------------------------------------------------
+# latency: 6 us, #12/12, CPU#2 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:4)
+# -----------------
+# | task: sleep-5882 (uid:0 nice:0 policy:1 rt_prio:5)
+# -----------------
+#
+# _------=> CPU#
+# / _-----=> irqs-off
+# | / _----=> need-resched
+# || / _---=> hardirq/softirq
+# ||| / _--=> preempt-depth
+# |||| / delay
+# cmd pid ||||| time | caller
+# \ / ||||| \ | /
+ <idle>-0 2d.h4 0us : 0:120:R + [002] 5882: 94:R sleep
+ <idle>-0 2d.h4 0us : ttwu_do_activate.constprop.87 <-try_to_wake_up
+ <idle>-0 2d.h4 1us : sched_wakeup: comm=sleep pid=5882 prio=94 success=1 target_cpu=002
+ <idle>-0 2dNh2 1us : hrtimer_expire_exit: hrtimer=ffff88007796feb8
+ <idle>-0 2.N.2 2us : power_end: cpu_id=2
+ <idle>-0 2.N.2 3us : cpu_idle: state=4294967295 cpu_id=2
+ <idle>-0 2dN.3 4us : hrtimer_cancel: hrtimer=ffff88007d50d5e0
+ <idle>-0 2dN.3 4us : hrtimer_start: hrtimer=ffff88007d50d5e0 function=tick_sched_timer expires=34311211000000 softexpires=34311211000000
+ <idle>-0 2.N.2 5us : rcu_utilization: Start context switch
+ <idle>-0 2.N.2 5us : rcu_utilization: End context switch
+ <idle>-0 2d..3 6us : __schedule <-schedule
+ <idle>-0 2d..3 6us : 0:120:R ==> [002] 5882: 94:R sleep
+
function
--------
@@ -1039,6 +1653,7 @@
This tracer is the function tracer. Enabling the function tracer
can be done from the debug file system. Make sure the
ftrace_enabled is set; otherwise this tracer is a nop.
+See the "ftrace_enabled" section below.
# sysctl kernel.ftrace_enabled=1
# echo function > current_tracer
@@ -1048,23 +1663,23 @@
# cat trace
# tracer: function
#
-# TASK-PID CPU# TIMESTAMP FUNCTION
-# | | | | |
- bash-4003 [00] 123.638713: finish_task_switch <-schedule
- bash-4003 [00] 123.638714: _spin_unlock_irq <-finish_task_switch
- bash-4003 [00] 123.638714: sub_preempt_count <-_spin_unlock_irq
- bash-4003 [00] 123.638715: hrtick_set <-schedule
- bash-4003 [00] 123.638715: _spin_lock_irqsave <-hrtick_set
- bash-4003 [00] 123.638716: add_preempt_count <-_spin_lock_irqsave
- bash-4003 [00] 123.638716: _spin_unlock_irqrestore <-hrtick_set
- bash-4003 [00] 123.638717: sub_preempt_count <-_spin_unlock_irqrestore
- bash-4003 [00] 123.638717: hrtick_clear <-hrtick_set
- bash-4003 [00] 123.638718: sub_preempt_count <-schedule
- bash-4003 [00] 123.638718: sub_preempt_count <-preempt_schedule
- bash-4003 [00] 123.638719: wait_for_completion <-__stop_machine_run
- bash-4003 [00] 123.638719: wait_for_common <-wait_for_completion
- bash-4003 [00] 123.638720: _spin_lock_irq <-wait_for_common
- bash-4003 [00] 123.638720: add_preempt_count <-_spin_lock_irq
+# entries-in-buffer/entries-written: 24799/24799 #P:4
+#
+# _-----=> irqs-off
+# / _----=> need-resched
+# | / _---=> hardirq/softirq
+# || / _--=> preempt-depth
+# ||| / delay
+# TASK-PID CPU# |||| TIMESTAMP FUNCTION
+# | | | |||| | |
+ bash-1994 [002] .... 3082.063030: mutex_unlock <-rb_simple_write
+ bash-1994 [002] .... 3082.063031: __mutex_unlock_slowpath <-mutex_unlock
+ bash-1994 [002] .... 3082.063031: __fsnotify_parent <-fsnotify_modify
+ bash-1994 [002] .... 3082.063032: fsnotify <-fsnotify_modify
+ bash-1994 [002] .... 3082.063032: __srcu_read_lock <-fsnotify
+ bash-1994 [002] .... 3082.063032: add_preempt_count <-__srcu_read_lock
+ bash-1994 [002] ...1 3082.063032: sub_preempt_count <-__srcu_read_lock
+ bash-1994 [002] .... 3082.063033: __srcu_read_unlock <-fsnotify
[...]
@@ -1214,79 +1829,19 @@
return 0;
}
+Or this simple script!
-hw-branch-tracer (x86 only)
----------------------------
+------
+#!/bin/bash
-This tracer uses the x86 last branch tracing hardware feature to
-collect a branch trace on all cpus with relatively low overhead.
-
-The tracer uses a fixed-size circular buffer per cpu and only
-traces ring 0 branches. The trace file dumps that buffer in the
-following format:
-
-# tracer: hw-branch-tracer
-#
-# CPU# TO <- FROM
- 0 scheduler_tick+0xb5/0x1bf <- task_tick_idle+0x5/0x6
- 2 run_posix_cpu_timers+0x2b/0x72a <- run_posix_cpu_timers+0x25/0x72a
- 0 scheduler_tick+0x139/0x1bf <- scheduler_tick+0xed/0x1bf
- 0 scheduler_tick+0x17c/0x1bf <- scheduler_tick+0x148/0x1bf
- 2 run_posix_cpu_timers+0x9e/0x72a <- run_posix_cpu_timers+0x5e/0x72a
- 0 scheduler_tick+0x1b6/0x1bf <- scheduler_tick+0x1aa/0x1bf
-
-
-The tracer may be used to dump the trace for the oops'ing cpu on
-a kernel oops into the system log. To enable this,
-ftrace_dump_on_oops must be set. To set ftrace_dump_on_oops, one
-can either use the sysctl function or set it via the proc system
-interface.
-
- sysctl kernel.ftrace_dump_on_oops=n
-
-or
-
- echo n > /proc/sys/kernel/ftrace_dump_on_oops
-
-If n = 1, ftrace will dump buffers of all CPUs, if n = 2 ftrace will
-only dump the buffer of the CPU that triggered the oops.
-
-Here's an example of such a dump after a null pointer
-dereference in a kernel module:
-
-[57848.105921] BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
-[57848.106019] IP: [<ffffffffa0000006>] open+0x6/0x14 [oops]
-[57848.106019] PGD 2354e9067 PUD 2375e7067 PMD 0
-[57848.106019] Oops: 0002 [#1] SMP
-[57848.106019] last sysfs file: /sys/devices/pci0000:00/0000:00:1e.0/0000:20:05.0/local_cpus
-[57848.106019] Dumping ftrace buffer:
-[57848.106019] ---------------------------------
-[...]
-[57848.106019] 0 chrdev_open+0xe6/0x165 <- cdev_put+0x23/0x24
-[57848.106019] 0 chrdev_open+0x117/0x165 <- chrdev_open+0xfa/0x165
-[57848.106019] 0 chrdev_open+0x120/0x165 <- chrdev_open+0x11c/0x165
-[57848.106019] 0 chrdev_open+0x134/0x165 <- chrdev_open+0x12b/0x165
-[57848.106019] 0 open+0x0/0x14 [oops] <- chrdev_open+0x144/0x165
-[57848.106019] 0 page_fault+0x0/0x30 <- open+0x6/0x14 [oops]
-[57848.106019] 0 error_entry+0x0/0x5b <- page_fault+0x4/0x30
-[57848.106019] 0 error_kernelspace+0x0/0x31 <- error_entry+0x59/0x5b
-[57848.106019] 0 error_sti+0x0/0x1 <- error_kernelspace+0x2d/0x31
-[57848.106019] 0 page_fault+0x9/0x30 <- error_sti+0x0/0x1
-[57848.106019] 0 do_page_fault+0x0/0x881 <- page_fault+0x1a/0x30
-[...]
-[57848.106019] 0 do_page_fault+0x66b/0x881 <- is_prefetch+0x1ee/0x1f2
-[57848.106019] 0 do_page_fault+0x6e0/0x881 <- do_page_fault+0x67a/0x881
-[57848.106019] 0 oops_begin+0x0/0x96 <- do_page_fault+0x6e0/0x881
-[57848.106019] 0 trace_hw_branch_oops+0x0/0x2d <- oops_begin+0x9/0x96
-[...]
-[57848.106019] 0 ds_suspend_bts+0x2a/0xe3 <- ds_suspend_bts+0x1a/0xe3
-[57848.106019] ---------------------------------
-[57848.106019] CPU 0
-[57848.106019] Modules linked in: oops
-[57848.106019] Pid: 5542, comm: cat Tainted: G W 2.6.28 #23
-[57848.106019] RIP: 0010:[<ffffffffa0000006>] [<ffffffffa0000006>] open+0x6/0x14 [oops]
-[57848.106019] RSP: 0018:ffff880235457d48 EFLAGS: 00010246
-[...]
+debugfs=`sed -ne 's/^debugfs \(.*\) debugfs.*/\1/p' /proc/mounts`
+echo nop > $debugfs/tracing/current_tracer
+echo 0 > $debugfs/tracing/tracing_on
+echo $$ > $debugfs/tracing/set_ftrace_pid
+echo function > $debugfs/tracing/current_tracer
+echo 1 > $debugfs/tracing/tracing_on
+exec "$@"
+------
function graph tracer
@@ -1473,16 +2028,18 @@
include the -pg switch in the compiling of the kernel.)
At compile time every C file object is run through the
-recordmcount.pl script (located in the scripts directory). This
-script will process the C object using objdump to find all the
-locations in the .text section that call mcount. (Note, only the
-.text section is processed, since processing other sections like
-.init.text may cause races due to those sections being freed).
+recordmcount program (located in the scripts directory). This
+program will parse the ELF headers in the C object to find all
+the locations in the .text section that call mcount. (Note, only
+white listed .text sections are processed, since processing other
+sections like .init.text may cause races due to those sections
+being freed unexpectedly).
A new section called "__mcount_loc" is created that holds
references to all the mcount call sites in the .text section.
-This section is compiled back into the original object. The
-final linker will add all these references into a single table.
+The recordmcount program re-links this section back into the
+original object. The final linking stage of the kernel will add all these
+references into a single table.
On boot up, before SMP is initialized, the dynamic ftrace code
scans this table and updates all the locations into nops. It
@@ -1493,13 +2050,25 @@
list. This is automatic in the module unload code, and the
module author does not need to worry about it.
-When tracing is enabled, kstop_machine is called to prevent
-races with the CPUS executing code being modified (which can
-cause the CPU to do undesirable things), and the nops are
+When tracing is enabled, the process of modifying the function
+tracepoints is dependent on architecture. The old method is to use
+kstop_machine to prevent races with the CPUs executing code being
+modified (which can cause the CPU to do undesirable things, especially
+if the modified code crosses cache (or page) boundaries), and the nops are
patched back to calls. But this time, they do not call mcount
(which is just a function stub). They now call into the ftrace
infrastructure.
+The new method of modifying the function tracepoints is to place
+a breakpoint at the location to be modified, sync all CPUs, modify
+the rest of the instruction not covered by the breakpoint. Sync
+all CPUs again, and then remove the breakpoint with the finished
+version to the ftrace call site.
+
+Some archs do not even need to monkey around with the synchronization,
+and can just slap the new code on top of the old without any
+problems with other CPUs executing it at the same time.
+
One special side-effect to the recording of the functions being
traced is that we can now selectively choose which functions we
wish to trace and which ones we want the mcount calls to remain
@@ -1530,20 +2099,28 @@
If I am only interested in sys_nanosleep and hrtimer_interrupt:
- # echo sys_nanosleep hrtimer_interrupt \
- > set_ftrace_filter
+ # echo sys_nanosleep hrtimer_interrupt > set_ftrace_filter
# echo function > current_tracer
# echo 1 > tracing_on
# usleep 1
# echo 0 > tracing_on
# cat trace
-# tracer: ftrace
+# tracer: function
#
-# TASK-PID CPU# TIMESTAMP FUNCTION
-# | | | | |
- usleep-4134 [00] 1317.070017: hrtimer_interrupt <-smp_apic_timer_interrupt
- usleep-4134 [00] 1317.070111: sys_nanosleep <-syscall_call
- <idle>-0 [00] 1317.070115: hrtimer_interrupt <-smp_apic_timer_interrupt
+# entries-in-buffer/entries-written: 5/5 #P:4
+#
+# _-----=> irqs-off
+# / _----=> need-resched
+# | / _---=> hardirq/softirq
+# || / _--=> preempt-depth
+# ||| / delay
+# TASK-PID CPU# |||| TIMESTAMP FUNCTION
+# | | | |||| | |
+ usleep-2665 [001] .... 4186.475355: sys_nanosleep <-system_call_fastpath
+ <idle>-0 [001] d.h1 4186.475409: hrtimer_interrupt <-smp_apic_timer_interrupt
+ usleep-2665 [001] d.h1 4186.475426: hrtimer_interrupt <-smp_apic_timer_interrupt
+ <idle>-0 [003] d.h1 4186.475426: hrtimer_interrupt <-smp_apic_timer_interrupt
+ <idle>-0 [002] d.h1 4186.475427: hrtimer_interrupt <-smp_apic_timer_interrupt
To see which functions are being traced, you can cat the file:
@@ -1571,20 +2148,25 @@
Produces:
-# tracer: ftrace
+# tracer: function
#
-# TASK-PID CPU# TIMESTAMP FUNCTION
-# | | | | |
- bash-4003 [00] 1480.611794: hrtimer_init <-copy_process
- bash-4003 [00] 1480.611941: hrtimer_start <-hrtick_set
- bash-4003 [00] 1480.611956: hrtimer_cancel <-hrtick_clear
- bash-4003 [00] 1480.611956: hrtimer_try_to_cancel <-hrtimer_cancel
- <idle>-0 [00] 1480.612019: hrtimer_get_next_event <-get_next_timer_interrupt
- <idle>-0 [00] 1480.612025: hrtimer_get_next_event <-get_next_timer_interrupt
- <idle>-0 [00] 1480.612032: hrtimer_get_next_event <-get_next_timer_interrupt
- <idle>-0 [00] 1480.612037: hrtimer_get_next_event <-get_next_timer_interrupt
- <idle>-0 [00] 1480.612382: hrtimer_get_next_event <-get_next_timer_interrupt
-
+# entries-in-buffer/entries-written: 897/897 #P:4
+#
+# _-----=> irqs-off
+# / _----=> need-resched
+# | / _---=> hardirq/softirq
+# || / _--=> preempt-depth
+# ||| / delay
+# TASK-PID CPU# |||| TIMESTAMP FUNCTION
+# | | | |||| | |
+ <idle>-0 [003] dN.1 4228.547803: hrtimer_cancel <-tick_nohz_idle_exit
+ <idle>-0 [003] dN.1 4228.547804: hrtimer_try_to_cancel <-hrtimer_cancel
+ <idle>-0 [003] dN.2 4228.547805: hrtimer_force_reprogram <-__remove_hrtimer
+ <idle>-0 [003] dN.1 4228.547805: hrtimer_forward <-tick_nohz_idle_exit
+ <idle>-0 [003] dN.1 4228.547805: hrtimer_start_range_ns <-hrtimer_start_expires.constprop.11
+ <idle>-0 [003] d..1 4228.547858: hrtimer_get_next_event <-get_next_timer_interrupt
+ <idle>-0 [003] d..1 4228.547859: hrtimer_start <-__tick_nohz_idle_enter
+ <idle>-0 [003] d..2 4228.547860: hrtimer_force_reprogram <-__rem
Notice that we lost the sys_nanosleep.
@@ -1651,19 +2233,29 @@
Produces:
-# tracer: ftrace
+# tracer: function
#
-# TASK-PID CPU# TIMESTAMP FUNCTION
-# | | | | |
- bash-4043 [01] 115.281644: finish_task_switch <-schedule
- bash-4043 [01] 115.281645: hrtick_set <-schedule
- bash-4043 [01] 115.281645: hrtick_clear <-hrtick_set
- bash-4043 [01] 115.281646: wait_for_completion <-__stop_machine_run
- bash-4043 [01] 115.281647: wait_for_common <-wait_for_completion
- bash-4043 [01] 115.281647: kthread_stop <-stop_machine_run
- bash-4043 [01] 115.281648: init_waitqueue_head <-kthread_stop
- bash-4043 [01] 115.281648: wake_up_process <-kthread_stop
- bash-4043 [01] 115.281649: try_to_wake_up <-wake_up_process
+# entries-in-buffer/entries-written: 39608/39608 #P:4
+#
+# _-----=> irqs-off
+# / _----=> need-resched
+# | / _---=> hardirq/softirq
+# || / _--=> preempt-depth
+# ||| / delay
+# TASK-PID CPU# |||| TIMESTAMP FUNCTION
+# | | | |||| | |
+ bash-1994 [000] .... 4342.324896: file_ra_state_init <-do_dentry_open
+ bash-1994 [000] .... 4342.324897: open_check_o_direct <-do_last
+ bash-1994 [000] .... 4342.324897: ima_file_check <-do_last
+ bash-1994 [000] .... 4342.324898: process_measurement <-ima_file_check
+ bash-1994 [000] .... 4342.324898: ima_get_action <-process_measurement
+ bash-1994 [000] .... 4342.324898: ima_match_policy <-ima_get_action
+ bash-1994 [000] .... 4342.324899: do_truncate <-do_last
+ bash-1994 [000] .... 4342.324899: should_remove_suid <-do_truncate
+ bash-1994 [000] .... 4342.324899: notify_change <-do_truncate
+ bash-1994 [000] .... 4342.324900: current_fs_time <-notify_change
+ bash-1994 [000] .... 4342.324900: current_kernel_time <-current_fs_time
+ bash-1994 [000] .... 4342.324900: timespec_trunc <-current_fs_time
We can see that there's no more lock or preempt tracing.
@@ -1729,6 +2321,28 @@
echo > set_graph_function
+ftrace_enabled
+--------------
+
+Note, the proc sysctl ftrace_enable is a big on/off switch for the
+function tracer. By default it is enabled (when function tracing is
+enabled in the kernel). If it is disabled, all function tracing is
+disabled. This includes not only the function tracers for ftrace, but
+also for any other uses (perf, kprobes, stack tracing, profiling, etc).
+
+Please disable this with care.
+
+This can be disable (and enabled) with:
+
+ sysctl kernel.ftrace_enabled=0
+ sysctl kernel.ftrace_enabled=1
+
+ or
+
+ echo 0 > /proc/sys/kernel/ftrace_enabled
+ echo 1 > /proc/sys/kernel/ftrace_enabled
+
+
Filter commands
---------------
@@ -1763,12 +2377,71 @@
echo '__schedule_bug:traceoff:5' > set_ftrace_filter
+ To always disable tracing when __schedule_bug is hit:
+
+ echo '__schedule_bug:traceoff' > set_ftrace_filter
+
These commands are cumulative whether or not they are appended
to set_ftrace_filter. To remove a command, prepend it by '!'
and drop the parameter:
+ echo '!__schedule_bug:traceoff:0' > set_ftrace_filter
+
+ The above removes the traceoff command for __schedule_bug
+ that have a counter. To remove commands without counters:
+
echo '!__schedule_bug:traceoff' > set_ftrace_filter
+- snapshot
+ Will cause a snapshot to be triggered when the function is hit.
+
+ echo 'native_flush_tlb_others:snapshot' > set_ftrace_filter
+
+ To only snapshot once:
+
+ echo 'native_flush_tlb_others:snapshot:1' > set_ftrace_filter
+
+ To remove the above commands:
+
+ echo '!native_flush_tlb_others:snapshot' > set_ftrace_filter
+ echo '!native_flush_tlb_others:snapshot:0' > set_ftrace_filter
+
+- enable_event/disable_event
+ These commands can enable or disable a trace event. Note, because
+ function tracing callbacks are very sensitive, when these commands
+ are registered, the trace point is activated, but disabled in
+ a "soft" mode. That is, the tracepoint will be called, but
+ just will not be traced. The event tracepoint stays in this mode
+ as long as there's a command that triggers it.
+
+ echo 'try_to_wake_up:enable_event:sched:sched_switch:2' > \
+ set_ftrace_filter
+
+ The format is:
+
+ <function>:enable_event:<system>:<event>[:count]
+ <function>:disable_event:<system>:<event>[:count]
+
+ To remove the events commands:
+
+
+ echo '!try_to_wake_up:enable_event:sched:sched_switch:0' > \
+ set_ftrace_filter
+ echo '!schedule:disable_event:sched:sched_switch' > \
+ set_ftrace_filter
+
+- dump
+ When the function is hit, it will dump the contents of the ftrace
+ ring buffer to the console. This is useful if you need to debug
+ something, and want to dump the trace when a certain function
+ is hit. Perhaps its a function that is called before a tripple
+ fault happens and does not allow you to get a regular dump.
+
+- cpudump
+ When the function is hit, it will dump the contents of the ftrace
+ ring buffer for the current CPU to the console. Unlike the "dump"
+ command, it only prints out the contents of the ring buffer for the
+ CPU that executed the function that triggered the dump.
trace_pipe
----------
@@ -1787,28 +2460,31 @@
# cat trace
# tracer: function
#
-# TASK-PID CPU# TIMESTAMP FUNCTION
-# | | | | |
+# entries-in-buffer/entries-written: 0/0 #P:4
+#
+# _-----=> irqs-off
+# / _----=> need-resched
+# | / _---=> hardirq/softirq
+# || / _--=> preempt-depth
+# ||| / delay
+# TASK-PID CPU# |||| TIMESTAMP FUNCTION
+# | | | |||| | |
#
# cat /tmp/trace.out
- bash-4043 [00] 41.267106: finish_task_switch <-schedule
- bash-4043 [00] 41.267106: hrtick_set <-schedule
- bash-4043 [00] 41.267107: hrtick_clear <-hrtick_set
- bash-4043 [00] 41.267108: wait_for_completion <-__stop_machine_run
- bash-4043 [00] 41.267108: wait_for_common <-wait_for_completion
- bash-4043 [00] 41.267109: kthread_stop <-stop_machine_run
- bash-4043 [00] 41.267109: init_waitqueue_head <-kthread_stop
- bash-4043 [00] 41.267110: wake_up_process <-kthread_stop
- bash-4043 [00] 41.267110: try_to_wake_up <-wake_up_process
- bash-4043 [00] 41.267111: select_task_rq_rt <-try_to_wake_up
+ bash-1994 [000] .... 5281.568961: mutex_unlock <-rb_simple_write
+ bash-1994 [000] .... 5281.568963: __mutex_unlock_slowpath <-mutex_unlock
+ bash-1994 [000] .... 5281.568963: __fsnotify_parent <-fsnotify_modify
+ bash-1994 [000] .... 5281.568964: fsnotify <-fsnotify_modify
+ bash-1994 [000] .... 5281.568964: __srcu_read_lock <-fsnotify
+ bash-1994 [000] .... 5281.568964: add_preempt_count <-__srcu_read_lock
+ bash-1994 [000] ...1 5281.568965: sub_preempt_count <-__srcu_read_lock
+ bash-1994 [000] .... 5281.568965: __srcu_read_unlock <-fsnotify
+ bash-1994 [000] .... 5281.568967: sys_dup2 <-system_call_fastpath
Note, reading the trace_pipe file will block until more input is
-added. By changing the tracer, trace_pipe will issue an EOF. We
-needed to set the function tracer _before_ we "cat" the
-trace_pipe file.
-
+added.
trace entries
-------------
@@ -1817,32 +2493,315 @@
diagnosing an issue in the kernel. The file buffer_size_kb is
used to modify the size of the internal trace buffers. The
number listed is the number of entries that can be recorded per
-CPU. To know the full size, multiply the number of possible CPUS
+CPU. To know the full size, multiply the number of possible CPUs
with the number of entries.
# cat buffer_size_kb
1408 (units kilobytes)
-Note, to modify this, you must have tracing completely disabled.
-To do that, echo "nop" into the current_tracer. If the
-current_tracer is not set to "nop", an EINVAL error will be
-returned.
+Or simply read buffer_total_size_kb
- # echo nop > current_tracer
+ # cat buffer_total_size_kb
+5632
+
+To modify the buffer, simple echo in a number (in 1024 byte segments).
+
# echo 10000 > buffer_size_kb
# cat buffer_size_kb
10000 (units kilobytes)
-The number of pages which will be allocated is limited to a
-percentage of available memory. Allocating too much will produce
-an error.
+It will try to allocate as much as possible. If you allocate too
+much, it can cause Out-Of-Memory to trigger.
# echo 1000000000000 > buffer_size_kb
-bash: echo: write error: Cannot allocate memory
# cat buffer_size_kb
85
+The per_cpu buffers can be changed individually as well:
+
+ # echo 10000 > per_cpu/cpu0/buffer_size_kb
+ # echo 100 > per_cpu/cpu1/buffer_size_kb
+
+When the per_cpu buffers are not the same, the buffer_size_kb
+at the top level will just show an X
+
+ # cat buffer_size_kb
+X
+
+This is where the buffer_total_size_kb is useful:
+
+ # cat buffer_total_size_kb
+12916
+
+Writing to the top level buffer_size_kb will reset all the buffers
+to be the same again.
+
+Snapshot
+--------
+CONFIG_TRACER_SNAPSHOT makes a generic snapshot feature
+available to all non latency tracers. (Latency tracers which
+record max latency, such as "irqsoff" or "wakeup", can't use
+this feature, since those are already using the snapshot
+mechanism internally.)
+
+Snapshot preserves a current trace buffer at a particular point
+in time without stopping tracing. Ftrace swaps the current
+buffer with a spare buffer, and tracing continues in the new
+current (=previous spare) buffer.
+
+The following debugfs files in "tracing" are related to this
+feature:
+
+ snapshot:
+
+ This is used to take a snapshot and to read the output
+ of the snapshot. Echo 1 into this file to allocate a
+ spare buffer and to take a snapshot (swap), then read
+ the snapshot from this file in the same format as
+ "trace" (described above in the section "The File
+ System"). Both reads snapshot and tracing are executable
+ in parallel. When the spare buffer is allocated, echoing
+ 0 frees it, and echoing else (positive) values clear the
+ snapshot contents.
+ More details are shown in the table below.
+
+ status\input | 0 | 1 | else |
+ --------------+------------+------------+------------+
+ not allocated |(do nothing)| alloc+swap |(do nothing)|
+ --------------+------------+------------+------------+
+ allocated | free | swap | clear |
+ --------------+------------+------------+------------+
+
+Here is an example of using the snapshot feature.
+
+ # echo 1 > events/sched/enable
+ # echo 1 > snapshot
+ # cat snapshot
+# tracer: nop
+#
+# entries-in-buffer/entries-written: 71/71 #P:8
+#
+# _-----=> irqs-off
+# / _----=> need-resched
+# | / _---=> hardirq/softirq
+# || / _--=> preempt-depth
+# ||| / delay
+# TASK-PID CPU# |||| TIMESTAMP FUNCTION
+# | | | |||| | |
+ <idle>-0 [005] d... 2440.603828: sched_switch: prev_comm=swapper/5 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=snapshot-test-2 next_pid=2242 next_prio=120
+ sleep-2242 [005] d... 2440.603846: sched_switch: prev_comm=snapshot-test-2 prev_pid=2242 prev_prio=120 prev_state=R ==> next_comm=kworker/5:1 next_pid=60 next_prio=120
+[...]
+ <idle>-0 [002] d... 2440.707230: sched_switch: prev_comm=swapper/2 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=snapshot-test-2 next_pid=2229 next_prio=120
+
+ # cat trace
+# tracer: nop
+#
+# entries-in-buffer/entries-written: 77/77 #P:8
+#
+# _-----=> irqs-off
+# / _----=> need-resched
+# | / _---=> hardirq/softirq
+# || / _--=> preempt-depth
+# ||| / delay
+# TASK-PID CPU# |||| TIMESTAMP FUNCTION
+# | | | |||| | |
+ <idle>-0 [007] d... 2440.707395: sched_switch: prev_comm=swapper/7 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=snapshot-test-2 next_pid=2243 next_prio=120
+ snapshot-test-2-2229 [002] d... 2440.707438: sched_switch: prev_comm=snapshot-test-2 prev_pid=2229 prev_prio=120 prev_state=S ==> next_comm=swapper/2 next_pid=0 next_prio=120
+[...]
+
+
+If you try to use this snapshot feature when current tracer is
+one of the latency tracers, you will get the following results.
+
+ # echo wakeup > current_tracer
+ # echo 1 > snapshot
+bash: echo: write error: Device or resource busy
+ # cat snapshot
+cat: snapshot: Device or resource busy
+
+
+Instances
+---------
+In the debugfs tracing directory is a directory called "instances".
+This directory can have new directories created inside of it using
+mkdir, and removing directories with rmdir. The directory created
+with mkdir in this directory will already contain files and other
+directories after it is created.
+
+ # mkdir instances/foo
+ # ls instances/foo
+buffer_size_kb buffer_total_size_kb events free_buffer per_cpu
+set_event snapshot trace trace_clock trace_marker trace_options
+trace_pipe tracing_on
+
+As you can see, the new directory looks similar to the tracing directory
+itself. In fact, it is very similar, except that the buffer and
+events are agnostic from the main director, or from any other
+instances that are created.
+
+The files in the new directory work just like the files with the
+same name in the tracing directory except the buffer that is used
+is a separate and new buffer. The files affect that buffer but do not
+affect the main buffer with the exception of trace_options. Currently,
+the trace_options affect all instances and the top level buffer
+the same, but this may change in future releases. That is, options
+may become specific to the instance they reside in.
+
+Notice that none of the function tracer files are there, nor is
+current_tracer and available_tracers. This is because the buffers
+can currently only have events enabled for them.
+
+ # mkdir instances/foo
+ # mkdir instances/bar
+ # mkdir instances/zoot
+ # echo 100000 > buffer_size_kb
+ # echo 1000 > instances/foo/buffer_size_kb
+ # echo 5000 > instances/bar/per_cpu/cpu1/buffer_size_kb
+ # echo function > current_trace
+ # echo 1 > instances/foo/events/sched/sched_wakeup/enable
+ # echo 1 > instances/foo/events/sched/sched_wakeup_new/enable
+ # echo 1 > instances/foo/events/sched/sched_switch/enable
+ # echo 1 > instances/bar/events/irq/enable
+ # echo 1 > instances/zoot/events/syscalls/enable
+ # cat trace_pipe
+CPU:2 [LOST 11745 EVENTS]
+ bash-2044 [002] .... 10594.481032: _raw_spin_lock_irqsave <-get_page_from_freelist
+ bash-2044 [002] d... 10594.481032: add_preempt_count <-_raw_spin_lock_irqsave
+ bash-2044 [002] d..1 10594.481032: __rmqueue <-get_page_from_freelist
+ bash-2044 [002] d..1 10594.481033: _raw_spin_unlock <-get_page_from_freelist
+ bash-2044 [002] d..1 10594.481033: sub_preempt_count <-_raw_spin_unlock
+ bash-2044 [002] d... 10594.481033: get_pageblock_flags_group <-get_pageblock_migratetype
+ bash-2044 [002] d... 10594.481034: __mod_zone_page_state <-get_page_from_freelist
+ bash-2044 [002] d... 10594.481034: zone_statistics <-get_page_from_freelist
+ bash-2044 [002] d... 10594.481034: __inc_zone_state <-zone_statistics
+ bash-2044 [002] d... 10594.481034: __inc_zone_state <-zone_statistics
+ bash-2044 [002] .... 10594.481035: arch_dup_task_struct <-copy_process
+[...]
+
+ # cat instances/foo/trace_pipe
+ bash-1998 [000] d..4 136.676759: sched_wakeup: comm=kworker/0:1 pid=59 prio=120 success=1 target_cpu=000
+ bash-1998 [000] dN.4 136.676760: sched_wakeup: comm=bash pid=1998 prio=120 success=1 target_cpu=000
+ <idle>-0 [003] d.h3 136.676906: sched_wakeup: comm=rcu_preempt pid=9 prio=120 success=1 target_cpu=003
+ <idle>-0 [003] d..3 136.676909: sched_switch: prev_comm=swapper/3 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=rcu_preempt next_pid=9 next_prio=120
+ rcu_preempt-9 [003] d..3 136.676916: sched_switch: prev_comm=rcu_preempt prev_pid=9 prev_prio=120 prev_state=S ==> next_comm=swapper/3 next_pid=0 next_prio=120
+ bash-1998 [000] d..4 136.677014: sched_wakeup: comm=kworker/0:1 pid=59 prio=120 success=1 target_cpu=000
+ bash-1998 [000] dN.4 136.677016: sched_wakeup: comm=bash pid=1998 prio=120 success=1 target_cpu=000
+ bash-1998 [000] d..3 136.677018: sched_switch: prev_comm=bash prev_pid=1998 prev_prio=120 prev_state=R+ ==> next_comm=kworker/0:1 next_pid=59 next_prio=120
+ kworker/0:1-59 [000] d..4 136.677022: sched_wakeup: comm=sshd pid=1995 prio=120 success=1 target_cpu=001
+ kworker/0:1-59 [000] d..3 136.677025: sched_switch: prev_comm=kworker/0:1 prev_pid=59 prev_prio=120 prev_state=S ==> next_comm=bash next_pid=1998 next_prio=120
+[...]
+
+ # cat instances/bar/trace_pipe
+ migration/1-14 [001] d.h3 138.732674: softirq_raise: vec=3 [action=NET_RX]
+ <idle>-0 [001] dNh3 138.732725: softirq_raise: vec=3 [action=NET_RX]
+ bash-1998 [000] d.h1 138.733101: softirq_raise: vec=1 [action=TIMER]
+ bash-1998 [000] d.h1 138.733102: softirq_raise: vec=9 [action=RCU]
+ bash-1998 [000] ..s2 138.733105: softirq_entry: vec=1 [action=TIMER]
+ bash-1998 [000] ..s2 138.733106: softirq_exit: vec=1 [action=TIMER]
+ bash-1998 [000] ..s2 138.733106: softirq_entry: vec=9 [action=RCU]
+ bash-1998 [000] ..s2 138.733109: softirq_exit: vec=9 [action=RCU]
+ sshd-1995 [001] d.h1 138.733278: irq_handler_entry: irq=21 name=uhci_hcd:usb4
+ sshd-1995 [001] d.h1 138.733280: irq_handler_exit: irq=21 ret=unhandled
+ sshd-1995 [001] d.h1 138.733281: irq_handler_entry: irq=21 name=eth0
+ sshd-1995 [001] d.h1 138.733283: irq_handler_exit: irq=21 ret=handled
+[...]
+
+ # cat instances/zoot/trace
+# tracer: nop
+#
+# entries-in-buffer/entries-written: 18996/18996 #P:4
+#
+# _-----=> irqs-off
+# / _----=> need-resched
+# | / _---=> hardirq/softirq
+# || / _--=> preempt-depth
+# ||| / delay
+# TASK-PID CPU# |||| TIMESTAMP FUNCTION
+# | | | |||| | |
+ bash-1998 [000] d... 140.733501: sys_write -> 0x2
+ bash-1998 [000] d... 140.733504: sys_dup2(oldfd: a, newfd: 1)
+ bash-1998 [000] d... 140.733506: sys_dup2 -> 0x1
+ bash-1998 [000] d... 140.733508: sys_fcntl(fd: a, cmd: 1, arg: 0)
+ bash-1998 [000] d... 140.733509: sys_fcntl -> 0x1
+ bash-1998 [000] d... 140.733510: sys_close(fd: a)
+ bash-1998 [000] d... 140.733510: sys_close -> 0x0
+ bash-1998 [000] d... 140.733514: sys_rt_sigprocmask(how: 0, nset: 0, oset: 6e2768, sigsetsize: 8)
+ bash-1998 [000] d... 140.733515: sys_rt_sigprocmask -> 0x0
+ bash-1998 [000] d... 140.733516: sys_rt_sigaction(sig: 2, act: 7fff718846f0, oact: 7fff71884650, sigsetsize: 8)
+ bash-1998 [000] d... 140.733516: sys_rt_sigaction -> 0x0
+
+You can see that the trace of the top most trace buffer shows only
+the function tracing. The foo instance displays wakeups and task
+switches.
+
+To remove the instances, simply delete their directories:
+
+ # rmdir instances/foo
+ # rmdir instances/bar
+ # rmdir instances/zoot
+
+Note, if a process has a trace file open in one of the instance
+directories, the rmdir will fail with EBUSY.
+
+
+Stack trace
-----------
+Since the kernel has a fixed sized stack, it is important not to
+waste it in functions. A kernel developer must be conscience of
+what they allocate on the stack. If they add too much, the system
+can be in danger of a stack overflow, and corruption will occur,
+usually leading to a system panic.
+
+There are some tools that check this, usually with interrupts
+periodically checking usage. But if you can perform a check
+at every function call that will become very useful. As ftrace provides
+a function tracer, it makes it convenient to check the stack size
+at every function call. This is enabled via the stack tracer.
+
+CONFIG_STACK_TRACER enables the ftrace stack tracing functionality.
+To enable it, write a '1' into /proc/sys/kernel/stack_tracer_enabled.
+
+ # echo 1 > /proc/sys/kernel/stack_tracer_enabled
+
+You can also enable it from the kernel command line to trace
+the stack size of the kernel during boot up, by adding "stacktrace"
+to the kernel command line parameter.
+
+After running it for a few minutes, the output looks like:
+
+ # cat stack_max_size
+2928
+
+ # cat stack_trace
+ Depth Size Location (18 entries)
+ ----- ---- --------
+ 0) 2928 224 update_sd_lb_stats+0xbc/0x4ac
+ 1) 2704 160 find_busiest_group+0x31/0x1f1
+ 2) 2544 256 load_balance+0xd9/0x662
+ 3) 2288 80 idle_balance+0xbb/0x130
+ 4) 2208 128 __schedule+0x26e/0x5b9
+ 5) 2080 16 schedule+0x64/0x66
+ 6) 2064 128 schedule_timeout+0x34/0xe0
+ 7) 1936 112 wait_for_common+0x97/0xf1
+ 8) 1824 16 wait_for_completion+0x1d/0x1f
+ 9) 1808 128 flush_work+0xfe/0x119
+ 10) 1680 16 tty_flush_to_ldisc+0x1e/0x20
+ 11) 1664 48 input_available_p+0x1d/0x5c
+ 12) 1616 48 n_tty_poll+0x6d/0x134
+ 13) 1568 64 tty_poll+0x64/0x7f
+ 14) 1504 880 do_select+0x31e/0x511
+ 15) 624 400 core_sys_select+0x177/0x216
+ 16) 224 96 sys_select+0x91/0xb9
+ 17) 128 128 system_call_fastpath+0x16/0x1b
+
+Note, if -mfentry is being used by gcc, functions get traced before
+they set up the stack frame. This means that leaf level functions
+are not tested by the stack tracer when -mfentry is used.
+
+Currently, -mfentry is used by gcc 4.6.0 and above on x86 only.
+
+---------
More details can be found in the source code, in the
kernel/trace/*.c files.
diff --git a/Documentation/trace/tracepoints.txt b/Documentation/trace/tracepoints.txt
index c0e1cee..da49437 100644
--- a/Documentation/trace/tracepoints.txt
+++ b/Documentation/trace/tracepoints.txt
@@ -81,7 +81,6 @@
the module exit function to make sure there is no caller left using
the probe. This, and the fact that preemption is disabled around the
probe call, make sure that probe removal and module unload are safe.
-See the "Probe example" section below for a sample probe module.
The tracepoint mechanism supports inserting multiple instances of the
same tracepoint, but a single definition must be made of a given
@@ -100,17 +99,3 @@
If the tracepoint has to be used in kernel modules, an
EXPORT_TRACEPOINT_SYMBOL_GPL() or EXPORT_TRACEPOINT_SYMBOL() can be
used to export the defined tracepoints.
-
-* Probe / tracepoint example
-
-See the example provided in samples/tracepoints
-
-Compile them with your kernel. They are built during 'make' (not
-'make modules') when CONFIG_SAMPLE_TRACEPOINTS=m.
-
-Run, as root :
-modprobe tracepoint-sample (insmod order is not important)
-modprobe tracepoint-probe-sample
-cat /proc/tracepoint-sample (returns an expected error)
-rmmod tracepoint-sample tracepoint-probe-sample
-dmesg
diff --git a/Documentation/trace/uprobetracer.txt b/Documentation/trace/uprobetracer.txt
index 24ce682..d9c3e68 100644
--- a/Documentation/trace/uprobetracer.txt
+++ b/Documentation/trace/uprobetracer.txt
@@ -1,6 +1,8 @@
- Uprobe-tracer: Uprobe-based Event Tracing
- =========================================
- Documentation written by Srikar Dronamraju
+ Uprobe-tracer: Uprobe-based Event Tracing
+ =========================================
+
+ Documentation written by Srikar Dronamraju
+
Overview
--------
@@ -13,78 +15,94 @@
/sys/kernel/debug/tracing/events/uprobes/<EVENT>/enabled.
However unlike kprobe-event tracer, the uprobe event interface expects the
-user to calculate the offset of the probepoint in the object
+user to calculate the offset of the probepoint in the object.
Synopsis of uprobe_tracer
-------------------------
- p[:[GRP/]EVENT] PATH:SYMBOL[+offs] [FETCHARGS] : Set a probe
+ p[:[GRP/]EVENT] PATH:SYMBOL[+offs] [FETCHARGS] : Set a uprobe
+ r[:[GRP/]EVENT] PATH:SYMBOL[+offs] [FETCHARGS] : Set a return uprobe (uretprobe)
+ -:[GRP/]EVENT : Clear uprobe or uretprobe event
- GRP : Group name. If omitted, use "uprobes" for it.
- EVENT : Event name. If omitted, the event name is generated
- based on SYMBOL+offs.
- PATH : path to an executable or a library.
- SYMBOL[+offs] : Symbol+offset where the probe is inserted.
+ GRP : Group name. If omitted, "uprobes" is the default value.
+ EVENT : Event name. If omitted, the event name is generated based
+ on SYMBOL+offs.
+ PATH : Path to an executable or a library.
+ SYMBOL[+offs] : Symbol+offset where the probe is inserted.
- FETCHARGS : Arguments. Each probe can have up to 128 args.
- %REG : Fetch register REG
+ FETCHARGS : Arguments. Each probe can have up to 128 args.
+ %REG : Fetch register REG
Event Profiling
---------------
- You can check the total number of probe hits and probe miss-hits via
+You can check the total number of probe hits and probe miss-hits via
/sys/kernel/debug/tracing/uprobe_profile.
- The first column is event name, the second is the number of probe hits,
+The first column is event name, the second is the number of probe hits,
the third is the number of probe miss-hits.
Usage examples
--------------
-To add a probe as a new event, write a new definition to uprobe_events
-as below.
+ * Add a probe as a new uprobe event, write a new definition to uprobe_events
+as below: (sets a uprobe at an offset of 0x4245c0 in the executable /bin/bash)
- echo 'p: /bin/bash:0x4245c0' > /sys/kernel/debug/tracing/uprobe_events
+ echo 'p: /bin/bash:0x4245c0' > /sys/kernel/debug/tracing/uprobe_events
- This sets a uprobe at an offset of 0x4245c0 in the executable /bin/bash
+ * Add a probe as a new uretprobe event:
- echo > /sys/kernel/debug/tracing/uprobe_events
+ echo 'r: /bin/bash:0x4245c0' > /sys/kernel/debug/tracing/uprobe_events
- This clears all probe points.
+ * Unset registered event:
-The following example shows how to dump the instruction pointer and %ax
-a register at the probed text address. Here we are trying to probe
-function zfree in /bin/zsh
+ echo '-:bash_0x4245c0' >> /sys/kernel/debug/tracing/uprobe_events
+
+ * Print out the events that are registered:
+
+ cat /sys/kernel/debug/tracing/uprobe_events
+
+ * Clear all events:
+
+ echo > /sys/kernel/debug/tracing/uprobe_events
+
+Following example shows how to dump the instruction pointer and %ax register
+at the probed text address. Probe zfree function in /bin/zsh:
# cd /sys/kernel/debug/tracing/
- # cat /proc/`pgrep zsh`/maps | grep /bin/zsh | grep r-xp
+ # cat /proc/`pgrep zsh`/maps | grep /bin/zsh | grep r-xp
00400000-0048a000 r-xp 00000000 08:03 130904 /bin/zsh
# objdump -T /bin/zsh | grep -w zfree
0000000000446420 g DF .text 0000000000000012 Base zfree
-0x46420 is the offset of zfree in object /bin/zsh that is loaded at
-0x00400000. Hence the command to probe would be :
+ 0x46420 is the offset of zfree in object /bin/zsh that is loaded at
+ 0x00400000. Hence the command to uprobe would be:
- # echo 'p /bin/zsh:0x46420 %ip %ax' > uprobe_events
+ # echo 'p:zfree_entry /bin/zsh:0x46420 %ip %ax' > uprobe_events
-Please note: User has to explicitly calculate the offset of the probepoint
+ And the same for the uretprobe would be:
+
+ # echo 'r:zfree_exit /bin/zsh:0x46420 %ip %ax' >> uprobe_events
+
+Please note: User has to explicitly calculate the offset of the probe-point
in the object. We can see the events that are registered by looking at the
uprobe_events file.
# cat uprobe_events
- p:uprobes/p_zsh_0x46420 /bin/zsh:0x00046420 arg1=%ip arg2=%ax
+ p:uprobes/zfree_entry /bin/zsh:0x00046420 arg1=%ip arg2=%ax
+ r:uprobes/zfree_exit /bin/zsh:0x00046420 arg1=%ip arg2=%ax
-The format of events can be seen by viewing the file events/uprobes/p_zsh_0x46420/format
+Format of events can be seen by viewing the file events/uprobes/zfree_entry/format
- # cat events/uprobes/p_zsh_0x46420/format
- name: p_zsh_0x46420
+ # cat events/uprobes/zfree_entry/format
+ name: zfree_entry
ID: 922
format:
- field:unsigned short common_type; offset:0; size:2; signed:0;
- field:unsigned char common_flags; offset:2; size:1; signed:0;
- field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
- field:int common_pid; offset:4; size:4; signed:1;
- field:int common_padding; offset:8; size:4; signed:1;
+ field:unsigned short common_type; offset:0; size:2; signed:0;
+ field:unsigned char common_flags; offset:2; size:1; signed:0;
+ field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
+ field:int common_pid; offset:4; size:4; signed:1;
+ field:int common_padding; offset:8; size:4; signed:1;
- field:unsigned long __probe_ip; offset:12; size:4; signed:0;
- field:u32 arg1; offset:16; size:4; signed:0;
- field:u32 arg2; offset:20; size:4; signed:0;
+ field:unsigned long __probe_ip; offset:12; size:4; signed:0;
+ field:u32 arg1; offset:16; size:4; signed:0;
+ field:u32 arg2; offset:20; size:4; signed:0;
print fmt: "(%lx) arg1=%lx arg2=%lx", REC->__probe_ip, REC->arg1, REC->arg2
@@ -94,6 +112,7 @@
# echo 1 > events/uprobes/enable
Lets disable the event after sleeping for some time.
+
# sleep 20
# echo 0 > events/uprobes/enable
@@ -104,10 +123,11 @@
#
# TASK-PID CPU# TIMESTAMP FUNCTION
# | | | | |
- zsh-24842 [006] 258544.995456: p_zsh_0x46420: (0x446420) arg1=446421 arg2=79
- zsh-24842 [007] 258545.000270: p_zsh_0x46420: (0x446420) arg1=446421 arg2=79
- zsh-24842 [002] 258545.043929: p_zsh_0x46420: (0x446420) arg1=446421 arg2=79
- zsh-24842 [004] 258547.046129: p_zsh_0x46420: (0x446420) arg1=446421 arg2=79
+ zsh-24842 [006] 258544.995456: zfree_entry: (0x446420) arg1=446420 arg2=79
+ zsh-24842 [007] 258545.000270: zfree_exit: (0x446540 <- 0x446420) arg1=446540 arg2=0
+ zsh-24842 [002] 258545.043929: zfree_entry: (0x446420) arg1=446420 arg2=79
+ zsh-24842 [004] 258547.046129: zfree_exit: (0x446540 <- 0x446420) arg1=446540 arg2=0
-Each line shows us probes were triggered for a pid 24842 with ip being
-0x446421 and contents of ax register being 79.
+Output shows us uprobe was triggered for a pid 24842 with ip being 0x446420
+and contents of ax register being 79. And uretprobe was triggered with ip at
+0x446540 with counterpart function entry at 0x446420.
diff --git a/Documentation/usb/gadget_configfs.txt b/Documentation/usb/gadget_configfs.txt
new file mode 100644
index 0000000..8ec2a67
--- /dev/null
+++ b/Documentation/usb/gadget_configfs.txt
@@ -0,0 +1,384 @@
+
+
+
+
+ Linux USB gadget configured through configfs
+
+
+ 25th April 2013
+
+
+
+
+Overview
+========
+
+A USB Linux Gadget is a device which has a UDC (USB Device Controller) and can
+be connected to a USB Host to extend it with additional functions like a serial
+port or a mass storage capability.
+
+A gadget is seen by its host as a set of configurations, each of which contains
+a number of interfaces which, from the gadget's perspective, are known as
+functions, each function representing e.g. a serial connection or a SCSI disk.
+
+Linux provides a number of functions for gadgets to use.
+
+Creating a gadget means deciding what configurations there will be
+and which functions each configuration will provide.
+
+Configfs (please see Documentation/filesystems/configfs/*) lends itslef nicely
+for the purpose of telling the kernel about the above mentioned decision.
+This document is about how to do it.
+
+It also describes how configfs integration into gadget is designed.
+
+
+
+
+Requirements
+============
+
+In order for this to work configfs must be available, so CONFIGFS_FS must be
+'y' or 'm' in .config. As of this writing USB_LIBCOMPOSITE selects CONFIGFS_FS.
+
+
+
+
+Usage
+=====
+
+(The original post describing the first function
+made available through configfs can be seen here:
+http://www.spinics.net/lists/linux-usb/msg76388.html)
+
+$ modprobe libcomposite
+$ mount none $CONFIGFS_HOME -t configfs
+
+where CONFIGFS_HOME is the mount point for configfs
+
+1. Creating the gadgets
+-----------------------
+
+For each gadget to be created its corresponding directory must be created:
+
+$ mkdir $CONFIGFS_HOME/usb_gadget/<gadget name>
+
+e.g.:
+
+$ mkdir $CONFIGFS_HOME/usb_gadget/g1
+
+...
+...
+...
+
+$ cd $CONFIGFS_HOME/usb_gadget/g1
+
+Each gadget needs to have its vendor id <VID> and product id <PID> specified:
+
+$ echo <VID> > idVendor
+$ echo <PID> > idProduct
+
+A gadget also needs its serial number, manufacturer and product strings.
+In order to have a place to store them, a strings subdirectory must be created
+for each language, e.g.:
+
+$ mkdir strings/0x409
+
+Then the strings can be specified:
+
+$ echo <serial number> > strings/0x409/serialnumber
+$ echo <manufacturer> > strings/0x409/manufacturer
+$ echo <product> > strings/0x409/product
+
+2. Creating the configurations
+------------------------------
+
+Each gadget will consist of a number of configurations, their corresponding
+directories must be created:
+
+$ mkdir configs/<name>.<number>
+
+where <name> can be any string which is legal in a filesystem and the
+<numebr> is the configuration's number, e.g.:
+
+$ mkdir configs/c.1
+
+...
+...
+...
+
+Each configuration also needs its strings, so a subdirectory must be created
+for each language, e.g.:
+
+$ mkdir configs/c.1/strings/0x409
+
+Then the configuration string can be specified:
+
+$ echo <configuration> > configs/c.1/strings/0x409/configuration
+
+Some attributes can also be set for a configuration, e.g.:
+
+$ echo 120 > configs/c.1/MaxPower
+
+3. Creating the functions
+-------------------------
+
+The gadget will provide some functions, for each function its corresponding
+directory must be created:
+
+$ mkdir functions/<name>.<instance name>
+
+where <name> corresponds to one of allowed function names and instance name
+is an arbitrary string allowed in a filesystem, e.g.:
+
+$ mkdir functions/ncm.usb0 # usb_f_ncm.ko gets loaded with request_module()
+
+...
+...
+...
+
+Each function provides its specific set of attributes, with either read-only
+or read-write access. Where applicable they need to be written to as
+appropriate.
+Please refer to Documentation/ABI/*/configfs-usb-gadget* for more information.
+
+4. Associating the functions with their configurations
+------------------------------------------------------
+
+At this moment a number of gadgets is created, each of which has a number of
+configurations specified and a number of functions available. What remains
+is specifying which function is available in which configuration (the same
+function can be used in multiple configurations). This is achieved with
+creating symbolic links:
+
+$ ln -s functions/<name>.<instance name> configs/<name>.<number>
+
+e.g.:
+
+$ ln -s functions/ncm.usb0 configs/c.1
+
+...
+...
+...
+
+5. Enabling the gadget
+----------------------
+
+All the above steps serve the purpose of composing the gadget of
+configurations and functions.
+
+An example directory structure might look like this:
+
+.
+./strings
+./strings/0x409
+./strings/0x409/serialnumber
+./strings/0x409/product
+./strings/0x409/manufacturer
+./configs
+./configs/c.1
+./configs/c.1/ncm.usb0 -> ../../../../usb_gadget/g1/functions/ncm.usb0
+./configs/c.1/strings
+./configs/c.1/strings/0x409
+./configs/c.1/strings/0x409/configuration
+./configs/c.1/bmAttributes
+./configs/c.1/MaxPower
+./functions
+./functions/ncm.usb0
+./functions/ncm.usb0/ifname
+./functions/ncm.usb0/qmult
+./functions/ncm.usb0/host_addr
+./functions/ncm.usb0/dev_addr
+./UDC
+./bcdUSB
+./bcdDevice
+./idProduct
+./idVendor
+./bMaxPacketSize0
+./bDeviceProtocol
+./bDeviceSubClass
+./bDeviceClass
+
+
+Such a gadget must be finally enabled so that the USB host can enumerate it.
+In order to enable the gadget it must be bound to a UDC (USB Device Controller).
+
+$ echo <udc name> > UDC
+
+where <udc name> is one of those found in /sys/class/udc/*
+e.g.:
+
+$ echo s3c-hsotg > UDC
+
+
+6. Disabling the gadget
+-----------------------
+
+$ echo "" > UDC
+
+7. Cleaning up
+--------------
+
+Remove functions from configurations:
+
+$ rm configs/<config name>.<number>/<function>
+
+where <config name>.<number> specify the configuration and <function> is
+a symlink to a function being removed from the configuration, e.g.:
+
+$ rm configfs/c.1/ncm.usb0
+
+...
+...
+...
+
+Remove strings directories in configurations
+
+$ rmdir configs/<config name>.<number>/strings/<lang>
+
+e.g.:
+
+$ rmdir configs/c.1/strings/0x409
+
+...
+...
+...
+
+and remove the configurations
+
+$ rmdir configs/<config name>.<number>
+
+e.g.:
+
+rmdir configs/c.1
+
+...
+...
+...
+
+Remove functions (function modules are not unloaded, though)
+
+$ rmdir functions/<name>.<instance name>
+
+e.g.:
+
+$ rmdir functions/ncm.usb0
+
+...
+...
+...
+
+Remove strings directories in the gadget
+
+$ rmdir strings/<lang>
+
+e.g.:
+
+$ rmdir strings/0x409
+
+and finally remove the gadget:
+
+$ cd ..
+$ rmdir <gadget name>
+
+e.g.:
+
+$ rmdir g1
+
+
+
+
+Implementation design
+=====================
+
+Below the idea of how configfs works is presented.
+In configfs there are items and groups, both represented as directories.
+The difference between an item and a group is that a group can contain
+other groups. In the picture below only an item is shown.
+Both items and groups can have attributes, which are represented as files.
+The user can create and remove directories, but cannot remove files,
+which can be read-only or read-write, depending on what they represent.
+
+The filesystem part of configfs operates on config_items/groups and
+configfs_attributes which are generic and of the same type for all
+configured elements. However, they are embedded in usage-specific
+larger structures. In the picture below there is a "cs" which contains
+a config_item and an "sa" which contains a configfs_attribute.
+
+The filesystem view would be like this:
+
+./
+./cs (directory)
+ |
+ +--sa (file)
+ |
+ .
+ .
+ .
+
+Whenever a user reads/writes the "sa" file, a function is called
+which accepts a struct config_item and a struct configfs_attribute.
+In the said function the "cs" and "sa" are retrieved using the well
+known container_of technique and an appropriate sa's function (show or
+store) is called and passed the "cs" and a character buffer. The "show"
+is for displaying the file's contents (copy data from the cs to the
+buffer), while the "store" is for modifying the file's contents (copy data
+from the buffer to the cs), but it is up to the implementer of the
+two functions to decide what they actually do.
+
+typedef struct configured_structure cs;
+typedef struc specific_attribute sa;
+
+ sa
+ +----------------------------------+
+ cs | (*show)(cs *, buffer); |
++-----------------+ | (*store)(cs *, buffer, length); |
+| | | |
+| +-------------+ | | +------------------+ |
+| | struct |-|----|------>|struct | |
+| | config_item | | | |configfs_attribute| |
+| +-------------+ | | +------------------+ |
+| | +----------------------------------+
+| data to be set | .
+| | .
++-----------------+ .
+
+The file names are decided by the config item/group designer, while
+the directories in general can be named at will. A group can have
+a number of its default sub-groups created automatically.
+
+For more information on configfs please see
+Documentation/filesystems/configfs/*.
+
+The concepts described above translate to USB gadgets like this:
+
+1. A gadget has its config group, which has some attributes (idVendor,
+idProduct etc) and default sub-groups (configs, functions, strings).
+Writing to the attributes causes the information to be stored in
+appropriate locations. In the configs, functions and strings sub-groups
+a user can create their sub-groups to represent configurations, functions,
+and groups of strings in a given language.
+
+2. The user creates configurations and functions, in the configurations
+creates symbolic links to functions. This information is used when the
+gadget's UDC attribute is written to, which means binding the gadget
+to the UDC. The code in drivers/usb/gadget/configfs.c iterates over
+all configurations, and in each configuration it iterates over all
+functions and binds them. This way the whole gadget is bound.
+
+3. The file drivers/usb/gadget/configfs.c contains code for
+
+ - gadget's config_group
+ - gadget's default groups (configs, functions, strings)
+ - associating functions with configurations (symlinks)
+
+4. Each USB function naturally has its own view of what it wants
+configured, so config_groups for particular functions are defined
+in the functions implementation files drivers/usb/gadget/f_*.c.
+
+5. Funciton's code is written in such a way that it uses
+
+usb_get_function_instance(), which, in turn, calls request_module.
+So, provided that modprobe works, modules for particular functions
+are loaded automatically. Please note that the converse is not true:
+after a gadget is disabled and torn down, the modules remain loaded.
diff --git a/Documentation/usb/hotplug.txt b/Documentation/usb/hotplug.txt
index 4c945716..6424b13 100644
--- a/Documentation/usb/hotplug.txt
+++ b/Documentation/usb/hotplug.txt
@@ -33,9 +33,9 @@
KERNEL HOTPLUG HELPER (/sbin/hotplug)
-When you compile with CONFIG_HOTPLUG, you get a new kernel parameter:
-/proc/sys/kernel/hotplug, which normally holds the pathname "/sbin/hotplug".
-That parameter names a program which the kernel may invoke at various times.
+There is a kernel parameter: /proc/sys/kernel/hotplug, which normally
+holds the pathname "/sbin/hotplug". That parameter names a program
+which the kernel may invoke at various times.
The /sbin/hotplug program can be invoked by any subsystem as part of its
reaction to a configuration change, from a thread in that subsystem.
diff --git a/Documentation/usb/power-management.txt b/Documentation/usb/power-management.txt
index 4204eb0..1392b61 100644
--- a/Documentation/usb/power-management.txt
+++ b/Documentation/usb/power-management.txt
@@ -33,6 +33,10 @@
CONFIG_PM_RUNTIME). System PM support is present only if the kernel
was built with CONFIG_SUSPEND or CONFIG_HIBERNATION enabled.
+(Starting with the 3.10 kernel release, dynamic PM support for USB is
+present whenever the kernel was built with CONFIG_PM_RUNTIME enabled.
+The CONFIG_USB_SUSPEND option has been eliminated.)
+
What is Remote Wakeup?
----------------------
@@ -206,10 +210,8 @@
will not be affected.)
Setting the initial default idle-delay to -1 will prevent any
-autosuspend of any USB device. This is a simple alternative to
-disabling CONFIG_USB_SUSPEND and rebuilding the kernel, and it has the
-added benefit of allowing you to enable autosuspend for selected
-devices.
+autosuspend of any USB device. This has the benefit of allowing you
+then to enable autosuspend for selected devices.
Warnings
diff --git a/Documentation/vfio.txt b/Documentation/vfio.txt
index 8eda363..d7993dc 100644
--- a/Documentation/vfio.txt
+++ b/Documentation/vfio.txt
@@ -172,12 +172,12 @@
struct vfio_device_info device_info = { .argsz = sizeof(device_info) };
/* Create a new container */
- container = open("/dev/vfio/vfio, O_RDWR);
+ container = open("/dev/vfio/vfio", O_RDWR);
if (ioctl(container, VFIO_GET_API_VERSION) != VFIO_API_VERSION)
/* Unknown API version */
- if (!ioctl(container, VFIO_CHECK_EXTENSION, VFIO_X86_IOMMU))
+ if (!ioctl(container, VFIO_CHECK_EXTENSION, VFIO_TYPE1_IOMMU))
/* Doesn't support the IOMMU driver we want. */
/* Open the group */
@@ -193,7 +193,7 @@
ioctl(group, VFIO_GROUP_SET_CONTAINER, &container);
/* Enable the IOMMU model we want */
- ioctl(container, VFIO_SET_IOMMU, VFIO_X86_IOMMU)
+ ioctl(container, VFIO_SET_IOMMU, VFIO_TYPE1_IOMMU)
/* Get addition IOMMU info */
ioctl(container, VFIO_IOMMU_GET_INFO, &iommu_info);
@@ -283,6 +283,69 @@
interfaces implement the device region access defined by the device's
own VFIO_DEVICE_GET_REGION_INFO ioctl.
+
+PPC64 sPAPR implementation note
+-------------------------------------------------------------------------------
+
+This implementation has some specifics:
+
+1) Only one IOMMU group per container is supported as an IOMMU group
+represents the minimal entity which isolation can be guaranteed for and
+groups are allocated statically, one per a Partitionable Endpoint (PE)
+(PE is often a PCI domain but not always).
+
+2) The hardware supports so called DMA windows - the PCI address range
+within which DMA transfer is allowed, any attempt to access address space
+out of the window leads to the whole PE isolation.
+
+3) PPC64 guests are paravirtualized but not fully emulated. There is an API
+to map/unmap pages for DMA, and it normally maps 1..32 pages per call and
+currently there is no way to reduce the number of calls. In order to make things
+faster, the map/unmap handling has been implemented in real mode which provides
+an excellent performance which has limitations such as inability to do
+locked pages accounting in real time.
+
+So 3 additional ioctls have been added:
+
+ VFIO_IOMMU_SPAPR_TCE_GET_INFO - returns the size and the start
+ of the DMA window on the PCI bus.
+
+ VFIO_IOMMU_ENABLE - enables the container. The locked pages accounting
+ is done at this point. This lets user first to know what
+ the DMA window is and adjust rlimit before doing any real job.
+
+ VFIO_IOMMU_DISABLE - disables the container.
+
+
+The code flow from the example above should be slightly changed:
+
+ .....
+ /* Add the group to the container */
+ ioctl(group, VFIO_GROUP_SET_CONTAINER, &container);
+
+ /* Enable the IOMMU model we want */
+ ioctl(container, VFIO_SET_IOMMU, VFIO_SPAPR_TCE_IOMMU)
+
+ /* Get addition sPAPR IOMMU info */
+ vfio_iommu_spapr_tce_info spapr_iommu_info;
+ ioctl(container, VFIO_IOMMU_SPAPR_TCE_GET_INFO, &spapr_iommu_info);
+
+ if (ioctl(container, VFIO_IOMMU_ENABLE))
+ /* Cannot enable container, may be low rlimit */
+
+ /* Allocate some space and setup a DMA mapping */
+ dma_map.vaddr = mmap(0, 1024 * 1024, PROT_READ | PROT_WRITE,
+ MAP_PRIVATE | MAP_ANONYMOUS, 0, 0);
+
+ dma_map.size = 1024 * 1024;
+ dma_map.iova = 0; /* 1MB starting at 0x0 from device view */
+ dma_map.flags = VFIO_DMA_MAP_FLAG_READ | VFIO_DMA_MAP_FLAG_WRITE;
+
+ /* Check here is .iova/.size are within DMA window from spapr_iommu_info */
+
+ ioctl(container, VFIO_IOMMU_MAP_DMA, &dma_map);
+ .....
+
-------------------------------------------------------------------------------
[1] VFIO was originally an acronym for "Virtual Function I/O" in its
diff --git a/Documentation/video4linux/CARDLIST.au0828 b/Documentation/video4linux/CARDLIST.au0828
index a8a6575..55a21de 100644
--- a/Documentation/video4linux/CARDLIST.au0828
+++ b/Documentation/video4linux/CARDLIST.au0828
@@ -1,5 +1,5 @@
0 -> Unknown board (au0828)
- 1 -> Hauppauge HVR950Q (au0828) [2040:7200,2040:7210,2040:7217,2040:721b,2040:721e,2040:721f,2040:7280,0fd9:0008,2040:7260,2040:7213]
+ 1 -> Hauppauge HVR950Q (au0828) [2040:7200,2040:7210,2040:7217,2040:721b,2040:721e,2040:721f,2040:7280,0fd9:0008,2040:7260,2040:7213,2040:7270]
2 -> Hauppauge HVR850 (au0828) [2040:7240]
3 -> DViCO FusionHDTV USB (au0828) [0fe9:d620]
4 -> Hauppauge HVR950Q rev xxF8 (au0828) [2040:7201,2040:7211,2040:7281]
diff --git a/Documentation/video4linux/CARDLIST.bttv b/Documentation/video4linux/CARDLIST.bttv
index 581f666..f144750 100644
--- a/Documentation/video4linux/CARDLIST.bttv
+++ b/Documentation/video4linux/CARDLIST.bttv
@@ -160,3 +160,6 @@
159 -> ProVideo PV183 [1830:1540,1831:1540,1832:1540,1833:1540,1834:1540,1835:1540,1836:1540,1837:1540]
160 -> Tongwei Video Technology TD-3116 [f200:3116]
161 -> Aposonic W-DVR [0279:0228]
+162 -> Adlink MPG24
+163 -> Bt848 Capture 14MHz
+164 -> CyberVision CV06 (SV)
diff --git a/Documentation/video4linux/CARDLIST.cx23885 b/Documentation/video4linux/CARDLIST.cx23885
index 1299b5e..9f056d5 100644
--- a/Documentation/video4linux/CARDLIST.cx23885
+++ b/Documentation/video4linux/CARDLIST.cx23885
@@ -36,3 +36,5 @@
35 -> TeVii S471 [d471:9022]
36 -> Hauppauge WinTV-HVR1255 [0070:2259]
37 -> Prof Revolution DVB-S2 8000 [8000:3034]
+ 38 -> Hauppauge WinTV-HVR4400 [0070:c108,0070:c138,0070:c12a,0070:c1f8]
+ 39 -> AVerTV Hybrid Express Slim HC81R [1461:d939]
diff --git a/Documentation/video4linux/CARDLIST.em28xx b/Documentation/video4linux/CARDLIST.em28xx
index d99262d..e818644 100644
--- a/Documentation/video4linux/CARDLIST.em28xx
+++ b/Documentation/video4linux/CARDLIST.em28xx
@@ -76,7 +76,7 @@
76 -> KWorld PlusTV 340U or UB435-Q (ATSC) (em2870) [1b80:a340]
77 -> EM2874 Leadership ISDBT (em2874)
78 -> PCTV nanoStick T2 290e (em28174)
- 79 -> Terratec Cinergy H5 (em2884) [0ccd:008e,0ccd:00ac,0ccd:10a2,0ccd:10ad]
+ 79 -> Terratec Cinergy H5 (em2884) [0ccd:10a2,0ccd:10ad,0ccd:10b6]
80 -> PCTV DVB-S2 Stick (460e) (em28174)
81 -> Hauppauge WinTV HVR 930C (em2884) [2040:1605]
82 -> Terratec Cinergy HTC Stick (em2884) [0ccd:00b2]
@@ -84,3 +84,5 @@
84 -> MaxMedia UB425-TC (em2874) [1b80:e425]
85 -> PCTV QuatroStick (510e) (em2884) [2304:0242]
86 -> PCTV QuatroStick nano (520e) (em2884) [2013:0251]
+ 87 -> Terratec Cinergy HTC USB XS (em2884) [0ccd:008e,0ccd:00ac]
+ 88 -> C3 Tech Digital Duo HDTV/SDTV USB (em2884) [1b80:e755]
diff --git a/Documentation/video4linux/CARDLIST.saa7134 b/Documentation/video4linux/CARDLIST.saa7134
index 94d9025..8df17d0 100644
--- a/Documentation/video4linux/CARDLIST.saa7134
+++ b/Documentation/video4linux/CARDLIST.saa7134
@@ -189,3 +189,5 @@
188 -> Sensoray 811/911 [6000:0811,6000:0911]
189 -> Kworld PC150-U [17de:a134]
190 -> Asus My Cinema PS3-100 [1043:48cd]
+191 -> Hawell HW-9004V1
+192 -> AverMedia AverTV Satellite Hybrid+FM A706 [1461:2055]
diff --git a/Documentation/video4linux/CARDLIST.tuner b/Documentation/video4linux/CARDLIST.tuner
index c83f6e4..ac88621 100644
--- a/Documentation/video4linux/CARDLIST.tuner
+++ b/Documentation/video4linux/CARDLIST.tuner
@@ -86,3 +86,6 @@
tuner=86 - Tena TNF5337 MFD
tuner=87 - Xceive 4000 tuner
tuner=88 - Xceive 5000C tuner
+tuner=89 - Sony BTF-PG472Z PAL/SECAM
+tuner=90 - Sony BTF-PK467Z NTSC-M-JP
+tuner=91 - Sony BTF-PB463Z NTSC-M
diff --git a/Documentation/video4linux/et61x251.txt b/Documentation/video4linux/et61x251.txt
deleted file mode 100644
index e0cdae4..0000000
--- a/Documentation/video4linux/et61x251.txt
+++ /dev/null
@@ -1,315 +0,0 @@
-
- ET61X[12]51 PC Camera Controllers
- Driver for Linux
- =================================
-
- - Documentation -
-
-
-Index
-=====
-1. Copyright
-2. Disclaimer
-3. License
-4. Overview and features
-5. Module dependencies
-6. Module loading
-7. Module parameters
-8. Optional device control through "sysfs"
-9. Supported devices
-10. Notes for V4L2 application developers
-11. Contact information
-
-
-1. Copyright
-============
-Copyright (C) 2006-2007 by Luca Risolia <luca.risolia@studio.unibo.it>
-
-
-2. Disclaimer
-=============
-Etoms is a trademark of Etoms Electronics Corp.
-This software is not developed or sponsored by Etoms Electronics.
-
-
-3. License
-==========
-This program is free software; you can redistribute it and/or modify
-it under the terms of the GNU General Public License as published by
-the Free Software Foundation; either version 2 of the License, or
-(at your option) any later version.
-
-This program is distributed in the hope that it will be useful,
-but WITHOUT ANY WARRANTY; without even the implied warranty of
-MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-GNU General Public License for more details.
-
-You should have received a copy of the GNU General Public License
-along with this program; if not, write to the Free Software
-Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
-
-
-4. Overview and features
-========================
-This driver supports the video interface of the devices mounting the ET61X151
-or ET61X251 PC Camera Controllers.
-
-It's worth to note that Etoms Electronics has never collaborated with the
-author during the development of this project; despite several requests,
-Etoms Electronics also refused to release enough detailed specifications of
-the video compression engine.
-
-The driver relies on the Video4Linux2 and USB core modules. It has been
-designed to run properly on SMP systems as well.
-
-The latest version of the ET61X[12]51 driver can be found at the following URL:
-http://www.linux-projects.org/
-
-Some of the features of the driver are:
-
-- full compliance with the Video4Linux2 API (see also "Notes for V4L2
- application developers" paragraph);
-- available mmap or read/poll methods for video streaming through isochronous
- data transfers;
-- automatic detection of image sensor;
-- support for any window resolutions and optional panning within the maximum
- pixel area of image sensor;
-- image downscaling with arbitrary scaling factors from 1 and 2 in both
- directions (see "Notes for V4L2 application developers" paragraph);
-- two different video formats for uncompressed or compressed data in low or
- high compression quality (see also "Notes for V4L2 application developers"
- paragraph);
-- full support for the capabilities of every possible image sensors that can
- be connected to the ET61X[12]51 bridges, including, for instance, red, green,
- blue and global gain adjustments and exposure control (see "Supported
- devices" paragraph for details);
-- use of default color settings for sunlight conditions;
-- dynamic I/O interface for both ET61X[12]51 and image sensor control (see
- "Optional device control through 'sysfs'" paragraph);
-- dynamic driver control thanks to various module parameters (see "Module
- parameters" paragraph);
-- up to 64 cameras can be handled at the same time; they can be connected and
- disconnected from the host many times without turning off the computer, if
- the system supports hotplugging;
-- no known bugs.
-
-
-5. Module dependencies
-======================
-For it to work properly, the driver needs kernel support for Video4Linux and
-USB.
-
-The following options of the kernel configuration file must be enabled and
-corresponding modules must be compiled:
-
- # Multimedia devices
- #
- CONFIG_VIDEO_DEV=m
-
-To enable advanced debugging functionality on the device through /sysfs:
-
- # Multimedia devices
- #
- CONFIG_VIDEO_ADV_DEBUG=y
-
- # USB support
- #
- CONFIG_USB=m
-
-In addition, depending on the hardware being used, the modules below are
-necessary:
-
- # USB Host Controller Drivers
- #
- CONFIG_USB_EHCI_HCD=m
- CONFIG_USB_UHCI_HCD=m
- CONFIG_USB_OHCI_HCD=m
-
-And finally:
-
- # USB Multimedia devices
- #
- CONFIG_USB_ET61X251=m
-
-
-6. Module loading
-=================
-To use the driver, it is necessary to load the "et61x251" module into memory
-after every other module required: "videodev", "v4l2_common", "compat_ioctl32",
-"usbcore" and, depending on the USB host controller you have, "ehci-hcd",
-"uhci-hcd" or "ohci-hcd".
-
-Loading can be done as shown below:
-
- [root@localhost home]# modprobe et61x251
-
-At this point the devices should be recognized. You can invoke "dmesg" to
-analyze kernel messages and verify that the loading process has gone well:
-
- [user@localhost home]$ dmesg
-
-
-7. Module parameters
-====================
-Module parameters are listed below:
--------------------------------------------------------------------------------
-Name: video_nr
-Type: short array (min = 0, max = 64)
-Syntax: <-1|n[,...]>
-Description: Specify V4L2 minor mode number:
- -1 = use next available
- n = use minor number n
- You can specify up to 64 cameras this way.
- For example:
- video_nr=-1,2,-1 would assign minor number 2 to the second
- registered camera and use auto for the first one and for every
- other camera.
-Default: -1
--------------------------------------------------------------------------------
-Name: force_munmap
-Type: bool array (min = 0, max = 64)
-Syntax: <0|1[,...]>
-Description: Force the application to unmap previously mapped buffer memory
- before calling any VIDIOC_S_CROP or VIDIOC_S_FMT ioctl's. Not
- all the applications support this feature. This parameter is
- specific for each detected camera.
- 0 = do not force memory unmapping
- 1 = force memory unmapping (save memory)
-Default: 0
--------------------------------------------------------------------------------
-Name: frame_timeout
-Type: uint array (min = 0, max = 64)
-Syntax: <n[,...]>
-Description: Timeout for a video frame in seconds. This parameter is
- specific for each detected camera. This parameter can be
- changed at runtime thanks to the /sys filesystem interface.
-Default: 2
--------------------------------------------------------------------------------
-Name: debug
-Type: ushort
-Syntax: <n>
-Description: Debugging information level, from 0 to 3:
- 0 = none (use carefully)
- 1 = critical errors
- 2 = significant information
- 3 = more verbose messages
- Level 3 is useful for testing only, when only one device
- is used at the same time. It also shows some more information
- about the hardware being detected. This module parameter can be
- changed at runtime thanks to the /sys filesystem interface.
-Default: 2
--------------------------------------------------------------------------------
-
-
-8. Optional device control through "sysfs"
-==========================================
-If the kernel has been compiled with the CONFIG_VIDEO_ADV_DEBUG option enabled,
-it is possible to read and write both the ET61X[12]51 and the image sensor
-registers by using the "sysfs" filesystem interface.
-
-There are four files in the /sys/class/video4linux/videoX directory for each
-registered camera: "reg", "val", "i2c_reg" and "i2c_val". The first two files
-control the ET61X[12]51 bridge, while the other two control the sensor chip.
-"reg" and "i2c_reg" hold the values of the current register index where the
-following reading/writing operations are addressed at through "val" and
-"i2c_val". Their use is not intended for end-users, unless you know what you
-are doing. Remember that you must be logged in as root before writing to them.
-
-As an example, suppose we were to want to read the value contained in the
-register number 1 of the sensor register table - which is usually the product
-identifier - of the camera registered as "/dev/video0":
-
- [root@localhost #] cd /sys/class/video4linux/video0
- [root@localhost #] echo 1 > i2c_reg
- [root@localhost #] cat i2c_val
-
-Note that if the sensor registers cannot be read, "cat" will fail.
-To avoid race conditions, all the I/O accesses to the files are serialized.
-
-
-9. Supported devices
-====================
-None of the names of the companies as well as their products will be mentioned
-here. They have never collaborated with the author, so no advertising.
-
-From the point of view of a driver, what unambiguously identify a device are
-its vendor and product USB identifiers. Below is a list of known identifiers of
-devices mounting the ET61X[12]51 PC camera controllers:
-
-Vendor ID Product ID
---------- ----------
-0x102c 0x6151
-0x102c 0x6251
-0x102c 0x6253
-0x102c 0x6254
-0x102c 0x6255
-0x102c 0x6256
-0x102c 0x6257
-0x102c 0x6258
-0x102c 0x6259
-0x102c 0x625a
-0x102c 0x625b
-0x102c 0x625c
-0x102c 0x625d
-0x102c 0x625e
-0x102c 0x625f
-0x102c 0x6260
-0x102c 0x6261
-0x102c 0x6262
-0x102c 0x6263
-0x102c 0x6264
-0x102c 0x6265
-0x102c 0x6266
-0x102c 0x6267
-0x102c 0x6268
-0x102c 0x6269
-
-The following image sensors are supported:
-
-Model Manufacturer
------ ------------
-TAS5130D1B Taiwan Advanced Sensor Corporation
-
-All the available control settings of each image sensor are supported through
-the V4L2 interface.
-
-
-10. Notes for V4L2 application developers
-=========================================
-This driver follows the V4L2 API specifications. In particular, it enforces two
-rules:
-
-- exactly one I/O method, either "mmap" or "read", is associated with each
-file descriptor. Once it is selected, the application must close and reopen the
-device to switch to the other I/O method;
-
-- although it is not mandatory, previously mapped buffer memory should always
-be unmapped before calling any "VIDIOC_S_CROP" or "VIDIOC_S_FMT" ioctl's.
-The same number of buffers as before will be allocated again to match the size
-of the new video frames, so you have to map the buffers again before any I/O
-attempts on them.
-
-Consistently with the hardware limits, this driver also supports image
-downscaling with arbitrary scaling factors from 1 and 2 in both directions.
-However, the V4L2 API specifications don't correctly define how the scaling
-factor can be chosen arbitrarily by the "negotiation" of the "source" and
-"target" rectangles. To work around this flaw, we have added the convention
-that, during the negotiation, whenever the "VIDIOC_S_CROP" ioctl is issued, the
-scaling factor is restored to 1.
-
-This driver supports two different video formats: the first one is the "8-bit
-Sequential Bayer" format and can be used to obtain uncompressed video data
-from the device through the current I/O method, while the second one provides
-"raw" compressed video data (without frame headers not related to the
-compressed data). The current compression quality may vary from 0 to 1 and can
-be selected or queried thanks to the VIDIOC_S_JPEGCOMP and VIDIOC_G_JPEGCOMP
-V4L2 ioctl's.
-
-
-11. Contact information
-=======================
-The author may be contacted by e-mail at <luca.risolia@studio.unibo.it>.
-
-GPG/PGP encrypted e-mail's are accepted. The GPG key ID of the author is
-'FCE635A4'; the public 1024-bit key should be available at any keyserver;
-the fingerprint is: '88E8 F32F 7244 68BA 3958 5D40 99DA 5D2A FCE6 35A4'.
diff --git a/Documentation/video4linux/extract_xc3028.pl b/Documentation/video4linux/extract_xc3028.pl
old mode 100644
new mode 100755
diff --git a/Documentation/video4linux/fimc.txt b/Documentation/video4linux/fimc.txt
index fd02d9a..e51f1b5 100644
--- a/Documentation/video4linux/fimc.txt
+++ b/Documentation/video4linux/fimc.txt
@@ -1,6 +1,6 @@
Samsung S5P/EXYNOS4 FIMC driver
-Copyright (C) 2012 Samsung Electronics Co., Ltd.
+Copyright (C) 2012 - 2013 Samsung Electronics Co., Ltd.
---------------------------------------------------------------------------
The FIMC (Fully Interactive Mobile Camera) device available in Samsung
@@ -10,7 +10,7 @@
path. There are multiple FIMC instances in the SoCs (up to 4), having
slightly different capabilities, like pixel alignment constraints, rotator
availability, LCD writeback support, etc. The driver is located at
-drivers/media/platform/s5p-fimc directory.
+drivers/media/platform/exynos4-is directory.
1. Supported SoCs
=================
@@ -36,21 +36,21 @@
=====================
- media device driver
- drivers/media/platform/s5p-fimc/fimc-mdevice.[ch]
+ drivers/media/platform/exynos4-is/media-dev.[ch]
- camera capture video device driver
- drivers/media/platform/s5p-fimc/fimc-capture.c
+ drivers/media/platform/exynos4-is/fimc-capture.c
- MIPI-CSI2 receiver subdev
- drivers/media/platform/s5p-fimc/mipi-csis.[ch]
+ drivers/media/platform/exynos4-is/mipi-csis.[ch]
- video post-processor (mem-to-mem)
- drivers/media/platform/s5p-fimc/fimc-core.c
+ drivers/media/platform/exynos4-is/fimc-core.c
- common files
- drivers/media/platform/s5p-fimc/fimc-core.h
- drivers/media/platform/s5p-fimc/fimc-reg.h
- drivers/media/platform/s5p-fimc/regs-fimc.h
+ drivers/media/platform/exynos4-is/fimc-core.h
+ drivers/media/platform/exynos4-is/fimc-reg.h
+ drivers/media/platform/exynos4-is/regs-fimc.h
4. User space interfaces
========================
@@ -58,7 +58,7 @@
4.1. Media device interface
The driver supports Media Controller API as defined at
-http://http://linuxtv.org/downloads/v4l-dvb-apis/media_common.html
+http://linuxtv.org/downloads/v4l-dvb-apis/media_common.html
The media device driver name is "SAMSUNG S5P FIMC".
The purpose of this interface is to allow changing assignment of FIMC instances
@@ -143,7 +143,8 @@
6. Platform support
===================
-The machine code (plat-s5p and arch/arm/mach-*) must select following options
+The machine code (arch/arm/plat-samsung and arch/arm/mach-*) must select
+following options:
CONFIG_S5P_DEV_FIMC0 mandatory
CONFIG_S5P_DEV_FIMC1 \
diff --git a/Documentation/video4linux/ibmcam.txt b/Documentation/video4linux/ibmcam.txt
deleted file mode 100644
index a5105521..0000000
--- a/Documentation/video4linux/ibmcam.txt
+++ /dev/null
@@ -1,323 +0,0 @@
-README for Linux device driver for the IBM "C-It" USB video camera
-
-INTRODUCTION:
-
-This driver does not use all features known to exist in
-the IBM camera. However most of needed features work well.
-
-This driver was developed using logs of observed USB traffic
-which was produced by standard Windows driver (c-it98.sys).
-I did not have data sheets from Xirlink.
-
-Video formats:
- 128x96 [model 1]
- 176x144
- 320x240 [model 2]
- 352x240 [model 2]
- 352x288
-Frame rate: 3 - 30 frames per second (FPS)
-External interface: USB
-Internal interface: Video For Linux (V4L)
-Supported controls:
-- by V4L: Contrast, Brightness, Color, Hue
-- by driver options: frame rate, lighting conditions, video format,
- default picture settings, sharpness.
-
-SUPPORTED CAMERAS:
-
-Xirlink "C-It" camera, also known as "IBM PC Camera".
-The device uses proprietary ASIC (and compression method);
-it is manufactured by Xirlink. See http://xirlinkwebcam.sourceforge.net,
-http://www.ibmpccamera.com, or http://www.c-itnow.com/ for details and pictures.
-
-This very chipset ("X Chip", as marked at the factory)
-is used in several other cameras, and they are supported
-as well:
-
-- IBM NetCamera
-- Veo Stingray
-
-The Linux driver was developed with camera with following
-model number (or FCC ID): KSX-XVP510. This camera has three
-interfaces, each with one endpoint (control, iso, iso). This
-type of cameras is referred to as "model 1". These cameras are
-no longer manufactured.
-
-Xirlink now manufactures new cameras which are somewhat different.
-In particular, following models [FCC ID] belong to that category:
-
-XVP300 [KSX-X9903]
-XVP600 [KSX-X9902]
-XVP610 [KSX-X9902]
-
-(see http://www.xirlink.com/ibmpccamera/ for updates, they refer
-to these new cameras by Windows driver dated 12-27-99, v3005 BETA)
-These cameras have two interfaces, one endpoint in each (iso, bulk).
-Such type of cameras is referred to as "model 2". They are supported
-(with exception of 352x288 native mode).
-
-Some IBM NetCameras (Model 4) are made to generate only compressed
-video streams. This is great for performance, but unfortunately
-nobody knows how to decompress the stream :-( Therefore, these
-cameras are *unsupported* and if you try to use one of those, all
-you get is random colored horizontal streaks, not the image!
-If you have one of those cameras, you probably should return it
-to the store and get something that is supported.
-
-Tell me more about all that "model" business
---------------------------------------------
-
-I just invented model numbers to uniquely identify flavors of the
-hardware/firmware that were sold. It was very confusing to use
-brand names or some other internal numbering schemes. So I found
-by experimentation that all Xirlink chipsets fall into four big
-classes, and I called them "models". Each model is programmed in
-its own way, and each model sends back the video in its own way.
-
-Quirks of Model 2 cameras:
--------------------------
-
-Model 2 does not have hardware contrast control. Corresponding V4L
-control is implemented in software, which is not very nice to your
-CPU, but at least it works.
-
-This driver provides 352x288 mode by switching the camera into
-quasi-352x288 RGB mode (800 Kbits per frame) essentially limiting
-this mode to 10 frames per second or less, in ideal conditions on
-the bus (USB is shared, after all). The frame rate
-has to be programmed very conservatively. Additional concern is that
-frame rate depends on brightness setting; therefore the picture can
-be good at one brightness and broken at another! I did not want to fix
-the frame rate at slowest setting, but I had to move it pretty much down
-the scale (so that framerate option barely matters). I also noticed that
-camera after first powering up produces frames slightly faster than during
-consecutive uses. All this means that if you use 352x288 (which is
-default), be warned - you may encounter broken picture on first connect;
-try to adjust brightness - brighter image is slower, so USB will be able
-to send all data. However if you regularly use Model 2 cameras you may
-prefer 176x144 which makes perfectly good I420, with no scaling and
-lesser demands on USB (300 Kbits per second, or 26 frames per second).
-
-Another strange effect of 352x288 mode is the fine vertical grid visible
-on some colored surfaces. I am sure it is caused by me not understanding
-what the camera is trying to say. Blame trade secrets for that.
-
-The camera that I had also has a hardware quirk: if disconnected,
-it needs few minutes to "relax" before it can be plugged in again
-(poorly designed USB processor reset circuit?)
-
-[Veo Stingray with Product ID 0x800C is also Model 2, but I haven't
-observed this particular flaw in it.]
-
-Model 2 camera can be programmed for very high sensitivity (even starlight
-may be enough), this makes it convenient for tinkering with. The driver
-code has enough comments to help a programmer to tweak the camera
-as s/he feels necessary.
-
-WHAT YOU NEED:
-
-- A supported IBM PC (C-it) camera (model 1 or 2)
-
-- A Linux box with USB support (2.3/2.4; 2.2 w/backport may work)
-
-- A Video4Linux compatible frame grabber program such as xawtv.
-
-HOW TO COMPILE THE DRIVER:
-
-You need to compile the driver only if you are a developer
-or if you want to make changes to the code. Most distributions
-precompile all modules, so you can go directly to the next
-section "HOW TO USE THE DRIVER".
-
-The ibmcam driver uses usbvideo helper library (module),
-so if you are studying the ibmcam code you will be led there.
-
-The driver itself consists of only one file in usb/ directory:
-ibmcam.c. This file is included into the Linux kernel build
-process if you configure the kernel for CONFIG_USB_IBMCAM.
-Run "make xconfig" and in USB section you will find the IBM
-camera driver. Select it, save the configuration and recompile.
-
-HOW TO USE THE DRIVER:
-
-I recommend to compile driver as a module. This gives you an
-easier access to its configuration. The camera has many more
-settings than V4L can operate, so some settings are done using
-module options.
-
-To begin with, on most modern Linux distributions the driver
-will be automatically loaded whenever you plug the supported
-camera in. Therefore, you don't need to do anything. However
-if you want to experiment with some module parameters then
-you can load and unload the driver manually, with camera
-plugged in or unplugged.
-
-Typically module is installed with command 'modprobe', like this:
-
-# modprobe ibmcam framerate=1
-
-Alternatively you can use 'insmod' in similar fashion:
-
-# insmod /lib/modules/2.x.y/usb/ibmcam.o framerate=1
-
-Module can be inserted with camera connected or disconnected.
-
-The driver can have options, though some defaults are provided.
-
-Driver options: (* indicates that option is model-dependent)
-
-Name Type Range [default] Example
--------------- -------------- -------------- ------------------
-debug Integer 0-9 [0] debug=1
-flags Integer 0-0xFF [0] flags=0x0d
-framerate Integer 0-6 [2] framerate=1
-hue_correction Integer 0-255 [128] hue_correction=115
-init_brightness Integer 0-255 [128] init_brightness=100
-init_contrast Integer 0-255 [192] init_contrast=200
-init_color Integer 0-255 [128] init_color=130
-init_hue Integer 0-255 [128] init_hue=115
-lighting Integer 0-2* [1] lighting=2
-sharpness Integer 0-6* [4] sharpness=3
-size Integer 0-2* [2] size=1
-
-Options for Model 2 only:
-
-Name Type Range [default] Example
--------------- -------------- -------------- ------------------
-init_model2_rg Integer 0..255 [0x70] init_model2_rg=128
-init_model2_rg2 Integer 0..255 [0x2f] init_model2_rg2=50
-init_model2_sat Integer 0..255 [0x34] init_model2_sat=65
-init_model2_yb Integer 0..255 [0xa0] init_model2_yb=200
-
-debug You don't need this option unless you are a developer.
- If you are a developer then you will see in the code
- what values do what. 0=off.
-
-flags This is a bit mask, and you can combine any number of
- bits to produce what you want. Usually you don't want
- any of extra features this option provides:
-
- FLAGS_RETRY_VIDIOCSYNC 1 This bit allows to retry failed
- VIDIOCSYNC ioctls without failing.
- Will work with xawtv, will not
- with xrealproducer. Default is
- not set.
- FLAGS_MONOCHROME 2 Activates monochrome (b/w) mode.
- FLAGS_DISPLAY_HINTS 4 Shows colored pixels which have
- magic meaning to developers.
- FLAGS_OVERLAY_STATS 8 Shows tiny numbers on screen,
- useful only for debugging.
- FLAGS_FORCE_TESTPATTERN 16 Shows blue screen with numbers.
- FLAGS_SEPARATE_FRAMES 32 Shows each frame separately, as
- it was received from the camera.
- Default (not set) is to mix the
- preceding frame in to compensate
- for occasional loss of Isoc data
- on high frame rates.
- FLAGS_CLEAN_FRAMES 64 Forces "cleanup" of each frame
- prior to use; relevant only if
- FLAGS_SEPARATE_FRAMES is set.
- Default is not to clean frames,
- this is a little faster but may
- produce flicker if frame rate is
- too high and Isoc data gets lost.
- FLAGS_NO_DECODING 128 This flag turns the video stream
- decoder off, and dumps the raw
- Isoc data from the camera into
- the reading process. Useful to
- developers, but not to users.
-
-framerate This setting controls frame rate of the camera. This is
- an approximate setting (in terms of "worst" ... "best")
- because camera changes frame rate depending on amount
- of light available. Setting 0 is slowest, 6 is fastest.
- Beware - fast settings are very demanding and may not
- work well with all video sizes. Be conservative.
-
-hue_correction This highly optional setting allows to adjust the
- hue of the image in a way slightly different from
- what usual "hue" control does. Both controls affect
- YUV colorspace: regular "hue" control adjusts only
- U component, and this "hue_correction" option similarly
- adjusts only V component. However usually it is enough
- to tweak only U or V to compensate for colored light or
- color temperature; this option simply allows more
- complicated correction when and if it is necessary.
-
-init_brightness These settings specify _initial_ values which will be
-init_contrast used to set up the camera. If your V4L application has
-init_color its own controls to adjust the picture then these
-init_hue controls will be used too. These options allow you to
- preconfigure the camera when it gets connected, before
- any V4L application connects to it. Good for webcams.
-
-init_model2_rg These initial settings alter color balance of the
-init_model2_rg2 camera on hardware level. All four settings may be used
-init_model2_sat to tune the camera to specific lighting conditions. These
-init_model2_yb settings only apply to Model 2 cameras.
-
-lighting This option selects one of three hardware-defined
- photosensitivity settings of the camera. 0=bright light,
- 1=Medium (default), 2=Low light. This setting affects
- frame rate: the dimmer the lighting the lower the frame
- rate (because longer exposition time is needed). The
- Model 2 cameras allow values more than 2 for this option,
- thus enabling extremely high sensitivity at cost of frame
- rate, color saturation and imaging sensor noise.
-
-sharpness This option controls smoothing (noise reduction)
- made by camera. Setting 0 is most smooth, setting 6
- is most sharp. Be aware that CMOS sensor used in the
- camera is pretty noisy, so if you choose 6 you will
- be greeted with "snowy" image. Default is 4. Model 2
- cameras do not support this feature.
-
-size This setting chooses one of several image sizes that are
- supported by this driver. Cameras may support more, but
- it's difficult to reverse-engineer all formats.
- Following video sizes are supported:
-
- size=0 128x96 (Model 1 only)
- size=1 160x120
- size=2 176x144
- size=3 320x240 (Model 2 only)
- size=4 352x240 (Model 2 only)
- size=5 352x288
- size=6 640x480 (Model 3 only)
-
- The 352x288 is the native size of the Model 1 sensor
- array, so it's the best resolution the camera can
- yield. The best resolution of Model 2 is 176x144, and
- larger images are produced by stretching the bitmap.
- Model 3 has sensor with 640x480 grid, and it works too,
- but the frame rate will be exceptionally low (1-2 FPS);
- it may be still OK for some applications, like security.
- Choose the image size you need. The smaller image can
- support faster frame rate. Default is 352x288.
-
-For more information and the Troubleshooting FAQ visit this URL:
-
- http://www.linux-usb.org/ibmcam/
-
-WHAT NEEDS TO BE DONE:
-
-- The button on the camera is not used. I don't know how to get to it.
- I know now how to read button on Model 2, but what to do with it?
-
-- Camera reports its status back to the driver; however I don't know
- what returned data means. If camera fails at some initialization
- stage then something should be done, and I don't do that because
- I don't even know that some command failed. This is mostly Model 1
- concern because Model 2 uses different commands which do not return
- status (and seem to complete successfully every time).
-
-- Some flavors of Model 4 NetCameras produce only compressed video
- streams, and I don't know how to decode them.
-
-CREDITS:
-
-The code is based in no small part on the CPiA driver by Johannes Erdfelt,
-Randy Dunlap, and others. Big thanks to them for their pioneering work on that
-and the USB stack.
-
-I also thank John Lightsey for his donation of the Veo Stingray camera.
diff --git a/Documentation/video4linux/m5602.txt b/Documentation/video4linux/m5602.txt
deleted file mode 100644
index 4450ab1..0000000
--- a/Documentation/video4linux/m5602.txt
+++ /dev/null
@@ -1,12 +0,0 @@
-This document describes the ALi m5602 bridge connected
-to the following supported sensors:
-OmniVision OV9650,
-Samsung s5k83a,
-Samsung s5k4aa,
-Micron mt9m111,
-Pixel plus PO1030
-
-This driver mimics the windows drivers, which have a braindead implementation sending bayer-encoded frames at VGA resolution.
-In a perfect world we should be able to reprogram the m5602 and the connected sensor in hardware instead, supporting a range of resolutions and pixelformats
-
-Anyway, have fun and please report any bugs to m560x-driver-devel@lists.sourceforge.net
diff --git a/Documentation/video4linux/ov511.txt b/Documentation/video4linux/ov511.txt
deleted file mode 100644
index b3326b1..0000000
--- a/Documentation/video4linux/ov511.txt
+++ /dev/null
@@ -1,288 +0,0 @@
--------------------------------------------------------------------------------
-Readme for Linux device driver for the OmniVision OV511 USB to camera bridge IC
--------------------------------------------------------------------------------
-
-Author: Mark McClelland
-Homepage: http://alpha.dyndns.org/ov511
-
-INTRODUCTION:
-
-This is a driver for the OV511, a USB-only chip used in many "webcam" devices.
-Any camera using the OV511/OV511+ and the OV6620/OV7610/20/20AE should work.
-Video capture devices that use the Philips SAA7111A decoder also work. It
-supports streaming and capture of color or monochrome video via the Video4Linux
-API. Most V4L apps are compatible with it. Most resolutions with a width and
-height that are a multiple of 8 are supported.
-
-If you need more information, please visit the OV511 homepage at the above URL.
-
-WHAT YOU NEED:
-
-- If you want to help with the development, get the chip's specification docs at
- http://www.ovt.com/omniusbp.html
-
-- A Video4Linux compatible frame grabber program (I recommend vidcat and xawtv)
- vidcat is part of the w3cam package: http://mpx.freeshell.net/
- xawtv is available at: http://linux.bytesex.org/xawtv/
-
-HOW TO USE IT:
-
-Note: These are simplified instructions. For complete instructions see:
- http://alpha.dyndns.org/ov511/install.html
-
-You must have first compiled USB support, support for your specific USB host
-controller (UHCI or OHCI), and Video4Linux support for your kernel (I recommend
-making them modules.) Make sure "Enforce bandwidth allocation" is NOT enabled.
-
-Next, (as root):
-
- modprobe usbcore
- modprobe usb-uhci <OR> modprobe usb-ohci
- modprobe videodev
- modprobe ov511
-
-If it is not already there (it usually is), create the video device:
-
- mknod /dev/video0 c 81 0
-
-Optionally, symlink /dev/video to /dev/video0
-
-You will have to set permissions on this device to allow you to read/write
-from it:
-
- chmod 666 /dev/video
- chmod 666 /dev/video0 (if necessary)
-
-Now you are ready to run a video app! Both vidcat and xawtv work well for me
-at 640x480.
-
-[Using vidcat:]
-
- vidcat -s 640x480 -p c > test.jpg
- xview test.jpg
-
-[Using xawtv:]
-
-From the main xawtv directory:
-
- make clean
- ./configure
- make
- make install
-
-Now you should be able to run xawtv. Right click for the options dialog.
-
-MODULE PARAMETERS:
-
- You can set these with: insmod ov511 NAME=VALUE
- There is currently no way to set these on a per-camera basis.
-
- NAME: autobright
- TYPE: integer (Boolean)
- DEFAULT: 1
- DESC: Brightness is normally under automatic control and can't be set
- manually by the video app. Set to 0 for manual control.
-
- NAME: autogain
- TYPE: integer (Boolean)
- DEFAULT: 1
- DESC: Auto Gain Control enable. This feature is not yet implemented.
-
- NAME: autoexp
- TYPE: integer (Boolean)
- DEFAULT: 1
- DESC: Auto Exposure Control enable. This feature is not yet implemented.
-
- NAME: debug
- TYPE: integer (0-6)
- DEFAULT: 3
- DESC: Sets the threshold for printing debug messages. The higher the value,
- the more is printed. The levels are cumulative, and are as follows:
- 0=no debug messages
- 1=init/detection/unload and other significant messages
- 2=some warning messages
- 3=config/control function calls
- 4=most function calls and data parsing messages
- 5=highly repetitive mesgs
-
- NAME: snapshot
- TYPE: integer (Boolean)
- DEFAULT: 0
- DESC: Set to 1 to enable snapshot mode. read()/VIDIOCSYNC will block until
- the snapshot button is pressed. Note: enabling this mode disables
- /proc/video/ov511/<minor#>/button
-
- NAME: cams
- TYPE: integer (1-4 for OV511, 1-31 for OV511+)
- DEFAULT: 1
- DESC: Number of cameras allowed to stream simultaneously on a single bus.
- Values higher than 1 reduce the data rate of each camera, allowing two
- or more to be used at once. If you have a complicated setup involving
- both OV511 and OV511+ cameras, trial-and-error may be necessary for
- finding the optimum setting.
-
- NAME: compress
- TYPE: integer (Boolean)
- DEFAULT: 0
- DESC: Set this to 1 to turn on the camera's compression engine. This can
- potentially increase the frame rate at the expense of quality, if you
- have a fast CPU. You must load the proper compression module for your
- camera before starting your application (ov511_decomp or ov518_decomp).
-
- NAME: testpat
- TYPE: integer (Boolean)
- DEFAULT: 0
- DESC: This configures the camera's sensor to transmit a colored test-pattern
- instead of an image. This does not work correctly yet.
-
- NAME: dumppix
- TYPE: integer (0-2)
- DEFAULT: 0
- DESC: Dumps raw pixel data and skips post-processing and format conversion.
- It is for debugging purposes only. Options are:
- 0: Disable (default)
- 1: Dump raw data from camera, excluding headers and trailers
- 2: Dumps data exactly as received from camera
-
- NAME: led
- TYPE: integer (0-2)
- DEFAULT: 1 (Always on)
- DESC: Controls whether the LED (the little light) on the front of the camera
- is always off (0), always on (1), or only on when driver is open (2).
- This is not supported with the OV511, and might only work with certain
- cameras (ones that actually have the LED wired to the control pin, and
- not just hard-wired to be on all the time).
-
- NAME: dump_bridge
- TYPE: integer (Boolean)
- DEFAULT: 0
- DESC: Dumps the bridge (OV511[+] or OV518[+]) register values to the system
- log. Only useful for serious debugging/development purposes.
-
- NAME: dump_sensor
- TYPE: integer (Boolean)
- DEFAULT: 0
- DESC: Dumps the sensor register values to the system log. Only useful for
- serious debugging/development purposes.
-
- NAME: printph
- TYPE: integer (Boolean)
- DEFAULT: 0
- DESC: Setting this to 1 will dump the first 12 bytes of each isoc frame. This
- is only useful if you are trying to debug problems with the isoc data
- stream (i.e.: camera initializes, but vidcat hangs until Ctrl-C). Be
- warned that this dumps a large number of messages to your kernel log.
-
- NAME: phy, phuv, pvy, pvuv, qhy, qhuv, qvy, qvuv
- TYPE: integer (0-63 for phy and phuv, 0-255 for rest)
- DEFAULT: OV511 default values
- DESC: These are registers 70h - 77h of the OV511, which control the
- prediction ranges and quantization thresholds of the compressor, for
- the Y and UV channels in the horizontal and vertical directions. See
- the OV511 or OV511+ data sheet for more detailed descriptions. These
- normally do not need to be changed.
-
- NAME: lightfreq
- TYPE: integer (0, 50, or 60)
- DEFAULT: 0 (use sensor default)
- DESC: Sets the sensor to match your lighting frequency. This can reduce the
- appearance of "banding", i.e. horizontal lines or waves of light and
- dark that are often caused by artificial lighting. Valid values are:
- 0 - Use default (depends on sensor, most likely 60 Hz)
- 50 - For European and Asian 50 Hz power
- 60 - For American 60 Hz power
-
- NAME: bandingfilter
- TYPE: integer (Boolean)
- DEFAULT: 0 (off)
- DESC: Enables the sensor´s banding filter exposure algorithm. This reduces
- or stabilizes the "banding" caused by some artificial light sources
- (especially fluorescent). You might have to set lightfreq correctly for
- this to work right. As an added bonus, this sometimes makes it
- possible to capture your monitor´s output.
-
- NAME: fastset
- TYPE: integer (Boolean)
- DEFAULT: 0 (off)
- DESC: Allows picture settings (brightness, contrast, color, and hue) to take
- effect immediately, even in the middle of a frame. This reduces the
- time to change settings, but can ruin frames during the change. Only
- affects OmniVision sensors.
-
- NAME: force_palette
- TYPE: integer (Boolean)
- DEFAULT: 0 (off)
- DESC: Forces the palette (color format) to a specific value. If an
- application requests a different palette, it will be rejected, thereby
- forcing it to try others until it succeeds. This is useful for forcing
- greyscale mode with a color camera, for example. Supported modes are:
- 0 (Allows all the following formats)
- 1 VIDEO_PALETTE_GREY (Linear greyscale)
- 10 VIDEO_PALETTE_YUV420 (YUV 4:2:0 Planar)
- 15 VIDEO_PALETTE_YUV420P (YUV 4:2:0 Planar, same as 10)
-
- NAME: backlight
- TYPE: integer (Boolean)
- DEFAULT: 0 (off)
- DESC: Setting this flag changes the exposure algorithm for OmniVision sensors
- such that objects in the camera's view (i.e. your head) can be clearly
- seen when they are illuminated from behind. It reduces or eliminates
- the sensor's auto-exposure function, so it should only be used when
- needed. Additionally, it is only supported with the OV6620 and OV7620.
-
- NAME: unit_video
- TYPE: Up to 16 comma-separated integers
- DEFAULT: 0,0,0... (automatically assign the next available minor(s))
- DESC: You can specify up to 16 minor numbers to be assigned to ov511 devices.
- For example, "unit_video=1,3" will make the driver use /dev/video1 and
- /dev/video3 for the first two devices it detects. Additional devices
- will be assigned automatically starting at the first available device
- node (/dev/video0 in this case). Note that you cannot specify 0 as a
- minor number. This feature requires kernel version 2.4.5 or higher.
-
- NAME: remove_zeros
- TYPE: integer (Boolean)
- DEFAULT: 0 (do not skip any incoming data)
- DESC: Setting this to 1 will remove zero-padding from incoming data. This
- will compensate for the blocks of corruption that can appear when the
- camera cannot keep up with the speed of the USB bus (eg. at low frame
- resolutions). This feature is always enabled when compression is on.
-
- NAME: mirror
- TYPE: integer (Boolean)
- DEFAULT: 0 (off)
- DESC: Setting this to 1 will reverse ("mirror") the image horizontally. This
- might be necessary if your camera has a custom lens assembly. This has
- no effect with video capture devices.
-
- NAME: ov518_color
- TYPE: integer (Boolean)
- DEFAULT: 0 (off)
- DESC: Enable OV518 color support. This is off by default since it doesn't
- work most of the time. If you want to try it, you must also load
- ov518_decomp with the "nouv=0" parameter. If you get improper colors or
- diagonal lines through the image, restart your video app and try again.
- Repeat as necessary.
-
-WORKING FEATURES:
- o Color streaming/capture at most widths and heights that are multiples of 8.
- o Monochrome (use force_palette=1 to enable)
- o Setting/getting of saturation, contrast, brightness, and hue (only some of
- them work the OV7620 and OV7620AE)
- o /proc status reporting
- o SAA7111A video capture support at 320x240 and 640x480
- o Compression support
- o SMP compatibility
-
-HOW TO CONTACT ME:
-
-You can email me at mark@alpha.dyndns.org . Please prefix the subject line
-with "OV511: " so that I am certain to notice your message.
-
-CREDITS:
-
-The code is based in no small part on the CPiA driver by Johannes Erdfelt,
-Randy Dunlap, and others. Big thanks to them for their pioneering work on that
-and the USB stack. Thanks to Bret Wallach for getting camera reg IO, ISOC, and
-image capture working. Thanks to Orion Sky Lawlor, Kevin Moore, and Claudio
-Matsuoka for their work as well.
diff --git a/Documentation/video4linux/se401.txt b/Documentation/video4linux/se401.txt
deleted file mode 100644
index bd6526e..0000000
--- a/Documentation/video4linux/se401.txt
+++ /dev/null
@@ -1,54 +0,0 @@
-Linux driver for SE401 based USB cameras
-
-Copyright, 2001, Jeroen Vreeken
-
-
-INTRODUCTION:
-
-The SE401 chip is the used in low-cost usb webcams.
-It is produced by Endpoints Inc. (www.endpoints.com).
-It interfaces directly to a cmos image sensor and USB. The only other major
-part in a se401 based camera is a dram chip.
-
-The following cameras are known to work with this driver:
-
-Aox se401 (non-branded) cameras
-Philips PVCV665 USB VGA webcam 'Vesta Fun'
-Kensington VideoCAM PC Camera Model 67014
-Kensington VideoCAM PC Camera Model 67015
-Kensington VideoCAM PC Camera Model 67016
-Kensington VideoCAM PC Camera Model 67017
-
-
-WHAT YOU NEED:
-
-- USB support
-- VIDEO4LINUX support
-
-More information about USB support for linux can be found at:
-http://www.linux-usb.org
-
-
-MODULE OPTIONS:
-
-When the driver is compiled as a module you can also use the 'flickerless'
-option. With it exposure is limited to values that do not interfere with the
-net frequency. Valid options for this option are 0, 50 and 60. (0=disable,
-50=50hz, 60=60hz)
-
-
-KNOWN PROBLEMS:
-
-The driver works fine with the usb-ohci and uhci host controller drivers,
-the default settings also work with usb-uhci. But sending more than one bulk
-transfer at a time with usb-uhci doesn't work yet.
-Users of usb-ohci and uhci can safely enlarge SE401_NUMSBUF in se401.h in
-order to increase the throughput (and thus framerate).
-
-
-HELP:
-
-The latest info on this driver can be found at:
-http://members.chello.nl/~j.vreeken/se401/
-And questions to me can be send to:
-pe1rxq@amsat.org
diff --git a/Documentation/video4linux/si470x.txt b/Documentation/video4linux/si470x.txt
index 3a7823e..98c3292 100644
--- a/Documentation/video4linux/si470x.txt
+++ b/Documentation/video4linux/si470x.txt
@@ -53,6 +53,9 @@
- kradio - Comfortable Radio Application for KDE
- radio - ncurses-based radio application
- mplayer - The Ultimate Movie Player For Linux
+- v4l2-ctl - Collection of command line video4linux utilities
+For example, you can use:
+v4l2-ctl -d /dev/radio0 --set-ctrl=volume=10,mute=0 --set-freq=95.21 --all
There is also a library libv4l, which can be used. It's going to have a function
for frequency seeking, either by using hardware functionality as in radio-si470x
@@ -75,8 +78,10 @@
If you just want to test audio (very poor quality):
cat /dev/dsp1 > /dev/dsp
-If you use OSS try:
+If you use sox + OSS try:
sox -2 --endian little -r 96000 -t oss /dev/dsp1 -t oss /dev/dsp
+or using sox + alsa:
+sox --endian little -c 2 -S -r 96000 -t alsa hw:1 -t alsa -r 96000 hw:0
If you use arts try:
arecord -D hw:1,0 -r96000 -c2 -f S16_LE | artsdsp aplay -B -
diff --git a/Documentation/video4linux/si476x.txt b/Documentation/video4linux/si476x.txt
new file mode 100644
index 0000000..2f9b487
--- /dev/null
+++ b/Documentation/video4linux/si476x.txt
@@ -0,0 +1,187 @@
+SI476x Driver Readme
+------------------------------------------------
+ Copyright (C) 2013 Andrey Smirnov <andrew.smirnov@gmail.com>
+
+TODO for the driver
+------------------------------
+
+- According to the SiLabs' datasheet it is possible to update the
+ firmware of the radio chip in the run-time, thus bringing it to the
+ most recent version. Unfortunately I couldn't find any mentioning of
+ the said firmware update for the old chips that I tested the driver
+ against, so for chips like that the driver only exposes the old
+ functionality.
+
+
+Parameters exposed over debugfs
+-------------------------------
+SI476x allow user to get multiple characteristics that can be very
+useful for EoL testing/RF performance estimation, parameters that have
+very little to do with V4L2 subsystem. Such parameters are exposed via
+debugfs and can be accessed via regular file I/O operations.
+
+The drivers exposes following files:
+
+* /sys/kernel/debug/<device-name>/acf
+ This file contains ACF(Automatically Controlled Features) status
+ information. The contents of the file is binary data of the
+ following layout:
+
+ Offset | Name | Description
+ ====================================================================
+ 0x00 | blend_int | Flag, set when stereo separation has
+ | | crossed below the blend threshold
+ --------------------------------------------------------------------
+ 0x01 | hblend_int | Flag, set when HiBlend cutoff
+ | | frequency is lower than threshold
+ --------------------------------------------------------------------
+ 0x02 | hicut_int | Flag, set when HiCut cutoff
+ | | frequency is lower than threshold
+ --------------------------------------------------------------------
+ 0x03 | chbw_int | Flag, set when channel filter
+ | | bandwidth is less than threshold
+ --------------------------------------------------------------------
+ 0x04 | softmute_int | Flag indicating that softmute
+ | | attenuation has increased above
+ | | softmute threshold
+ --------------------------------------------------------------------
+ 0x05 | smute | 0 - Audio is not soft muted
+ | | 1 - Audio is soft muted
+ --------------------------------------------------------------------
+ 0x06 | smattn | Soft mute attenuation level in dB
+ --------------------------------------------------------------------
+ 0x07 | chbw | Channel filter bandwidth in kHz
+ --------------------------------------------------------------------
+ 0x08 | hicut | HiCut cutoff frequency in units of
+ | | 100Hz
+ --------------------------------------------------------------------
+ 0x09 | hiblend | HiBlend cutoff frequency in units
+ | | of 100 Hz
+ --------------------------------------------------------------------
+ 0x10 | pilot | 0 - Stereo pilot is not present
+ | | 1 - Stereo pilot is present
+ --------------------------------------------------------------------
+ 0x11 | stblend | Stereo blend in %
+ --------------------------------------------------------------------
+
+
+* /sys/kernel/debug/<device-name>/rds_blckcnt
+ This file contains statistics about RDS receptions. It's binary data
+ has the following layout:
+
+ Offset | Name | Description
+ ====================================================================
+ 0x00 | expected | Number of expected RDS blocks
+ --------------------------------------------------------------------
+ 0x02 | received | Number of received RDS blocks
+ --------------------------------------------------------------------
+ 0x04 | uncorrectable | Number of uncorrectable RDS blocks
+ --------------------------------------------------------------------
+
+* /sys/kernel/debug/<device-name>/agc
+ This file contains information about parameters pertaining to
+ AGC(Automatic Gain Control)
+
+ The layout is:
+ Offset | Name | Description
+ ====================================================================
+ 0x00 | mxhi | 0 - FM Mixer PD high threshold is
+ | | not tripped
+ | | 1 - FM Mixer PD high threshold is
+ | | tripped
+ --------------------------------------------------------------------
+ 0x01 | mxlo | ditto for FM Mixer PD low
+ --------------------------------------------------------------------
+ 0x02 | lnahi | ditto for FM LNA PD high
+ --------------------------------------------------------------------
+ 0x03 | lnalo | ditto for FM LNA PD low
+ --------------------------------------------------------------------
+ 0x04 | fmagc1 | FMAGC1 attenuator resistance
+ | | (see datasheet for more detail)
+ --------------------------------------------------------------------
+ 0x05 | fmagc2 | ditto for FMAGC2
+ --------------------------------------------------------------------
+ 0x06 | pgagain | PGA gain in dB
+ --------------------------------------------------------------------
+ 0x07 | fmwblang | FM/WB LNA Gain in dB
+ --------------------------------------------------------------------
+
+* /sys/kernel/debug/<device-name>/rsq
+ This file contains information about parameters pertaining to
+ RSQ(Received Signal Quality)
+
+ The layout is:
+ Offset | Name | Description
+ ====================================================================
+ 0x00 | multhint | 0 - multipath value has not crossed
+ | | the Multipath high threshold
+ | | 1 - multipath value has crossed
+ | | the Multipath high threshold
+ --------------------------------------------------------------------
+ 0x01 | multlint | ditto for Multipath low threshold
+ --------------------------------------------------------------------
+ 0x02 | snrhint | 0 - received signal's SNR has not
+ | | crossed high threshold
+ | | 1 - received signal's SNR has
+ | | crossed high threshold
+ --------------------------------------------------------------------
+ 0x03 | snrlint | ditto for low threshold
+ --------------------------------------------------------------------
+ 0x04 | rssihint | ditto for RSSI high threshold
+ --------------------------------------------------------------------
+ 0x05 | rssilint | ditto for RSSI low threshold
+ --------------------------------------------------------------------
+ 0x06 | bltf | Flag indicating if seek command
+ | | reached/wrapped seek band limit
+ --------------------------------------------------------------------
+ 0x07 | snr_ready | Indicates that SNR metrics is ready
+ --------------------------------------------------------------------
+ 0x08 | rssiready | ditto for RSSI metrics
+ --------------------------------------------------------------------
+ 0x09 | injside | 0 - Low-side injection is being used
+ | | 1 - High-side injection is used
+ --------------------------------------------------------------------
+ 0x10 | afcrl | Flag indicating if AFC rails
+ --------------------------------------------------------------------
+ 0x11 | valid | Flag indicating if channel is valid
+ --------------------------------------------------------------------
+ 0x12 | readfreq | Current tuned frequency
+ --------------------------------------------------------------------
+ 0x14 | freqoff | Singed frequency offset in units of
+ | | 2ppm
+ --------------------------------------------------------------------
+ 0x15 | rssi | Signed value of RSSI in dBuV
+ --------------------------------------------------------------------
+ 0x16 | snr | Signed RF SNR in dB
+ --------------------------------------------------------------------
+ 0x17 | issi | Signed Image Strength Signal
+ | | indicator
+ --------------------------------------------------------------------
+ 0x18 | lassi | Signed Low side adjacent Channel
+ | | Strength indicator
+ --------------------------------------------------------------------
+ 0x19 | hassi | ditto fpr High side
+ --------------------------------------------------------------------
+ 0x20 | mult | Multipath indicator
+ --------------------------------------------------------------------
+ 0x21 | dev | Frequency deviation
+ --------------------------------------------------------------------
+ 0x24 | assi | Adjacent channel SSI
+ --------------------------------------------------------------------
+ 0x25 | usn | Ultrasonic noise indicator
+ --------------------------------------------------------------------
+ 0x26 | pilotdev | Pilot deviation in units of 100 Hz
+ --------------------------------------------------------------------
+ 0x27 | rdsdev | ditto for RDS
+ --------------------------------------------------------------------
+ 0x28 | assidev | ditto for ASSI
+ --------------------------------------------------------------------
+ 0x29 | strongdev | Frequency deviation
+ --------------------------------------------------------------------
+ 0x30 | rdspi | RDS PI code
+ --------------------------------------------------------------------
+
+* /sys/kernel/debug/<device-name>/rsq_primary
+ This file contains information about parameters pertaining to
+ RSQ(Received Signal Quality) for primary tuner only. Layout is as
+ the one above.
diff --git a/Documentation/video4linux/soc-camera.txt b/Documentation/video4linux/soc-camera.txt
index 3f87c7d..daa9e2a 100644
--- a/Documentation/video4linux/soc-camera.txt
+++ b/Documentation/video4linux/soc-camera.txt
@@ -9,32 +9,36 @@
of connecting to a variety of systems and interfaces, typically uses i2c for
control and configuration, and a parallel or a serial bus for data.
- camera host - an interface, to which a camera is connected. Typically a
- specialised interface, present on many SoCs, e.g., PXA27x and PXA3xx, SuperH,
+ specialised interface, present on many SoCs, e.g. PXA27x and PXA3xx, SuperH,
AVR32, i.MX27, i.MX31.
- camera host bus - a connection between a camera host and a camera. Can be
- parallel or serial, consists of data and control lines, e.g., clock, vertical
+ parallel or serial, consists of data and control lines, e.g. clock, vertical
and horizontal synchronization signals.
Purpose of the soc-camera subsystem
-----------------------------------
-The soc-camera subsystem provides a unified API between camera host drivers and
-camera sensor drivers. It implements a V4L2 interface to the user, currently
-only the mmap method is supported.
+The soc-camera subsystem initially provided a unified API between camera host
+drivers and camera sensor drivers. Later the soc-camera sensor API has been
+replaced with the V4L2 standard subdev API. This also made camera driver re-use
+with non-soc-camera hosts possible. The camera host API to the soc-camera core
+has been preserved.
-This subsystem has been written to connect drivers for System-on-Chip (SoC)
-video capture interfaces with drivers for CMOS camera sensor chips to enable
-the reuse of sensor drivers with various hosts. The subsystem has been designed
-to support multiple camera host interfaces and multiple cameras per interface,
-although most applications have only one camera sensor.
+Soc-camera implements a V4L2 interface to the user, currently only the "mmap"
+method is supported by host drivers. However, the soc-camera core also provides
+support for the "read" method.
+
+The subsystem has been designed to support multiple camera host interfaces and
+multiple cameras per interface, although most applications have only one camera
+sensor.
Existing drivers
----------------
-As of 2.6.27-rc4 there are two host drivers in the mainline: pxa_camera.c for
-PXA27x SoCs and sh_mobile_ceu_camera.c for SuperH SoCs, and four sensor drivers:
-mt9m001.c, mt9m111.c, mt9v022.c and a generic soc_camera_platform.c driver. This
-list is not supposed to be updated, look for more examples in your tree.
+As of 3.7 there are seven host drivers in the mainline: atmel-isi.c,
+mx1_camera.c (broken, scheduled for removal), mx2_camera.c, mx3_camera.c,
+omap1_camera.c, pxa_camera.c, sh_mobile_ceu_camera.c, and multiple sensor
+drivers under drivers/media/i2c/soc_camera/.
Camera host API
---------------
@@ -45,38 +49,37 @@
function. The host object can be initialized as follows:
-static struct soc_camera_host pxa_soc_camera_host = {
- .drv_name = PXA_CAM_DRV_NAME,
- .ops = &pxa_soc_camera_host_ops,
-};
+ struct soc_camera_host *ici;
+ ici->drv_name = DRV_NAME;
+ ici->ops = &camera_host_ops;
+ ici->priv = pcdev;
+ ici->v4l2_dev.dev = &pdev->dev;
+ ici->nr = pdev->id;
All camera host methods are passed in a struct soc_camera_host_ops:
-static struct soc_camera_host_ops pxa_soc_camera_host_ops = {
+static struct soc_camera_host_ops camera_host_ops = {
.owner = THIS_MODULE,
- .add = pxa_camera_add_device,
- .remove = pxa_camera_remove_device,
- .suspend = pxa_camera_suspend,
- .resume = pxa_camera_resume,
- .set_fmt_cap = pxa_camera_set_fmt_cap,
- .try_fmt_cap = pxa_camera_try_fmt_cap,
- .init_videobuf = pxa_camera_init_videobuf,
- .reqbufs = pxa_camera_reqbufs,
- .poll = pxa_camera_poll,
- .querycap = pxa_camera_querycap,
- .try_bus_param = pxa_camera_try_bus_param,
- .set_bus_param = pxa_camera_set_bus_param,
+ .add = camera_add_device,
+ .remove = camera_remove_device,
+ .set_fmt = camera_set_fmt_cap,
+ .try_fmt = camera_try_fmt_cap,
+ .init_videobuf2 = camera_init_videobuf2,
+ .poll = camera_poll,
+ .querycap = camera_querycap,
+ .set_bus_param = camera_set_bus_param,
+ /* The rest of host operations are optional */
};
.add and .remove methods are called when a sensor is attached to or detached
-from the host, apart from performing host-internal tasks they shall also call
-sensor driver's .init and .release methods respectively. .suspend and .resume
-methods implement host's power-management functionality and its their
-responsibility to call respective sensor's methods. .try_bus_param and
-.set_bus_param are used to negotiate physical connection parameters between the
-host and the sensor. .init_videobuf is called by soc-camera core when a
-video-device is opened, further video-buffer management is implemented completely
-by the specific camera host driver. The rest of the methods are called from
+from the host. .set_bus_param is used to configure physical connection
+parameters between the host and the sensor. .init_videobuf2 is called by
+soc-camera core when a video-device is opened, the host driver would typically
+call vb2_queue_init() in this method. Further video-buffer management is
+implemented completely by the specific camera host driver. If the host driver
+supports non-standard pixel format conversion, it should implement a
+.get_formats and, possibly, a .put_formats operations. See below for more
+details about format conversion. The rest of the methods are called from
respective V4L2 operations.
Camera API
@@ -84,37 +87,21 @@
Sensor drivers can use struct soc_camera_link, typically provided by the
platform, and used to specify to which camera host bus the sensor is connected,
-and arbitrarily provide platform .power and .reset methods for the camera.
-soc_camera_device_register() and soc_camera_device_unregister() functions are
-used to add a sensor driver to or remove one from the system. The registration
-function takes a pointer to struct soc_camera_device as the only parameter.
-This struct can be initialized as follows:
-
- /* link to driver operations */
- icd->ops = &mt9m001_ops;
- /* link to the underlying physical (e.g., i2c) device */
- icd->control = &client->dev;
- /* window geometry */
- icd->x_min = 20;
- icd->y_min = 12;
- icd->x_current = 20;
- icd->y_current = 12;
- icd->width_min = 48;
- icd->width_max = 1280;
- icd->height_min = 32;
- icd->height_max = 1024;
- icd->y_skip_top = 1;
- /* camera bus ID, typically obtained from platform data */
- icd->iface = icl->bus_id;
-
-struct soc_camera_ops provides .probe and .remove methods, which are called by
-the soc-camera core, when a camera is matched against or removed from a camera
-host bus, .init, .release, .suspend, and .resume are called from the camera host
-driver as discussed above. Other members of this struct provide respective V4L2
-functionality.
-
-struct soc_camera_device also links to an array of struct soc_camera_data_format,
-listing pixel formats, supported by the camera.
+and optionally provide platform .power and .reset methods for the camera. This
+struct is provided to the camera driver via the I2C client device platform data
+and can be obtained, using the soc_camera_i2c_to_link() macro. Care should be
+taken, when using soc_camera_vdev_to_subdev() and when accessing struct
+soc_camera_device, using v4l2_get_subdev_hostdata(): both only work, when
+running on an soc-camera host. The actual camera driver operation is implemented
+using the V4L2 subdev API. Additionally soc-camera camera drivers can use
+auxiliary soc-camera helper functions like soc_camera_power_on() and
+soc_camera_power_off(), which switch regulators, provided by the platform and call
+board-specific power switching methods. soc_camera_apply_board_flags() takes
+camera bus configuration capability flags and applies any board transformations,
+e.g. signal polarity inversion. soc_mbus_get_fmtdesc() can be used to obtain a
+pixel format descriptor, corresponding to a certain media-bus pixel format code.
+soc_camera_limit_side() can be used to restrict beginning and length of a frame
+side, based on camera capabilities.
VIDIOC_S_CROP and VIDIOC_S_FMT behaviour
----------------------------------------
@@ -129,7 +116,7 @@
much as possible by modifying scaling factors. If the sensor window cannot be
preserved precisely, it may be changed too.
-In soc-camera there are two locations, where scaling and cropping can taks
+In soc-camera there are two locations, where scaling and cropping can take
place: in the camera driver and in the host driver. User ioctls are first passed
to the host driver, which then generally passes them down to the camera driver.
It is more efficient to perform scaling and cropping in the camera driver to
@@ -153,8 +140,25 @@
User window geometry is kept in .user_width and .user_height fields in struct
soc_camera_device and used by the soc-camera core and host drivers. The core
updates these fields upon successful completion of a .s_fmt() call, but if these
-fields change elsewhere, e.g., during .s_crop() processing, the host driver is
+fields change elsewhere, e.g. during .s_crop() processing, the host driver is
responsible for updating them.
+Format conversion
+-----------------
+
+V4L2 distinguishes between pixel formats, as they are stored in memory, and as
+they are transferred over a media bus. Soc-camera provides support to
+conveniently manage these formats. A table of standard transformations is
+maintained by soc-camera core, which describes, what FOURCC pixel format will
+be obtained, if a media-bus pixel format is stored in memory according to
+certain rules. E.g. if V4L2_MBUS_FMT_YUYV8_2X8 data is sampled with 8 bits per
+sample and stored in memory in the little-endian order with no gaps between
+bytes, data in memory will represent the V4L2_PIX_FMT_YUYV FOURCC format. These
+standard transformations will be used by soc-camera or by camera host drivers to
+configure camera drivers to produce the FOURCC format, requested by the user,
+using the VIDIOC_S_FMT ioctl(). Apart from those standard format conversions,
+host drivers can also provide their own conversion rules by implementing a
+.get_formats and, if required, a .put_formats methods.
+
--
Author: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
diff --git a/Documentation/video4linux/stv680.txt b/Documentation/video4linux/stv680.txt
deleted file mode 100644
index e3de336..0000000
--- a/Documentation/video4linux/stv680.txt
+++ /dev/null
@@ -1,53 +0,0 @@
-Linux driver for STV0680 based USB cameras
-
-Copyright, 2001, Kevin Sisson
-
-
-INTRODUCTION:
-
-STMicroelectronics produces the STV0680B chip, which comes in two
-types, -001 and -003. The -003 version allows the recording and downloading
-of sound clips from the camera, and allows a flash attachment. Otherwise,
-it uses the same commands as the -001 version. Both versions support a
-variety of SDRAM sizes and sensors, allowing for a maximum of 26 VGA or 20
-CIF pictures. The STV0680 supports either a serial or a usb interface, and
-video is possible through the usb interface.
-
-The following cameras are known to work with this driver, although any
-camera with Vendor/Product codes of 0553/0202 should work:
-
-Aiptek Pencam (various models)
-Nisis QuickPix 2
-Radio Shack 'Kid's digital camera' (#60-1207)
-At least one Trust Spycam model
-Several other European brand models
-
-WHAT YOU NEED:
-
-- USB support
-- VIDEO4LINUX support
-
-More information about USB support for linux can be found at:
-http://www.linux-usb.org
-
-
-MODULE OPTIONS:
-
-When the driver is compiled as a module, you can set a "swapRGB=1"
-option, if necessary, for those applications that require it
-(such as xawtv). However, the driver should detect and set this
-automatically, so this option should not normally be used.
-
-
-KNOWN PROBLEMS:
-
-The driver seems to work better with the usb-ohci than the usb-uhci host
-controller driver.
-
-HELP:
-
-The latest info on this driver can be found at:
-http://personal.clt.bellsouth.net/~kjsisson or at
-http://stv0680-usb.sourceforge.net
-
-Any questions to me can be send to: kjsisson@bellsouth.net
diff --git a/Documentation/video4linux/v4l2-controls.txt b/Documentation/video4linux/v4l2-controls.txt
index cfe52c7..676f873 100644
--- a/Documentation/video4linux/v4l2-controls.txt
+++ b/Documentation/video4linux/v4l2-controls.txt
@@ -715,14 +715,20 @@
class is added.
-Proposals for Extensions
-========================
+Adding Notify Callbacks
+=======================
-Some ideas for future extensions to the spec:
+Sometimes the platform or bridge driver needs to be notified when a control
+from a sub-device driver changes. You can set a notify callback by calling
+this function:
-1) Add a V4L2_CTRL_FLAG_HEX to have values shown as hexadecimal instead of
-decimal. Useful for e.g. video_mute_yuv.
+void v4l2_ctrl_notify(struct v4l2_ctrl *ctrl,
+ void (*notify)(struct v4l2_ctrl *ctrl, void *priv), void *priv);
-2) It is possible to mark in the controls array which controls have been
-successfully written and which failed by for example adding a bit to the
-control ID. Not sure if it is worth the effort, though.
+Whenever the give control changes value the notify callback will be called
+with a pointer to the control and the priv pointer that was passed with
+v4l2_ctrl_notify. Note that the control's handler lock is held when the
+notify function is called.
+
+There can be only one notify function per control handler. Any attempt
+to set another notify function will cause a WARN_ON.
diff --git a/Documentation/video4linux/v4l2-framework.txt b/Documentation/video4linux/v4l2-framework.txt
index 32bfe92..6c4866b 100644
--- a/Documentation/video4linux/v4l2-framework.txt
+++ b/Documentation/video4linux/v4l2-framework.txt
@@ -68,8 +68,7 @@
The framework closely resembles the driver structure: it has a v4l2_device
struct for the device instance data, a v4l2_subdev struct to refer to
sub-device instances, the video_device struct stores V4L2 device node data
-and in the future a v4l2_fh struct will keep track of filehandle instances
-(this is not yet implemented).
+and the v4l2_fh struct keeps track of filehandle instances.
The V4L2 framework also optionally integrates with the media framework. If a
driver sets the struct v4l2_device mdev field, sub-devices and video nodes
@@ -174,8 +173,7 @@
static atomic_t drv_instance = ATOMIC_INIT(0);
-static int __devinit drv_probe(struct pci_dev *pdev,
- const struct pci_device_id *pci_id)
+static int drv_probe(struct pci_dev *pdev, const struct pci_device_id *pci_id)
{
...
state->instance = atomic_inc_return(&drv_instance) - 1;
@@ -248,7 +246,6 @@
It looks like this:
struct v4l2_subdev_core_ops {
- int (*g_chip_ident)(struct v4l2_subdev *sd, struct v4l2_dbg_chip_ident *chip);
int (*log_status)(struct v4l2_subdev *sd);
int (*init)(struct v4l2_subdev *sd, u32 val);
...
@@ -328,8 +325,27 @@
sink of the link. Subdev drivers are also free to use this function to
perform the checks mentioned above in addition to their own checks.
-A device (bridge) driver needs to register the v4l2_subdev with the
-v4l2_device:
+There are currently two ways to register subdevices with the V4L2 core. The
+first (traditional) possibility is to have subdevices registered by bridge
+drivers. This can be done when the bridge driver has the complete information
+about subdevices connected to it and knows exactly when to register them. This
+is typically the case for internal subdevices, like video data processing units
+within SoCs or complex PCI(e) boards, camera sensors in USB cameras or connected
+to SoCs, which pass information about them to bridge drivers, usually in their
+platform data.
+
+There are however also situations where subdevices have to be registered
+asynchronously to bridge devices. An example of such a configuration is a Device
+Tree based system where information about subdevices is made available to the
+system independently from the bridge devices, e.g. when subdevices are defined
+in DT as I2C device nodes. The API used in this second case is described further
+below.
+
+Using one or the other registration method only affects the probing process, the
+run-time bridge-subdevice interaction is in both cases the same.
+
+In the synchronous case a device (bridge) driver needs to register the
+v4l2_subdev with the v4l2_device:
int err = v4l2_device_register_subdev(v4l2_dev, sd);
@@ -348,24 +364,24 @@
You can call an ops function either directly:
- err = sd->ops->core->g_chip_ident(sd, &chip);
+ err = sd->ops->core->g_std(sd, &norm);
but it is better and easier to use this macro:
- err = v4l2_subdev_call(sd, core, g_chip_ident, &chip);
+ err = v4l2_subdev_call(sd, core, g_std, &norm);
The macro will to the right NULL pointer checks and returns -ENODEV if subdev
-is NULL, -ENOIOCTLCMD if either subdev->core or subdev->core->g_chip_ident is
-NULL, or the actual result of the subdev->ops->core->g_chip_ident ops.
+is NULL, -ENOIOCTLCMD if either subdev->core or subdev->core->g_std is
+NULL, or the actual result of the subdev->ops->core->g_std ops.
It is also possible to call all or a subset of the sub-devices:
- v4l2_device_call_all(v4l2_dev, 0, core, g_chip_ident, &chip);
+ v4l2_device_call_all(v4l2_dev, 0, core, g_std, &norm);
Any subdev that does not support this ops is skipped and error results are
ignored. If you want to check for errors use this:
- err = v4l2_device_call_until_err(v4l2_dev, 0, core, g_chip_ident, &chip);
+ err = v4l2_device_call_until_err(v4l2_dev, 0, core, g_std, &norm);
Any error except -ENOIOCTLCMD will exit the loop with that error. If no
errors (except -ENOIOCTLCMD) occurred, then 0 is returned.
@@ -396,6 +412,30 @@
up the device, but once the subdev is registered it is completely transparent.
+In the asynchronous case subdevice probing can be invoked independently of the
+bridge driver availability. The subdevice driver then has to verify whether all
+the requirements for a successful probing are satisfied. This can include a
+check for a master clock availability. If any of the conditions aren't satisfied
+the driver might decide to return -EPROBE_DEFER to request further reprobing
+attempts. Once all conditions are met the subdevice shall be registered using
+the v4l2_async_register_subdev() function. Unregistration is performed using
+the v4l2_async_unregister_subdev() call. Subdevices registered this way are
+stored in a global list of subdevices, ready to be picked up by bridge drivers.
+
+Bridge drivers in turn have to register a notifier object with an array of
+subdevice descriptors that the bridge device needs for its operation. This is
+performed using the v4l2_async_notifier_register() call. To unregister the
+notifier the driver has to call v4l2_async_notifier_unregister(). The former of
+the two functions takes two arguments: a pointer to struct v4l2_device and a
+pointer to struct v4l2_async_notifier. The latter contains a pointer to an array
+of pointers to subdevice descriptors of type struct v4l2_async_subdev type. The
+V4L2 core will then use these descriptors to match asynchronously registered
+subdevices to them. If a match is detected the .bound() notifier callback is
+called. After all subdevices have been located the .complete() callback is
+called. When a subdevice is removed from the system the .unbind() method is
+called. All three callbacks are optional.
+
+
V4L2 sub-device userspace API
-----------------------------
@@ -577,9 +617,13 @@
The default video_device_release() callback just calls kfree to free the
allocated memory.
+There is also a video_device_release_empty() function that does nothing
+(is empty) and can be used if the struct is embedded and there is nothing
+to do when it is released.
+
You should also set these fields:
-- v4l2_dev: set to the v4l2_device parent device.
+- v4l2_dev: must be set to the v4l2_device parent device.
- name: set to something descriptive and unique.
@@ -616,15 +660,16 @@
If you want to have a separate priority state per (group of) device node(s),
then you can point it to your own struct v4l2_prio_state.
-- parent: you only set this if v4l2_device was registered with NULL as
+- dev_parent: you only set this if v4l2_device was registered with NULL as
the parent device struct. This only happens in cases where one hardware
device has multiple PCI devices that all share the same v4l2_device core.
The cx88 driver is an example of this: one core v4l2_device struct, but
- it is used by both an raw video PCI device (cx8800) and a MPEG PCI device
- (cx8802). Since the v4l2_device cannot be associated with a particular
- PCI device it is setup without a parent device. But when the struct
- video_device is setup you do know which parent PCI device to use.
+ it is used by both a raw video PCI device (cx8800) and a MPEG PCI device
+ (cx8802). Since the v4l2_device cannot be associated with two PCI devices
+ at the same time it is setup without a parent device. But when the struct
+ video_device is initialized you *do* know which parent PCI device to use and
+ so you set dev_device to the correct PCI device.
- flags: optional. Set to V4L2_FL_USE_FH_PRIO if you want to let the framework
handle the VIDIOC_G/S_PRIORITY ioctls. This requires that you use struct
@@ -1063,3 +1108,29 @@
An example on how the V4L2 events may be used can be found in the OMAP
3 ISP driver (drivers/media/platform/omap3isp).
+
+
+V4L2 clocks
+-----------
+
+Many subdevices, like camera sensors, TV decoders and encoders, need a clock
+signal to be supplied by the system. Often this clock is supplied by the
+respective bridge device. The Linux kernel provides a Common Clock Framework for
+this purpose. However, it is not (yet) available on all architectures. Besides,
+the nature of the multi-functional (clock, data + synchronisation, I2C control)
+connection of subdevices to the system might impose special requirements on the
+clock API usage. E.g. V4L2 has to support clock provider driver unregistration
+while a subdevice driver is holding a reference to the clock. For these reasons
+a V4L2 clock helper API has been developed and is provided to bridge and
+subdevice drivers.
+
+The API consists of two parts: two functions to register and unregister a V4L2
+clock source: v4l2_clk_register() and v4l2_clk_unregister() and calls to control
+a clock object, similar to the respective generic clock API calls:
+v4l2_clk_get(), v4l2_clk_put(), v4l2_clk_enable(), v4l2_clk_disable(),
+v4l2_clk_get_rate(), and v4l2_clk_set_rate(). Clock suppliers have to provide
+clock operations that will be called when clock users invoke respective API
+methods.
+
+It is expected that once the CCF becomes available on all relevant
+architectures this API will be removed.
diff --git a/Documentation/video4linux/w9968cf.txt b/Documentation/video4linux/w9968cf.txt
deleted file mode 100644
index 9649450..0000000
--- a/Documentation/video4linux/w9968cf.txt
+++ /dev/null
@@ -1,458 +0,0 @@
-
- W996[87]CF JPEG USB Dual Mode Camera Chip
- Driver for Linux 2.6 (basic version)
- =========================================
-
- - Documentation -
-
-
-Index
-=====
-1. Copyright
-2. Disclaimer
-3. License
-4. Overview
-5. Supported devices
-6. Module dependencies
-7. Module loading
-8. Module parameters
-9. Contact information
-10. Credits
-
-
-1. Copyright
-============
-Copyright (C) 2002-2004 by Luca Risolia <luca.risolia@studio.unibo.it>
-
-
-2. Disclaimer
-=============
-Winbond is a trademark of Winbond Electronics Corporation.
-This software is not sponsored or developed by Winbond.
-
-
-3. License
-==========
-This program is free software; you can redistribute it and/or modify
-it under the terms of the GNU General Public License as published by
-the Free Software Foundation; either version 2 of the License, or
-(at your option) any later version.
-
-This program is distributed in the hope that it will be useful,
-but WITHOUT ANY WARRANTY; without even the implied warranty of
-MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-GNU General Public License for more details.
-
-You should have received a copy of the GNU General Public License
-along with this program; if not, write to the Free Software
-Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
-
-
-4. Overview
-===========
-This driver supports the video streaming capabilities of the devices mounting
-Winbond W9967CF and Winbond W9968CF JPEG USB Dual Mode Camera Chips. OV681
-based cameras should be supported as well.
-
-The driver is divided into two modules: the basic one, "w9968cf", is needed for
-the supported devices to work; the second one, "w9968cf-vpp", is an optional
-module, which provides some useful video post-processing functions like video
-decoding, up-scaling and colour conversions.
-
-Note that the official kernels do neither include nor support the second
-module for performance purposes. Therefore, it is always recommended to
-download and install the latest and complete release of the driver,
-replacing the existing one, if present.
-
-The latest and full-featured version of the W996[87]CF driver can be found at:
-http://www.linux-projects.org. Please refer to the documentation included in
-that package, if you are going to use it.
-
-Up to 32 cameras can be handled at the same time. They can be connected and
-disconnected from the host many times without turning off the computer, if
-your system supports the hotplug facility.
-
-To change the default settings for each camera, many parameters can be passed
-through command line when the module is loaded into memory.
-
-The driver relies on the Video4Linux, USB and I2C core modules. It has been
-designed to run properly on SMP systems as well. An additional module,
-"ovcamchip", is mandatory; it provides support for some OmniVision image
-sensors connected to the W996[87]CF chips; if found in the system, the module
-will be automatically loaded by default (provided that the kernel has been
-compiled with the automatic module loading option).
-
-
-5. Supported devices
-====================
-At the moment, known W996[87]CF and OV681 based devices are:
-- Aroma Digi Pen VGA Dual Mode ADG-5000 (unknown image sensor)
-- AVerMedia AVerTV USB (SAA7111A, Philips FI1216Mk2 tuner, PT2313L audio chip)
-- Creative Labs Video Blaster WebCam Go (OmniVision OV7610 sensor)
-- Creative Labs Video Blaster WebCam Go Plus (OmniVision OV7620 sensor)
-- Lebon LDC-035A (unknown image sensor)
-- Ezonics EZ-802 EZMega Cam (OmniVision OV8610C sensor)
-- OmniVision OV8610-EDE (OmniVision OV8610 sensor)
-- OPCOM Digi Pen VGA Dual Mode Pen Camera (unknown image sensor)
-- Pretec Digi Pen-II (OmniVision OV7620 sensor)
-- Pretec DigiPen-480 (OmniVision OV8610 sensor)
-
-If you know any other W996[87]CF or OV681 based cameras, please contact me.
-
-The list above does not imply that all those devices work with this driver: up
-until now only webcams that have an image sensor supported by the "ovcamchip"
-module work. Kernel messages will always tell you whether this is case.
-
-Possible external microcontrollers of those webcams are not supported: this
-means that still images cannot be downloaded from the device memory.
-
-Furthermore, it's worth to note that I was only able to run tests on my
-"Creative Labs Video Blaster WebCam Go". Donations of other models, for
-additional testing and full support, would be much appreciated.
-
-
-6. Module dependencies
-======================
-For it to work properly, the driver needs kernel support for Video4Linux, USB
-and I2C, and the "ovcamchip" module for the image sensor. Make sure you are not
-actually using any external "ovcamchip" module, given that the W996[87]CF
-driver depends on the version of the module present in the official kernels.
-
-The following options of the kernel configuration file must be enabled and
-corresponding modules must be compiled:
-
- # Multimedia devices
- #
- CONFIG_VIDEO_DEV=m
-
- # I2C support
- #
- CONFIG_I2C=m
-
-The I2C core module can be compiled statically in the kernel as well.
-
- # OmniVision Camera Chip support
- #
- CONFIG_VIDEO_OVCAMCHIP=m
-
- # USB support
- #
- CONFIG_USB=m
-
-In addition, depending on the hardware being used, only one of the modules
-below is necessary:
-
- # USB Host Controller Drivers
- #
- CONFIG_USB_EHCI_HCD=m
- CONFIG_USB_UHCI_HCD=m
- CONFIG_USB_OHCI_HCD=m
-
-And finally:
-
- # USB Multimedia devices
- #
- CONFIG_USB_W9968CF=m
-
-
-7. Module loading
-=================
-To use the driver, it is necessary to load the "w9968cf" module into memory
-after every other module required.
-
-Loading can be done this way, from root:
-
- [root@localhost home]# modprobe usbcore
- [root@localhost home]# modprobe i2c-core
- [root@localhost home]# modprobe videodev
- [root@localhost home]# modprobe w9968cf
-
-At this point the pertinent devices should be recognized: "dmesg" can be used
-to analyze kernel messages:
-
- [user@localhost home]$ dmesg
-
-There are a lot of parameters the module can use to change the default
-settings for each device. To list every possible parameter with a brief
-explanation about them and which syntax to use, it is recommended to run the
-"modinfo" command:
-
- [root@locahost home]# modinfo w9968cf
-
-
-8. Module parameters
-====================
-Module parameters are listed below:
--------------------------------------------------------------------------------
-Name: ovmod_load
-Type: bool
-Syntax: <0|1>
-Description: Automatic 'ovcamchip' module loading: 0 disabled, 1 enabled.
- If enabled, 'insmod' searches for the required 'ovcamchip'
- module in the system, according to its configuration, and
- loads that module automatically. This action is performed as
- once soon as the 'w9968cf' module is loaded into memory.
-Default: 1
--------------------------------------------------------------------------------
-Name: simcams
-Type: int
-Syntax: <n>
-Description: Number of cameras allowed to stream simultaneously.
- n may vary from 0 to 32.
-Default: 32
--------------------------------------------------------------------------------
-Name: video_nr
-Type: int array (min = 0, max = 32)
-Syntax: <-1|n[,...]>
-Description: Specify V4L minor mode number.
- -1 = use next available
- n = use minor number n
- You can specify up to 32 cameras this way.
- For example:
- video_nr=-1,2,-1 would assign minor number 2 to the second
- recognized camera and use auto for the first one and for every
- other camera.
-Default: -1
--------------------------------------------------------------------------------
-Name: packet_size
-Type: int array (min = 0, max = 32)
-Syntax: <n[,...]>
-Description: Specify the maximum data payload size in bytes for alternate
- settings, for each device. n is scaled between 63 and 1023.
-Default: 1023
--------------------------------------------------------------------------------
-Name: max_buffers
-Type: int array (min = 0, max = 32)
-Syntax: <n[,...]>
-Description: For advanced users.
- Specify the maximum number of video frame buffers to allocate
- for each device, from 2 to 32.
-Default: 2
--------------------------------------------------------------------------------
-Name: double_buffer
-Type: bool array (min = 0, max = 32)
-Syntax: <0|1[,...]>
-Description: Hardware double buffering: 0 disabled, 1 enabled.
- It should be enabled if you want smooth video output: if you
- obtain out of sync. video, disable it, or try to
- decrease the 'clockdiv' module parameter value.
-Default: 1 for every device.
--------------------------------------------------------------------------------
-Name: clamping
-Type: bool array (min = 0, max = 32)
-Syntax: <0|1[,...]>
-Description: Video data clamping: 0 disabled, 1 enabled.
-Default: 0 for every device.
--------------------------------------------------------------------------------
-Name: filter_type
-Type: int array (min = 0, max = 32)
-Syntax: <0|1|2[,...]>
-Description: Video filter type.
- 0 none, 1 (1-2-1) 3-tap filter, 2 (2-3-6-3-2) 5-tap filter.
- The filter is used to reduce noise and aliasing artifacts
- produced by the CCD or CMOS image sensor.
-Default: 0 for every device.
--------------------------------------------------------------------------------
-Name: largeview
-Type: bool array (min = 0, max = 32)
-Syntax: <0|1[,...]>
-Description: Large view: 0 disabled, 1 enabled.
-Default: 1 for every device.
--------------------------------------------------------------------------------
-Name: upscaling
-Type: bool array (min = 0, max = 32)
-Syntax: <0|1[,...]>
-Description: Software scaling (for non-compressed video only):
- 0 disabled, 1 enabled.
- Disable it if you have a slow CPU or you don't have enough
- memory.
-Default: 0 for every device.
-Note: If 'w9968cf-vpp' is not present, this parameter is set to 0.
--------------------------------------------------------------------------------
-Name: decompression
-Type: int array (min = 0, max = 32)
-Syntax: <0|1|2[,...]>
-Description: Software video decompression:
- 0 = disables decompression
- (doesn't allow formats needing decompression).
- 1 = forces decompression
- (allows formats needing decompression only).
- 2 = allows any permitted formats.
- Formats supporting (de)compressed video are YUV422P and
- YUV420P/YUV420 in any resolutions where width and height are
- multiples of 16.
-Default: 2 for every device.
-Note: If 'w9968cf-vpp' is not present, forcing decompression is not
- allowed; in this case this parameter is set to 2.
--------------------------------------------------------------------------------
-Name: force_palette
-Type: int array (min = 0, max = 32)
-Syntax: <0|9|10|13|15|8|7|1|6|3|4|5[,...]>
-Description: Force picture palette.
- In order:
- 0 = Off - allows any of the following formats:
- 9 = UYVY 16 bpp - Original video, compression disabled
- 10 = YUV420 12 bpp - Original video, compression enabled
- 13 = YUV422P 16 bpp - Original video, compression enabled
- 15 = YUV420P 12 bpp - Original video, compression enabled
- 8 = YUVY 16 bpp - Software conversion from UYVY
- 7 = YUV422 16 bpp - Software conversion from UYVY
- 1 = GREY 8 bpp - Software conversion from UYVY
- 6 = RGB555 16 bpp - Software conversion from UYVY
- 3 = RGB565 16 bpp - Software conversion from UYVY
- 4 = RGB24 24 bpp - Software conversion from UYVY
- 5 = RGB32 32 bpp - Software conversion from UYVY
- When not 0, this parameter will override 'decompression'.
-Default: 0 for every device. Initial palette is 9 (UYVY).
-Note: If 'w9968cf-vpp' is not present, this parameter is set to 9.
--------------------------------------------------------------------------------
-Name: force_rgb
-Type: bool array (min = 0, max = 32)
-Syntax: <0|1[,...]>
-Description: Read RGB video data instead of BGR:
- 1 = use RGB component ordering.
- 0 = use BGR component ordering.
- This parameter has effect when using RGBX palettes only.
-Default: 0 for every device.
--------------------------------------------------------------------------------
-Name: autobright
-Type: bool array (min = 0, max = 32)
-Syntax: <0|1[,...]>
-Description: Image sensor automatically changes brightness:
- 0 = no, 1 = yes
-Default: 0 for every device.
--------------------------------------------------------------------------------
-Name: autoexp
-Type: bool array (min = 0, max = 32)
-Syntax: <0|1[,...]>
-Description: Image sensor automatically changes exposure:
- 0 = no, 1 = yes
-Default: 1 for every device.
--------------------------------------------------------------------------------
-Name: lightfreq
-Type: int array (min = 0, max = 32)
-Syntax: <50|60[,...]>
-Description: Light frequency in Hz:
- 50 for European and Asian lighting, 60 for American lighting.
-Default: 50 for every device.
--------------------------------------------------------------------------------
-Name: bandingfilter
-Type: bool array (min = 0, max = 32)
-Syntax: <0|1[,...]>
-Description: Banding filter to reduce effects of fluorescent
- lighting:
- 0 disabled, 1 enabled.
- This filter tries to reduce the pattern of horizontal
- light/dark bands caused by some (usually fluorescent) lighting.
-Default: 0 for every device.
--------------------------------------------------------------------------------
-Name: clockdiv
-Type: int array (min = 0, max = 32)
-Syntax: <-1|n[,...]>
-Description: Force pixel clock divisor to a specific value (for experts):
- n may vary from 0 to 127.
- -1 for automatic value.
- See also the 'double_buffer' module parameter.
-Default: -1 for every device.
--------------------------------------------------------------------------------
-Name: backlight
-Type: bool array (min = 0, max = 32)
-Syntax: <0|1[,...]>
-Description: Objects are lit from behind:
- 0 = no, 1 = yes
-Default: 0 for every device.
--------------------------------------------------------------------------------
-Name: mirror
-Type: bool array (min = 0, max = 32)
-Syntax: <0|1[,...]>
-Description: Reverse image horizontally:
- 0 = no, 1 = yes
-Default: 0 for every device.
--------------------------------------------------------------------------------
-Name: monochrome
-Type: bool array (min = 0, max = 32)
-Syntax: <0|1[,...]>
-Description: The image sensor is monochrome:
- 0 = no, 1 = yes
-Default: 0 for every device.
--------------------------------------------------------------------------------
-Name: brightness
-Type: long array (min = 0, max = 32)
-Syntax: <n[,...]>
-Description: Set picture brightness (0-65535).
- This parameter has no effect if 'autobright' is enabled.
-Default: 31000 for every device.
--------------------------------------------------------------------------------
-Name: hue
-Type: long array (min = 0, max = 32)
-Syntax: <n[,...]>
-Description: Set picture hue (0-65535).
-Default: 32768 for every device.
--------------------------------------------------------------------------------
-Name: colour
-Type: long array (min = 0, max = 32)
-Syntax: <n[,...]>
-Description: Set picture saturation (0-65535).
-Default: 32768 for every device.
--------------------------------------------------------------------------------
-Name: contrast
-Type: long array (min = 0, max = 32)
-Syntax: <n[,...]>
-Description: Set picture contrast (0-65535).
-Default: 50000 for every device.
--------------------------------------------------------------------------------
-Name: whiteness
-Type: long array (min = 0, max = 32)
-Syntax: <n[,...]>
-Description: Set picture whiteness (0-65535).
-Default: 32768 for every device.
--------------------------------------------------------------------------------
-Name: debug
-Type: int
-Syntax: <n>
-Description: Debugging information level, from 0 to 6:
- 0 = none (use carefully)
- 1 = critical errors
- 2 = significant information
- 3 = configuration or general messages
- 4 = warnings
- 5 = called functions
- 6 = function internals
- Level 5 and 6 are useful for testing only, when only one
- device is used.
-Default: 2
--------------------------------------------------------------------------------
-Name: specific_debug
-Type: bool
-Syntax: <0|1>
-Description: Enable or disable specific debugging messages:
- 0 = print messages concerning every level <= 'debug' level.
- 1 = print messages concerning the level indicated by 'debug'.
-Default: 0
--------------------------------------------------------------------------------
-
-
-9. Contact information
-======================
-I may be contacted by e-mail at <luca.risolia@studio.unibo.it>.
-
-I can accept GPG/PGP encrypted e-mail. My GPG key ID is 'FCE635A4'.
-My public 1024-bit key should be available at your keyserver; the fingerprint
-is: '88E8 F32F 7244 68BA 3958 5D40 99DA 5D2A FCE6 35A4'.
-
-
-10. Credits
-==========
-The development would not have proceed much further without having looked at
-the source code of other drivers and without the help of several persons; in
-particular:
-
-- the I2C interface to kernel and high-level image sensor control routines have
- been taken from the OV511 driver by Mark McClelland;
-
-- memory management code has been copied from the bttv driver by Ralph Metzler,
- Marcus Metzler and Gerd Knorr;
-
-- the low-level I2C read function has been written by Frederic Jouault;
-
-- the low-level I2C fast write function has been written by Piotr Czerczak.
diff --git a/Documentation/video4linux/zc0301.txt b/Documentation/video4linux/zc0301.txt
deleted file mode 100644
index b41c83c..0000000
--- a/Documentation/video4linux/zc0301.txt
+++ /dev/null
@@ -1,270 +0,0 @@
-
- ZC0301 and ZC0301P Image Processor and Control Chip
- Driver for Linux
- ===================================================
-
- - Documentation -
-
-
-Index
-=====
-1. Copyright
-2. Disclaimer
-3. License
-4. Overview and features
-5. Module dependencies
-6. Module loading
-7. Module parameters
-8. Supported devices
-9. Notes for V4L2 application developers
-10. Contact information
-11. Credits
-
-
-1. Copyright
-============
-Copyright (C) 2006-2007 by Luca Risolia <luca.risolia@studio.unibo.it>
-
-
-2. Disclaimer
-=============
-This software is not developed or sponsored by Z-Star Microelectronics Corp.
-Trademarks are property of their respective owner.
-
-
-3. License
-==========
-This program is free software; you can redistribute it and/or modify
-it under the terms of the GNU General Public License as published by
-the Free Software Foundation; either version 2 of the License, or
-(at your option) any later version.
-
-This program is distributed in the hope that it will be useful,
-but WITHOUT ANY WARRANTY; without even the implied warranty of
-MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-GNU General Public License for more details.
-
-You should have received a copy of the GNU General Public License
-along with this program; if not, write to the Free Software
-Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
-
-
-4. Overview and features
-========================
-This driver supports the video interface of the devices mounting the ZC0301 or
-ZC0301P Image Processors and Control Chips.
-
-The driver relies on the Video4Linux2 and USB core modules. It has been
-designed to run properly on SMP systems as well.
-
-The latest version of the ZC0301[P] driver can be found at the following URL:
-http://www.linux-projects.org/
-
-Some of the features of the driver are:
-
-- full compliance with the Video4Linux2 API (see also "Notes for V4L2
- application developers" paragraph);
-- available mmap or read/poll methods for video streaming through isochronous
- data transfers;
-- automatic detection of image sensor;
-- video format is standard JPEG;
-- dynamic driver control thanks to various module parameters (see "Module
- parameters" paragraph);
-- up to 64 cameras can be handled at the same time; they can be connected and
- disconnected from the host many times without turning off the computer, if
- the system supports hotplugging;
-
-
-5. Module dependencies
-======================
-For it to work properly, the driver needs kernel support for Video4Linux and
-USB.
-
-The following options of the kernel configuration file must be enabled and
-corresponding modules must be compiled:
-
- # Multimedia devices
- #
- CONFIG_VIDEO_DEV=m
-
- # USB support
- #
- CONFIG_USB=m
-
-In addition, depending on the hardware being used, the modules below are
-necessary:
-
- # USB Host Controller Drivers
- #
- CONFIG_USB_EHCI_HCD=m
- CONFIG_USB_UHCI_HCD=m
- CONFIG_USB_OHCI_HCD=m
-
-The ZC0301 controller also provides a built-in microphone interface. It is
-supported by the USB Audio driver thanks to the ALSA API:
-
- # Sound
- #
- CONFIG_SOUND=y
-
- # Advanced Linux Sound Architecture
- #
- CONFIG_SND=m
-
- # USB devices
- #
- CONFIG_SND_USB_AUDIO=m
-
-And finally:
-
- # V4L USB devices
- #
- CONFIG_USB_ZC0301=m
-
-
-6. Module loading
-=================
-To use the driver, it is necessary to load the "zc0301" module into memory
-after every other module required: "videodev", "v4l2_common", "compat_ioctl32",
-"usbcore" and, depending on the USB host controller you have, "ehci-hcd",
-"uhci-hcd" or "ohci-hcd".
-
-Loading can be done as shown below:
-
- [root@localhost home]# modprobe zc0301
-
-At this point the devices should be recognized. You can invoke "dmesg" to
-analyze kernel messages and verify that the loading process has gone well:
-
- [user@localhost home]$ dmesg
-
-
-7. Module parameters
-====================
-Module parameters are listed below:
--------------------------------------------------------------------------------
-Name: video_nr
-Type: short array (min = 0, max = 64)
-Syntax: <-1|n[,...]>
-Description: Specify V4L2 minor mode number:
- -1 = use next available
- n = use minor number n
- You can specify up to 64 cameras this way.
- For example:
- video_nr=-1,2,-1 would assign minor number 2 to the second
- registered camera and use auto for the first one and for every
- other camera.
-Default: -1
--------------------------------------------------------------------------------
-Name: force_munmap
-Type: bool array (min = 0, max = 64)
-Syntax: <0|1[,...]>
-Description: Force the application to unmap previously mapped buffer memory
- before calling any VIDIOC_S_CROP or VIDIOC_S_FMT ioctl's. Not
- all the applications support this feature. This parameter is
- specific for each detected camera.
- 0 = do not force memory unmapping
- 1 = force memory unmapping (save memory)
-Default: 0
--------------------------------------------------------------------------------
-Name: frame_timeout
-Type: uint array (min = 0, max = 64)
-Syntax: <n[,...]>
-Description: Timeout for a video frame in seconds. This parameter is
- specific for each detected camera. This parameter can be
- changed at runtime thanks to the /sys filesystem interface.
-Default: 2
--------------------------------------------------------------------------------
-Name: debug
-Type: ushort
-Syntax: <n>
-Description: Debugging information level, from 0 to 3:
- 0 = none (use carefully)
- 1 = critical errors
- 2 = significant information
- 3 = more verbose messages
- Level 3 is useful for testing only, when only one device
- is used at the same time. It also shows some information
- about the hardware being detected. This module parameter can be
- changed at runtime thanks to the /sys filesystem interface.
-Default: 2
--------------------------------------------------------------------------------
-
-
-8. Supported devices
-====================
-None of the names of the companies as well as their products will be mentioned
-here. They have never collaborated with the author, so no advertising.
-
-From the point of view of a driver, what unambiguously identify a device are
-its vendor and product USB identifiers. Below is a list of known identifiers of
-devices mounting the ZC0301 Image Processor and Control Chips:
-
-Vendor ID Product ID
---------- ----------
-0x041e 0x4017
-0x041e 0x401c
-0x041e 0x401e
-0x041e 0x401f
-0x041e 0x4022
-0x041e 0x4034
-0x041e 0x4035
-0x041e 0x4036
-0x041e 0x403a
-0x0458 0x7007
-0x0458 0x700c
-0x0458 0x700f
-0x046d 0x08ae
-0x055f 0xd003
-0x055f 0xd004
-0x0ac8 0x0301
-0x0ac8 0x301b
-0x0ac8 0x303b
-0x10fd 0x0128
-0x10fd 0x8050
-0x10fd 0x804e
-
-The list above does not imply that all those devices work with this driver: up
-until now only the ones that mount the following image sensors are supported;
-kernel messages will always tell you whether this is the case:
-
-Model Manufacturer
------ ------------
-PAS202BCB PixArt Imaging, Inc.
-PB-0330 Photobit Corporation
-
-
-9. Notes for V4L2 application developers
-========================================
-This driver follows the V4L2 API specifications. In particular, it enforces two
-rules:
-
-- exactly one I/O method, either "mmap" or "read", is associated with each
-file descriptor. Once it is selected, the application must close and reopen the
-device to switch to the other I/O method;
-
-- although it is not mandatory, previously mapped buffer memory should always
-be unmapped before calling any "VIDIOC_S_CROP" or "VIDIOC_S_FMT" ioctl's.
-The same number of buffers as before will be allocated again to match the size
-of the new video frames, so you have to map the buffers again before any I/O
-attempts on them.
-
-
-10. Contact information
-=======================
-The author may be contacted by e-mail at <luca.risolia@studio.unibo.it>.
-
-GPG/PGP encrypted e-mail's are accepted. The GPG key ID of the author is
-'FCE635A4'; the public 1024-bit key should be available at any keyserver;
-the fingerprint is: '88E8 F32F 7244 68BA 3958 5D40 99DA 5D2A FCE6 35A4'.
-
-
-11. Credits
-===========
-- Information about the chip internals needed to enable the I2C protocol have
- been taken from the documentation of the ZC030x Video4Linux1 driver written
- by Andrew Birkett <andy@nobugs.org>;
-- The initialization values of the ZC0301 controller connected to the PAS202BCB
- and PB-0330 image sensors have been taken from the SPCA5XX driver maintained
- by Michel Xhaard <mxhaard@magic.fr>;
-- Stanislav Lechev donated one camera.
diff --git a/Documentation/virtual/00-INDEX b/Documentation/virtual/00-INDEX
index 924bd46..e952d30 100644
--- a/Documentation/virtual/00-INDEX
+++ b/Documentation/virtual/00-INDEX
@@ -6,6 +6,3 @@
- Kernel Virtual Machine. See also http://linux-kvm.org
uml/
- User Mode Linux, builds/runs Linux kernel as a userspace program.
-virtio.txt
- - Text version of draft virtio spec.
- See http://ozlabs.org/~rusty/virtio-spec
diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
index a4df553..ef925ea 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -219,19 +219,6 @@
single-threaded guest vcpus, it should make all vcpu ids be a multiple
of the number of vcpus per vcore.
-On powerpc using book3s_hv mode, the vcpus are mapped onto virtual
-threads in one or more virtual CPU cores. (This is because the
-hardware requires all the hardware threads in a CPU core to be in the
-same partition.) The KVM_CAP_PPC_SMT capability indicates the number
-of vcpus per virtual core (vcore). The vcore id is obtained by
-dividing the vcpu id by the number of vcpus per vcore. The vcpus in a
-given vcore will always be in the same physical core as each other
-(though that might be a different physical core from time to time).
-Userspace can control the threading (SMT) mode of the guest by its
-allocation of vcpu ids. For example, if userspace wants
-single-threaded guest vcpus, it should make all vcpu ids be a multiple
-of the number of vcpus per vcore.
-
For virtual cpus that have been created with S390 user controlled virtual
machines, the resulting vcpu fd can be memory mapped at page offset
KVM_S390_SIE_PAGE_OFFSET in order to obtain a memory map of the virtual
@@ -293,7 +280,7 @@
4.11 KVM_GET_REGS
Capability: basic
-Architectures: all
+Architectures: all except ARM, arm64
Type: vcpu ioctl
Parameters: struct kvm_regs (out)
Returns: 0 on success, -1 on error
@@ -314,7 +301,7 @@
4.12 KVM_SET_REGS
Capability: basic
-Architectures: all
+Architectures: all except ARM, arm64
Type: vcpu ioctl
Parameters: struct kvm_regs (in)
Returns: 0 on success, -1 on error
@@ -345,7 +332,7 @@
__u64 interrupt_bitmap[(KVM_NR_INTERRUPTS + 63) / 64];
};
-/* ppc -- see arch/powerpc/include/asm/kvm.h */
+/* ppc -- see arch/powerpc/include/uapi/asm/kvm.h */
interrupt_bitmap is a bitmap of pending external interrupts. At most
one bit may be set. This interrupt has been acknowledged by the APIC
@@ -600,7 +587,7 @@
4.24 KVM_CREATE_IRQCHIP
Capability: KVM_CAP_IRQCHIP
-Architectures: x86, ia64
+Architectures: x86, ia64, ARM, arm64
Type: vm ioctl
Parameters: none
Returns: 0 on success, -1 on error
@@ -608,21 +595,40 @@
Creates an interrupt controller model in the kernel. On x86, creates a virtual
ioapic, a virtual PIC (two PICs, nested), and sets up future vcpus to have a
local APIC. IRQ routing for GSIs 0-15 is set to both PIC and IOAPIC; GSI 16-23
-only go to the IOAPIC. On ia64, a IOSAPIC is created.
+only go to the IOAPIC. On ia64, a IOSAPIC is created. On ARM/arm64, a GIC is
+created.
4.25 KVM_IRQ_LINE
Capability: KVM_CAP_IRQCHIP
-Architectures: x86, ia64
+Architectures: x86, ia64, arm, arm64
Type: vm ioctl
Parameters: struct kvm_irq_level
Returns: 0 on success, -1 on error
Sets the level of a GSI input to the interrupt controller model in the kernel.
-Requires that an interrupt controller model has been previously created with
-KVM_CREATE_IRQCHIP. Note that edge-triggered interrupts require the level
-to be set to 1 and then back to 0.
+On some architectures it is required that an interrupt controller model has
+been previously created with KVM_CREATE_IRQCHIP. Note that edge-triggered
+interrupts require the level to be set to 1 and then back to 0.
+
+ARM/arm64 can signal an interrupt either at the CPU level, or at the
+in-kernel irqchip (GIC), and for in-kernel irqchip can tell the GIC to
+use PPIs designated for specific cpus. The irq field is interpreted
+like this:
+
+ bits: | 31 ... 24 | 23 ... 16 | 15 ... 0 |
+ field: | irq_type | vcpu_index | irq_id |
+
+The irq_type field has the following values:
+- irq_type[0]: out-of-kernel GIC: irq_id 0 is IRQ, irq_id 1 is FIQ
+- irq_type[1]: in-kernel GIC: SPI, irq_id between 32 and 1019 (incl.)
+ (the vcpu_index field is ignored)
+- irq_type[2]: in-kernel GIC: PPI, irq_id between 16 and 31 (incl.)
+
+(The irq_id field thus corresponds nicely to the IRQ ID in the ARM GIC specs)
+
+In both cases, level is used to raise/lower the line.
struct kvm_irq_level {
union {
@@ -874,12 +880,12 @@
be identical. This allows large pages in the guest to be backed by large
pages in the host.
-The flags field supports two flag, KVM_MEM_LOG_DIRTY_PAGES, which instructs
-kvm to keep track of writes to memory within the slot. See KVM_GET_DIRTY_LOG
-ioctl. The KVM_CAP_READONLY_MEM capability indicates the availability of the
-KVM_MEM_READONLY flag. When this flag is set for a memory region, KVM only
-allows read accesses. Writes will be posted to userspace as KVM_EXIT_MMIO
-exits.
+The flags field supports two flags: KVM_MEM_LOG_DIRTY_PAGES and
+KVM_MEM_READONLY. The former can be set to instruct KVM to keep track of
+writes to memory within the slot. See KVM_GET_DIRTY_LOG ioctl to know how to
+use it. The latter can be set, if KVM_CAP_READONLY_MEM capability allows it,
+to make a new slot read-only. In this case, writes to this memory will be
+posted to userspace as KVM_EXIT_MMIO exits.
When the KVM_CAP_SYNC_MMU capability is available, changes in the backing of
the memory region are automatically reflected into the guest. For example, an
@@ -913,7 +919,7 @@
4.37 KVM_ENABLE_CAP
Capability: KVM_CAP_ENABLE_CAP
-Architectures: ppc
+Architectures: ppc, s390
Type: vcpu ioctl
Parameters: struct kvm_enable_cap (in)
Returns: 0 on success; -1 on error
@@ -1481,15 +1487,23 @@
__u8 pad[36];
};
+For the special case of virtio-ccw devices on s390, the ioevent is matched
+to a subchannel/virtqueue tuple instead.
+
The following flags are defined:
#define KVM_IOEVENTFD_FLAG_DATAMATCH (1 << kvm_ioeventfd_flag_nr_datamatch)
#define KVM_IOEVENTFD_FLAG_PIO (1 << kvm_ioeventfd_flag_nr_pio)
#define KVM_IOEVENTFD_FLAG_DEASSIGN (1 << kvm_ioeventfd_flag_nr_deassign)
+#define KVM_IOEVENTFD_FLAG_VIRTIO_CCW_NOTIFY \
+ (1 << kvm_ioeventfd_flag_nr_virtio_ccw_notify)
If datamatch flag is set, the event will be signaled only if the written value
to the registered address is equal to datamatch in struct kvm_ioeventfd.
+For virtio-ccw devices, addr contains the subchannel id and datamatch the
+virtqueue index.
+
4.60 KVM_DIRTY_TLB
@@ -1670,7 +1684,7 @@
This ioctl maps the memory at "user_addr" with the length "length" to
the vcpu's address space starting at "vcpu_addr". All parameters need to
-be alligned by 1 megabyte.
+be aligned by 1 megabyte.
4.66 KVM_S390_UCAS_UNMAP
@@ -1690,7 +1704,7 @@
This ioctl unmaps the memory in the vcpu's address space starting at
"vcpu_addr" with the length "length". The field "user_addr" is ignored.
-All parameters need to be alligned by 1 megabyte.
+All parameters need to be aligned by 1 megabyte.
4.67 KVM_S390_VCPU_FAULT
@@ -1774,6 +1788,65 @@
PPC | KVM_REG_PPC_VPA_SLB | 128
PPC | KVM_REG_PPC_VPA_DTL | 128
PPC | KVM_REG_PPC_EPCR | 32
+ PPC | KVM_REG_PPC_EPR | 32
+ PPC | KVM_REG_PPC_TCR | 32
+ PPC | KVM_REG_PPC_TSR | 32
+ PPC | KVM_REG_PPC_OR_TSR | 32
+ PPC | KVM_REG_PPC_CLEAR_TSR | 32
+ PPC | KVM_REG_PPC_MAS0 | 32
+ PPC | KVM_REG_PPC_MAS1 | 32
+ PPC | KVM_REG_PPC_MAS2 | 64
+ PPC | KVM_REG_PPC_MAS7_3 | 64
+ PPC | KVM_REG_PPC_MAS4 | 32
+ PPC | KVM_REG_PPC_MAS6 | 32
+ PPC | KVM_REG_PPC_MMUCFG | 32
+ PPC | KVM_REG_PPC_TLB0CFG | 32
+ PPC | KVM_REG_PPC_TLB1CFG | 32
+ PPC | KVM_REG_PPC_TLB2CFG | 32
+ PPC | KVM_REG_PPC_TLB3CFG | 32
+ PPC | KVM_REG_PPC_TLB0PS | 32
+ PPC | KVM_REG_PPC_TLB1PS | 32
+ PPC | KVM_REG_PPC_TLB2PS | 32
+ PPC | KVM_REG_PPC_TLB3PS | 32
+ PPC | KVM_REG_PPC_EPTCFG | 32
+ PPC | KVM_REG_PPC_ICP_STATE | 64
+
+ARM registers are mapped using the lower 32 bits. The upper 16 of that
+is the register group type, or coprocessor number:
+
+ARM core registers have the following id bit patterns:
+ 0x4020 0000 0010 <index into the kvm_regs struct:16>
+
+ARM 32-bit CP15 registers have the following id bit patterns:
+ 0x4020 0000 000F <zero:1> <crn:4> <crm:4> <opc1:4> <opc2:3>
+
+ARM 64-bit CP15 registers have the following id bit patterns:
+ 0x4030 0000 000F <zero:1> <zero:4> <crm:4> <opc1:4> <zero:3>
+
+ARM CCSIDR registers are demultiplexed by CSSELR value:
+ 0x4020 0000 0011 00 <csselr:8>
+
+ARM 32-bit VFP control registers have the following id bit patterns:
+ 0x4020 0000 0012 1 <regno:12>
+
+ARM 64-bit FP registers have the following id bit patterns:
+ 0x4030 0000 0012 0 <regno:12>
+
+
+arm64 registers are mapped using the lower 32 bits. The upper 16 of
+that is the register group type, or coprocessor number:
+
+arm64 core/FP-SIMD registers have the following id bit patterns. Note
+that the size of the access is variable, as the kvm_regs structure
+contains elements ranging from 32 to 128 bits. The index is a 32bit
+value in the kvm_regs structure seen as a 32bit array.
+ 0x60x0 0000 0010 <index into the kvm_regs struct:16>
+
+arm64 CCSIDR registers are demultiplexed by CSSELR value:
+ 0x6020 0000 0011 00 <csselr:8>
+
+arm64 system registers have the following id bit patterns:
+ 0x6030 0000 0013 <op0:2> <op1:3> <crn:4> <crm:4> <op2:3>
4.69 KVM_GET_ONE_REG
@@ -1916,7 +1989,7 @@
This populates and returns a structure describing the features of
the "Server" class MMU emulation supported by KVM.
-This can in turn be used by userspace to generate the appropariate
+This can in turn be used by userspace to generate the appropriate
device-tree properties for the guest operating system.
The structure contains some global informations, followed by an
@@ -1963,7 +2036,7 @@
The "enc" array is a list which for each of those segment base page
size provides the list of supported actual page sizes (which can be
only larger or equal to the base page size), along with the
-corresponding encoding in the hash PTE. Similarily, the array is
+corresponding encoding in the hash PTE. Similarly, the array is
8 entries sorted by increasing sizes and an entry with a "0" shift
is an empty entry and a terminator:
@@ -2069,6 +2142,14 @@
KVM_S390_INT_SERVICE (vm) - sclp external interrupt; sclp parameter in parm
KVM_S390_INT_EMERGENCY (vcpu) - sigp emergency; source cpu in parm
KVM_S390_INT_EXTERNAL_CALL (vcpu) - sigp external call; source cpu in parm
+KVM_S390_INT_IO(ai,cssid,ssid,schid) (vm) - compound value to indicate an
+ I/O interrupt (ai - adapter interrupt; cssid,ssid,schid - subchannel);
+ I/O interruption parameters in parm (subchannel) and parm64 (intparm,
+ interruption subclass)
+KVM_S390_MCHK (vm, vcpu) - machine check interrupt; cr 14 bits in parm,
+ machine check interrupt code in parm64 (note that
+ machine checks needing further payload are not
+ supported by this ioctl)
Note that the vcpu ioctl is asynchronous to vcpu execution.
@@ -2126,6 +2207,180 @@
written, then `n_invalid' invalid entries, invalidating any previously
valid entries found.
+4.79 KVM_CREATE_DEVICE
+
+Capability: KVM_CAP_DEVICE_CTRL
+Type: vm ioctl
+Parameters: struct kvm_create_device (in/out)
+Returns: 0 on success, -1 on error
+Errors:
+ ENODEV: The device type is unknown or unsupported
+ EEXIST: Device already created, and this type of device may not
+ be instantiated multiple times
+
+ Other error conditions may be defined by individual device types or
+ have their standard meanings.
+
+Creates an emulated device in the kernel. The file descriptor returned
+in fd can be used with KVM_SET/GET/HAS_DEVICE_ATTR.
+
+If the KVM_CREATE_DEVICE_TEST flag is set, only test whether the
+device type is supported (not necessarily whether it can be created
+in the current vm).
+
+Individual devices should not define flags. Attributes should be used
+for specifying any behavior that is not implied by the device type
+number.
+
+struct kvm_create_device {
+ __u32 type; /* in: KVM_DEV_TYPE_xxx */
+ __u32 fd; /* out: device handle */
+ __u32 flags; /* in: KVM_CREATE_DEVICE_xxx */
+};
+
+4.80 KVM_SET_DEVICE_ATTR/KVM_GET_DEVICE_ATTR
+
+Capability: KVM_CAP_DEVICE_CTRL
+Type: device ioctl
+Parameters: struct kvm_device_attr
+Returns: 0 on success, -1 on error
+Errors:
+ ENXIO: The group or attribute is unknown/unsupported for this device
+ EPERM: The attribute cannot (currently) be accessed this way
+ (e.g. read-only attribute, or attribute that only makes
+ sense when the device is in a different state)
+
+ Other error conditions may be defined by individual device types.
+
+Gets/sets a specified piece of device configuration and/or state. The
+semantics are device-specific. See individual device documentation in
+the "devices" directory. As with ONE_REG, the size of the data
+transferred is defined by the particular attribute.
+
+struct kvm_device_attr {
+ __u32 flags; /* no flags currently defined */
+ __u32 group; /* device-defined */
+ __u64 attr; /* group-defined */
+ __u64 addr; /* userspace address of attr data */
+};
+
+4.81 KVM_HAS_DEVICE_ATTR
+
+Capability: KVM_CAP_DEVICE_CTRL
+Type: device ioctl
+Parameters: struct kvm_device_attr
+Returns: 0 on success, -1 on error
+Errors:
+ ENXIO: The group or attribute is unknown/unsupported for this device
+
+Tests whether a device supports a particular attribute. A successful
+return indicates the attribute is implemented. It does not necessarily
+indicate that the attribute can be read or written in the device's
+current state. "addr" is ignored.
+
+4.82 KVM_ARM_VCPU_INIT
+
+Capability: basic
+Architectures: arm, arm64
+Type: vcpu ioctl
+Parameters: struct struct kvm_vcpu_init (in)
+Returns: 0 on success; -1 on error
+Errors:
+ EINVAL: the target is unknown, or the combination of features is invalid.
+ ENOENT: a features bit specified is unknown.
+
+This tells KVM what type of CPU to present to the guest, and what
+optional features it should have. This will cause a reset of the cpu
+registers to their initial values. If this is not called, KVM_RUN will
+return ENOEXEC for that vcpu.
+
+Note that because some registers reflect machine topology, all vcpus
+should be created before this ioctl is invoked.
+
+Possible features:
+ - KVM_ARM_VCPU_POWER_OFF: Starts the CPU in a power-off state.
+ Depends on KVM_CAP_ARM_PSCI.
+ - KVM_ARM_VCPU_EL1_32BIT: Starts the CPU in a 32bit mode.
+ Depends on KVM_CAP_ARM_EL1_32BIT (arm64 only).
+
+
+4.83 KVM_GET_REG_LIST
+
+Capability: basic
+Architectures: arm, arm64
+Type: vcpu ioctl
+Parameters: struct kvm_reg_list (in/out)
+Returns: 0 on success; -1 on error
+Errors:
+ E2BIG: the reg index list is too big to fit in the array specified by
+ the user (the number required will be written into n).
+
+struct kvm_reg_list {
+ __u64 n; /* number of registers in reg[] */
+ __u64 reg[0];
+};
+
+This ioctl returns the guest registers that are supported for the
+KVM_GET_ONE_REG/KVM_SET_ONE_REG calls.
+
+
+4.84 KVM_ARM_SET_DEVICE_ADDR
+
+Capability: KVM_CAP_ARM_SET_DEVICE_ADDR
+Architectures: arm, arm64
+Type: vm ioctl
+Parameters: struct kvm_arm_device_address (in)
+Returns: 0 on success, -1 on error
+Errors:
+ ENODEV: The device id is unknown
+ ENXIO: Device not supported on current system
+ EEXIST: Address already set
+ E2BIG: Address outside guest physical address space
+ EBUSY: Address overlaps with other device range
+
+struct kvm_arm_device_addr {
+ __u64 id;
+ __u64 addr;
+};
+
+Specify a device address in the guest's physical address space where guests
+can access emulated or directly exposed devices, which the host kernel needs
+to know about. The id field is an architecture specific identifier for a
+specific device.
+
+ARM/arm64 divides the id field into two parts, a device id and an
+address type id specific to the individual device.
+
+ bits: | 63 ... 32 | 31 ... 16 | 15 ... 0 |
+ field: | 0x00000000 | device id | addr type id |
+
+ARM/arm64 currently only require this when using the in-kernel GIC
+support for the hardware VGIC features, using KVM_ARM_DEVICE_VGIC_V2
+as the device id. When setting the base address for the guest's
+mapping of the VGIC virtual CPU and distributor interface, the ioctl
+must be called after calling KVM_CREATE_IRQCHIP, but before calling
+KVM_RUN on any of the VCPUs. Calling this ioctl twice for any of the
+base addresses will return -EEXIST.
+
+4.85 KVM_PPC_RTAS_DEFINE_TOKEN
+
+Capability: KVM_CAP_PPC_RTAS
+Architectures: ppc
+Type: vm ioctl
+Parameters: struct kvm_rtas_token_args
+Returns: 0 on success, -1 on error
+
+Defines a token value for a RTAS (Run Time Abstraction Services)
+service in order to allow it to be handled in the kernel. The
+argument struct gives the name of the service, which must be the name
+of a service that has a kernel-side implementation. If the token
+value is non-zero, it will be associated with that service, and
+subsequent RTAS calls by the guest specifying that token will be
+handled by the kernel. If the token value is 0, then any token
+associated with the service will be forgotten, and subsequent RTAS
+calls by the guest for that service will be passed to userspace to be
+handled.
+
5. The kvm_run structure
------------------------
@@ -2238,8 +2493,8 @@
by kvm. The 'data' member contains the written data if 'is_write' is
true, and should be filled by application code otherwise.
-NOTE: For KVM_EXIT_IO, KVM_EXIT_MMIO, KVM_EXIT_OSI, KVM_EXIT_DCR
- and KVM_EXIT_PAPR the corresponding
+NOTE: For KVM_EXIT_IO, KVM_EXIT_MMIO, KVM_EXIT_OSI, KVM_EXIT_DCR,
+ KVM_EXIT_PAPR and KVM_EXIT_EPR the corresponding
operations are complete (and guest state is consistent) only after userspace
has re-entered the kernel with KVM_RUN. The kernel side will first finish
incomplete operations and then check for pending signals. Userspace
@@ -2342,6 +2597,41 @@
Requirements (PAPR) document available from www.power.org (free
developer registration required to access it).
+ /* KVM_EXIT_S390_TSCH */
+ struct {
+ __u16 subchannel_id;
+ __u16 subchannel_nr;
+ __u32 io_int_parm;
+ __u32 io_int_word;
+ __u32 ipb;
+ __u8 dequeued;
+ } s390_tsch;
+
+s390 specific. This exit occurs when KVM_CAP_S390_CSS_SUPPORT has been enabled
+and TEST SUBCHANNEL was intercepted. If dequeued is set, a pending I/O
+interrupt for the target subchannel has been dequeued and subchannel_id,
+subchannel_nr, io_int_parm and io_int_word contain the parameters for that
+interrupt. ipb is needed for instruction parameter decoding.
+
+ /* KVM_EXIT_EPR */
+ struct {
+ __u32 epr;
+ } epr;
+
+On FSL BookE PowerPC chips, the interrupt controller has a fast patch
+interrupt acknowledge path to the core. When the core successfully
+delivers an interrupt, it automatically populates the EPR register with
+the interrupt vector number and acknowledges the interrupt inside
+the interrupt controller.
+
+In case the interrupt controller lives in user space, we need to do
+the interrupt acknowledge cycle through it to fetch the next to be
+delivered interrupt vector using this exit.
+
+It gets triggered whenever both KVM_CAP_PPC_EPR are enabled and an
+external interrupt has just been delivered into the guest. User space
+should put the acknowledged interrupt vector into the 'epr' field.
+
/* Fix the size of the union. */
char padding[256];
};
@@ -2463,3 +2753,50 @@
where "num_sets" is the tlb_sizes[] value divided by the tlb_ways[] value.
- The tsize field of mas1 shall be set to 4K on TLB0, even though the
hardware ignores this value for TLB0.
+
+6.4 KVM_CAP_S390_CSS_SUPPORT
+
+Architectures: s390
+Parameters: none
+Returns: 0 on success; -1 on error
+
+This capability enables support for handling of channel I/O instructions.
+
+TEST PENDING INTERRUPTION and the interrupt portion of TEST SUBCHANNEL are
+handled in-kernel, while the other I/O instructions are passed to userspace.
+
+When this capability is enabled, KVM_EXIT_S390_TSCH will occur on TEST
+SUBCHANNEL intercepts.
+
+6.5 KVM_CAP_PPC_EPR
+
+Architectures: ppc
+Parameters: args[0] defines whether the proxy facility is active
+Returns: 0 on success; -1 on error
+
+This capability enables or disables the delivery of interrupts through the
+external proxy facility.
+
+When enabled (args[0] != 0), every time the guest gets an external interrupt
+delivered, it automatically exits into user space with a KVM_EXIT_EPR exit
+to receive the topmost interrupt vector.
+
+When disabled (args[0] == 0), behavior is as if this facility is unsupported.
+
+When this capability is enabled, KVM_EXIT_EPR can occur.
+
+6.6 KVM_CAP_IRQ_MPIC
+
+Architectures: ppc
+Parameters: args[0] is the MPIC device fd
+ args[1] is the MPIC CPU number for this vcpu
+
+This capability connects the vcpu to an in-kernel MPIC device.
+
+6.7 KVM_CAP_IRQ_XICS
+
+Architectures: ppc
+Parameters: args[0] is the XICS device fd
+ args[1] is the XICS CPU number (server ID) for this vcpu
+
+This capability connects the vcpu to an in-kernel XICS device.
diff --git a/Documentation/virtual/kvm/devices/README b/Documentation/virtual/kvm/devices/README
new file mode 100644
index 0000000..34a6983
--- /dev/null
+++ b/Documentation/virtual/kvm/devices/README
@@ -0,0 +1 @@
+This directory contains specific device bindings for KVM_CAP_DEVICE_CTRL.
diff --git a/Documentation/virtual/kvm/devices/mpic.txt b/Documentation/virtual/kvm/devices/mpic.txt
new file mode 100644
index 0000000..8257397
--- /dev/null
+++ b/Documentation/virtual/kvm/devices/mpic.txt
@@ -0,0 +1,53 @@
+MPIC interrupt controller
+=========================
+
+Device types supported:
+ KVM_DEV_TYPE_FSL_MPIC_20 Freescale MPIC v2.0
+ KVM_DEV_TYPE_FSL_MPIC_42 Freescale MPIC v4.2
+
+Only one MPIC instance, of any type, may be instantiated. The created
+MPIC will act as the system interrupt controller, connecting to each
+vcpu's interrupt inputs.
+
+Groups:
+ KVM_DEV_MPIC_GRP_MISC
+ Attributes:
+ KVM_DEV_MPIC_BASE_ADDR (rw, 64-bit)
+ Base address of the 256 KiB MPIC register space. Must be
+ naturally aligned. A value of zero disables the mapping.
+ Reset value is zero.
+
+ KVM_DEV_MPIC_GRP_REGISTER (rw, 32-bit)
+ Access an MPIC register, as if the access were made from the guest.
+ "attr" is the byte offset into the MPIC register space. Accesses
+ must be 4-byte aligned.
+
+ MSIs may be signaled by using this attribute group to write
+ to the relevant MSIIR.
+
+ KVM_DEV_MPIC_GRP_IRQ_ACTIVE (rw, 32-bit)
+ IRQ input line for each standard openpic source. 0 is inactive and 1
+ is active, regardless of interrupt sense.
+
+ For edge-triggered interrupts: Writing 1 is considered an activating
+ edge, and writing 0 is ignored. Reading returns 1 if a previously
+ signaled edge has not been acknowledged, and 0 otherwise.
+
+ "attr" is the IRQ number. IRQ numbers for standard sources are the
+ byte offset of the relevant IVPR from EIVPR0, divided by 32.
+
+IRQ Routing:
+
+ The MPIC emulation supports IRQ routing. Only a single MPIC device can
+ be instantiated. Once that device has been created, it's available as
+ irqchip id 0.
+
+ This irqchip 0 has 256 interrupt pins, which expose the interrupts in
+ the main array of interrupt sources (a.k.a. "SRC" interrupts).
+
+ The numbering is the same as the MPIC device tree binding -- based on
+ the register offset from the beginning of the sources array, without
+ regard to any subdivisions in chip documentation such as "internal"
+ or "external" interrupts.
+
+ Access to non-SRC interrupts is not implemented through IRQ routing mechanisms.
diff --git a/Documentation/virtual/kvm/devices/xics.txt b/Documentation/virtual/kvm/devices/xics.txt
new file mode 100644
index 0000000..4286493
--- /dev/null
+++ b/Documentation/virtual/kvm/devices/xics.txt
@@ -0,0 +1,66 @@
+XICS interrupt controller
+
+Device type supported: KVM_DEV_TYPE_XICS
+
+Groups:
+ KVM_DEV_XICS_SOURCES
+ Attributes: One per interrupt source, indexed by the source number.
+
+This device emulates the XICS (eXternal Interrupt Controller
+Specification) defined in PAPR. The XICS has a set of interrupt
+sources, each identified by a 20-bit source number, and a set of
+Interrupt Control Presentation (ICP) entities, also called "servers",
+each associated with a virtual CPU.
+
+The ICP entities are created by enabling the KVM_CAP_IRQ_ARCH
+capability for each vcpu, specifying KVM_CAP_IRQ_XICS in args[0] and
+the interrupt server number (i.e. the vcpu number from the XICS's
+point of view) in args[1] of the kvm_enable_cap struct. Each ICP has
+64 bits of state which can be read and written using the
+KVM_GET_ONE_REG and KVM_SET_ONE_REG ioctls on the vcpu. The 64 bit
+state word has the following bitfields, starting at the
+least-significant end of the word:
+
+* Unused, 16 bits
+
+* Pending interrupt priority, 8 bits
+ Zero is the highest priority, 255 means no interrupt is pending.
+
+* Pending IPI (inter-processor interrupt) priority, 8 bits
+ Zero is the highest priority, 255 means no IPI is pending.
+
+* Pending interrupt source number, 24 bits
+ Zero means no interrupt pending, 2 means an IPI is pending
+
+* Current processor priority, 8 bits
+ Zero is the highest priority, meaning no interrupts can be
+ delivered, and 255 is the lowest priority.
+
+Each source has 64 bits of state that can be read and written using
+the KVM_GET_DEVICE_ATTR and KVM_SET_DEVICE_ATTR ioctls, specifying the
+KVM_DEV_XICS_SOURCES attribute group, with the attribute number being
+the interrupt source number. The 64 bit state word has the following
+bitfields, starting from the least-significant end of the word:
+
+* Destination (server number), 32 bits
+ This specifies where the interrupt should be sent, and is the
+ interrupt server number specified for the destination vcpu.
+
+* Priority, 8 bits
+ This is the priority specified for this interrupt source, where 0 is
+ the highest priority and 255 is the lowest. An interrupt with a
+ priority of 255 will never be delivered.
+
+* Level sensitive flag, 1 bit
+ This bit is 1 for a level-sensitive interrupt source, or 0 for
+ edge-sensitive (or MSI).
+
+* Masked flag, 1 bit
+ This bit is set to 1 if the interrupt is masked (cannot be delivered
+ regardless of its priority), for example by the ibm,int-off RTAS
+ call, or 0 if it is not masked.
+
+* Pending flag, 1 bit
+ This bit is 1 if the source has a pending interrupt, otherwise 0.
+
+Only one XICS instance may be created per VM.
diff --git a/Documentation/virtual/kvm/mmu.txt b/Documentation/virtual/kvm/mmu.txt
index fa5f1db..2908941 100644
--- a/Documentation/virtual/kvm/mmu.txt
+++ b/Documentation/virtual/kvm/mmu.txt
@@ -187,23 +187,16 @@
perform a reverse map from a pte to a gfn. When role.direct is set, any
element of this array can be calculated from the gfn field when used, in
this case, the array of gfns is not allocated. See role.direct and gfn.
- slot_bitmap:
- A bitmap containing one bit per memory slot. If the page contains a pte
- mapping a page from memory slot n, then bit n of slot_bitmap will be set
- (if a page is aliased among several slots, then it is not guaranteed that
- all slots will be marked).
- Used during dirty logging to avoid scanning a shadow page if none if its
- pages need tracking.
root_count:
A counter keeping track of how many hardware registers (guest cr3 or
pdptrs) are now pointing at the page. While this counter is nonzero, the
page cannot be destroyed. See role.invalid.
- multimapped:
- Whether there exist multiple sptes pointing at this page.
- parent_pte/parent_ptes:
- If multimapped is zero, parent_pte points at the single spte that points at
- this page's spt. Otherwise, parent_ptes points at a data structure
- with a list of parent_ptes.
+ parent_ptes:
+ The reverse mapping for the pte/ptes pointing at this page's spt. If
+ parent_ptes bit 0 is zero, only one spte points at this pages and
+ parent_ptes points at this single spte, otherwise, there exists multiple
+ sptes pointing at this page and (parent_ptes & ~0x1) points at a data
+ structure with a list of parent_ptes.
unsync:
If true, then the translations in this page may not match the guest's
translation. This is equivalent to the state of the tlb when a pte is
@@ -217,6 +210,24 @@
A bitmap indicating which sptes in spt point (directly or indirectly) at
pages that may be unsynchronized. Used to quickly locate all unsychronized
pages reachable from a given page.
+ mmu_valid_gen:
+ Generation number of the page. It is compared with kvm->arch.mmu_valid_gen
+ during hash table lookup, and used to skip invalidated shadow pages (see
+ "Zapping all pages" below.)
+ clear_spte_count:
+ Only present on 32-bit hosts, where a 64-bit spte cannot be written
+ atomically. The reader uses this while running out of the MMU lock
+ to detect in-progress updates and retry them until the writer has
+ finished the write.
+ write_flooding_count:
+ A guest may write to a page table many times, causing a lot of
+ emulations if the page needs to be write-protected (see "Synchronized
+ and unsynchronized pages" below). Leaf pages can be unsynchronized
+ so that they do not trigger frequent emulation, but this is not
+ possible for non-leafs. This field counts the number of emulations
+ since the last time the page table was actually used; if emulation
+ is triggered too frequently on this page, KVM will unmap the page
+ to avoid emulation in the future.
Reverse map
===========
@@ -265,14 +276,26 @@
Handling a page fault is performed as follows:
+ - if the RSV bit of the error code is set, the page fault is caused by guest
+ accessing MMIO and cached MMIO information is available.
+ - walk shadow page table
+ - check for valid generation number in the spte (see "Fast invalidation of
+ MMIO sptes" below)
+ - cache the information to vcpu->arch.mmio_gva, vcpu->arch.access and
+ vcpu->arch.mmio_gfn, and call the emulator
+ - If both P bit and R/W bit of error code are set, this could possibly
+ be handled as a "fast page fault" (fixed without taking the MMU lock). See
+ the description in Documentation/virtual/kvm/locking.txt.
- if needed, walk the guest page tables to determine the guest translation
(gva->gpa or ngpa->gpa)
- if permissions are insufficient, reflect the fault back to the guest
- determine the host page
- - if this is an mmio request, there is no host page; call the emulator
- to emulate the instruction instead
+ - if this is an mmio request, there is no host page; cache the info to
+ vcpu->arch.mmio_gva, vcpu->arch.access and vcpu->arch.mmio_gfn
- walk the shadow page table to find the spte for the translation,
instantiating missing intermediate page tables as necessary
+ - If this is an mmio request, cache the mmio info to the spte and set some
+ reserved bit on the spte (see callers of kvm_mmu_set_mmio_spte_mask)
- try to unsynchronize the page
- if successful, we can let the guest continue and modify the gpte
- emulate the instruction
@@ -358,6 +381,51 @@
a large spte. The frames at the end of an unaligned memory slot have
artificially inflated ->write_counts so they can never be instantiated.
+Zapping all pages (page generation count)
+=========================================
+
+For the large memory guests, walking and zapping all pages is really slow
+(because there are a lot of pages), and also blocks memory accesses of
+all VCPUs because it needs to hold the MMU lock.
+
+To make it be more scalable, kvm maintains a global generation number
+which is stored in kvm->arch.mmu_valid_gen. Every shadow page stores
+the current global generation-number into sp->mmu_valid_gen when it
+is created. Pages with a mismatching generation number are "obsolete".
+
+When KVM need zap all shadow pages sptes, it just simply increases the global
+generation-number then reload root shadow pages on all vcpus. As the VCPUs
+create new shadow page tables, the old pages are not used because of the
+mismatching generation number.
+
+KVM then walks through all pages and zaps obsolete pages. While the zap
+operation needs to take the MMU lock, the lock can be released periodically
+so that the VCPUs can make progress.
+
+Fast invalidation of MMIO sptes
+===============================
+
+As mentioned in "Reaction to events" above, kvm will cache MMIO
+information in leaf sptes. When a new memslot is added or an existing
+memslot is changed, this information may become stale and needs to be
+invalidated. This also needs to hold the MMU lock while walking all
+shadow pages, and is made more scalable with a similar technique.
+
+MMIO sptes have a few spare bits, which are used to store a
+generation number. The global generation number is stored in
+kvm_memslots(kvm)->generation, and increased whenever guest memory info
+changes. This generation number is distinct from the one described in
+the previous section.
+
+When KVM finds an MMIO spte, it checks the generation number of the spte.
+If the generation number of the spte does not equal the global generation
+number, it will ignore the cached MMIO information and handle the page
+fault through the slow path.
+
+Since only 19 bits are used to store generation-number on mmio spte, all
+pages are zapped when there is an overflow.
+
+
Further reading
===============
diff --git a/Documentation/virtual/uml/UserModeLinux-HOWTO.txt b/Documentation/virtual/uml/UserModeLinux-HOWTO.txt
index a5f8436..f4099ca 100644
--- a/Documentation/virtual/uml/UserModeLinux-HOWTO.txt
+++ b/Documentation/virtual/uml/UserModeLinux-HOWTO.txt
@@ -3127,7 +3127,7 @@
at process_kern.c:156
#3 0x1006a052 in switch_to (prev=0x50072000, next=0x507e8000, last=0x50072000)
at process_kern.c:161
- #4 0x10001d12 in schedule () at sched.c:777
+ #4 0x10001d12 in schedule () at core.c:777
#5 0x1006a744 in __down (sem=0x507d241c) at semaphore.c:71
#6 0x1006aa10 in __down_failed () at semaphore.c:157
#7 0x1006c5d8 in segv_handler (sc=0x5006e940) at trap_user.c:174
@@ -3191,7 +3191,7 @@
at process_kern.c:161
161 _switch_to(prev, next);
(gdb)
- #4 0x10001d12 in schedule () at sched.c:777
+ #4 0x10001d12 in schedule () at core.c:777
777 switch_to(prev, next, prev);
(gdb)
#5 0x1006a744 in __down (sem=0x507d241c) at semaphore.c:71
diff --git a/Documentation/virtual/virtio-spec.txt b/Documentation/virtual/virtio-spec.txt
deleted file mode 100644
index 0d6ec85..0000000
--- a/Documentation/virtual/virtio-spec.txt
+++ /dev/null
@@ -1,3210 +0,0 @@
-[Generated file: see http://ozlabs.org/~rusty/virtio-spec/]
-Virtio PCI Card Specification
-v0.9.5 DRAFT
--
-
-Rusty Russell <rusty@rustcorp.com.au> IBM Corporation (Editor)
-
-2012 May 7.
-
-Purpose and Description
-
-This document describes the specifications of the “virtio” family
-of PCI[LaTeX Command: nomenclature] devices. These are devices
-are found in virtual environments[LaTeX Command: nomenclature],
-yet by design they are not all that different from physical PCI
-devices, and this document treats them as such. This allows the
-guest to use standard PCI drivers and discovery mechanisms.
-
-The purpose of virtio and this specification is that virtual
-environments and guests should have a straightforward, efficient,
-standard and extensible mechanism for virtual devices, rather
-than boutique per-environment or per-OS mechanisms.
-
- Straightforward: Virtio PCI devices use normal PCI mechanisms
- of interrupts and DMA which should be familiar to any device
- driver author. There is no exotic page-flipping or COW
- mechanism: it's just a PCI device.[footnote:
-This lack of page-sharing implies that the implementation of the
-device (e.g. the hypervisor or host) needs full access to the
-guest memory. Communication with untrusted parties (i.e.
-inter-guest communication) requires copying.
-]
-
- Efficient: Virtio PCI devices consist of rings of descriptors
- for input and output, which are neatly separated to avoid cache
- effects from both guest and device writing to the same cache
- lines.
-
- Standard: Virtio PCI makes no assumptions about the environment
- in which it operates, beyond supporting PCI. In fact the virtio
- devices specified in the appendices do not require PCI at all:
- they have been implemented on non-PCI buses.[footnote:
-The Linux implementation further separates the PCI virtio code
-from the specific virtio drivers: these drivers are shared with
-the non-PCI implementations (currently lguest and S/390).
-]
-
- Extensible: Virtio PCI devices contain feature bits which are
- acknowledged by the guest operating system during device setup.
- This allows forwards and backwards compatibility: the device
- offers all the features it knows about, and the driver
- acknowledges those it understands and wishes to use.
-
- Virtqueues
-
-The mechanism for bulk data transport on virtio PCI devices is
-pretentiously called a virtqueue. Each device can have zero or
-more virtqueues: for example, the network device has one for
-transmit and one for receive.
-
-Each virtqueue occupies two or more physically-contiguous pages
-(defined, for the purposes of this specification, as 4096 bytes),
-and consists of three parts:
-
-
-+-------------------+-----------------------------------+-----------+
-| Descriptor Table | Available Ring (padding) | Used Ring |
-+-------------------+-----------------------------------+-----------+
-
-
-When the driver wants to send a buffer to the device, it fills in
-a slot in the descriptor table (or chains several together), and
-writes the descriptor index into the available ring. It then
-notifies the device. When the device has finished a buffer, it
-writes the descriptor into the used ring, and sends an interrupt.
-
-Specification
-
- PCI Discovery
-
-Any PCI device with Vendor ID 0x1AF4, and Device ID 0x1000
-through 0x103F inclusive is a virtio device[footnote:
-The actual value within this range is ignored
-]. The device must also have a Revision ID of 0 to match this
-specification.
-
-The Subsystem Device ID indicates which virtio device is
-supported by the device. The Subsystem Vendor ID should reflect
-the PCI Vendor ID of the environment (it's currently only used
-for informational purposes by the guest).
-
-
-+----------------------+--------------------+---------------+
-| Subsystem Device ID | Virtio Device | Specification |
-+----------------------+--------------------+---------------+
-+----------------------+--------------------+---------------+
-| 1 | network card | Appendix C |
-+----------------------+--------------------+---------------+
-| 2 | block device | Appendix D |
-+----------------------+--------------------+---------------+
-| 3 | console | Appendix E |
-+----------------------+--------------------+---------------+
-| 4 | entropy source | Appendix F |
-+----------------------+--------------------+---------------+
-| 5 | memory ballooning | Appendix G |
-+----------------------+--------------------+---------------+
-| 6 | ioMemory | - |
-+----------------------+--------------------+---------------+
-| 7 | rpmsg | Appendix H |
-+----------------------+--------------------+---------------+
-| 8 | SCSI host | Appendix I |
-+----------------------+--------------------+---------------+
-| 9 | 9P transport | - |
-+----------------------+--------------------+---------------+
-| 10 | mac80211 wlan | - |
-+----------------------+--------------------+---------------+
-
-
- Device Configuration
-
-To configure the device, we use the first I/O region of the PCI
-device. This contains a virtio header followed by a
-device-specific region.
-
-There may be different widths of accesses to the I/O region; the “
-natural” access method for each field in the virtio header must
-be used (i.e. 32-bit accesses for 32-bit fields, etc), but the
-device-specific region can be accessed using any width accesses,
-and should obtain the same results.
-
-Note that this is possible because while the virtio header is PCI
-(i.e. little) endian, the device-specific region is encoded in
-the native endian of the guest (where such distinction is
-applicable).
-
- Device Initialization Sequence<sub:Device-Initialization-Sequence>
-
-We start with an overview of device initialization, then expand
-on the details of the device and how each step is preformed.
-
- Reset the device. This is not required on initial start up.
-
- The ACKNOWLEDGE status bit is set: we have noticed the device.
-
- The DRIVER status bit is set: we know how to drive the device.
-
- Device-specific setup, including reading the Device Feature
- Bits, discovery of virtqueues for the device, optional MSI-X
- setup, and reading and possibly writing the virtio
- configuration space.
-
- The subset of Device Feature Bits understood by the driver is
- written to the device.
-
- The DRIVER_OK status bit is set.
-
- The device can now be used (ie. buffers added to the
- virtqueues)[footnote:
-Historically, drivers have used the device before steps 5 and 6.
-This is only allowed if the driver does not use any features
-which would alter this early use of the device.
-]
-
-If any of these steps go irrecoverably wrong, the guest should
-set the FAILED status bit to indicate that it has given up on the
-device (it can reset the device later to restart if desired).
-
-We now cover the fields required for general setup in detail.
-
- Virtio Header
-
-The virtio header looks as follows:
-
-
-+------------++---------------------+---------------------+----------+--------+---------+---------+---------+--------+
-| Bits || 32 | 32 | 32 | 16 | 16 | 16 | 8 | 8 |
-+------------++---------------------+---------------------+----------+--------+---------+---------+---------+--------+
-| Read/Write || R | R+W | R+W | R | R+W | R+W | R+W | R |
-+------------++---------------------+---------------------+----------+--------+---------+---------+---------+--------+
-| Purpose || Device | Guest | Queue | Queue | Queue | Queue | Device | ISR |
-| || Features bits 0:31 | Features bits 0:31 | Address | Size | Select | Notify | Status | Status |
-+------------++---------------------+---------------------+----------+--------+---------+---------+---------+--------+
-
-
-If MSI-X is enabled for the device, two additional fields
-immediately follow this header:[footnote:
-ie. once you enable MSI-X on the device, the other fields move.
-If you turn it off again, they move back!
-]
-
-
-+------------++----------------+--------+
-| Bits || 16 | 16 |
- +----------------+--------+
-+------------++----------------+--------+
-| Read/Write || R+W | R+W |
-+------------++----------------+--------+
-| Purpose || Configuration | Queue |
-| (MSI-X) || Vector | Vector |
-+------------++----------------+--------+
-
-
-Immediately following these general headers, there may be
-device-specific headers:
-
-
-+------------++--------------------+
-| Bits || Device Specific |
- +--------------------+
-+------------++--------------------+
-| Read/Write || Device Specific |
-+------------++--------------------+
-| Purpose || Device Specific... |
-| || |
-+------------++--------------------+
-
-
- Device Status
-
-The Device Status field is updated by the guest to indicate its
-progress. This provides a simple low-level diagnostic: it's most
-useful to imagine them hooked up to traffic lights on the console
-indicating the status of each device.
-
-The device can be reset by writing a 0 to this field, otherwise
-at least one bit should be set:
-
- ACKNOWLEDGE (1) Indicates that the guest OS has found the
- device and recognized it as a valid virtio device.
-
- DRIVER (2) Indicates that the guest OS knows how to drive the
- device. Under Linux, drivers can be loadable modules so there
- may be a significant (or infinite) delay before setting this
- bit.
-
- DRIVER_OK (4) Indicates that the driver is set up and ready to
- drive the device.
-
- FAILED (128) Indicates that something went wrong in the guest,
- and it has given up on the device. This could be an internal
- error, or the driver didn't like the device for some reason, or
- even a fatal error during device operation. The device must be
- reset before attempting to re-initialize.
-
- Feature Bits<sub:Feature-Bits>
-
-Thefirst configuration field indicates the features that the
-device supports. The bits are allocated as follows:
-
- 0 to 23 Feature bits for the specific device type
-
- 24 to 32 Feature bits reserved for extensions to the queue and
- feature negotiation mechanisms
-
-For example, feature bit 0 for a network device (i.e. Subsystem
-Device ID 1) indicates that the device supports checksumming of
-packets.
-
-The feature bits are negotiated: the device lists all the
-features it understands in the Device Features field, and the
-guest writes the subset that it understands into the Guest
-Features field. The only way to renegotiate is to reset the
-device.
-
-In particular, new fields in the device configuration header are
-indicated by offering a feature bit, so the guest can check
-before accessing that part of the configuration space.
-
-This allows for forwards and backwards compatibility: if the
-device is enhanced with a new feature bit, older guests will not
-write that feature bit back to the Guest Features field and it
-can go into backwards compatibility mode. Similarly, if a guest
-is enhanced with a feature that the device doesn't support, it
-will not see that feature bit in the Device Features field and
-can go into backwards compatibility mode (or, for poor
-implementations, set the FAILED Device Status bit).
-
- Configuration/Queue Vectors
-
-When MSI-X capability is present and enabled in the device
-(through standard PCI configuration space) 4 bytes at byte offset
-20 are used to map configuration change and queue interrupts to
-MSI-X vectors. In this case, the ISR Status field is unused, and
-device specific configuration starts at byte offset 24 in virtio
-header structure. When MSI-X capability is not enabled, device
-specific configuration starts at byte offset 20 in virtio header.
-
-Writing a valid MSI-X Table entry number, 0 to 0x7FF, to one of
-Configuration/Queue Vector registers, maps interrupts triggered
-by the configuration change/selected queue events respectively to
-the corresponding MSI-X vector. To disable interrupts for a
-specific event type, unmap it by writing a special NO_VECTOR
-value:
-
-/* Vector value used to disable MSI for queue */
-
-#define VIRTIO_MSI_NO_VECTOR 0xffff
-
-Reading these registers returns vector mapped to a given event,
-or NO_VECTOR if unmapped. All queue and configuration change
-events are unmapped by default.
-
-Note that mapping an event to vector might require allocating
-internal device resources, and might fail. Devices report such
-failures by returning the NO_VECTOR value when the relevant
-Vector field is read. After mapping an event to vector, the
-driver must verify success by reading the Vector field value: on
-success, the previously written value is returned, and on
-failure, NO_VECTOR is returned. If a mapping failure is detected,
-the driver can retry mapping with fewervectors, or disable MSI-X.
-
- Virtqueue Configuration<sec:Virtqueue-Configuration>
-
-As a device can have zero or more virtqueues for bulk data
-transport (for example, the network driver has two), the driver
-needs to configure them as part of the device-specific
-configuration.
-
-This is done as follows, for each virtqueue a device has:
-
- Write the virtqueue index (first queue is 0) to the Queue
- Select field.
-
- Read the virtqueue size from the Queue Size field, which is
- always a power of 2. This controls how big the virtqueue is
- (see below). If this field is 0, the virtqueue does not exist.
-
- Allocate and zero virtqueue in contiguous physical memory, on a
- 4096 byte alignment. Write the physical address, divided by
- 4096 to the Queue Address field.[footnote:
-The 4096 is based on the x86 page size, but it's also large
-enough to ensure that the separate parts of the virtqueue are on
-separate cache lines.
-]
-
- Optionally, if MSI-X capability is present and enabled on the
- device, select a vector to use to request interrupts triggered
- by virtqueue events. Write the MSI-X Table entry number
- corresponding to this vector in Queue Vector field. Read the
- Queue Vector field: on success, previously written value is
- returned; on failure, NO_VECTOR value is returned.
-
-The Queue Size field controls the total number of bytes required
-for the virtqueue according to the following formula:
-
-#define ALIGN(x) (((x) + 4095) & ~4095)
-
-static inline unsigned vring_size(unsigned int qsz)
-
-{
-
- return ALIGN(sizeof(struct vring_desc)*qsz + sizeof(u16)*(2
-+ qsz))
-
- + ALIGN(sizeof(struct vring_used_elem)*qsz);
-
-}
-
-This currently wastes some space with padding, but also allows
-future extensions. The virtqueue layout structure looks like this
-(qsz is the Queue Size field, which is a variable, so this code
-won't compile):
-
-struct vring {
-
- /* The actual descriptors (16 bytes each) */
-
- struct vring_desc desc[qsz];
-
-
-
- /* A ring of available descriptor heads with free-running
-index. */
-
- struct vring_avail avail;
-
-
-
- // Padding to the next 4096 boundary.
-
- char pad[];
-
-
-
- // A ring of used descriptor heads with free-running index.
-
- struct vring_used used;
-
-};
-
- A Note on Virtqueue Endianness
-
-Note that the endian of these fields and everything else in the
-virtqueue is the native endian of the guest, not little-endian as
-PCI normally is. This makes for simpler guest code, and it is
-assumed that the host already has to be deeply aware of the guest
-endian so such an “endian-aware” device is not a significant
-issue.
-
- Descriptor Table
-
-The descriptor table refers to the buffers the guest is using for
-the device. The addresses are physical addresses, and the buffers
-can be chained via the next field. Each descriptor describes a
-buffer which is read-only or write-only, but a chain of
-descriptors can contain both read-only and write-only buffers.
-
-No descriptor chain may be more than 2^32 bytes long in total.struct vring_desc {
-
- /* Address (guest-physical). */
-
- u64 addr;
-
- /* Length. */
-
- u32 len;
-
-/* This marks a buffer as continuing via the next field. */
-
-#define VRING_DESC_F_NEXT 1
-
-/* This marks a buffer as write-only (otherwise read-only). */
-
-#define VRING_DESC_F_WRITE 2
-
-/* This means the buffer contains a list of buffer descriptors.
-*/
-
-#define VRING_DESC_F_INDIRECT 4
-
- /* The flags as indicated above. */
-
- u16 flags;
-
- /* Next field if flags & NEXT */
-
- u16 next;
-
-};
-
-The number of descriptors in the table is specified by the Queue
-Size field for this virtqueue.
-
- <sub:Indirect-Descriptors>Indirect Descriptors
-
-Some devices benefit by concurrently dispatching a large number
-of large requests. The VIRTIO_RING_F_INDIRECT_DESC feature can be
-used to allow this (see [cha:Reserved-Feature-Bits]). To increase
-ring capacity it is possible to store a table of indirect
-descriptors anywhere in memory, and insert a descriptor in main
-virtqueue (with flags&INDIRECT on) that refers to memory buffer
-containing this indirect descriptor table; fields addr and len
-refer to the indirect table address and length in bytes,
-respectively. The indirect table layout structure looks like this
-(len is the length of the descriptor that refers to this table,
-which is a variable, so this code won't compile):
-
-struct indirect_descriptor_table {
-
- /* The actual descriptors (16 bytes each) */
-
- struct vring_desc desc[len / 16];
-
-};
-
-The first indirect descriptor is located at start of the indirect
-descriptor table (index 0), additional indirect descriptors are
-chained by next field. An indirect descriptor without next field
-(with flags&NEXT off) signals the end of the indirect descriptor
-table, and transfers control back to the main virtqueue. An
-indirect descriptor can not refer to another indirect descriptor
-table (flags&INDIRECT must be off). A single indirect descriptor
-table can include both read-only and write-only descriptors;
-write-only flag (flags&WRITE) in the descriptor that refers to it
-is ignored.
-
- Available Ring
-
-The available ring refers to what descriptors we are offering the
-device: it refers to the head of a descriptor chain. The “flags”
-field is currently 0 or 1: 1 indicating that we do not need an
-interrupt when the device consumes a descriptor from the
-available ring. Alternatively, the guest can ask the device to
-delay interrupts until an entry with an index specified by the “
-used_event” field is written in the used ring (equivalently,
-until the idx field in the used ring will reach the value
-used_event + 1). The method employed by the device is controlled
-by the VIRTIO_RING_F_EVENT_IDX feature bit (see [cha:Reserved-Feature-Bits]
-). This interrupt suppression is merely an optimization; it may
-not suppress interrupts entirely.
-
-The “idx” field indicates where we would put the next descriptor
-entry (modulo the ring size). This starts at 0, and increases.
-
-struct vring_avail {
-
-#define VRING_AVAIL_F_NO_INTERRUPT 1
-
- u16 flags;
-
- u16 idx;
-
- u16 ring[qsz]; /* qsz is the Queue Size field read from device
-*/
-
- u16 used_event;
-
-};
-
- Used Ring
-
-The used ring is where the device returns buffers once it is done
-with them. The flags field can be used by the device to hint that
-no notification is necessary when the guest adds to the available
-ring. Alternatively, the “avail_event” field can be used by the
-device to hint that no notification is necessary until an entry
-with an index specified by the “avail_event” is written in the
-available ring (equivalently, until the idx field in the
-available ring will reach the value avail_event + 1). The method
-employed by the device is controlled by the guest through the
-VIRTIO_RING_F_EVENT_IDX feature bit (see [cha:Reserved-Feature-Bits]
-). [footnote:
-These fields are kept here because this is the only part of the
-virtqueue written by the device
-].
-
-Each entry in the ring is a pair: the head entry of the
-descriptor chain describing the buffer (this matches an entry
-placed in the available ring by the guest earlier), and the total
-of bytes written into the buffer. The latter is extremely useful
-for guests using untrusted buffers: if you do not know exactly
-how much has been written by the device, you usually have to zero
-the buffer to ensure no data leakage occurs.
-
-/* u32 is used here for ids for padding reasons. */
-
-struct vring_used_elem {
-
- /* Index of start of used descriptor chain. */
-
- u32 id;
-
- /* Total length of the descriptor chain which was used
-(written to) */
-
- u32 len;
-
-};
-
-
-
-struct vring_used {
-
-#define VRING_USED_F_NO_NOTIFY 1
-
- u16 flags;
-
- u16 idx;
-
- struct vring_used_elem ring[qsz];
-
- u16 avail_event;
-
-};
-
- Helpers for Managing Virtqueues
-
-The Linux Kernel Source code contains the definitions above and
-helper routines in a more usable form, in
-include/linux/virtio_ring.h. This was explicitly licensed by IBM
-and Red Hat under the (3-clause) BSD license so that it can be
-freely used by all other projects, and is reproduced (with slight
-variation to remove Linux assumptions) in Appendix A.
-
- Device Operation<sec:Device-Operation>
-
-There are two parts to device operation: supplying new buffers to
-the device, and processing used buffers from the device. As an
-example, the virtio network device has two virtqueues: the
-transmit virtqueue and the receive virtqueue. The driver adds
-outgoing (read-only) packets to the transmit virtqueue, and then
-frees them after they are used. Similarly, incoming (write-only)
-buffers are added to the receive virtqueue, and processed after
-they are used.
-
- Supplying Buffers to The Device
-
-Actual transfer of buffers from the guest OS to the device
-operates as follows:
-
- Place the buffer(s) into free descriptor(s).
-
- If there are no free descriptors, the guest may choose to
- notify the device even if notifications are suppressed (to
- reduce latency).[footnote:
-The Linux drivers do this only for read-only buffers: for
-write-only buffers, it is assumed that the driver is merely
-trying to keep the receive buffer ring full, and no notification
-of this expected condition is necessary.
-]
-
- Place the id of the buffer in the next ring entry of the
- available ring.
-
- The steps (1) and (2) may be performed repeatedly if batching
- is possible.
-
- A memory barrier should be executed to ensure the device sees
- the updated descriptor table and available ring before the next
- step.
-
- The available “idx” field should be increased by the number of
- entries added to the available ring.
-
- A memory barrier should be executed to ensure that we update
- the idx field before checking for notification suppression.
-
- If notifications are not suppressed, the device should be
- notified of the new buffers.
-
-Note that the above code does not take precautions against the
-available ring buffer wrapping around: this is not possible since
-the ring buffer is the same size as the descriptor table, so step
-(1) will prevent such a condition.
-
-In addition, the maximum queue size is 32768 (it must be a power
-of 2 which fits in 16 bits), so the 16-bit “idx” value can always
-distinguish between a full and empty buffer.
-
-Here is a description of each stage in more detail.
-
- Placing Buffers Into The Descriptor Table
-
-A buffer consists of zero or more read-only physically-contiguous
-elements followed by zero or more physically-contiguous
-write-only elements (it must have at least one element). This
-algorithm maps it into the descriptor table:
-
- for each buffer element, b:
-
- Get the next free descriptor table entry, d
-
- Set d.addr to the physical address of the start of b
-
- Set d.len to the length of b.
-
- If b is write-only, set d.flags to VRING_DESC_F_WRITE,
- otherwise 0.
-
- If there is a buffer element after this:
-
- Set d.next to the index of the next free descriptor element.
-
- Set the VRING_DESC_F_NEXT bit in d.flags.
-
-In practice, the d.next fields are usually used to chain free
-descriptors, and a separate count kept to check there are enough
-free descriptors before beginning the mappings.
-
- Updating The Available Ring
-
-The head of the buffer we mapped is the first d in the algorithm
-above. A naive implementation would do the following:
-
-avail->ring[avail->idx % qsz] = head;
-
-However, in general we can add many descriptors before we update
-the “idx” field (at which point they become visible to the
-device), so we keep a counter of how many we've added:
-
-avail->ring[(avail->idx + added++) % qsz] = head;
-
- Updating The Index Field
-
-Once the idx field of the virtqueue is updated, the device will
-be able to access the descriptor entries we've created and the
-memory they refer to. This is why a memory barrier is generally
-used before the idx update, to ensure it sees the most up-to-date
-copy.
-
-The idx field always increments, and we let it wrap naturally at
-65536:
-
-avail->idx += added;
-
- <sub:Notifying-The-Device>Notifying The Device
-
-Device notification occurs by writing the 16-bit virtqueue index
-of this virtqueue to the Queue Notify field of the virtio header
-in the first I/O region of the PCI device. This can be expensive,
-however, so the device can suppress such notifications if it
-doesn't need them. We have to be careful to expose the new idx
-value before checking the suppression flag: it's OK to notify
-gratuitously, but not to omit a required notification. So again,
-we use a memory barrier here before reading the flags or the
-avail_event field.
-
-If the VIRTIO_F_RING_EVENT_IDX feature is not negotiated, and if
-the VRING_USED_F_NOTIFY flag is not set, we go ahead and write to
-the PCI configuration space.
-
-If the VIRTIO_F_RING_EVENT_IDX feature is negotiated, we read the
-avail_event field in the available ring structure. If the
-available index crossed_the avail_event field value since the
-last notification, we go ahead and write to the PCI configuration
-space. The avail_event field wraps naturally at 65536 as well:
-
-(u16)(new_idx - avail_event - 1) < (u16)(new_idx - old_idx)
-
- <sub:Receiving-Used-Buffers>Receiving Used Buffers From The
- Device
-
-Once the device has used a buffer (read from or written to it, or
-parts of both, depending on the nature of the virtqueue and the
-device), it sends an interrupt, following an algorithm very
-similar to the algorithm used for the driver to send the device a
-buffer:
-
- Write the head descriptor number to the next field in the used
- ring.
-
- Update the used ring idx.
-
- Determine whether an interrupt is necessary:
-
- If the VIRTIO_F_RING_EVENT_IDX feature is not negotiated: check
- if f the VRING_AVAIL_F_NO_INTERRUPT flag is not set in avail-
- >flags
-
- If the VIRTIO_F_RING_EVENT_IDX feature is negotiated: check
- whether the used index crossed the used_event field value
- since the last update. The used_event field wraps naturally
- at 65536 as well:(u16)(new_idx - used_event - 1) < (u16)(new_idx - old_idx)
-
- If an interrupt is necessary:
-
- If MSI-X capability is disabled:
-
- Set the lower bit of the ISR Status field for the device.
-
- Send the appropriate PCI interrupt for the device.
-
- If MSI-X capability is enabled:
-
- Request the appropriate MSI-X interrupt message for the
- device, Queue Vector field sets the MSI-X Table entry
- number.
-
- If Queue Vector field value is NO_VECTOR, no interrupt
- message is requested for this event.
-
-The guest interrupt handler should:
-
- If MSI-X capability is disabled: read the ISR Status field,
- which will reset it to zero. If the lower bit is zero, the
- interrupt was not for this device. Otherwise, the guest driver
- should look through the used rings of each virtqueue for the
- device, to see if any progress has been made by the device
- which requires servicing.
-
- If MSI-X capability is enabled: look through the used rings of
- each virtqueue mapped to the specific MSI-X vector for the
- device, to see if any progress has been made by the device
- which requires servicing.
-
-For each ring, guest should then disable interrupts by writing
-VRING_AVAIL_F_NO_INTERRUPT flag in avail structure, if required.
-It can then process used ring entries finally enabling interrupts
-by clearing the VRING_AVAIL_F_NO_INTERRUPT flag or updating the
-EVENT_IDX field in the available structure, Guest should then
-execute a memory barrier, and then recheck the ring empty
-condition. This is necessary to handle the case where, after the
-last check and before enabling interrupts, an interrupt has been
-suppressed by the device:
-
-vring_disable_interrupts(vq);
-
-for (;;) {
-
- if (vq->last_seen_used != vring->used.idx) {
-
- vring_enable_interrupts(vq);
-
- mb();
-
- if (vq->last_seen_used != vring->used.idx)
-
- break;
-
- }
-
- struct vring_used_elem *e =
-vring.used->ring[vq->last_seen_used%vsz];
-
- process_buffer(e);
-
- vq->last_seen_used++;
-
-}
-
- Dealing With Configuration Changes<sub:Dealing-With-Configuration>
-
-Some virtio PCI devices can change the device configuration
-state, as reflected in the virtio header in the PCI configuration
-space. In this case:
-
- If MSI-X capability is disabled: an interrupt is delivered and
- the second highest bit is set in the ISR Status field to
- indicate that the driver should re-examine the configuration
- space.Note that a single interrupt can indicate both that one
- or more virtqueue has been used and that the configuration
- space has changed: even if the config bit is set, virtqueues
- must be scanned.
-
- If MSI-X capability is enabled: an interrupt message is
- requested. The Configuration Vector field sets the MSI-X Table
- entry number to use. If Configuration Vector field value is
- NO_VECTOR, no interrupt message is requested for this event.
-
-Creating New Device Types
-
-Various considerations are necessary when creating a new device
-type:
-
- How Many Virtqueues?
-
-It is possible that a very simple device will operate entirely
-through its configuration space, but most will need at least one
-virtqueue in which it will place requests. A device with both
-input and output (eg. console and network devices described here)
-need two queues: one which the driver fills with buffers to
-receive input, and one which the driver places buffers to
-transmit output.
-
- What Configuration Space Layout?
-
-Configuration space is generally used for rarely-changing or
-initialization-time parameters. But it is a limited resource, so
-it might be better to use a virtqueue to update configuration
-information (the network device does this for filtering,
-otherwise the table in the config space could potentially be very
-large).
-
-Note that this space is generally the guest's native endian,
-rather than PCI's little-endian.
-
- What Device Number?
-
-Currently device numbers are assigned quite freely: a simple
-request mail to the author of this document or the Linux
-virtualization mailing list[footnote:
-
-https://lists.linux-foundation.org/mailman/listinfo/virtualization
-] will be sufficient to secure a unique one.
-
-Meanwhile for experimental drivers, use 65535 and work backwards.
-
- How many MSI-X vectors?
-
-Using the optional MSI-X capability devices can speed up
-interrupt processing by removing the need to read ISR Status
-register by guest driver (which might be an expensive operation),
-reducing interrupt sharing between devices and queues within the
-device, and handling interrupts from multiple CPUs. However, some
-systems impose a limit (which might be as low as 256) on the
-total number of MSI-X vectors that can be allocated to all
-devices. Devices and/or device drivers should take this into
-account, limiting the number of vectors used unless the device is
-expected to cause a high volume of interrupts. Devices can
-control the number of vectors used by limiting the MSI-X Table
-Size or not presenting MSI-X capability in PCI configuration
-space. Drivers can control this by mapping events to as small
-number of vectors as possible, or disabling MSI-X capability
-altogether.
-
- Message Framing
-
-The descriptors used for a buffer should not effect the semantics
-of the message, except for the total length of the buffer. For
-example, a network buffer consists of a 10 byte header followed
-by the network packet. Whether this is presented in the ring
-descriptor chain as (say) a 10 byte buffer and a 1514 byte
-buffer, or a single 1524 byte buffer, or even three buffers,
-should have no effect.
-
-In particular, no implementation should use the descriptor
-boundaries to determine the size of any header in a request.[footnote:
-The current qemu device implementations mistakenly insist that
-the first descriptor cover the header in these cases exactly, so
-a cautious driver should arrange it so.
-]
-
- Device Improvements
-
-Any change to configuration space, or new virtqueues, or
-behavioural changes, should be indicated by negotiation of a new
-feature bit. This establishes clarity[footnote:
-Even if it does mean documenting design or implementation
-mistakes!
-] and avoids future expansion problems.
-
-Clusters of functionality which are always implemented together
-can use a single bit, but if one feature makes sense without the
-others they should not be gratuitously grouped together to
-conserve feature bits. We can always extend the spec when the
-first person needs more than 24 feature bits for their device.
-
-[LaTeX Command: printnomenclature]
-
-Appendix A: virtio_ring.h
-
-#ifndef VIRTIO_RING_H
-
-#define VIRTIO_RING_H
-
-/* An interface for efficient virtio implementation.
-
- *
-
- * This header is BSD licensed so anyone can use the definitions
-
- * to implement compatible drivers/servers.
-
- *
-
- * Copyright 2007, 2009, IBM Corporation
-
- * Copyright 2011, Red Hat, Inc
-
- * All rights reserved.
-
- *
-
- * Redistribution and use in source and binary forms, with or
-without
-
- * modification, are permitted provided that the following
-conditions
-
- * are met:
-
- * 1. Redistributions of source code must retain the above
-copyright
-
- * notice, this list of conditions and the following
-disclaimer.
-
- * 2. Redistributions in binary form must reproduce the above
-copyright
-
- * notice, this list of conditions and the following
-disclaimer in the
-
- * documentation and/or other materials provided with the
-distribution.
-
- * 3. Neither the name of IBM nor the names of its contributors
-
- * may be used to endorse or promote products derived from
-this software
-
- * without specific prior written permission.
-
- * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
-CONTRIBUTORS ``AS IS'' AND
-
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
-TO, THE
-
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
-PARTICULAR PURPOSE
-
- * ARE DISCLAIMED. IN NO EVENT SHALL IBM OR CONTRIBUTORS BE
-LIABLE
-
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
-CONSEQUENTIAL
-
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
-SUBSTITUTE GOODS
-
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
-INTERRUPTION)
-
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
-CONTRACT, STRICT
-
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
-IN ANY WAY
-
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
-POSSIBILITY OF
-
- * SUCH DAMAGE.
-
- */
-
-
-
-/* This marks a buffer as continuing via the next field. */
-
-#define VRING_DESC_F_NEXT 1
-
-/* This marks a buffer as write-only (otherwise read-only). */
-
-#define VRING_DESC_F_WRITE 2
-
-
-
-/* The Host uses this in used->flags to advise the Guest: don't
-kick me
-
- * when you add a buffer. It's unreliable, so it's simply an
-
- * optimization. Guest will still kick if it's out of buffers.
-*/
-
-#define VRING_USED_F_NO_NOTIFY 1
-
-/* The Guest uses this in avail->flags to advise the Host: don't
-
- * interrupt me when you consume a buffer. It's unreliable, so
-it's
-
- * simply an optimization. */
-
-#define VRING_AVAIL_F_NO_INTERRUPT 1
-
-
-
-/* Virtio ring descriptors: 16 bytes.
-
- * These can chain together via "next". */
-
-struct vring_desc {
-
- /* Address (guest-physical). */
-
- uint64_t addr;
-
- /* Length. */
-
- uint32_t len;
-
- /* The flags as indicated above. */
-
- uint16_t flags;
-
- /* We chain unused descriptors via this, too */
-
- uint16_t next;
-
-};
-
-
-
-struct vring_avail {
-
- uint16_t flags;
-
- uint16_t idx;
-
- uint16_t ring[];
-
- uint16_t used_event;
-
-};
-
-
-
-/* u32 is used here for ids for padding reasons. */
-
-struct vring_used_elem {
-
- /* Index of start of used descriptor chain. */
-
- uint32_t id;
-
- /* Total length of the descriptor chain which was written
-to. */
-
- uint32_t len;
-
-};
-
-
-
-struct vring_used {
-
- uint16_t flags;
-
- uint16_t idx;
-
- struct vring_used_elem ring[];
-
- uint16_t avail_event;
-
-};
-
-
-
-struct vring {
-
- unsigned int num;
-
-
-
- struct vring_desc *desc;
-
- struct vring_avail *avail;
-
- struct vring_used *used;
-
-};
-
-
-
-/* The standard layout for the ring is a continuous chunk of
-memory which
-
- * looks like this. We assume num is a power of 2.
-
- *
-
- * struct vring {
-
- * // The actual descriptors (16 bytes each)
-
- * struct vring_desc desc[num];
-
- *
-
- * // A ring of available descriptor heads with free-running
-index.
-
- * __u16 avail_flags;
-
- * __u16 avail_idx;
-
- * __u16 available[num];
-
- *
-
- * // Padding to the next align boundary.
-
- * char pad[];
-
- *
-
- * // A ring of used descriptor heads with free-running
-index.
-
- * __u16 used_flags;
-
- * __u16 EVENT_IDX;
-
- * struct vring_used_elem used[num];
-
- * };
-
- * Note: for virtio PCI, align is 4096.
-
- */
-
-static inline void vring_init(struct vring *vr, unsigned int num,
-void *p,
-
- unsigned long align)
-
-{
-
- vr->num = num;
-
- vr->desc = p;
-
- vr->avail = p + num*sizeof(struct vring_desc);
-
- vr->used = (void *)(((unsigned long)&vr->avail->ring[num]
-
- + align-1)
-
- & ~(align - 1));
-
-}
-
-
-
-static inline unsigned vring_size(unsigned int num, unsigned long
-align)
-
-{
-
- return ((sizeof(struct vring_desc)*num +
-sizeof(uint16_t)*(2+num)
-
- + align - 1) & ~(align - 1))
-
- + sizeof(uint16_t)*3 + sizeof(struct
-vring_used_elem)*num;
-
-}
-
-
-
-static inline int vring_need_event(uint16_t event_idx, uint16_t
-new_idx, uint16_t old_idx)
-
-{
-
- return (uint16_t)(new_idx - event_idx - 1) <
-(uint16_t)(new_idx - old_idx);
-
-}
-
-#endif /* VIRTIO_RING_H */
-
-<cha:Reserved-Feature-Bits>Appendix B: Reserved Feature Bits
-
-Currently there are five device-independent feature bits defined:
-
- VIRTIO_F_NOTIFY_ON_EMPTY (24) Negotiating this feature
- indicates that the driver wants an interrupt if the device runs
- out of available descriptors on a virtqueue, even though
- interrupts are suppressed using the VRING_AVAIL_F_NO_INTERRUPT
- flag or the used_event field. An example of this is the
- networking driver: it doesn't need to know every time a packet
- is transmitted, but it does need to free the transmitted
- packets a finite time after they are transmitted. It can avoid
- using a timer if the device interrupts it when all the packets
- are transmitted.
-
- VIRTIO_F_RING_INDIRECT_DESC (28) Negotiating this feature
- indicates that the driver can use descriptors with the
- VRING_DESC_F_INDIRECT flag set, as described in [sub:Indirect-Descriptors]
- .
-
- VIRTIO_F_RING_EVENT_IDX(29) This feature enables the used_event
- and the avail_event fields. If set, it indicates that the
- device should ignore the flags field in the available ring
- structure. Instead, the used_event field in this structure is
- used by guest to suppress device interrupts. Further, the
- driver should ignore the flags field in the used ring
- structure. Instead, the avail_event field in this structure is
- used by the device to suppress notifications. If unset, the
- driver should ignore the used_event field; the device should
- ignore the avail_event field; the flags field is used
-
-Appendix C: Network Device
-
-The virtio network device is a virtual ethernet card, and is the
-most complex of the devices supported so far by virtio. It has
-enhanced rapidly and demonstrates clearly how support for new
-features should be added to an existing device. Empty buffers are
-placed in one virtqueue for receiving packets, and outgoing
-packets are enqueued into another for transmission in that order.
-A third command queue is used to control advanced filtering
-features.
-
- Configuration
-
- Subsystem Device ID 1
-
- Virtqueues 0:receiveq. 1:transmitq. 2:controlq[footnote:
-Only if VIRTIO_NET_F_CTRL_VQ set
-]
-
- Feature bits
-
- VIRTIO_NET_F_CSUM (0) Device handles packets with partial
- checksum
-
- VIRTIO_NET_F_GUEST_CSUM (1) Guest handles packets with partial
- checksum
-
- VIRTIO_NET_F_MAC (5) Device has given MAC address.
-
- VIRTIO_NET_F_GSO (6) (Deprecated) device handles packets with
- any GSO type.[footnote:
-It was supposed to indicate segmentation offload support, but
-upon further investigation it became clear that multiple bits
-were required.
-]
-
- VIRTIO_NET_F_GUEST_TSO4 (7) Guest can receive TSOv4.
-
- VIRTIO_NET_F_GUEST_TSO6 (8) Guest can receive TSOv6.
-
- VIRTIO_NET_F_GUEST_ECN (9) Guest can receive TSO with ECN.
-
- VIRTIO_NET_F_GUEST_UFO (10) Guest can receive UFO.
-
- VIRTIO_NET_F_HOST_TSO4 (11) Device can receive TSOv4.
-
- VIRTIO_NET_F_HOST_TSO6 (12) Device can receive TSOv6.
-
- VIRTIO_NET_F_HOST_ECN (13) Device can receive TSO with ECN.
-
- VIRTIO_NET_F_HOST_UFO (14) Device can receive UFO.
-
- VIRTIO_NET_F_MRG_RXBUF (15) Guest can merge receive buffers.
-
- VIRTIO_NET_F_STATUS (16) Configuration status field is
- available.
-
- VIRTIO_NET_F_CTRL_VQ (17) Control channel is available.
-
- VIRTIO_NET_F_CTRL_RX (18) Control channel RX mode support.
-
- VIRTIO_NET_F_CTRL_VLAN (19) Control channel VLAN filtering.
-
- VIRTIO_NET_F_GUEST_ANNOUNCE(21) Guest can send gratuitous
- packets.
-
- Device configuration layout Two configuration fields are
- currently defined. The mac address field always exists (though
- is only valid if VIRTIO_NET_F_MAC is set), and the status field
- only exists if VIRTIO_NET_F_STATUS is set. Two read-only bits
- are currently defined for the status field:
- VIRTIO_NET_S_LINK_UP and VIRTIO_NET_S_ANNOUNCE. #define VIRTIO_NET_S_LINK_UP 1
-
-#define VIRTIO_NET_S_ANNOUNCE 2
-
-
-
-struct virtio_net_config {
-
- u8 mac[6];
-
- u16 status;
-
-};
-
- Device Initialization
-
- The initialization routine should identify the receive and
- transmission virtqueues.
-
- If the VIRTIO_NET_F_MAC feature bit is set, the configuration
- space “mac” entry indicates the “physical” address of the the
- network card, otherwise a private MAC address should be
- assigned. All guests are expected to negotiate this feature if
- it is set.
-
- If the VIRTIO_NET_F_CTRL_VQ feature bit is negotiated, identify
- the control virtqueue.
-
- If the VIRTIO_NET_F_STATUS feature bit is negotiated, the link
- status can be read from the bottom bit of the “status” config
- field. Otherwise, the link should be assumed active.
-
- The receive virtqueue should be filled with receive buffers.
- This is described in detail below in “Setting Up Receive
- Buffers”.
-
- A driver can indicate that it will generate checksumless
- packets by negotating the VIRTIO_NET_F_CSUM feature. This “
- checksum offload” is a common feature on modern network cards.
-
- If that feature is negotiated[footnote:
-ie. VIRTIO_NET_F_HOST_TSO* and VIRTIO_NET_F_HOST_UFO are
-dependent on VIRTIO_NET_F_CSUM; a dvice which offers the offload
-features must offer the checksum feature, and a driver which
-accepts the offload features must accept the checksum feature.
-Similar logic applies to the VIRTIO_NET_F_GUEST_TSO4 features
-depending on VIRTIO_NET_F_GUEST_CSUM.
-], a driver can use TCP or UDP segmentation offload by
- negotiating the VIRTIO_NET_F_HOST_TSO4 (IPv4 TCP),
- VIRTIO_NET_F_HOST_TSO6 (IPv6 TCP) and VIRTIO_NET_F_HOST_UFO
- (UDP fragmentation) features. It should not send TCP packets
- requiring segmentation offload which have the Explicit
- Congestion Notification bit set, unless the
- VIRTIO_NET_F_HOST_ECN feature is negotiated.[footnote:
-This is a common restriction in real, older network cards.
-]
-
- The converse features are also available: a driver can save the
- virtual device some work by negotiating these features.[footnote:
-For example, a network packet transported between two guests on
-the same system may not require checksumming at all, nor
-segmentation, if both guests are amenable.
-] The VIRTIO_NET_F_GUEST_CSUM feature indicates that partially
- checksummed packets can be received, and if it can do that then
- the VIRTIO_NET_F_GUEST_TSO4, VIRTIO_NET_F_GUEST_TSO6,
- VIRTIO_NET_F_GUEST_UFO and VIRTIO_NET_F_GUEST_ECN are the input
- equivalents of the features described above. See “Receiving
- Packets” below.
-
- Device Operation
-
-Packets are transmitted by placing them in the transmitq, and
-buffers for incoming packets are placed in the receiveq. In each
-case, the packet itself is preceeded by a header:
-
-struct virtio_net_hdr {
-
-#define VIRTIO_NET_HDR_F_NEEDS_CSUM 1
-
- u8 flags;
-
-#define VIRTIO_NET_HDR_GSO_NONE 0
-
-#define VIRTIO_NET_HDR_GSO_TCPV4 1
-
-#define VIRTIO_NET_HDR_GSO_UDP 3
-
-#define VIRTIO_NET_HDR_GSO_TCPV6 4
-
-#define VIRTIO_NET_HDR_GSO_ECN 0x80
-
- u8 gso_type;
-
- u16 hdr_len;
-
- u16 gso_size;
-
- u16 csum_start;
-
- u16 csum_offset;
-
-/* Only if VIRTIO_NET_F_MRG_RXBUF: */
-
- u16 num_buffers
-
-};
-
-The controlq is used to control device features such as
-filtering.
-
- Packet Transmission
-
-Transmitting a single packet is simple, but varies depending on
-the different features the driver negotiated.
-
- If the driver negotiated VIRTIO_NET_F_CSUM, and the packet has
- not been fully checksummed, then the virtio_net_hdr's fields
- are set as follows. Otherwise, the packet must be fully
- checksummed, and flags is zero.
-
- flags has the VIRTIO_NET_HDR_F_NEEDS_CSUM set,
-
- <ite:csum_start-is-set>csum_start is set to the offset within
- the packet to begin checksumming, and
-
- csum_offset indicates how many bytes after the csum_start the
- new (16 bit ones' complement) checksum should be placed.[footnote:
-For example, consider a partially checksummed TCP (IPv4) packet.
-It will have a 14 byte ethernet header and 20 byte IP header
-followed by the TCP header (with the TCP checksum field 16 bytes
-into that header). csum_start will be 14+20 = 34 (the TCP
-checksum includes the header), and csum_offset will be 16. The
-value in the TCP checksum field should be initialized to the sum
-of the TCP pseudo header, so that replacing it by the ones'
-complement checksum of the TCP header and body will give the
-correct result.
-]
-
- <enu:If-the-driver>If the driver negotiated
- VIRTIO_NET_F_HOST_TSO4, TSO6 or UFO, and the packet requires
- TCP segmentation or UDP fragmentation, then the “gso_type”
- field is set to VIRTIO_NET_HDR_GSO_TCPV4, TCPV6 or UDP.
- (Otherwise, it is set to VIRTIO_NET_HDR_GSO_NONE). In this
- case, packets larger than 1514 bytes can be transmitted: the
- metadata indicates how to replicate the packet header to cut it
- into smaller packets. The other gso fields are set:
-
- hdr_len is a hint to the device as to how much of the header
- needs to be kept to copy into each packet, usually set to the
- length of the headers, including the transport header.[footnote:
-Due to various bugs in implementations, this field is not useful
-as a guarantee of the transport header size.
-]
-
- gso_size is the maximum size of each packet beyond that header
- (ie. MSS).
-
- If the driver negotiated the VIRTIO_NET_F_HOST_ECN feature, the
- VIRTIO_NET_HDR_GSO_ECN bit may be set in “gso_type” as well,
- indicating that the TCP packet has the ECN bit set.[footnote:
-This case is not handled by some older hardware, so is called out
-specifically in the protocol.
-]
-
- If the driver negotiated the VIRTIO_NET_F_MRG_RXBUF feature,
- the num_buffers field is set to zero.
-
- The header and packet are added as one output buffer to the
- transmitq, and the device is notified of the new entry (see [sub:Notifying-The-Device]
- ).[footnote:
-Note that the header will be two bytes longer for the
-VIRTIO_NET_F_MRG_RXBUF case.
-]
-
- Packet Transmission Interrupt
-
-Often a driver will suppress transmission interrupts using the
-VRING_AVAIL_F_NO_INTERRUPT flag (see [sub:Receiving-Used-Buffers]
-) and check for used packets in the transmit path of following
-packets. However, it will still receive interrupts if the
-VIRTIO_F_NOTIFY_ON_EMPTY feature is negotiated, indicating that
-the transmission queue is completely emptied.
-
-The normal behavior in this interrupt handler is to retrieve and
-new descriptors from the used ring and free the corresponding
-headers and packets.
-
- Setting Up Receive Buffers
-
-It is generally a good idea to keep the receive virtqueue as
-fully populated as possible: if it runs out, network performance
-will suffer.
-
-If the VIRTIO_NET_F_GUEST_TSO4, VIRTIO_NET_F_GUEST_TSO6 or
-VIRTIO_NET_F_GUEST_UFO features are used, the Guest will need to
-accept packets of up to 65550 bytes long (the maximum size of a
-TCP or UDP packet, plus the 14 byte ethernet header), otherwise
-1514 bytes. So unless VIRTIO_NET_F_MRG_RXBUF is negotiated, every
-buffer in the receive queue needs to be at least this length [footnote:
-Obviously each one can be split across multiple descriptor
-elements.
-].
-
-If VIRTIO_NET_F_MRG_RXBUF is negotiated, each buffer must be at
-least the size of the struct virtio_net_hdr.
-
- Packet Receive Interrupt
-
-When a packet is copied into a buffer in the receiveq, the
-optimal path is to disable further interrupts for the receiveq
-(see [sub:Receiving-Used-Buffers]) and process packets until no
-more are found, then re-enable them.
-
-Processing packet involves:
-
- If the driver negotiated the VIRTIO_NET_F_MRG_RXBUF feature,
- then the “num_buffers” field indicates how many descriptors
- this packet is spread over (including this one). This allows
- receipt of large packets without having to allocate large
- buffers. In this case, there will be at least “num_buffers” in
- the used ring, and they should be chained together to form a
- single packet. The other buffers will not begin with a struct
- virtio_net_hdr.
-
- If the VIRTIO_NET_F_MRG_RXBUF feature was not negotiated, or
- the “num_buffers” field is one, then the entire packet will be
- contained within this buffer, immediately following the struct
- virtio_net_hdr.
-
- If the VIRTIO_NET_F_GUEST_CSUM feature was negotiated, the
- VIRTIO_NET_HDR_F_NEEDS_CSUM bit in the “flags” field may be
- set: if so, the checksum on the packet is incomplete and the “
- csum_start” and “csum_offset” fields indicate how to calculate
- it (see [ite:csum_start-is-set]).
-
- If the VIRTIO_NET_F_GUEST_TSO4, TSO6 or UFO options were
- negotiated, then the “gso_type” may be something other than
- VIRTIO_NET_HDR_GSO_NONE, and the “gso_size” field indicates the
- desired MSS (see [enu:If-the-driver]).
-
- Control Virtqueue
-
-The driver uses the control virtqueue (if VIRTIO_NET_F_VTRL_VQ is
-negotiated) to send commands to manipulate various features of
-the device which would not easily map into the configuration
-space.
-
-All commands are of the following form:
-
-struct virtio_net_ctrl {
-
- u8 class;
-
- u8 command;
-
- u8 command-specific-data[];
-
- u8 ack;
-
-};
-
-
-
-/* ack values */
-
-#define VIRTIO_NET_OK 0
-
-#define VIRTIO_NET_ERR 1
-
-The class, command and command-specific-data are set by the
-driver, and the device sets the ack byte. There is little it can
-do except issue a diagnostic if the ack byte is not
-VIRTIO_NET_OK.
-
- Packet Receive Filtering
-
-If the VIRTIO_NET_F_CTRL_RX feature is negotiated, the driver can
-send control commands for promiscuous mode, multicast receiving,
-and filtering of MAC addresses.
-
-Note that in general, these commands are best-effort: unwanted
-packets may still arrive.
-
- Setting Promiscuous Mode
-
-#define VIRTIO_NET_CTRL_RX 0
-
- #define VIRTIO_NET_CTRL_RX_PROMISC 0
-
- #define VIRTIO_NET_CTRL_RX_ALLMULTI 1
-
-The class VIRTIO_NET_CTRL_RX has two commands:
-VIRTIO_NET_CTRL_RX_PROMISC turns promiscuous mode on and off, and
-VIRTIO_NET_CTRL_RX_ALLMULTI turns all-multicast receive on and
-off. The command-specific-data is one byte containing 0 (off) or
-1 (on).
-
- Setting MAC Address Filtering
-
-struct virtio_net_ctrl_mac {
-
- u32 entries;
-
- u8 macs[entries][ETH_ALEN];
-
-};
-
-
-
-#define VIRTIO_NET_CTRL_MAC 1
-
- #define VIRTIO_NET_CTRL_MAC_TABLE_SET 0
-
-The device can filter incoming packets by any number of
-destination MAC addresses.[footnote:
-Since there are no guarentees, it can use a hash filter
-orsilently switch to allmulti or promiscuous mode if it is given
-too many addresses.
-] This table is set using the class VIRTIO_NET_CTRL_MAC and the
-command VIRTIO_NET_CTRL_MAC_TABLE_SET. The command-specific-data
-is two variable length tables of 6-byte MAC addresses. The first
-table contains unicast addresses, and the second contains
-multicast addresses.
-
- VLAN Filtering
-
-If the driver negotiates the VIRTION_NET_F_CTRL_VLAN feature, it
-can control a VLAN filter table in the device.
-
-#define VIRTIO_NET_CTRL_VLAN 2
-
- #define VIRTIO_NET_CTRL_VLAN_ADD 0
-
- #define VIRTIO_NET_CTRL_VLAN_DEL 1
-
-Both the VIRTIO_NET_CTRL_VLAN_ADD and VIRTIO_NET_CTRL_VLAN_DEL
-command take a 16-bit VLAN id as the command-specific-data.
-
- Gratuitous Packet Sending
-
-If the driver negotiates the VIRTIO_NET_F_GUEST_ANNOUNCE (depends
-on VIRTIO_NET_F_CTRL_VQ), it can ask the guest to send gratuitous
-packets; this is usually done after the guest has been physically
-migrated, and needs to announce its presence on the new network
-links. (As hypervisor does not have the knowledge of guest
-network configuration (eg. tagged vlan) it is simplest to prod
-the guest in this way).
-
-#define VIRTIO_NET_CTRL_ANNOUNCE 3
-
- #define VIRTIO_NET_CTRL_ANNOUNCE_ACK 0
-
-The Guest needs to check VIRTIO_NET_S_ANNOUNCE bit in status
-field when it notices the changes of device configuration. The
-command VIRTIO_NET_CTRL_ANNOUNCE_ACK is used to indicate that
-driver has recevied the notification and device would clear the
-VIRTIO_NET_S_ANNOUNCE bit in the status filed after it received
-this command.
-
-Processing this notification involves:
-
- Sending the gratuitous packets or marking there are pending
- gratuitous packets to be sent and letting deferred routine to
- send them.
-
- Sending VIRTIO_NET_CTRL_ANNOUNCE_ACK command through control
- vq.
-
- .
-
-Appendix D: Block Device
-
-The virtio block device is a simple virtual block device (ie.
-disk). Read and write requests (and other exotic requests) are
-placed in the queue, and serviced (probably out of order) by the
-device except where noted.
-
- Configuration
-
- Subsystem Device ID 2
-
- Virtqueues 0:requestq.
-
- Feature bits
-
- VIRTIO_BLK_F_BARRIER (0) Host supports request barriers.
-
- VIRTIO_BLK_F_SIZE_MAX (1) Maximum size of any single segment is
- in “size_max”.
-
- VIRTIO_BLK_F_SEG_MAX (2) Maximum number of segments in a
- request is in “seg_max”.
-
- VIRTIO_BLK_F_GEOMETRY (4) Disk-style geometry specified in “
- geometry”.
-
- VIRTIO_BLK_F_RO (5) Device is read-only.
-
- VIRTIO_BLK_F_BLK_SIZE (6) Block size of disk is in “blk_size”.
-
- VIRTIO_BLK_F_SCSI (7) Device supports scsi packet commands.
-
- VIRTIO_BLK_F_FLUSH (9) Cache flush command support.
-
- Device configuration layout The capacity of the device
- (expressed in 512-byte sectors) is always present. The
- availability of the others all depend on various feature bits
- as indicated above. struct virtio_blk_config {
-
- u64 capacity;
-
- u32 size_max;
-
- u32 seg_max;
-
- struct virtio_blk_geometry {
-
- u16 cylinders;
-
- u8 heads;
-
- u8 sectors;
-
- } geometry;
-
- u32 blk_size;
-
-
-
-};
-
- Device Initialization
-
- The device size should be read from the “capacity”
- configuration field. No requests should be submitted which goes
- beyond this limit.
-
- If the VIRTIO_BLK_F_BLK_SIZE feature is negotiated, the
- blk_size field can be read to determine the optimal sector size
- for the driver to use. This does not effect the units used in
- the protocol (always 512 bytes), but awareness of the correct
- value can effect performance.
-
- If the VIRTIO_BLK_F_RO feature is set by the device, any write
- requests will fail.
-
- Device Operation
-
-The driver queues requests to the virtqueue, and they are used by
-the device (not necessarily in order). Each request is of form:
-
-struct virtio_blk_req {
-
-
-
- u32 type;
-
- u32 ioprio;
-
- u64 sector;
-
- char data[][512];
-
- u8 status;
-
-};
-
-If the device has VIRTIO_BLK_F_SCSI feature, it can also support
-scsi packet command requests, each of these requests is of form:struct virtio_scsi_pc_req {
-
- u32 type;
-
- u32 ioprio;
-
- u64 sector;
-
- char cmd[];
-
- char data[][512];
-
-#define SCSI_SENSE_BUFFERSIZE 96
-
- u8 sense[SCSI_SENSE_BUFFERSIZE];
-
- u32 errors;
-
- u32 data_len;
-
- u32 sense_len;
-
- u32 residual;
-
- u8 status;
-
-};
-
-The type of the request is either a read (VIRTIO_BLK_T_IN), a
-write (VIRTIO_BLK_T_OUT), a scsi packet command
-(VIRTIO_BLK_T_SCSI_CMD or VIRTIO_BLK_T_SCSI_CMD_OUT[footnote:
-the SCSI_CMD and SCSI_CMD_OUT types are equivalent, the device
-does not distinguish between them
-]) or a flush (VIRTIO_BLK_T_FLUSH or VIRTIO_BLK_T_FLUSH_OUT[footnote:
-the FLUSH and FLUSH_OUT types are equivalent, the device does not
-distinguish between them
-]). If the device has VIRTIO_BLK_F_BARRIER feature the high bit
-(VIRTIO_BLK_T_BARRIER) indicates that this request acts as a
-barrier and that all preceeding requests must be complete before
-this one, and all following requests must not be started until
-this is complete. Note that a barrier does not flush caches in
-the underlying backend device in host, and thus does not serve as
-data consistency guarantee. Driver must use FLUSH request to
-flush the host cache.
-
-#define VIRTIO_BLK_T_IN 0
-
-#define VIRTIO_BLK_T_OUT 1
-
-#define VIRTIO_BLK_T_SCSI_CMD 2
-
-#define VIRTIO_BLK_T_SCSI_CMD_OUT 3
-
-#define VIRTIO_BLK_T_FLUSH 4
-
-#define VIRTIO_BLK_T_FLUSH_OUT 5
-
-#define VIRTIO_BLK_T_BARRIER 0x80000000
-
-The ioprio field is a hint about the relative priorities of
-requests to the device: higher numbers indicate more important
-requests.
-
-The sector number indicates the offset (multiplied by 512) where
-the read or write is to occur. This field is unused and set to 0
-for scsi packet commands and for flush commands.
-
-The cmd field is only present for scsi packet command requests,
-and indicates the command to perform. This field must reside in a
-single, separate read-only buffer; command length can be derived
-from the length of this buffer.
-
-Note that these first three (four for scsi packet commands)
-fields are always read-only: the data field is either read-only
-or write-only, depending on the request. The size of the read or
-write can be derived from the total size of the request buffers.
-
-The sense field is only present for scsi packet command requests,
-and indicates the buffer for scsi sense data.
-
-The data_len field is only present for scsi packet command
-requests, this field is deprecated, and should be ignored by the
-driver. Historically, devices copied data length there.
-
-The sense_len field is only present for scsi packet command
-requests and indicates the number of bytes actually written to
-the sense buffer.
-
-The residual field is only present for scsi packet command
-requests and indicates the residual size, calculated as data
-length - number of bytes actually transferred.
-
-The final status byte is written by the device: either
-VIRTIO_BLK_S_OK for success, VIRTIO_BLK_S_IOERR for host or guest
-error or VIRTIO_BLK_S_UNSUPP for a request unsupported by host:#define VIRTIO_BLK_S_OK 0
-
-#define VIRTIO_BLK_S_IOERR 1
-
-#define VIRTIO_BLK_S_UNSUPP 2
-
-Historically, devices assumed that the fields type, ioprio and
-sector reside in a single, separate read-only buffer; the fields
-errors, data_len, sense_len and residual reside in a single,
-separate write-only buffer; the sense field in a separate
-write-only buffer of size 96 bytes, by itself; the fields errors,
-data_len, sense_len and residual in a single write-only buffer;
-and the status field is a separate read-only buffer of size 1
-byte, by itself.
-
-Appendix E: Console Device
-
-The virtio console device is a simple device for data input and
-output. A device may have one or more ports. Each port has a pair
-of input and output virtqueues. Moreover, a device has a pair of
-control IO virtqueues. The control virtqueues are used to
-communicate information between the device and the driver about
-ports being opened and closed on either side of the connection,
-indication from the host about whether a particular port is a
-console port, adding new ports, port hot-plug/unplug, etc., and
-indication from the guest about whether a port or a device was
-successfully added, port open/close, etc.. For data IO, one or
-more empty buffers are placed in the receive queue for incoming
-data and outgoing characters are placed in the transmit queue.
-
- Configuration
-
- Subsystem Device ID 3
-
- Virtqueues 0:receiveq(port0). 1:transmitq(port0), 2:control
- receiveq[footnote:
-Ports 2 onwards only if VIRTIO_CONSOLE_F_MULTIPORT is set
-], 3:control transmitq, 4:receiveq(port1), 5:transmitq(port1),
- ...
-
- Feature bits
-
- VIRTIO_CONSOLE_F_SIZE (0) Configuration cols and rows fields
- are valid.
-
- VIRTIO_CONSOLE_F_MULTIPORT(1) Device has support for multiple
- ports; configuration fields nr_ports and max_nr_ports are
- valid and control virtqueues will be used.
-
- Device configuration layout The size of the console is supplied
- in the configuration space if the VIRTIO_CONSOLE_F_SIZE feature
- is set. Furthermore, if the VIRTIO_CONSOLE_F_MULTIPORT feature
- is set, the maximum number of ports supported by the device can
- be fetched.struct virtio_console_config {
-
- u16 cols;
-
- u16 rows;
-
-
-
- u32 max_nr_ports;
-
-};
-
- Device Initialization
-
- If the VIRTIO_CONSOLE_F_SIZE feature is negotiated, the driver
- can read the console dimensions from the configuration fields.
-
- If the VIRTIO_CONSOLE_F_MULTIPORT feature is negotiated, the
- driver can spawn multiple ports, not all of which may be
- attached to a console. Some could be generic ports. In this
- case, the control virtqueues are enabled and according to the
- max_nr_ports configuration-space value, the appropriate number
- of virtqueues are created. A control message indicating the
- driver is ready is sent to the host. The host can then send
- control messages for adding new ports to the device. After
- creating and initializing each port, a
- VIRTIO_CONSOLE_PORT_READY control message is sent to the host
- for that port so the host can let us know of any additional
- configuration options set for that port.
-
- The receiveq for each port is populated with one or more
- receive buffers.
-
- Device Operation
-
- For output, a buffer containing the characters is placed in the
- port's transmitq.[footnote:
-Because this is high importance and low bandwidth, the current
-Linux implementation polls for the buffer to be used, rather than
-waiting for an interrupt, simplifying the implementation
-significantly. However, for generic serial ports with the
-O_NONBLOCK flag set, the polling limitation is relaxed and the
-consumed buffers are freed upon the next write or poll call or
-when a port is closed or hot-unplugged.
-]
-
- When a buffer is used in the receiveq (signalled by an
- interrupt), the contents is the input to the port associated
- with the virtqueue for which the notification was received.
-
- If the driver negotiated the VIRTIO_CONSOLE_F_SIZE feature, a
- configuration change interrupt may occur. The updated size can
- be read from the configuration fields.
-
- If the driver negotiated the VIRTIO_CONSOLE_F_MULTIPORT
- feature, active ports are announced by the host using the
- VIRTIO_CONSOLE_PORT_ADD control message. The same message is
- used for port hot-plug as well.
-
- If the host specified a port `name', a sysfs attribute is
- created with the name filled in, so that udev rules can be
- written that can create a symlink from the port's name to the
- char device for port discovery by applications in the guest.
-
- Changes to ports' state are effected by control messages.
- Appropriate action is taken on the port indicated in the
- control message. The layout of the structure of the control
- buffer and the events associated are:struct virtio_console_control {
-
- uint32_t id; /* Port number */
-
- uint16_t event; /* The kind of control event */
-
- uint16_t value; /* Extra information for the event */
-
-};
-
-
-
-/* Some events for the internal messages (control packets) */
-
-
-
-#define VIRTIO_CONSOLE_DEVICE_READY 0
-
-#define VIRTIO_CONSOLE_PORT_ADD 1
-
-#define VIRTIO_CONSOLE_PORT_REMOVE 2
-
-#define VIRTIO_CONSOLE_PORT_READY 3
-
-#define VIRTIO_CONSOLE_CONSOLE_PORT 4
-
-#define VIRTIO_CONSOLE_RESIZE 5
-
-#define VIRTIO_CONSOLE_PORT_OPEN 6
-
-#define VIRTIO_CONSOLE_PORT_NAME 7
-
-Appendix F: Entropy Device
-
-The virtio entropy device supplies high-quality randomness for
-guest use.
-
- Configuration
-
- Subsystem Device ID 4
-
- Virtqueues 0:requestq.
-
- Feature bits None currently defined
-
- Device configuration layout None currently defined.
-
- Device Initialization
-
- The virtqueue is initialized
-
- Device Operation
-
-When the driver requires random bytes, it places the descriptor
-of one or more buffers in the queue. It will be completely filled
-by random data by the device.
-
-Appendix G: Memory Balloon Device
-
-The virtio memory balloon device is a primitive device for
-managing guest memory: the device asks for a certain amount of
-memory, and the guest supplies it (or withdraws it, if the device
-has more than it asks for). This allows the guest to adapt to
-changes in allowance of underlying physical memory. If the
-feature is negotiated, the device can also be used to communicate
-guest memory statistics to the host.
-
- Configuration
-
- Subsystem Device ID 5
-
- Virtqueues 0:inflateq. 1:deflateq. 2:statsq.[footnote:
-Only if VIRTIO_BALLON_F_STATS_VQ set
-]
-
- Feature bits
-
- VIRTIO_BALLOON_F_MUST_TELL_HOST (0) Host must be told before
- pages from the balloon are used.
-
- VIRTIO_BALLOON_F_STATS_VQ (1) A virtqueue for reporting guest
- memory statistics is present.
-
- Device configuration layout Both fields of this configuration
- are always available. Note that they are little endian, despite
- convention that device fields are guest endian:struct virtio_balloon_config {
-
- u32 num_pages;
-
- u32 actual;
-
-};
-
- Device Initialization
-
- The inflate and deflate virtqueues are identified.
-
- If the VIRTIO_BALLOON_F_STATS_VQ feature bit is negotiated:
-
- Identify the stats virtqueue.
-
- Add one empty buffer to the stats virtqueue and notify the
- host.
-
-Device operation begins immediately.
-
- Device Operation
-
- Memory Ballooning The device is driven by the receipt of a
- configuration change interrupt.
-
- The “num_pages” configuration field is examined. If this is
- greater than the “actual” number of pages, memory must be given
- to the balloon. If it is less than the “actual” number of
- pages, memory may be taken back from the balloon for general
- use.
-
- To supply memory to the balloon (aka. inflate):
-
- The driver constructs an array of addresses of unused memory
- pages. These addresses are divided by 4096[footnote:
-This is historical, and independent of the guest page size
-] and the descriptor describing the resulting 32-bit array is
- added to the inflateq.
-
- To remove memory from the balloon (aka. deflate):
-
- The driver constructs an array of addresses of memory pages it
- has previously given to the balloon, as described above. This
- descriptor is added to the deflateq.
-
- If the VIRTIO_BALLOON_F_MUST_TELL_HOST feature is set, the
- guest may not use these requested pages until that descriptor
- in the deflateq has been used by the device.
-
- Otherwise, the guest may begin to re-use pages previously given
- to the balloon before the device has acknowledged their
- withdrawl. [footnote:
-In this case, deflation advice is merely a courtesy
-]
-
- In either case, once the device has completed the inflation or
- deflation, the “actual” field of the configuration should be
- updated to reflect the new number of pages in the balloon.[footnote:
-As updates to configuration space are not atomic, this field
-isn't particularly reliable, but can be used to diagnose buggy
-guests.
-]
-
- Memory Statistics
-
-The stats virtqueue is atypical because communication is driven
-by the device (not the driver). The channel becomes active at
-driver initialization time when the driver adds an empty buffer
-and notifies the device. A request for memory statistics proceeds
-as follows:
-
- The device pushes the buffer onto the used ring and sends an
- interrupt.
-
- The driver pops the used buffer and discards it.
-
- The driver collects memory statistics and writes them into a
- new buffer.
-
- The driver adds the buffer to the virtqueue and notifies the
- device.
-
- The device pops the buffer (retaining it to initiate a
- subsequent request) and consumes the statistics.
-
- Memory Statistics Format Each statistic consists of a 16 bit
- tag and a 64 bit value. Both quantities are represented in the
- native endian of the guest. All statistics are optional and the
- driver may choose which ones to supply. To guarantee backwards
- compatibility, unsupported statistics should be omitted.
-
- struct virtio_balloon_stat {
-
-#define VIRTIO_BALLOON_S_SWAP_IN 0
-
-#define VIRTIO_BALLOON_S_SWAP_OUT 1
-
-#define VIRTIO_BALLOON_S_MAJFLT 2
-
-#define VIRTIO_BALLOON_S_MINFLT 3
-
-#define VIRTIO_BALLOON_S_MEMFREE 4
-
-#define VIRTIO_BALLOON_S_MEMTOT 5
-
- u16 tag;
-
- u64 val;
-
-} __attribute__((packed));
-
- Tags
-
- VIRTIO_BALLOON_S_SWAP_IN The amount of memory that has been
- swapped in (in bytes).
-
- VIRTIO_BALLOON_S_SWAP_OUT The amount of memory that has been
- swapped out to disk (in bytes).
-
- VIRTIO_BALLOON_S_MAJFLT The number of major page faults that
- have occurred.
-
- VIRTIO_BALLOON_S_MINFLT The number of minor page faults that
- have occurred.
-
- VIRTIO_BALLOON_S_MEMFREE The amount of memory not being used
- for any purpose (in bytes).
-
- VIRTIO_BALLOON_S_MEMTOT The total amount of memory available
- (in bytes).
-
-Appendix H: Rpmsg: Remote Processor Messaging
-
-Virtio rpmsg devices represent remote processors on the system
-which run in asymmetric multi-processing (AMP) configuration, and
-which are usually used to offload cpu-intensive tasks from the
-main application processor (a typical SoC methodology).
-
-Virtio is being used to communicate with those remote processors;
-empty buffers are placed in one virtqueue for receiving messages,
-and non-empty buffers, containing outbound messages, are enqueued
-in a second virtqueue for transmission.
-
-Numerous communication channels can be multiplexed over those two
-virtqueues, so different entities, running on the application and
-remote processor, can directly communicate in a point-to-point
-fashion.
-
- Configuration
-
- Subsystem Device ID 7
-
- Virtqueues 0:receiveq. 1:transmitq.
-
- Feature bits
-
- VIRTIO_RPMSG_F_NS (0) Device sends (and capable of receiving)
- name service messages announcing the creation (or
- destruction) of a channel:/**
-
- * struct rpmsg_ns_msg - dynamic name service announcement
-message
-
- * @name: name of remote service that is published
-
- * @addr: address of remote service that is published
-
- * @flags: indicates whether service is created or destroyed
-
- *
-
- * This message is sent across to publish a new service (or
-announce
-
- * about its removal). When we receives these messages, an
-appropriate
-
- * rpmsg channel (i.e device) is created/destroyed.
-
- */
-
-struct rpmsg_ns_msgoon_config {
-
- char name[RPMSG_NAME_SIZE];
-
- u32 addr;
-
- u32 flags;
-
-} __packed;
-
-
-
-/**
-
- * enum rpmsg_ns_flags - dynamic name service announcement flags
-
- *
-
- * @RPMSG_NS_CREATE: a new remote service was just created
-
- * @RPMSG_NS_DESTROY: a remote service was just destroyed
-
- */
-
-enum rpmsg_ns_flags {
-
- RPMSG_NS_CREATE = 0,
-
- RPMSG_NS_DESTROY = 1,
-
-};
-
- Device configuration layout
-
-At his point none currently defined.
-
- Device Initialization
-
- The initialization routine should identify the receive and
- transmission virtqueues.
-
- The receive virtqueue should be filled with receive buffers.
-
- Device Operation
-
-Messages are transmitted by placing them in the transmitq, and
-buffers for inbound messages are placed in the receiveq. In any
-case, messages are always preceded by the following header: /**
-
- * struct rpmsg_hdr - common header for all rpmsg messages
-
- * @src: source address
-
- * @dst: destination address
-
- * @reserved: reserved for future use
-
- * @len: length of payload (in bytes)
-
- * @flags: message flags
-
- * @data: @len bytes of message payload data
-
- *
-
- * Every message sent(/received) on the rpmsg bus begins with
-this header.
-
- */
-
-struct rpmsg_hdr {
-
- u32 src;
-
- u32 dst;
-
- u32 reserved;
-
- u16 len;
-
- u16 flags;
-
- u8 data[0];
-
-} __packed;
-
-Appendix I: SCSI Host Device
-
-The virtio SCSI host device groups together one or more virtual
-logical units (such as disks), and allows communicating to them
-using the SCSI protocol. An instance of the device represents a
-SCSI host to which many targets and LUNs are attached.
-
-The virtio SCSI device services two kinds of requests:
-
- command requests for a logical unit;
-
- task management functions related to a logical unit, target or
- command.
-
-The device is also able to send out notifications about added and
-removed logical units. Together, these capabilities provide a
-SCSI transport protocol that uses virtqueues as the transfer
-medium. In the transport protocol, the virtio driver acts as the
-initiator, while the virtio SCSI host provides one or more
-targets that receive and process the requests.
-
- Configuration
-
- Subsystem Device ID 8
-
- Virtqueues 0:controlq; 1:eventq; 2..n:request queues.
-
- Feature bits
-
- VIRTIO_SCSI_F_INOUT (0) A single request can include both
- read-only and write-only data buffers.
-
- VIRTIO_SCSI_F_HOTPLUG (1) The host should enable
- hot-plug/hot-unplug of new LUNs and targets on the SCSI bus.
-
- Device configuration layout All fields of this configuration
- are always available. sense_size and cdb_size are writable by
- the guest.struct virtio_scsi_config {
-
- u32 num_queues;
-
- u32 seg_max;
-
- u32 max_sectors;
-
- u32 cmd_per_lun;
-
- u32 event_info_size;
-
- u32 sense_size;
-
- u32 cdb_size;
-
- u16 max_channel;
-
- u16 max_target;
-
- u32 max_lun;
-
-};
-
- num_queues is the total number of request virtqueues exposed by
- the device. The driver is free to use only one request queue,
- or it can use more to achieve better performance.
-
- seg_max is the maximum number of segments that can be in a
- command. A bidirectional command can include seg_max input
- segments and seg_max output segments.
-
- max_sectors is a hint to the guest about the maximum transfer
- size it should use.
-
- cmd_per_lun is a hint to the guest about the maximum number of
- linked commands it should send to one LUN. The actual value
- to be used is the minimum of cmd_per_lun and the virtqueue
- size.
-
- event_info_size is the maximum size that the device will fill
- for buffers that the driver places in the eventq. The driver
- should always put buffers at least of this size. It is
- written by the device depending on the set of negotated
- features.
-
- sense_size is the maximum size of the sense data that the
- device will write. The default value is written by the device
- and will always be 96, but the driver can modify it. It is
- restored to the default when the device is reset.
-
- cdb_size is the maximum size of the CDB that the driver will
- write. The default value is written by the device and will
- always be 32, but the driver can likewise modify it. It is
- restored to the default when the device is reset.
-
- max_channel, max_target and max_lun can be used by the driver
- as hints to constrain scanning the logical units on the
- host.h
-
- Device Initialization
-
-The initialization routine should first of all discover the
-device's virtqueues.
-
-If the driver uses the eventq, it should then place at least a
-buffer in the eventq.
-
-The driver can immediately issue requests (for example, INQUIRY
-or REPORT LUNS) or task management functions (for example, I_T
-RESET).
-
- Device Operation: request queues
-
-The driver queues requests to an arbitrary request queue, and
-they are used by the device on that same queue. It is the
-responsibility of the driver to ensure strict request ordering
-for commands placed on different queues, because they will be
-consumed with no order constraints.
-
-Requests have the following format:
-
-struct virtio_scsi_req_cmd {
-
- // Read-only
-
- u8 lun[8];
-
- u64 id;
-
- u8 task_attr;
-
- u8 prio;
-
- u8 crn;
-
- char cdb[cdb_size];
-
- char dataout[];
-
- // Write-only part
-
- u32 sense_len;
-
- u32 residual;
-
- u16 status_qualifier;
-
- u8 status;
-
- u8 response;
-
- u8 sense[sense_size];
-
- char datain[];
-
-};
-
-
-
-/* command-specific response values */
-
-#define VIRTIO_SCSI_S_OK 0
-
-#define VIRTIO_SCSI_S_OVERRUN 1
-
-#define VIRTIO_SCSI_S_ABORTED 2
-
-#define VIRTIO_SCSI_S_BAD_TARGET 3
-
-#define VIRTIO_SCSI_S_RESET 4
-
-#define VIRTIO_SCSI_S_BUSY 5
-
-#define VIRTIO_SCSI_S_TRANSPORT_FAILURE 6
-
-#define VIRTIO_SCSI_S_TARGET_FAILURE 7
-
-#define VIRTIO_SCSI_S_NEXUS_FAILURE 8
-
-#define VIRTIO_SCSI_S_FAILURE 9
-
-
-
-/* task_attr */
-
-#define VIRTIO_SCSI_S_SIMPLE 0
-
-#define VIRTIO_SCSI_S_ORDERED 1
-
-#define VIRTIO_SCSI_S_HEAD 2
-
-#define VIRTIO_SCSI_S_ACA 3
-
-The lun field addresses a target and logical unit in the
-virtio-scsi device's SCSI domain. The only supported format for
-the LUN field is: first byte set to 1, second byte set to target,
-third and fourth byte representing a single level LUN structure,
-followed by four zero bytes. With this representation, a
-virtio-scsi device can serve up to 256 targets and 16384 LUNs per
-target.
-
-The id field is the command identifier (“tag”).
-
-task_attr, prio and crn should be left to zero. task_attr defines
-the task attribute as in the table above, but all task attributes
-may be mapped to SIMPLE by the device; crn may also be provided
-by clients, but is generally expected to be 0. The maximum CRN
-value defined by the protocol is 255, since CRN is stored in an
-8-bit integer.
-
-All of these fields are defined in SAM. They are always
-read-only, as are the cdb and dataout field. The cdb_size is
-taken from the configuration space.
-
-sense and subsequent fields are always write-only. The sense_len
-field indicates the number of bytes actually written to the sense
-buffer. The residual field indicates the residual size,
-calculated as “data_length - number_of_transferred_bytes”, for
-read or write operations. For bidirectional commands, the
-number_of_transferred_bytes includes both read and written bytes.
-A residual field that is less than the size of datain means that
-the dataout field was processed entirely. A residual field that
-exceeds the size of datain means that the dataout field was
-processed partially and the datain field was not processed at
-all.
-
-The status byte is written by the device to be the status code as
-defined in SAM.
-
-The response byte is written by the device to be one of the
-following:
-
- VIRTIO_SCSI_S_OK when the request was completed and the status
- byte is filled with a SCSI status code (not necessarily
- "GOOD").
-
- VIRTIO_SCSI_S_OVERRUN if the content of the CDB requires
- transferring more data than is available in the data buffers.
-
- VIRTIO_SCSI_S_ABORTED if the request was cancelled due to an
- ABORT TASK or ABORT TASK SET task management function.
-
- VIRTIO_SCSI_S_BAD_TARGET if the request was never processed
- because the target indicated by the lun field does not exist.
-
- VIRTIO_SCSI_S_RESET if the request was cancelled due to a bus
- or device reset (including a task management function).
-
- VIRTIO_SCSI_S_TRANSPORT_FAILURE if the request failed due to a
- problem in the connection between the host and the target
- (severed link).
-
- VIRTIO_SCSI_S_TARGET_FAILURE if the target is suffering a
- failure and the guest should not retry on other paths.
-
- VIRTIO_SCSI_S_NEXUS_FAILURE if the nexus is suffering a failure
- but retrying on other paths might yield a different result.
-
- VIRTIO_SCSI_S_BUSY if the request failed but retrying on the
- same path should work.
-
- VIRTIO_SCSI_S_FAILURE for other host or guest error. In
- particular, if neither dataout nor datain is empty, and the
- VIRTIO_SCSI_F_INOUT feature has not been negotiated, the
- request will be immediately returned with a response equal to
- VIRTIO_SCSI_S_FAILURE.
-
- Device Operation: controlq
-
-The controlq is used for other SCSI transport operations.
-Requests have the following format:
-
-struct virtio_scsi_ctrl {
-
- u32 type;
-
- ...
-
- u8 response;
-
-};
-
-
-
-/* response values valid for all commands */
-
-#define VIRTIO_SCSI_S_OK 0
-
-#define VIRTIO_SCSI_S_BAD_TARGET 3
-
-#define VIRTIO_SCSI_S_BUSY 5
-
-#define VIRTIO_SCSI_S_TRANSPORT_FAILURE 6
-
-#define VIRTIO_SCSI_S_TARGET_FAILURE 7
-
-#define VIRTIO_SCSI_S_NEXUS_FAILURE 8
-
-#define VIRTIO_SCSI_S_FAILURE 9
-
-#define VIRTIO_SCSI_S_INCORRECT_LUN 12
-
-The type identifies the remaining fields.
-
-The following commands are defined:
-
- Task management function
-#define VIRTIO_SCSI_T_TMF 0
-
-
-
-#define VIRTIO_SCSI_T_TMF_ABORT_TASK 0
-
-#define VIRTIO_SCSI_T_TMF_ABORT_TASK_SET 1
-
-#define VIRTIO_SCSI_T_TMF_CLEAR_ACA 2
-
-#define VIRTIO_SCSI_T_TMF_CLEAR_TASK_SET 3
-
-#define VIRTIO_SCSI_T_TMF_I_T_NEXUS_RESET 4
-
-#define VIRTIO_SCSI_T_TMF_LOGICAL_UNIT_RESET 5
-
-#define VIRTIO_SCSI_T_TMF_QUERY_TASK 6
-
-#define VIRTIO_SCSI_T_TMF_QUERY_TASK_SET 7
-
-
-
-struct virtio_scsi_ctrl_tmf
-
-{
-
- // Read-only part
-
- u32 type;
-
- u32 subtype;
-
- u8 lun[8];
-
- u64 id;
-
- // Write-only part
-
- u8 response;
-
-}
-
-
-
-/* command-specific response values */
-
-#define VIRTIO_SCSI_S_FUNCTION_COMPLETE 0
-
-#define VIRTIO_SCSI_S_FUNCTION_SUCCEEDED 10
-
-#define VIRTIO_SCSI_S_FUNCTION_REJECTED 11
-
- The type is VIRTIO_SCSI_T_TMF; the subtype field defines. All
- fields except response are filled by the driver. The subtype
- field must always be specified and identifies the requested
- task management function.
-
- Other fields may be irrelevant for the requested TMF; if so,
- they are ignored but they should still be present. The lun
- field is in the same format specified for request queues; the
- single level LUN is ignored when the task management function
- addresses a whole I_T nexus. When relevant, the value of the id
- field is matched against the id values passed on the requestq.
-
- The outcome of the task management function is written by the
- device in the response field. The command-specific response
- values map 1-to-1 with those defined in SAM.
-
- Asynchronous notification query
-#define VIRTIO_SCSI_T_AN_QUERY 1
-
-
-
-struct virtio_scsi_ctrl_an {
-
- // Read-only part
-
- u32 type;
-
- u8 lun[8];
-
- u32 event_requested;
-
- // Write-only part
-
- u32 event_actual;
-
- u8 response;
-
-}
-
-
-
-#define VIRTIO_SCSI_EVT_ASYNC_OPERATIONAL_CHANGE 2
-
-#define VIRTIO_SCSI_EVT_ASYNC_POWER_MGMT 4
-
-#define VIRTIO_SCSI_EVT_ASYNC_EXTERNAL_REQUEST 8
-
-#define VIRTIO_SCSI_EVT_ASYNC_MEDIA_CHANGE 16
-
-#define VIRTIO_SCSI_EVT_ASYNC_MULTI_HOST 32
-
-#define VIRTIO_SCSI_EVT_ASYNC_DEVICE_BUSY 64
-
- By sending this command, the driver asks the device which
- events the given LUN can report, as described in paragraphs 6.6
- and A.6 of the SCSI MMC specification. The driver writes the
- events it is interested in into the event_requested; the device
- responds by writing the events that it supports into
- event_actual.
-
- The type is VIRTIO_SCSI_T_AN_QUERY. The lun and event_requested
- fields are written by the driver. The event_actual and response
- fields are written by the device.
-
- No command-specific values are defined for the response byte.
-
- Asynchronous notification subscription
-#define VIRTIO_SCSI_T_AN_SUBSCRIBE 2
-
-
-
-struct virtio_scsi_ctrl_an {
-
- // Read-only part
-
- u32 type;
-
- u8 lun[8];
-
- u32 event_requested;
-
- // Write-only part
-
- u32 event_actual;
-
- u8 response;
-
-}
-
- By sending this command, the driver asks the specified LUN to
- report events for its physical interface, again as described in
- the SCSI MMC specification. The driver writes the events it is
- interested in into the event_requested; the device responds by
- writing the events that it supports into event_actual.
-
- Event types are the same as for the asynchronous notification
- query message.
-
- The type is VIRTIO_SCSI_T_AN_SUBSCRIBE. The lun and
- event_requested fields are written by the driver. The
- event_actual and response fields are written by the device.
-
- No command-specific values are defined for the response byte.
-
- Device Operation: eventq
-
-The eventq is used by the device to report information on logical
-units that are attached to it. The driver should always leave a
-few buffers ready in the eventq. In general, the device will not
-queue events to cope with an empty eventq, and will end up
-dropping events if it finds no buffer ready. However, when
-reporting events for many LUNs (e.g. when a whole target
-disappears), the device can throttle events to avoid dropping
-them. For this reason, placing 10-15 buffers on the event queue
-should be enough.
-
-Buffers are placed in the eventq and filled by the device when
-interesting events occur. The buffers should be strictly
-write-only (device-filled) and the size of the buffers should be
-at least the value given in the device's configuration
-information.
-
-Buffers returned by the device on the eventq will be referred to
-as "events" in the rest of this section. Events have the
-following format:
-
-#define VIRTIO_SCSI_T_EVENTS_MISSED 0x80000000
-
-
-
-struct virtio_scsi_event {
-
- // Write-only part
-
- u32 event;
-
- ...
-
-}
-
-If bit 31 is set in the event field, the device failed to report
-an event due to missing buffers. In this case, the driver should
-poll the logical units for unit attention conditions, and/or do
-whatever form of bus scan is appropriate for the guest operating
-system.
-
-Other data that the device writes to the buffer depends on the
-contents of the event field. The following events are defined:
-
- No event
-#define VIRTIO_SCSI_T_NO_EVENT 0
-
- This event is fired in the following cases:
-
- When the device detects in the eventq a buffer that is shorter
- than what is indicated in the configuration field, it might
- use it immediately and put this dummy value in the event
- field. A well-written driver will never observe this
- situation.
-
- When events are dropped, the device may signal this event as
- soon as the drivers makes a buffer available, in order to
- request action from the driver. In this case, of course, this
- event will be reported with the VIRTIO_SCSI_T_EVENTS_MISSED
- flag.
-
- Transport reset
-#define VIRTIO_SCSI_T_TRANSPORT_RESET 1
-
-
-
-struct virtio_scsi_event_reset {
-
- // Write-only part
-
- u32 event;
-
- u8 lun[8];
-
- u32 reason;
-
-}
-
-
-
-#define VIRTIO_SCSI_EVT_RESET_HARD 0
-
-#define VIRTIO_SCSI_EVT_RESET_RESCAN 1
-
-#define VIRTIO_SCSI_EVT_RESET_REMOVED 2
-
- By sending this event, the device signals that a logical unit
- on a target has been reset, including the case of a new device
- appearing or disappearing on the bus.The device fills in all
- fields. The event field is set to
- VIRTIO_SCSI_T_TRANSPORT_RESET. The lun field addresses a
- logical unit in the SCSI host.
-
- The reason value is one of the three #define values appearing
- above:
-
- VIRTIO_SCSI_EVT_RESET_REMOVED (“LUN/target removed”) is used if
- the target or logical unit is no longer able to receive
- commands.
-
- VIRTIO_SCSI_EVT_RESET_HARD (“LUN hard reset”) is used if the
- logical unit has been reset, but is still present.
-
- VIRTIO_SCSI_EVT_RESET_RESCAN (“rescan LUN/target”) is used if a
- target or logical unit has just appeared on the device.
-
- The “removed” and “rescan” events, when sent for LUN 0, may
- apply to the entire target. After receiving them the driver
- should ask the initiator to rescan the target, in order to
- detect the case when an entire target has appeared or
- disappeared. These two events will never be reported unless the
- VIRTIO_SCSI_F_HOTPLUG feature was negotiated between the host
- and the guest.
-
- Events will also be reported via sense codes (this obviously
- does not apply to newly appeared buses or targets, since the
- application has never discovered them):
-
- “LUN/target removed” maps to sense key ILLEGAL REQUEST, asc
- 0x25, ascq 0x00 (LOGICAL UNIT NOT SUPPORTED)
-
- “LUN hard reset” maps to sense key UNIT ATTENTION, asc 0x29
- (POWER ON, RESET OR BUS DEVICE RESET OCCURRED)
-
- “rescan LUN/target” maps to sense key UNIT ATTENTION, asc 0x3f,
- ascq 0x0e (REPORTED LUNS DATA HAS CHANGED)
-
- The preferred way to detect transport reset is always to use
- events, because sense codes are only seen by the driver when it
- sends a SCSI command to the logical unit or target. However, in
- case events are dropped, the initiator will still be able to
- synchronize with the actual state of the controller if the
- driver asks the initiator to rescan of the SCSI bus. During the
- rescan, the initiator will be able to observe the above sense
- codes, and it will process them as if it the driver had
- received the equivalent event.
-
- Asynchronous notification
-#define VIRTIO_SCSI_T_ASYNC_NOTIFY 2
-
-
-
-struct virtio_scsi_event_an {
-
- // Write-only part
-
- u32 event;
-
- u8 lun[8];
-
- u32 reason;
-
-}
-
- By sending this event, the device signals that an asynchronous
- event was fired from a physical interface.
-
- All fields are written by the device. The event field is set to
- VIRTIO_SCSI_T_ASYNC_NOTIFY. The lun field addresses a logical
- unit in the SCSI host. The reason field is a subset of the
- events that the driver has subscribed to via the "Asynchronous
- notification subscription" command.
-
- When dropped events are reported, the driver should poll for
- asynchronous events manually using SCSI commands.
-
-Appendix X: virtio-mmio
-
-Virtual environments without PCI support (a common situation in
-embedded devices models) might use simple memory mapped device (“
-virtio-mmio”) instead of the PCI device.
-
-The memory mapped virtio device behaviour is based on the PCI
-device specification. Therefore most of operations like device
-initialization, queues configuration and buffer transfers are
-nearly identical. Existing differences are described in the
-following sections.
-
- Device Initialization
-
-Instead of using the PCI IO space for virtio header, the “
-virtio-mmio” device provides a set of memory mapped control
-registers, all 32 bits wide, followed by device-specific
-configuration space. The following list presents their layout:
-
- Offset from the device base address | Direction | Name
- Description
-
- 0x000 | R | MagicValue
- “virt” string.
-
- 0x004 | R | Version
- Device version number. Currently must be 1.
-
- 0x008 | R | DeviceID
- Virtio Subsystem Device ID (ie. 1 for network card).
-
- 0x00c | R | VendorID
- Virtio Subsystem Vendor ID.
-
- 0x010 | R | HostFeatures
- Flags representing features the device supports.
- Reading from this register returns 32 consecutive flag bits,
- first bit depending on the last value written to
- HostFeaturesSel register. Access to this register returns bits HostFeaturesSel*32
-
- to (HostFeaturesSel*32)+31
-, eg. feature bits 0 to 31 if
- HostFeaturesSel is set to 0 and features bits 32 to 63 if
- HostFeaturesSel is set to 1. Also see [sub:Feature-Bits]
-
- 0x014 | W | HostFeaturesSel
- Device (Host) features word selection.
- Writing to this register selects a set of 32 device feature bits
- accessible by reading from HostFeatures register. Device driver
- must write a value to the HostFeaturesSel register before
- reading from the HostFeatures register.
-
- 0x020 | W | GuestFeatures
- Flags representing device features understood and activated by
- the driver.
- Writing to this register sets 32 consecutive flag bits, first
- bit depending on the last value written to GuestFeaturesSel
- register. Access to this register sets bits GuestFeaturesSel*32
-
- to (GuestFeaturesSel*32)+31
-, eg. feature bits 0 to 31 if
- GuestFeaturesSel is set to 0 and features bits 32 to 63 if
- GuestFeaturesSel is set to 1. Also see [sub:Feature-Bits]
-
- 0x024 | W | GuestFeaturesSel
- Activated (Guest) features word selection.
- Writing to this register selects a set of 32 activated feature
- bits accessible by writing to the GuestFeatures register.
- Device driver must write a value to the GuestFeaturesSel
- register before writing to the GuestFeatures register.
-
- 0x028 | W | GuestPageSize
- Guest page size.
- Device driver must write the guest page size in bytes to the
- register during initialization, before any queues are used.
- This value must be a power of 2 and is used by the Host to
- calculate Guest address of the first queue page (see QueuePFN).
-
- 0x030 | W | QueueSel
- Virtual queue index (first queue is 0).
- Writing to this register selects the virtual queue that the
- following operations on QueueNum, QueueAlign and QueuePFN apply
- to.
-
- 0x034 | R | QueueNumMax
- Maximum virtual queue size.
- Reading from the register returns the maximum size of the queue
- the Host is ready to process or zero (0x0) if the queue is not
- available. This applies to the queue selected by writing to
- QueueSel and is allowed only when QueuePFN is set to zero
- (0x0), so when the queue is not actively used.
-
- 0x038 | W | QueueNum
- Virtual queue size.
- Queue size is a number of elements in the queue, therefore size
- of the descriptor table and both available and used rings.
- Writing to this register notifies the Host what size of the
- queue the Guest will use. This applies to the queue selected by
- writing to QueueSel.
-
- 0x03c | W | QueueAlign
- Used Ring alignment in the virtual queue.
- Writing to this register notifies the Host about alignment
- boundary of the Used Ring in bytes. This value must be a power
- of 2 and applies to the queue selected by writing to QueueSel.
-
- 0x040 | RW | QueuePFN
- Guest physical page number of the virtual queue.
- Writing to this register notifies the host about location of the
- virtual queue in the Guest's physical address space. This value
- is the index number of a page starting with the queue
- Descriptor Table. Value zero (0x0) means physical address zero
- (0x00000000) and is illegal. When the Guest stops using the
- queue it must write zero (0x0) to this register.
- Reading from this register returns the currently used page
- number of the queue, therefore a value other than zero (0x0)
- means that the queue is in use.
- Both read and write accesses apply to the queue selected by
- writing to QueueSel.
-
- 0x050 | W | QueueNotify
- Queue notifier.
- Writing a queue index to this register notifies the Host that
- there are new buffers to process in the queue.
-
- 0x60 | R | InterruptStatus
-Interrupt status.
-Reading from this register returns a bit mask of interrupts
- asserted by the device. An interrupt is asserted if the
- corresponding bit is set, ie. equals one (1).
-
- Bit 0 | Used Ring Update
-This interrupt is asserted when the Host has updated the Used
- Ring in at least one of the active virtual queues.
-
- Bit 1 | Configuration change
-This interrupt is asserted when configuration of the device has
- changed.
-
- 0x064 | W | InterruptACK
- Interrupt acknowledge.
- Writing to this register notifies the Host that the Guest
- finished handling interrupts. Set bits in the value clear the
- corresponding bits of the InterruptStatus register.
-
- 0x070 | RW | Status
- Device status.
- Reading from this register returns the current device status
- flags.
- Writing non-zero values to this register sets the status flags,
- indicating the Guest progress. Writing zero (0x0) to this
- register triggers a device reset.
- Also see [sub:Device-Initialization-Sequence]
-
- 0x100+ | RW | Config
- Device-specific configuration space starts at an offset 0x100
- and is accessed with byte alignment. Its meaning and size
- depends on the device and the driver.
-
-Virtual queue size is a number of elements in the queue,
-therefore size of the descriptor table and both available and
-used rings.
-
-The endianness of the registers follows the native endianness of
-the Guest. Writing to registers described as “R” and reading from
-registers described as “W” is not permitted and can cause
-undefined behavior.
-
-The device initialization is performed as described in [sub:Device-Initialization-Sequence]
- with one exception: the Guest must notify the Host about its
-page size, writing the size in bytes to GuestPageSize register
-before the initialization is finished.
-
-The memory mapped virtio devices generate single interrupt only,
-therefore no special configuration is required.
-
- Virtqueue Configuration
-
-The virtual queue configuration is performed in a similar way to
-the one described in [sec:Virtqueue-Configuration] with a few
-additional operations:
-
- Select the queue writing its index (first queue is 0) to the
- QueueSel register.
-
- Check if the queue is not already in use: read QueuePFN
- register, returned value should be zero (0x0).
-
- Read maximum queue size (number of elements) from the
- QueueNumMax register. If the returned value is zero (0x0) the
- queue is not available.
-
- Allocate and zero the queue pages in contiguous virtual memory,
- aligning the Used Ring to an optimal boundary (usually page
- size). Size of the allocated queue may be smaller than or equal
- to the maximum size returned by the Host.
-
- Notify the Host about the queue size by writing the size to
- QueueNum register.
-
- Notify the Host about the used alignment by writing its value
- in bytes to QueueAlign register.
-
- Write the physical number of the first page of the queue to the
- QueuePFN register.
-
-The queue and the device are ready to begin normal operations
-now.
-
- Device Operation
-
-The memory mapped virtio device behaves in the same way as
-described in [sec:Device-Operation], with the following
-exceptions:
-
- The device is notified about new buffers available in a queue
- by writing the queue index to register QueueNum instead of the
- virtio header in PCI I/O space ([sub:Notifying-The-Device]).
-
- The memory mapped virtio device is using single, dedicated
- interrupt signal, which is raised when at least one of the
- interrupts described in the InterruptStatus register
- description is asserted. After receiving an interrupt, the
- driver must read the InterruptStatus register to check what
- caused the interrupt (see the register description). After the
- interrupt is handled, the driver must acknowledge it by writing
- a bit mask corresponding to the serviced interrupt to the
- InterruptACK register.
-
diff --git a/Documentation/vm/ksm.txt b/Documentation/vm/ksm.txt
index b392e49..f34a8ee 100644
--- a/Documentation/vm/ksm.txt
+++ b/Documentation/vm/ksm.txt
@@ -58,6 +58,21 @@
e.g. "echo 20 > /sys/kernel/mm/ksm/sleep_millisecs"
Default: 20 (chosen for demonstration purposes)
+merge_across_nodes - specifies if pages from different numa nodes can be merged.
+ When set to 0, ksm merges only pages which physically
+ reside in the memory area of same NUMA node. That brings
+ lower latency to access of shared pages. Systems with more
+ nodes, at significant NUMA distances, are likely to benefit
+ from the lower latency of setting 0. Smaller systems, which
+ need to minimize memory usage, are likely to benefit from
+ the greater sharing of setting 1 (default). You may wish to
+ compare how your system performs under each setting, before
+ deciding on which to use. merge_across_nodes setting can be
+ changed only when there are no ksm shared pages in system:
+ set run 2 to unmerge pages first, then to 1 after changing
+ merge_across_nodes, to remerge according to the new setting.
+ Default: 1 (merging across nodes as in earlier releases)
+
run - set 0 to stop ksmd from running but keep merged pages,
set 1 to run ksmd e.g. "echo 1 > /sys/kernel/mm/ksm/run",
set 2 to stop ksmd and unmerge all pages currently merged,
diff --git a/Documentation/vm/overcommit-accounting b/Documentation/vm/overcommit-accounting
index 706d7ed..8eaa2fc 100644
--- a/Documentation/vm/overcommit-accounting
+++ b/Documentation/vm/overcommit-accounting
@@ -8,7 +8,9 @@
default.
1 - Always overcommit. Appropriate for some scientific
- applications.
+ applications. Classic example is code using sparse arrays
+ and just relying on the virtual memory consisting almost
+ entirely of zero pages.
2 - Don't overcommit. The total address space commit
for the system is not permitted to exceed swap + a
@@ -18,6 +20,10 @@
pages but will receive errors on memory allocation as
appropriate.
+ Useful for applications that want to guarantee their
+ memory allocations will be available in the future
+ without having to initialize every page.
+
The overcommit policy is set via the sysctl `vm.overcommit_memory'.
The overcommit percentage is set via `vm.overcommit_ratio'.
diff --git a/Documentation/vm/pagemap.txt b/Documentation/vm/pagemap.txt
index 7587493..5948e45 100644
--- a/Documentation/vm/pagemap.txt
+++ b/Documentation/vm/pagemap.txt
@@ -15,7 +15,8 @@
* Bits 0-54 page frame number (PFN) if present
* Bits 0-4 swap type if swapped
* Bits 5-54 swap offset if swapped
- * Bits 55-60 page shift (page size = 1<<page shift)
+ * Bit 55 pte is soft-dirty (see Documentation/vm/soft-dirty.txt)
+ * Bits 56-60 zero
* Bit 61 page is file-page or shared-anon
* Bit 62 page swapped
* Bit 63 page present
@@ -147,5 +148,5 @@
Other notes:
Reading from any of the files will return -EINVAL if you are not starting
-the read on an 8-byte boundary (e.g., if you seeked an odd number of bytes
+the read on an 8-byte boundary (e.g., if you sought an odd number of bytes
into the file), or if the size of the read is not a multiple of 8 bytes.
diff --git a/Documentation/vm/soft-dirty.txt b/Documentation/vm/soft-dirty.txt
new file mode 100644
index 0000000..9a12a59
--- /dev/null
+++ b/Documentation/vm/soft-dirty.txt
@@ -0,0 +1,36 @@
+ SOFT-DIRTY PTEs
+
+ The soft-dirty is a bit on a PTE which helps to track which pages a task
+writes to. In order to do this tracking one should
+
+ 1. Clear soft-dirty bits from the task's PTEs.
+
+ This is done by writing "4" into the /proc/PID/clear_refs file of the
+ task in question.
+
+ 2. Wait some time.
+
+ 3. Read soft-dirty bits from the PTEs.
+
+ This is done by reading from the /proc/PID/pagemap. The bit 55 of the
+ 64-bit qword is the soft-dirty one. If set, the respective PTE was
+ written to since step 1.
+
+
+ Internally, to do this tracking, the writable bit is cleared from PTEs
+when the soft-dirty bit is cleared. So, after this, when the task tries to
+modify a page at some virtual address the #PF occurs and the kernel sets
+the soft-dirty bit on the respective PTE.
+
+ Note, that although all the task's address space is marked as r/o after the
+soft-dirty bits clear, the #PF-s that occur after that are processed fast.
+This is so, since the pages are still mapped to physical memory, and thus all
+the kernel does is finds this fact out and puts both writable and soft-dirty
+bits on the PTE.
+
+
+ This feature is actively used by the checkpoint-restore project. You
+can find more details about it on http://criu.org
+
+
+-- Pavel Emelyanov, Apr 9, 2013
diff --git a/Documentation/vm/transhuge.txt b/Documentation/vm/transhuge.txt
index 8785fb8..4a63953 100644
--- a/Documentation/vm/transhuge.txt
+++ b/Documentation/vm/transhuge.txt
@@ -120,8 +120,8 @@
It's possible to disable huge zero page by writing 0 or enable it
back by writing 1:
-echo 0 >/sys/kernel/mm/transparent_hugepage/khugepaged/use_zero_page
-echo 1 >/sys/kernel/mm/transparent_hugepage/khugepaged/use_zero_page
+echo 0 >/sys/kernel/mm/transparent_hugepage/use_zero_page
+echo 1 >/sys/kernel/mm/transparent_hugepage/use_zero_page
khugepaged will be automatically started when
transparent_hugepage/enabled is set to "always" or "madvise, and it'll
diff --git a/Documentation/vm/zswap.txt b/Documentation/vm/zswap.txt
new file mode 100644
index 0000000..7e492d8
--- /dev/null
+++ b/Documentation/vm/zswap.txt
@@ -0,0 +1,68 @@
+Overview:
+
+Zswap is a lightweight compressed cache for swap pages. It takes pages that are
+in the process of being swapped out and attempts to compress them into a
+dynamically allocated RAM-based memory pool. zswap basically trades CPU cycles
+for potentially reduced swap I/O. This trade-off can also result in a
+significant performance improvement if reads from the compressed cache are
+faster than reads from a swap device.
+
+NOTE: Zswap is a new feature as of v3.11 and interacts heavily with memory
+reclaim. This interaction has not be fully explored on the large set of
+potential configurations and workloads that exist. For this reason, zswap
+is a work in progress and should be considered experimental.
+
+Some potential benefits:
+* Desktop/laptop users with limited RAM capacities can mitigate the
+ performance impact of swapping.
+* Overcommitted guests that share a common I/O resource can
+ dramatically reduce their swap I/O pressure, avoiding heavy handed I/O
+ throttling by the hypervisor. This allows more work to get done with less
+ impact to the guest workload and guests sharing the I/O subsystem
+* Users with SSDs as swap devices can extend the life of the device by
+ drastically reducing life-shortening writes.
+
+Zswap evicts pages from compressed cache on an LRU basis to the backing swap
+device when the compressed pool reaches it size limit. This requirement had
+been identified in prior community discussions.
+
+To enabled zswap, the "enabled" attribute must be set to 1 at boot time. e.g.
+zswap.enabled=1
+
+Design:
+
+Zswap receives pages for compression through the Frontswap API and is able to
+evict pages from its own compressed pool on an LRU basis and write them back to
+the backing swap device in the case that the compressed pool is full.
+
+Zswap makes use of zbud for the managing the compressed memory pool. Each
+allocation in zbud is not directly accessible by address. Rather, a handle is
+return by the allocation routine and that handle must be mapped before being
+accessed. The compressed memory pool grows on demand and shrinks as compressed
+pages are freed. The pool is not preallocated.
+
+When a swap page is passed from frontswap to zswap, zswap maintains a mapping
+of the swap entry, a combination of the swap type and swap offset, to the zbud
+handle that references that compressed swap page. This mapping is achieved
+with a red-black tree per swap type. The swap offset is the search key for the
+tree nodes.
+
+During a page fault on a PTE that is a swap entry, frontswap calls the zswap
+load function to decompress the page into the page allocated by the page fault
+handler.
+
+Once there are no PTEs referencing a swap page stored in zswap (i.e. the count
+in the swap_map goes to 0) the swap code calls the zswap invalidate function,
+via frontswap, to free the compressed entry.
+
+Zswap seeks to be simple in its policies. Sysfs attributes allow for one user
+controlled policies:
+* max_pool_percent - The maximum percentage of memory that the compressed
+ pool can occupy.
+
+Zswap allows the compressor to be selected at kernel boot time by setting the
+“compressor” attribute. The default compressor is lzo. e.g.
+zswap.compressor=deflate
+
+A debugfs interface is provided for various statistic about pool size, number
+of pages stored, and various counters for the reasons pages are rejected.
diff --git a/Documentation/w1/slaves/w1_ds28e04 b/Documentation/w1/slaves/w1_ds28e04
index 85bc9a7..7819b65 100644
--- a/Documentation/w1/slaves/w1_ds28e04
+++ b/Documentation/w1/slaves/w1_ds28e04
@@ -24,7 +24,7 @@
A write operation on the "eeprom" file writes the given byte sequence
to the EEPROM of the DS28E04. If CRC checking mode is enabled only
- fully alligned blocks of 32 bytes with valid CRC16 values (in bytes 30
+ fully aligned blocks of 32 bytes with valid CRC16 values (in bytes 30
and 31) are allowed to be written.
PIO Access
diff --git a/Documentation/w1/slaves/w1_therm b/Documentation/w1/slaves/w1_therm
index 874a8ca..cc62a95 100644
--- a/Documentation/w1/slaves/w1_therm
+++ b/Documentation/w1/slaves/w1_therm
@@ -34,9 +34,16 @@
precision (which would also reduce the conversion time).
The module parameter strong_pullup can be set to 0 to disable the
-strong pullup or 1 to enable. If enabled the 5V strong pullup will be
-enabled when the conversion is taking place provided the master driver
-must support the strong pullup (or it falls back to a pullup
+strong pullup, 1 to enable autodetection or 2 to force strong pullup.
+In case of autodetection, the driver will use the "READ POWER SUPPLY"
+command to check if there are pariste powered devices on the bus.
+If so, it will activate the master's strong pullup.
+In case the detection of parasite devices using this command fails
+(seems to be the case with some DS18S20) the strong pullup can
+be force-enabled.
+If the strong pullup is enabled, the master's strong pullup will be
+driven when the conversion is taking place, provided the master driver
+does support the strong pullup (or it falls back to a pullup
resistor). The DS18b20 temperature sensor specification lists a
maximum current draw of 1.5mA and that a 5k pullup resistor is not
sufficient. The strong pullup is designed to provide the additional
diff --git a/Documentation/w1/w1.generic b/Documentation/w1/w1.generic
index 212f4ac..a31c5a2 100644
--- a/Documentation/w1/w1.generic
+++ b/Documentation/w1/w1.generic
@@ -25,8 +25,8 @@
- sysfs entries for that w1 master are created
- the w1 bus is periodically searched for new slave devices
-When a device is found on the bus, w1 core checks if driver for its family is
-loaded. If so, the family driver is attached to the slave.
+When a device is found on the bus, w1 core tries to load the driver for its family
+and check if it is loaded. If so, the family driver is attached to the slave.
If there is no driver for the family, default one is assigned, which allows to perform
almost any kind of operations. Each logical operation is a transaction
in nature, which can contain several (two or one) low-level operations.
diff --git a/Documentation/watchdog/watchdog-kernel-api.txt b/Documentation/watchdog/watchdog-kernel-api.txt
index 086638f..a0438f3 100644
--- a/Documentation/watchdog/watchdog-kernel-api.txt
+++ b/Documentation/watchdog/watchdog-kernel-api.txt
@@ -1,6 +1,6 @@
The Linux WatchDog Timer Driver Core kernel API.
===============================================
-Last reviewed: 22-May-2012
+Last reviewed: 12-Feb-2013
Wim Van Sebroeck <wim@iguana.be>
@@ -212,3 +212,15 @@
The watchdog_get_drvdata function allows you to retrieve driver specific data.
The argument of this function is the watchdog device where you want to retrieve
data from. The function returns the pointer to the driver specific data.
+
+To initialize the timeout field, the following function can be used:
+
+extern int watchdog_init_timeout(struct watchdog_device *wdd,
+ unsigned int timeout_parm, struct device *dev);
+
+The watchdog_init_timeout function allows you to initialize the timeout field
+using the module timeout parameter or by retrieving the timeout-sec property from
+the device tree (if the module timeout parameter is invalid). Best practice is
+to set the default timeout value as timeout value in the watchdog_device and
+then use this function to set the user "preferred" timeout value.
+This routine returns zero on success and a negative errno code for failure.
diff --git a/Documentation/watchdog/watchdog-parameters.txt b/Documentation/watchdog/watchdog-parameters.txt
index 04fddbac..f9492fe 100644
--- a/Documentation/watchdog/watchdog-parameters.txt
+++ b/Documentation/watchdog/watchdog-parameters.txt
@@ -194,14 +194,6 @@
nowayout: Watchdog cannot be stopped once started
(default=kernel config parameter)
-------------------------------------------------
-mpcore_wdt:
-mpcore_margin: MPcore timer margin in seconds.
- (0 < mpcore_margin < 65536, default=60)
-nowayout: Watchdog cannot be stopped once started
- (default=kernel config parameter)
-mpcore_noboot: MPcore watchdog action, set to 1 to ignore reboots,
- 0 to reboot (default=0
--------------------------------------------------
mv64x60_wdt:
nowayout: Watchdog cannot be stopped once started
(default=kernel config parameter)
diff --git a/Documentation/ww-mutex-design.txt b/Documentation/ww-mutex-design.txt
new file mode 100644
index 0000000..8a112dc
--- /dev/null
+++ b/Documentation/ww-mutex-design.txt
@@ -0,0 +1,344 @@
+Wait/Wound Deadlock-Proof Mutex Design
+======================================
+
+Please read mutex-design.txt first, as it applies to wait/wound mutexes too.
+
+Motivation for WW-Mutexes
+-------------------------
+
+GPU's do operations that commonly involve many buffers. Those buffers
+can be shared across contexts/processes, exist in different memory
+domains (for example VRAM vs system memory), and so on. And with
+PRIME / dmabuf, they can even be shared across devices. So there are
+a handful of situations where the driver needs to wait for buffers to
+become ready. If you think about this in terms of waiting on a buffer
+mutex for it to become available, this presents a problem because
+there is no way to guarantee that buffers appear in a execbuf/batch in
+the same order in all contexts. That is directly under control of
+userspace, and a result of the sequence of GL calls that an application
+makes. Which results in the potential for deadlock. The problem gets
+more complex when you consider that the kernel may need to migrate the
+buffer(s) into VRAM before the GPU operates on the buffer(s), which
+may in turn require evicting some other buffers (and you don't want to
+evict other buffers which are already queued up to the GPU), but for a
+simplified understanding of the problem you can ignore this.
+
+The algorithm that the TTM graphics subsystem came up with for dealing with
+this problem is quite simple. For each group of buffers (execbuf) that need
+to be locked, the caller would be assigned a unique reservation id/ticket,
+from a global counter. In case of deadlock while locking all the buffers
+associated with a execbuf, the one with the lowest reservation ticket (i.e.
+the oldest task) wins, and the one with the higher reservation id (i.e. the
+younger task) unlocks all of the buffers that it has already locked, and then
+tries again.
+
+In the RDBMS literature this deadlock handling approach is called wait/wound:
+The older tasks waits until it can acquire the contended lock. The younger tasks
+needs to back off and drop all the locks it is currently holding, i.e. the
+younger task is wounded.
+
+Concepts
+--------
+
+Compared to normal mutexes two additional concepts/objects show up in the lock
+interface for w/w mutexes:
+
+Acquire context: To ensure eventual forward progress it is important the a task
+trying to acquire locks doesn't grab a new reservation id, but keeps the one it
+acquired when starting the lock acquisition. This ticket is stored in the
+acquire context. Furthermore the acquire context keeps track of debugging state
+to catch w/w mutex interface abuse.
+
+W/w class: In contrast to normal mutexes the lock class needs to be explicit for
+w/w mutexes, since it is required to initialize the acquire context.
+
+Furthermore there are three different class of w/w lock acquire functions:
+
+* Normal lock acquisition with a context, using ww_mutex_lock.
+
+* Slowpath lock acquisition on the contending lock, used by the wounded task
+ after having dropped all already acquired locks. These functions have the
+ _slow postfix.
+
+ From a simple semantics point-of-view the _slow functions are not strictly
+ required, since simply calling the normal ww_mutex_lock functions on the
+ contending lock (after having dropped all other already acquired locks) will
+ work correctly. After all if no other ww mutex has been acquired yet there's
+ no deadlock potential and hence the ww_mutex_lock call will block and not
+ prematurely return -EDEADLK. The advantage of the _slow functions is in
+ interface safety:
+ - ww_mutex_lock has a __must_check int return type, whereas ww_mutex_lock_slow
+ has a void return type. Note that since ww mutex code needs loops/retries
+ anyway the __must_check doesn't result in spurious warnings, even though the
+ very first lock operation can never fail.
+ - When full debugging is enabled ww_mutex_lock_slow checks that all acquired
+ ww mutex have been released (preventing deadlocks) and makes sure that we
+ block on the contending lock (preventing spinning through the -EDEADLK
+ slowpath until the contended lock can be acquired).
+
+* Functions to only acquire a single w/w mutex, which results in the exact same
+ semantics as a normal mutex. This is done by calling ww_mutex_lock with a NULL
+ context.
+
+ Again this is not strictly required. But often you only want to acquire a
+ single lock in which case it's pointless to set up an acquire context (and so
+ better to avoid grabbing a deadlock avoidance ticket).
+
+Of course, all the usual variants for handling wake-ups due to signals are also
+provided.
+
+Usage
+-----
+
+Three different ways to acquire locks within the same w/w class. Common
+definitions for methods #1 and #2:
+
+static DEFINE_WW_CLASS(ww_class);
+
+struct obj {
+ struct ww_mutex lock;
+ /* obj data */
+};
+
+struct obj_entry {
+ struct list_head head;
+ struct obj *obj;
+};
+
+Method 1, using a list in execbuf->buffers that's not allowed to be reordered.
+This is useful if a list of required objects is already tracked somewhere.
+Furthermore the lock helper can use propagate the -EALREADY return code back to
+the caller as a signal that an object is twice on the list. This is useful if
+the list is constructed from userspace input and the ABI requires userspace to
+not have duplicate entries (e.g. for a gpu commandbuffer submission ioctl).
+
+int lock_objs(struct list_head *list, struct ww_acquire_ctx *ctx)
+{
+ struct obj *res_obj = NULL;
+ struct obj_entry *contended_entry = NULL;
+ struct obj_entry *entry;
+
+ ww_acquire_init(ctx, &ww_class);
+
+retry:
+ list_for_each_entry (entry, list, head) {
+ if (entry->obj == res_obj) {
+ res_obj = NULL;
+ continue;
+ }
+ ret = ww_mutex_lock(&entry->obj->lock, ctx);
+ if (ret < 0) {
+ contended_entry = entry;
+ goto err;
+ }
+ }
+
+ ww_acquire_done(ctx);
+ return 0;
+
+err:
+ list_for_each_entry_continue_reverse (entry, list, head)
+ ww_mutex_unlock(&entry->obj->lock);
+
+ if (res_obj)
+ ww_mutex_unlock(&res_obj->lock);
+
+ if (ret == -EDEADLK) {
+ /* we lost out in a seqno race, lock and retry.. */
+ ww_mutex_lock_slow(&contended_entry->obj->lock, ctx);
+ res_obj = contended_entry->obj;
+ goto retry;
+ }
+ ww_acquire_fini(ctx);
+
+ return ret;
+}
+
+Method 2, using a list in execbuf->buffers that can be reordered. Same semantics
+of duplicate entry detection using -EALREADY as method 1 above. But the
+list-reordering allows for a bit more idiomatic code.
+
+int lock_objs(struct list_head *list, struct ww_acquire_ctx *ctx)
+{
+ struct obj_entry *entry, *entry2;
+
+ ww_acquire_init(ctx, &ww_class);
+
+ list_for_each_entry (entry, list, head) {
+ ret = ww_mutex_lock(&entry->obj->lock, ctx);
+ if (ret < 0) {
+ entry2 = entry;
+
+ list_for_each_entry_continue_reverse (entry2, list, head)
+ ww_mutex_unlock(&entry2->obj->lock);
+
+ if (ret != -EDEADLK) {
+ ww_acquire_fini(ctx);
+ return ret;
+ }
+
+ /* we lost out in a seqno race, lock and retry.. */
+ ww_mutex_lock_slow(&entry->obj->lock, ctx);
+
+ /*
+ * Move buf to head of the list, this will point
+ * buf->next to the first unlocked entry,
+ * restarting the for loop.
+ */
+ list_del(&entry->head);
+ list_add(&entry->head, list);
+ }
+ }
+
+ ww_acquire_done(ctx);
+ return 0;
+}
+
+Unlocking works the same way for both methods #1 and #2:
+
+void unlock_objs(struct list_head *list, struct ww_acquire_ctx *ctx)
+{
+ struct obj_entry *entry;
+
+ list_for_each_entry (entry, list, head)
+ ww_mutex_unlock(&entry->obj->lock);
+
+ ww_acquire_fini(ctx);
+}
+
+Method 3 is useful if the list of objects is constructed ad-hoc and not upfront,
+e.g. when adjusting edges in a graph where each node has its own ww_mutex lock,
+and edges can only be changed when holding the locks of all involved nodes. w/w
+mutexes are a natural fit for such a case for two reasons:
+- They can handle lock-acquisition in any order which allows us to start walking
+ a graph from a starting point and then iteratively discovering new edges and
+ locking down the nodes those edges connect to.
+- Due to the -EALREADY return code signalling that a given objects is already
+ held there's no need for additional book-keeping to break cycles in the graph
+ or keep track off which looks are already held (when using more than one node
+ as a starting point).
+
+Note that this approach differs in two important ways from the above methods:
+- Since the list of objects is dynamically constructed (and might very well be
+ different when retrying due to hitting the -EDEADLK wound condition) there's
+ no need to keep any object on a persistent list when it's not locked. We can
+ therefore move the list_head into the object itself.
+- On the other hand the dynamic object list construction also means that the -EALREADY return
+ code can't be propagated.
+
+Note also that methods #1 and #2 and method #3 can be combined, e.g. to first lock a
+list of starting nodes (passed in from userspace) using one of the above
+methods. And then lock any additional objects affected by the operations using
+method #3 below. The backoff/retry procedure will be a bit more involved, since
+when the dynamic locking step hits -EDEADLK we also need to unlock all the
+objects acquired with the fixed list. But the w/w mutex debug checks will catch
+any interface misuse for these cases.
+
+Also, method 3 can't fail the lock acquisition step since it doesn't return
+-EALREADY. Of course this would be different when using the _interruptible
+variants, but that's outside of the scope of these examples here.
+
+struct obj {
+ struct ww_mutex ww_mutex;
+ struct list_head locked_list;
+};
+
+static DEFINE_WW_CLASS(ww_class);
+
+void __unlock_objs(struct list_head *list)
+{
+ struct obj *entry, *temp;
+
+ list_for_each_entry_safe (entry, temp, list, locked_list) {
+ /* need to do that before unlocking, since only the current lock holder is
+ allowed to use object */
+ list_del(&entry->locked_list);
+ ww_mutex_unlock(entry->ww_mutex)
+ }
+}
+
+void lock_objs(struct list_head *list, struct ww_acquire_ctx *ctx)
+{
+ struct obj *obj;
+
+ ww_acquire_init(ctx, &ww_class);
+
+retry:
+ /* re-init loop start state */
+ loop {
+ /* magic code which walks over a graph and decides which objects
+ * to lock */
+
+ ret = ww_mutex_lock(obj->ww_mutex, ctx);
+ if (ret == -EALREADY) {
+ /* we have that one already, get to the next object */
+ continue;
+ }
+ if (ret == -EDEADLK) {
+ __unlock_objs(list);
+
+ ww_mutex_lock_slow(obj, ctx);
+ list_add(&entry->locked_list, list);
+ goto retry;
+ }
+
+ /* locked a new object, add it to the list */
+ list_add_tail(&entry->locked_list, list);
+ }
+
+ ww_acquire_done(ctx);
+ return 0;
+}
+
+void unlock_objs(struct list_head *list, struct ww_acquire_ctx *ctx)
+{
+ __unlock_objs(list);
+ ww_acquire_fini(ctx);
+}
+
+Method 4: Only lock one single objects. In that case deadlock detection and
+prevention is obviously overkill, since with grabbing just one lock you can't
+produce a deadlock within just one class. To simplify this case the w/w mutex
+api can be used with a NULL context.
+
+Implementation Details
+----------------------
+
+Design:
+ ww_mutex currently encapsulates a struct mutex, this means no extra overhead for
+ normal mutex locks, which are far more common. As such there is only a small
+ increase in code size if wait/wound mutexes are not used.
+
+ In general, not much contention is expected. The locks are typically used to
+ serialize access to resources for devices. The only way to make wakeups
+ smarter would be at the cost of adding a field to struct mutex_waiter. This
+ would add overhead to all cases where normal mutexes are used, and
+ ww_mutexes are generally less performance sensitive.
+
+Lockdep:
+ Special care has been taken to warn for as many cases of api abuse
+ as possible. Some common api abuses will be caught with
+ CONFIG_DEBUG_MUTEXES, but CONFIG_PROVE_LOCKING is recommended.
+
+ Some of the errors which will be warned about:
+ - Forgetting to call ww_acquire_fini or ww_acquire_init.
+ - Attempting to lock more mutexes after ww_acquire_done.
+ - Attempting to lock the wrong mutex after -EDEADLK and
+ unlocking all mutexes.
+ - Attempting to lock the right mutex after -EDEADLK,
+ before unlocking all mutexes.
+
+ - Calling ww_mutex_lock_slow before -EDEADLK was returned.
+
+ - Unlocking mutexes with the wrong unlock function.
+ - Calling one of the ww_acquire_* twice on the same context.
+ - Using a different ww_class for the mutex than for the ww_acquire_ctx.
+ - Normal lockdep errors that can result in deadlocks.
+
+ Some of the lockdep errors that can result in deadlocks:
+ - Calling ww_acquire_init to initialize a second ww_acquire_ctx before
+ having called ww_acquire_fini on the first.
+ - 'normal' deadlocks that can occur.
+
+FIXME: Update this section once we have the TASK_DEADLOCK task state flag magic
+implemented.
diff --git a/Documentation/x86/boot.txt b/Documentation/x86/boot.txt
index 406d82d..fc66d42 100644
--- a/Documentation/x86/boot.txt
+++ b/Documentation/x86/boot.txt
@@ -57,6 +57,10 @@
Protocol 2.11: (Kernel 3.6) Added a field for offset of EFI handover
protocol entry point.
+Protocol 2.12: (Kernel 3.8) Added the xloadflags field and extension fields
+ to struct boot_params for for loading bzImage and ramdisk
+ above 4G in 64bit.
+
**** MEMORY LAYOUT
The traditional memory map for the kernel loader, used for Image or
@@ -182,7 +186,7 @@
0230/4 2.05+ kernel_alignment Physical addr alignment required for kernel
0234/1 2.05+ relocatable_kernel Whether kernel is relocatable or not
0235/1 2.10+ min_alignment Minimum alignment, as a power of two
-0236/2 N/A pad3 Unused
+0236/2 2.12+ xloadflags Boot protocol option flags
0238/4 2.06+ cmdline_size Maximum size of the kernel command line
023C/4 2.07+ hardware_subarch Hardware subarchitecture
0240/8 2.07+ hardware_subarch_data Subarchitecture-specific data
@@ -386,6 +390,7 @@
F Special (0xFF = undefined)
10 Reserved
11 Minimal Linux Bootloader <http://sebastian-plotz.blogspot.de>
+ 12 OVMF UEFI virtualization stack
Please contact <hpa@zytor.com> if you need a bootloader ID
value assigned.
@@ -582,6 +587,27 @@
misaligned kernel. Therefore, a loader should typically try each
power-of-two alignment from kernel_alignment down to this alignment.
+Field name: xloadflags
+Type: read
+Offset/size: 0x236/2
+Protocol: 2.12+
+
+ This field is a bitmask.
+
+ Bit 0 (read): XLF_KERNEL_64
+ - If 1, this kernel has the legacy 64-bit entry point at 0x200.
+
+ Bit 1 (read): XLF_CAN_BE_LOADED_ABOVE_4G
+ - If 1, kernel/boot_params/cmdline/ramdisk can be above 4G.
+
+ Bit 2 (read): XLF_EFI_HANDOVER_32
+ - If 1, the kernel supports the 32-bit EFI handoff entry point
+ given at handover_offset.
+
+ Bit 3 (read): XLF_EFI_HANDOVER_64
+ - If 1, the kernel supports the 64-bit EFI handoff entry point
+ given at handover_offset + 0x200.
+
Field name: cmdline_size
Type: read
Offset/size: 0x238/4
@@ -631,9 +657,10 @@
uncompressed data should be determined using the standard magic
numbers. The currently supported compression formats are gzip
(magic numbers 1F 8B or 1F 9E), bzip2 (magic number 42 5A), LZMA
- (magic number 5D 00), and XZ (magic number FD 37). The uncompressed
- payload is currently always ELF (magic number 7F 45 4C 46).
-
+ (magic number 5D 00), XZ (magic number FD 37), and LZ4 (magic number
+ 02 21). The uncompressed payload is currently always ELF (magic
+ number 7F 45 4C 46).
+
Field name: payload_length
Type: read
Offset/size: 0x24c/4
@@ -1029,6 +1056,44 @@
must be __BOOT_DS; interrupt must be disabled; %esi must hold the base
address of the struct boot_params; %ebp, %edi and %ebx must be zero.
+**** 64-bit BOOT PROTOCOL
+
+For machine with 64bit cpus and 64bit kernel, we could use 64bit bootloader
+and we need a 64-bit boot protocol.
+
+In 64-bit boot protocol, the first step in loading a Linux kernel
+should be to setup the boot parameters (struct boot_params,
+traditionally known as "zero page"). The memory for struct boot_params
+could be allocated anywhere (even above 4G) and initialized to all zero.
+Then, the setup header at offset 0x01f1 of kernel image on should be
+loaded into struct boot_params and examined. The end of setup header
+can be calculated as follows:
+
+ 0x0202 + byte value at offset 0x0201
+
+In addition to read/modify/write the setup header of the struct
+boot_params as that of 16-bit boot protocol, the boot loader should
+also fill the additional fields of the struct boot_params as described
+in zero-page.txt.
+
+After setting up the struct boot_params, the boot loader can load
+64-bit kernel in the same way as that of 16-bit boot protocol, but
+kernel could be loaded above 4G.
+
+In 64-bit boot protocol, the kernel is started by jumping to the
+64-bit kernel entry point, which is the start address of loaded
+64-bit kernel plus 0x200.
+
+At entry, the CPU must be in 64-bit mode with paging enabled.
+The range with setup_header.init_size from start address of loaded
+kernel and zero page and command line buffer get ident mapping;
+a GDT must be loaded with the descriptors for selectors
+__BOOT_CS(0x10) and __BOOT_DS(0x18); both descriptors must be 4G flat
+segment; __BOOT_CS must have execute/read permission, and __BOOT_DS
+must have read/write permission; CS must be __BOOT_CS and DS, ES, SS
+must be __BOOT_DS; interrupt must be disabled; %rsi must hold the base
+address of the struct boot_params.
+
**** EFI HANDOVER PROTOCOL
This protocol allows boot loaders to defer initialisation to the EFI
diff --git a/Documentation/x86/early-microcode.txt b/Documentation/x86/early-microcode.txt
new file mode 100644
index 0000000..d62bea6
--- /dev/null
+++ b/Documentation/x86/early-microcode.txt
@@ -0,0 +1,42 @@
+Early load microcode
+====================
+By Fenghua Yu <fenghua.yu@intel.com>
+
+Kernel can update microcode in early phase of boot time. Loading microcode early
+can fix CPU issues before they are observed during kernel boot time.
+
+Microcode is stored in an initrd file. The microcode is read from the initrd
+file and loaded to CPUs during boot time.
+
+The format of the combined initrd image is microcode in cpio format followed by
+the initrd image (maybe compressed). Kernel parses the combined initrd image
+during boot time. The microcode file in cpio name space is:
+on Intel: kernel/x86/microcode/GenuineIntel.bin
+on AMD : kernel/x86/microcode/AuthenticAMD.bin
+
+During BSP boot (before SMP starts), if the kernel finds the microcode file in
+the initrd file, it parses the microcode and saves matching microcode in memory.
+If matching microcode is found, it will be uploaded in BSP and later on in all
+APs.
+
+The cached microcode patch is applied when CPUs resume from a sleep state.
+
+There are two legacy user space interfaces to load microcode, either through
+/dev/cpu/microcode or through /sys/devices/system/cpu/microcode/reload file
+in sysfs.
+
+In addition to these two legacy methods, the early loading method described
+here is the third method with which microcode can be uploaded to a system's
+CPUs.
+
+The following example script shows how to generate a new combined initrd file in
+/boot/initrd-3.5.0.ucode.img with original microcode microcode.bin and
+original initrd image /boot/initrd-3.5.0.img.
+
+mkdir initrd
+cd initrd
+mkdir -p kernel/x86/microcode
+cp ../microcode.bin kernel/x86/microcode/GenuineIntel.bin (or AuthenticAMD.bin)
+find . | cpio -o -H newc >../ucode.cpio
+cd ..
+cat ucode.cpio /boot/initrd-3.5.0.img >/boot/initrd-3.5.0.ucode.img
diff --git a/Documentation/x86/x86_64/boot-options.txt b/Documentation/x86/x86_64/boot-options.txt
index de38429..e9e8ddb 100644
--- a/Documentation/x86/x86_64/boot-options.txt
+++ b/Documentation/x86/x86_64/boot-options.txt
@@ -91,20 +91,6 @@
apicmaintimer. Useful when your PIT timer is totally
broken.
-Early Console
-
- syntax: earlyprintk=vga
- earlyprintk=serial[,ttySn[,baudrate]]
-
- The early console is useful when the kernel crashes before the
- normal console is initialized. It is not enabled by
- default because it has some cosmetic problems.
- Append ,keep to not disable it when the real console takes over.
- Only vga or serial at a time, not both.
- Currently only ttyS0 and ttyS1 are supported.
- Interaction with the standard serial driver is not very good.
- The VGA output is eventually overwritten by the real console.
-
Timing
notsc
@@ -112,10 +98,6 @@
This can be used to work around timing problems on multiprocessor systems
with not properly synchronized CPUs.
- report_lost_ticks
- Report when timer interrupts are lost because some code turned off
- interrupts for too long.
-
nohpet
Don't use the HPET timer.
diff --git a/Documentation/x86/x86_64/mm.txt b/Documentation/x86/x86_64/mm.txt
index d6498e3..881582f 100644
--- a/Documentation/x86/x86_64/mm.txt
+++ b/Documentation/x86/x86_64/mm.txt
@@ -13,7 +13,9 @@
ffffea0000000000 - ffffeaffffffffff (=40 bits) virtual memory map (1TB)
... unused hole ...
ffffffff80000000 - ffffffffa0000000 (=512 MB) kernel text mapping, from phys 0
-ffffffffa0000000 - fffffffffff00000 (=1536 MB) module mapping space
+ffffffffa0000000 - ffffffffff5fffff (=1525 MB) module mapping space
+ffffffffff600000 - ffffffffffdfffff (=8 MB) vsyscalls
+ffffffffffe00000 - ffffffffffffffff (=2 MB) unused hole
The direct mapping covers all memory in the system up to the highest
memory address (this means in some cases it can also include PCI memory
diff --git a/Documentation/x86/zero-page.txt b/Documentation/x86/zero-page.txt
index cf5437ded..199f453 100644
--- a/Documentation/x86/zero-page.txt
+++ b/Documentation/x86/zero-page.txt
@@ -19,6 +19,9 @@
090/010 ALL hd1_info hd1 disk parameter, OBSOLETE!!
0A0/010 ALL sys_desc_table System description table (struct sys_desc_table)
0B0/010 ALL olpc_ofw_header OLPC's OpenFirmware CIF and friends
+0C0/004 ALL ext_ramdisk_image ramdisk_image high 32bits
+0C4/004 ALL ext_ramdisk_size ramdisk_size high 32bits
+0C8/004 ALL ext_cmd_line_ptr cmd_line_ptr high 32bits
140/080 ALL edid_info Video mode setup (struct edid_info)
1C0/020 ALL efi_info EFI 32 information (struct efi_info)
1E0/004 ALL alk_mem_k Alternative mem check, in KB
@@ -27,6 +30,7 @@
1E9/001 ALL eddbuf_entries Number of entries in eddbuf (below)
1EA/001 ALL edd_mbr_sig_buf_entries Number of entries in edd_mbr_sig_buffer
(below)
+1EF/001 ALL sentinel Used to detect broken bootloaders
290/040 ALL edd_mbr_sig_buffer EDD MBR signatures
2D0/A00 ALL e820_map E820 memory map table
(array of struct e820entry)
diff --git a/Documentation/xtensa/mmu.txt b/Documentation/xtensa/mmu.txt
new file mode 100644
index 0000000..2b1af76
--- /dev/null
+++ b/Documentation/xtensa/mmu.txt
@@ -0,0 +1,46 @@
+MMUv3 initialization sequence.
+
+The code in the initialize_mmu macro sets up MMUv3 memory mapping
+identically to MMUv2 fixed memory mapping. Depending on
+CONFIG_INITIALIZE_XTENSA_MMU_INSIDE_VMLINUX symbol this code is
+located in one of the following address ranges:
+
+ 0xF0000000..0xFFFFFFFF (will keep same address in MMU v2 layout;
+ typically ROM)
+ 0x00000000..0x07FFFFFF (system RAM; this code is actually linked
+ at 0xD0000000..0xD7FFFFFF [cached]
+ or 0xD8000000..0xDFFFFFFF [uncached];
+ in any case, initially runs elsewhere
+ than linked, so have to be careful)
+
+The code has the following assumptions:
+ This code fragment is run only on an MMU v3.
+ TLBs are in their reset state.
+ ITLBCFG and DTLBCFG are zero (reset state).
+ RASID is 0x04030201 (reset state).
+ PS.RING is zero (reset state).
+ LITBASE is zero (reset state, PC-relative literals); required to be PIC.
+
+TLB setup proceeds along the following steps.
+
+ Legend:
+ VA = virtual address (two upper nibbles of it);
+ PA = physical address (two upper nibbles of it);
+ pc = physical range that contains this code;
+
+After step 2, we jump to virtual address in 0x40000000..0x5fffffff
+that corresponds to next instruction to execute in this code.
+After step 4, we jump to intended (linked) address of this code.
+
+ Step 0 Step1 Step 2 Step3 Step 4 Step5
+ ============ ===== ============ ===== ============ =====
+ VA PA PA VA PA PA VA PA PA
+ ------ -- -- ------ -- -- ------ -- --
+ E0..FF -> E0 -> E0 E0..FF -> E0 F0..FF -> F0 -> F0
+ C0..DF -> C0 -> C0 C0..DF -> C0 E0..EF -> F0 -> F0
+ A0..BF -> A0 -> A0 A0..BF -> A0 D8..DF -> 00 -> 00
+ 80..9F -> 80 -> 80 80..9F -> 80 D0..D7 -> 00 -> 00
+ 60..7F -> 60 -> 60 60..7F -> 60
+ 40..5F -> 40 40..5F -> pc -> pc 40..5F -> pc
+ 20..3F -> 20 -> 20 20..3F -> 20
+ 00..1F -> 00 -> 00 00..1F -> 00
diff --git a/Documentation/zh_CN/CodingStyle b/Documentation/zh_CN/CodingStyle
index ecd9307..654afd7 100644
--- a/Documentation/zh_CN/CodingStyle
+++ b/Documentation/zh_CN/CodingStyle
@@ -462,13 +462,6 @@
logging of avc messages output). Does not do system-call
auditing without CONFIG_AUDITSYSCALL.
-仍然被认为不够稳定的功能应该被定义为依赖于“EXPERIMENTAL”：
-
-config SLUB
- depends on EXPERIMENTAL && !ARCH_USES_SLAB_PAGE_STRUCT
- bool "SLUB (Unqueued Allocator)"
- ...
-
而那些危险的功能（比如某些文件系统的写支持）应该在它们的提示字符串里显著的声明这
一点：
diff --git a/Documentation/zh_CN/gpio.txt b/Documentation/zh_CN/gpio.txt
index 4fa7b4e..d5b8f01 100644
--- a/Documentation/zh_CN/gpio.txt
+++ b/Documentation/zh_CN/gpio.txt
@@ -84,10 +84,10 @@
控制器的抽象函数来实现它。(有一些可选的代码能支持这种策略的实现,本文档
后面会介绍，但作为 GPIO 接口的客户端驱动程序必须与它的实现无关。)
-也就是说,如果在他们的平台上支持这个公约，驱动应尽可能的使用它。平台
-必须在 Kconfig 中声明对 GENERIC_GPIO的支持 (布尔型 true)，并提供
-一个 <asm/gpio.h> 文件。那些调用标准 GPIO 函数的驱动应该在 Kconfig
-入口中声明依赖GENERIC_GPIO。当驱动包含文件:
+也就是说,如果在他们的平台上支持这个公约，驱动应尽可能的使用它。同时，平台
+必须在 Kconfig 中选择 ARCH_REQUIRE_GPIOLIB 或者 ARCH_WANT_OPTIONAL_GPIOLIB
+选项。那些调用标准 GPIO 函数的驱动应该在 Kconfig 入口中声明依赖GENERIC_GPIO。
+当驱动包含文件:
#include <linux/gpio.h>
diff --git a/Documentation/zh_CN/magic-number.txt b/Documentation/zh_CN/magic-number.txt
index 4263022..2ebe539 100644
--- a/Documentation/zh_CN/magic-number.txt
+++ b/Documentation/zh_CN/magic-number.txt
@@ -122,7 +122,7 @@
COW_MAGIC 0x4f4f4f4d cow_header_v1 arch/um/drivers/ubd_user.c
I810_CARD_MAGIC 0x5072696E i810_card sound/oss/i810_audio.c
TRIDENT_CARD_MAGIC 0x5072696E trident_card sound/oss/trident.c
-ROUTER_MAGIC 0x524d4157 wan_device include/linux/wanrouter.h
+ROUTER_MAGIC 0x524d4157 wan_device [in wanrouter.h pre 3.9]
SCC_MAGIC 0x52696368 gs_port drivers/char/scc.h
SAVEKMSG_MAGIC1 0x53415645 savekmsg arch/*/amiga/config.c
GDA_MAGIC 0x58464552 gda arch/mips/include/asm/sn/gda.h
diff --git a/Documentation/zh_CN/video4linux/v4l2-framework.txt b/Documentation/zh_CN/video4linux/v4l2-framework.txt
index 3e74f13..0da95db 100644
--- a/Documentation/zh_CN/video4linux/v4l2-framework.txt
+++ b/Documentation/zh_CN/video4linux/v4l2-framework.txt
@@ -182,8 +182,7 @@
static atomic_t drv_instance = ATOMIC_INIT(0);
-static int __devinit drv_probe(struct pci_dev *pdev,
- const struct pci_device_id *pci_id)
+static int drv_probe(struct pci_dev *pdev, const struct pci_device_id *pci_id)
{
...
state->instance = atomic_inc_return(&drv_instance) - 1;
@@ -248,7 +247,6 @@
这些结构体定义如下：
struct v4l2_subdev_core_ops {
- int (*g_chip_ident)(struct v4l2_subdev *sd, struct v4l2_dbg_chip_ident *chip);
int (*log_status)(struct v4l2_subdev *sd);
int (*init)(struct v4l2_subdev *sd, u32 val);
...
@@ -338,24 +336,24 @@
注册之设备后，可通过以下方式直接调用其操作函数：
- err = sd->ops->core->g_chip_ident(sd, &chip);
+ err = sd->ops->core->g_std(sd, &norm);
但使用如下宏会比较容易且合适：
- err = v4l2_subdev_call(sd, core, g_chip_ident, &chip);
+ err = v4l2_subdev_call(sd, core, g_std, &norm);
这个宏将会做 NULL 指针检查，如果 subdev 为 NULL，则返回-ENODEV；如果
-subdev->core 或 subdev->core->g_chip_ident 为 NULL，则返回 -ENOIOCTLCMD；
-否则将返回 subdev->ops->core->g_chip_ident ops 调用的实际结果。
+subdev->core 或 subdev->core->g_std 为 NULL，则返回 -ENOIOCTLCMD；
+否则将返回 subdev->ops->core->g_std ops 调用的实际结果。
有时也可能同时调用所有或一系列子设备的某个操作函数：
- v4l2_device_call_all(v4l2_dev, 0, core, g_chip_ident, &chip);
+ v4l2_device_call_all(v4l2_dev, 0, core, g_std, &norm);
任何不支持此操作的子设备都会被跳过，并忽略错误返回值。但如果你需要
检查出错码，则可使用如下函数：
- err = v4l2_device_call_until_err(v4l2_dev, 0, core, g_chip_ident, &chip);
+ err = v4l2_device_call_until_err(v4l2_dev, 0, core, g_std, &norm);
除 -ENOIOCTLCMD 外的任何错误都会跳出循环并返回错误值。如果（除 -ENOIOCTLCMD
外）没有错误发生，则返回 0。
diff --git a/MAINTAINERS b/MAINTAINERS
index 4e2a1f6..bf61e04 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -90,6 +90,9 @@
F: drivers/net/* all files in drivers/net, but not below
F: */net/* all files in "any top level directory"/net
One pattern per line. Multiple F: lines acceptable.
+ N: Files and directories with regex patterns.
+ N: [^a-z]tegra all files whose path contains the word tegra
+ One pattern per line. Multiple N: lines acceptable.
X: Files and directories that are NOT maintained, same rules as F:
Files exclusions are tested before file matches.
Can be useful for excluding a specific subdirectory, for instance:
@@ -113,12 +116,6 @@
-----------------------------------
-3C505 NETWORK DRIVER
-M: Philip Blundell <philb@gnu.org>
-L: netdev@vger.kernel.org
-S: Maintained
-F: drivers/net/ethernet/i825xx/3c505*
-
3C59X NETWORK DRIVER
M: Steffen Klassert <klassert@mathematik.tu-chemnitz.de>
L: netdev@vger.kernel.org
@@ -183,6 +180,11 @@
S: Maintained
F: Documentation/filesystems/9p.txt
F: fs/9p/
+F: net/9p/
+F: include/net/9p/
+F: include/uapi/linux/virtio_9p.h
+F: include/trace/events/9p.h
+
A8293 MEDIA DRIVER
M: Antti Palosaari <crope@iki.fi>
@@ -228,7 +230,7 @@
F: drivers/platform/x86/acerhdf.c
ACER WMI LAPTOP EXTRAS
-M: Joey Lee <jlee@novell.com>
+M: "Lee, Chun-Yi" <jlee@suse.com>
L: platform-driver-x86@vger.kernel.org
S: Maintained
F: drivers/platform/x86/acer-wmi.c
@@ -245,6 +247,11 @@
F: drivers/pnp/pnpacpi/
F: include/linux/acpi.h
F: include/acpi/
+F: Documentation/acpi
+F: Documentation/ABI/testing/sysfs-bus-acpi
+F: drivers/pci/*acpi*
+F: drivers/pci/*/*acpi*
+F: drivers/pci/*/*/*acpi*
ACPI FAN DRIVER
M: Zhang Rui <rui.zhang@intel.com>
@@ -449,6 +456,7 @@
S: Maintained
F: drivers/char/agp/
F: include/linux/agp*
+F: include/uapi/linux/agp*
AHA152X SCSI DRIVER
M: "Juergen E. Fischer" <fischer@norbit.de>
@@ -464,6 +472,14 @@
F: drivers/scsi/aic7xxx/
F: drivers/scsi/aic7xxx_old/
+AIMSLAB FM RADIO RECEIVER DRIVER
+M: Hans Verkuil <hverkuil@xs4all.nl>
+L: linux-media@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+W: http://linuxtv.org
+S: Maintained
+F: drivers/media/radio/radio-aimslab*
+
AIO
M: Benjamin LaHaise <bcrl@kvack.org>
L: linux-aio@kvack.org
@@ -558,6 +574,18 @@
S: Maintained
F: drivers/infiniband/hw/amso1100/
+ANALOG DEVICES INC AD9389B DRIVER
+M: Hans Verkuil <hans.verkuil@cisco.com>
+L: linux-media@vger.kernel.org
+S: Maintained
+F: drivers/media/i2c/ad9389b*
+
+ANALOG DEVICES INC ADV7604 DRIVER
+M: Hans Verkuil <hans.verkuil@cisco.com>
+L: linux-media@vger.kernel.org
+S: Maintained
+F: drivers/media/i2c/adv7604*
+
ANALOG DEVICES INC ASOC CODEC DRIVERS
M: Lars-Peter Clausen <lars@metafoo.de>
L: device-drivers-devel@blackfin.uclinux.org
@@ -589,6 +617,7 @@
S: Odd fixes
F: arch/x86/kernel/apm_32.c
F: include/linux/apm_bios.h
+F: include/uapi/linux/apm_bios.h
F: drivers/char/apm-emulation.c
APPLE BCM5974 MULTITOUCH DRIVER
@@ -646,7 +675,7 @@
ARM SUB-ARCHITECTURES
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
-S: MAINTAINED
+S: Maintained
F: arch/arm/mach-*/
F: arch/arm/plat-*/
T: git git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git
@@ -668,8 +697,16 @@
F: include/linux/amba/kmi.h
ARM PRIMECELL MMCI PL180/1 DRIVER
-S: Orphan
+M: Russell King <linux@arm.linux.org.uk>
+S: Maintained
F: drivers/mmc/host/mmci.*
+F: include/linux/amba/mmci.h
+
+ARM PRIMECELL UART PL010 AND PL011 DRIVERS
+M: Russell King <linux@arm.linux.org.uk>
+S: Maintained
+F: drivers/tty/serial/amba-pl01*.c
+F: include/linux/amba/serial.h
ARM PRIMECELL BUS SUPPORT
M: Russell King <linux@arm.linux.org.uk>
@@ -715,7 +752,7 @@
F: arch/arm/mach-highbank/
ARM/CAVIUM NETWORKS CNS3XXX MACHINE SUPPORT
-M: Anton Vorontsov <avorontsov@mvista.com>
+M: Anton Vorontsov <anton@enomsg.org>
S: Maintained
F: arch/arm/mach-cns3xxx/
T: git git://git.infradead.org/users/cbou/linux-cns3xxx.git
@@ -770,10 +807,12 @@
ARM/CSR SIRFPRIMA2 MACHINE SUPPORT
M: Barry Song <baohua.song@csr.com>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/baohua/linux.git
S: Maintained
F: arch/arm/mach-prima2/
F: drivers/dma/sirf-dma.c
F: drivers/i2c/busses/i2c-sirf.c
+F: drivers/mmc/host/sdhci-sirf.c
F: drivers/pinctrl/pinctrl-sirf.c
F: drivers/spi/spi-sirf.c
@@ -1005,8 +1044,8 @@
F: drivers/mmc/host/msm_sdcc.h
F: drivers/tty/serial/msm_serial.h
F: drivers/tty/serial/msm_serial.c
-F: drivers/platform/msm/
F: drivers/*/pm8???-*
+F: drivers/ssbi/
F: include/linux/mfd/pm8xxx/
T: git git://git.kernel.org/pub/scm/linux/kernel/git/davidb/linux-msm.git
S: Maintained
@@ -1069,7 +1108,6 @@
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
W: http://www.arm.linux.org.uk/
S: Maintained
-F: arch/arm/common/time-acorn.c
F: arch/arm/include/asm/hardware/entry-macro-iomd.S
F: arch/arm/include/asm/hardware/ioc.h
F: arch/arm/include/asm/hardware/iomd.h
@@ -1094,7 +1132,6 @@
S: Maintained
F: arch/arm/plat-samsung/
F: arch/arm/plat-s3c24xx/
-F: arch/arm/plat-s5p/
F: arch/arm/mach-s3c24*/
F: arch/arm/mach-s3c64xx/
F: drivers/*/*s3c2410*
@@ -1109,6 +1146,7 @@
S: Maintained
F: arch/arm/mach-s5p*/
F: arch/arm/mach-exynos*/
+N: exynos
ARM/SAMSUNG MOBILE MACHINE SUPPORT
M: Kyungmin Park <kyungmin.park@samsung.com>
@@ -1119,15 +1157,13 @@
F: arch/arm/mach-exynos/mach-universal_c210.c
F: arch/arm/mach-exynos/mach-nuri.c
-ARM/SAMSUNG S5P SERIES FIMC SUPPORT
+ARM/SAMSUNG S5P SERIES 2D GRAPHICS ACCELERATION (G2D) SUPPORT
M: Kyungmin Park <kyungmin.park@samsung.com>
-M: Sylwester Nawrocki <s.nawrocki@samsung.com>
+M: Kamil Debski <k.debski@samsung.com>
L: linux-arm-kernel@lists.infradead.org
L: linux-media@vger.kernel.org
S: Maintained
-F: arch/arm/plat-s5p/dev-fimc*
-F: arch/arm/plat-samsung/include/plat/*fimc*
-F: drivers/media/platform/s5p-fimc/
+F: drivers/media/platform/s5p-g2d/
ARM/SAMSUNG S5P SERIES Multi Format Codec (MFC) SUPPORT
M: Kyungmin Park <kyungmin.park@samsung.com>
@@ -1136,7 +1172,7 @@
L: linux-arm-kernel@lists.infradead.org
L: linux-media@vger.kernel.org
S: Maintained
-F: arch/arm/plat-s5p/dev-mfc.c
+F: arch/arm/plat-samsung/s5p-dev-mfc.c
F: drivers/media/platform/s5p-mfc/
ARM/SAMSUNG S5P SERIES TV SUBSYSTEM SUPPORT
@@ -1168,6 +1204,15 @@
S: Maintained
F: drivers/clk/socfpga/
+ARM/STI ARCHITECTURE
+M: Srinivas Kandagatla <srinivas.kandagatla@st.com>
+M: Stuart Menefy <stuart.menefy@st.com>
+L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
+L: kernel@stlinux.com
+W: http://www.stlinux.com
+S: Maintained
+F: arch/arm/mach-sti/
+
ARM/TECHNOLOGIC SYSTEMS TS7250 MACHINE SUPPORT
M: Lennert Buytenhek <kernel@wantstofly.org>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
@@ -1250,12 +1295,18 @@
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
F: arch/arm/mach-vt8500/
+F: drivers/clocksource/vt8500_timer.c
+F: drivers/gpio/gpio-vt8500.c
+F: drivers/i2c/busses/i2c-wmt.c
+F: drivers/mmc/host/wmt-sdmmc.c
+F: drivers/pwm/pwm-vt8500.c
+F: drivers/rtc/rtc-vt8500.c
+F: drivers/tty/serial/vt8500_serial.c
+F: drivers/usb/host/ehci-vt8500.c
+F: drivers/usb/host/uhci-platform.c
F: drivers/video/vt8500lcdfb.*
F: drivers/video/wm8505fb*
F: drivers/video/wmt_ge_rops.*
-F: drivers/tty/serial/vt8500_serial.c
-F: drivers/rtc/rtc-vt8500-c
-F: drivers/mmc/host/wmt-sdmmc.c
ARM/ZIPIT Z2 SUPPORT
M: Marek Vasut <marek.vasut@gmail.com>
@@ -1264,6 +1315,21 @@
F: arch/arm/mach-pxa/z2.c
F: arch/arm/mach-pxa/include/mach/z2.h
+ARM/ZYNQ ARCHITECTURE
+M: Michal Simek <michal.simek@xilinx.com>
+L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
+W: http://wiki.xilinx.com
+T: git git://git.xilinx.com/linux-xlnx.git
+S: Supported
+F: arch/arm/mach-zynq/
+F: drivers/cpuidle/cpuidle-zynq.c
+
+ARM SMMU DRIVER
+M: Will Deacon <will.deacon@arm.com>
+L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
+S: Maintained
+F: drivers/iommu/arm-smmu.c
+
ARM64 PORT (AARCH64 ARCHITECTURE)
M: Catalin Marinas <catalin.marinas@arm.com>
M: Will Deacon <will.deacon@arm.com>
@@ -1272,6 +1338,14 @@
F: arch/arm64/
F: Documentation/arm64/
+AS3645A LED FLASH CONTROLLER DRIVER
+M: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+L: linux-media@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+S: Maintained
+F: drivers/media/i2c/as3645a.c
+F: include/media/as3645a.h
+
ASC7621 HARDWARE MONITOR DRIVER
M: George Joseph <george.joseph@fairview5.com>
L: lm-sensors@lm-sensors.org
@@ -1288,12 +1362,6 @@
F: drivers/platform/x86/asus*.c
F: drivers/platform/x86/eeepc*.c
-ASUS ASB100 HARDWARE MONITOR DRIVER
-M: "Mark M. Hoffman" <mhoffman@lightlink.com>
-L: lm-sensors@lm-sensors.org
-S: Maintained
-F: drivers/hwmon/asb100.c
-
ASYNCHRONOUS TRANSFERS/TRANSFORMS (IOAT) API
M: Dan Williams <djbw@fb.com>
W: http://sourceforge.net/projects/xscaleiop
@@ -1305,7 +1373,7 @@
F: include/linux/async_tx.h
AT24 EEPROM DRIVER
-M: Wolfram Sang <w.sang@pengutronix.de>
+M: Wolfram Sang <wsa@the-dreams.de>
L: linux-i2c@vger.kernel.org
S: Maintained
F: drivers/misc/eeprom/at24.c
@@ -1353,6 +1421,14 @@
S: Supported
F: drivers/net/wireless/ath/ath9k/
+WILOCITY WIL6210 WIRELESS DRIVER
+M: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
+L: linux-wireless@vger.kernel.org
+L: wil6210@qca.qualcomm.com
+S: Supported
+W: http://wireless.kernel.org/en/users/Drivers/wil6210
+F: drivers/net/wireless/ath/wil6210/
+
CARL9170 LINUX COMMUNITY WIRELESS DRIVER
M: Christian Lamparter <chunkeey@googlemail.com>
L: linux-wireless@vger.kernel.org
@@ -1388,6 +1464,7 @@
S: Maintained
F: drivers/atm/
F: include/linux/atm*
+F: include/uapi/linux/atm*
ATMEL AT91 / AT32 MCI DRIVER
M: Ludovic Desroches <ludovic.desroches@atmel.com>
@@ -1406,13 +1483,19 @@
S: Supported
F: drivers/dma/at_hdmac.c
F: drivers/dma/at_hdmac_regs.h
-F: arch/arm/mach-at91/include/mach/at_hdmac.h
+F: include/linux/platform_data/dma-atmel.h
+
+ATMEL I2C DRIVER
+M: Ludovic Desroches <ludovic.desroches@atmel.com>
+L: linux-i2c@vger.kernel.org
+S: Supported
+F: drivers/i2c/busses/i2c-at91.c
ATMEL ISI DRIVER
M: Josh Wu <josh.wu@atmel.com>
L: linux-media@vger.kernel.org
S: Supported
-F: drivers/media/platform/atmel-isi.c
+F: drivers/media/platform/soc_camera/atmel-isi.c
F: include/media/atmel-isi.h
ATMEL LCDFB DRIVER
@@ -1467,6 +1550,7 @@
T: git git://git.kernel.org/pub/scm/linux/kernel/git/viro/audit-current.git
S: Maintained
F: include/linux/audit.h
+F: include/uapi/linux/audit.h
F: kernel/audit*
AUXILIARY DISPLAY DRIVERS
@@ -1481,7 +1565,7 @@
M: Haavard Skinnemoen <hskinnemoen@gmail.com>
M: Hans-Christian Egtvedt <egtvedt@samfundet.no>
W: http://www.atmel.com/products/AVR32/
-W: http://avr32linux.org/
+W: http://mirror.egtvedt.no/avr32linux.org/
W: http://avrfreaks.net/
S: Maintained
F: arch/avr32/
@@ -1497,18 +1581,26 @@
L: linux-hams@vger.kernel.org
W: http://www.linux-ax25.org/
S: Maintained
-F: include/linux/ax25.h
+F: include/uapi/linux/ax25.h
F: include/net/ax25.h
F: net/ax25/
AZ6007 DVB DRIVER
-M: Mauro Carvalho Chehab <mchehab@redhat.com>
+M: Mauro Carvalho Chehab <m.chehab@samsung.com>
L: linux-media@vger.kernel.org
W: http://linuxtv.org
T: git git://linuxtv.org/media_tree.git
S: Maintained
F: drivers/media/usb/dvb-usb-v2/az6007.c
+AZTECH FM RADIO RECEIVER DRIVER
+M: Hans Verkuil <hverkuil@xs4all.nl>
+L: linux-media@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+W: http://linuxtv.org
+S: Maintained
+F: drivers/media/radio/radio-aztech*
+
B43 WIRELESS DRIVER
M: Stefano Brivio <stefano.brivio@polimi.it>
L: linux-wireless@vger.kernel.org
@@ -1528,6 +1620,7 @@
BACKLIGHT CLASS/SUBSYSTEM
M: Richard Purdie <rpurdie@rpsys.net>
+M: Jingoo Han <jg1.han@samsung.com>
S: Maintained
F: drivers/video/backlight/
F: include/linux/backlight.h
@@ -1548,6 +1641,13 @@
S: Maintained
F: drivers/net/hamradio/baycom*
+BCACHE (BLOCK LAYER CACHE)
+M: Kent Overstreet <koverstreet@google.com>
+L: linux-bcache@vger.kernel.org
+W: http://bcache.evilpiepirate.org
+S: Maintained:
+F: drivers/md/bcache/
+
BEFS FILE SYSTEM
S: Orphan
F: Documentation/filesystems/befs.txt
@@ -1558,7 +1658,7 @@
S: Maintained
F: Documentation/filesystems/bfs.txt
F: fs/bfs/
-F: include/linux/bfs_fs.h
+F: include/uapi/linux/bfs_fs.h
BLACKFIN ARCHITECTURE
M: Mike Frysinger <vapier@gentoo.org>
@@ -1608,6 +1708,15 @@
S: Supported
F: drivers/i2c/busses/i2c-bfin-twi.c
+BLACKFIN MEDIA DRIVER
+M: Scott Jiang <scott.jiang.linux@gmail.com>
+L: uclinux-dist-devel@blackfin.uclinux.org
+W: http://blackfin.uclinux.org/
+S: Supported
+F: drivers/media/platform/blackfin/
+F: drivers/media/i2c/adv7183*
+F: drivers/media/i2c/vs6624*
+
BLINKM RGB LED DRIVER
M: Jan-Simon Moeller <jansimon.moeller@gmx.de>
S: Maintained
@@ -1655,7 +1764,7 @@
W: http://sourceforge.net/projects/bonding/
S: Supported
F: drivers/net/bonding/
-F: include/linux/if_bonding.h
+F: include/uapi/linux/if_bonding.h
BROADCOM B44 10/100 ETHERNET DRIVER
M: Gary Zambrano <zambrano@broadcom.com>
@@ -1687,7 +1796,7 @@
F: drivers/*/*bcm2835*
BROADCOM TG3 GIGABIT ETHERNET DRIVER
-M: Matt Carlson <mcarlson@broadcom.com>
+M: Nithin Nayak Sujir <nsujir@broadcom.com>
M: Michael Chan <mchan@broadcom.com>
L: netdev@vger.kernel.org
S: Supported
@@ -1717,7 +1826,8 @@
F: include/linux/bcma/
BROCADE BFA FC SCSI DRIVER
-M: Krishna C Gudipati <kgudipat@brocade.com>
+M: Anil Gurumurthy <agurumur@brocade.com>
+M: Vijaya Mohan Guvva <vmohan@brocade.com>
L: linux-scsi@vger.kernel.org
S: Supported
F: drivers/scsi/bfa/
@@ -1734,6 +1844,7 @@
S: Supported
F: block/bsg.c
F: include/linux/bsg.h
+F: include/uapi/linux/bsg.h
BT87X AUDIO DRIVER
M: Clemens Ladisch <clemens@ladisch.de>
@@ -1760,7 +1871,7 @@
F: fs/btrfs/
BTTV VIDEO4LINUX DRIVER
-M: Mauro Carvalho Chehab <mchehab@redhat.com>
+M: Mauro Carvalho Chehab <m.chehab@samsung.com>
L: linux-media@vger.kernel.org
W: http://linuxtv.org
T: git git://linuxtv.org/media_tree.git
@@ -1768,6 +1879,13 @@
F: Documentation/video4linux/bttv/
F: drivers/media/pci/bt8xx/bttv*
+BUSLOGIC SCSI DRIVER
+M: Khalid Aziz <khalid@gonehiking.org>
+L: linux-scsi@vger.kernel.org
+S: Maintained
+F: drivers/scsi/BusLogic.*
+F: drivers/scsi/FlashPoint.*
+
C-MEDIA CMI8788 DRIVER
M: Clemens Ladisch <clemens@ladisch.de>
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
@@ -1790,6 +1908,14 @@
F: Documentation/filesystems/caching/cachefiles.txt
F: fs/cachefiles/
+CADET FM/AM RADIO RECEIVER DRIVER
+M: Hans Verkuil <hverkuil@xs4all.nl>
+L: linux-media@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+W: http://linuxtv.org
+S: Maintained
+F: drivers/media/radio/radio-cadet*
+
CAFE CMOS INTEGRATED CAMERA CONTROLLER DRIVER
M: Jonathan Corbet <corbet@lwn.net>
L: linux-media@vger.kernel.org
@@ -1799,12 +1925,12 @@
F: drivers/media/platform/marvell-ccic/
CAIF NETWORK LAYER
-M: Sjur Braendeland <sjur.brandeland@stericsson.com>
+M: Dmitry Tarnyagin <dmitry.tarnyagin@lockless.no>
L: netdev@vger.kernel.org
S: Supported
F: Documentation/networking/caif/
F: drivers/net/caif/
-F: include/linux/caif/
+F: include/uapi/linux/caif/
F: include/net/caif/
F: net/caif/
@@ -1825,11 +1951,11 @@
T: git git://gitorious.org/linux-can/linux-can-next.git
S: Maintained
F: net/can/
-F: include/linux/can.h
F: include/linux/can/core.h
-F: include/linux/can/bcm.h
-F: include/linux/can/raw.h
-F: include/linux/can/gw.h
+F: include/uapi/linux/can.h
+F: include/uapi/linux/can/bcm.h
+F: include/uapi/linux/can/raw.h
+F: include/uapi/linux/can/gw.h
CAN NETWORK DRIVERS
M: Wolfgang Grandegger <wg@grandegger.com>
@@ -1840,15 +1966,16 @@
S: Maintained
F: drivers/net/can/
F: include/linux/can/dev.h
-F: include/linux/can/error.h
-F: include/linux/can/netlink.h
F: include/linux/can/platform/
+F: include/uapi/linux/can/error.h
+F: include/uapi/linux/can/netlink.h
CAPABILITIES
M: Serge Hallyn <serge.hallyn@canonical.com>
L: linux-security-module@vger.kernel.org
S: Supported
F: include/linux/capability.h
+F: include/uapi/linux/capability.h
F: security/capability.c
F: security/commoncap.c
F: kernel/capability.c
@@ -1861,6 +1988,7 @@
S: Supported
F: arch/powerpc/include/asm/cell*.h
F: arch/powerpc/include/asm/spu*.h
+F: arch/powerpc/include/uapi/asm/spu*.h
F: arch/powerpc/oprofile/*cell*
F: arch/powerpc/platforms/cell/
@@ -1909,7 +2037,7 @@
T: git git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git
S: Maintained
-F: include/linux/nl80211.h
+F: include/uapi/linux/nl80211.h
F: include/net/cfg80211.h
F: net/wireless/*
X: net/wireless/wext*
@@ -1924,7 +2052,8 @@
CHECKPATCH
M: Andy Whitcroft <apw@canonical.com>
-S: Supported
+M: Joe Perches <joe@perches.com>
+S: Maintained
F: scripts/checkpatch.pl
CHINESE DOCUMENTATION
@@ -1961,9 +2090,9 @@
F: drivers/usb/host/ohci-ep93xx.c
CIRRUS LOGIC CS4270 SOUND DRIVER
-M: Timur Tabi <timur@freescale.com>
+M: Timur Tabi <timur@tabi.org>
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
-S: Supported
+S: Odd Fixes
F: sound/soc/codecs/cs4270*
CLEANCACHE API
@@ -1979,8 +2108,8 @@
F: include/linux/clk.h
CISCO FCOE HBA DRIVER
-M: Abhijeet Joglekar <abjoglek@cisco.com>
-M: Venkata Siva Vijayendra Bhamidipati <vbhamidi@cisco.com>
+M: Hiral Patel <hiralpat@cisco.com>
+M: Suma Ramars <sramars@cisco.com>
M: Brian Uchino <buchino@cisco.com>
L: linux-scsi@vger.kernel.org
S: Supported
@@ -1997,9 +2126,12 @@
M: Julia Lawall <Julia.Lawall@lip6.fr>
M: Gilles Muller <Gilles.Muller@lip6.fr>
M: Nicolas Palix <nicolas.palix@imag.fr>
+M: Michal Marek <mmarek@suse.cz>
L: cocci@systeme.lip6.fr (moderated for non-subscribers)
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild.git misc
W: http://coccinelle.lip6.fr/
S: Supported
+F: Documentation/coccinelle.txt
F: scripts/coccinelle/
F: scripts/coccicheck
@@ -2012,15 +2144,17 @@
F: Documentation/filesystems/coda.txt
F: fs/coda/
F: include/linux/coda*.h
+F: include/uapi/linux/coda*.h
COMMON CLK FRAMEWORK
M: Mike Turquette <mturquette@linaro.org>
L: linux-arm-kernel@lists.infradead.org (same as CLK API & CLKDEV)
T: git git://git.linaro.org/people/mturquette/linux.git
S: Maintained
-F: drivers/clk/clk.c
-F: drivers/clk/clk-*
+F: drivers/clk/
+X: drivers/clk/clkdev.c
F: include/linux/clk-pr*
+F: include/linux/clk/
COMMON INTERNET FILE SYSTEM (CIFS)
M: Steve French <sfrench@samba.org>
@@ -2109,12 +2243,35 @@
CPU FREQUENCY DRIVERS
M: Rafael J. Wysocki <rjw@sisk.pl>
+M: Viresh Kumar <viresh.kumar@linaro.org>
L: cpufreq@vger.kernel.org
L: linux-pm@vger.kernel.org
S: Maintained
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git
+T: git git://git.linaro.org/people/vireshk/linux.git (For ARM Updates)
F: drivers/cpufreq/
F: include/linux/cpufreq.h
+CPU FREQUENCY DRIVERS - ARM BIG LITTLE
+M: Viresh Kumar <viresh.kumar@linaro.org>
+M: Sudeep KarkadaNagesha <sudeep.karkadanagesha@arm.com>
+L: cpufreq@vger.kernel.org
+L: linux-pm@vger.kernel.org
+W: http://www.arm.com/products/processors/technologies/biglittleprocessing.php
+S: Maintained
+F: drivers/cpufreq/arm_big_little.h
+F: drivers/cpufreq/arm_big_little.c
+F: drivers/cpufreq/arm_big_little_dt.c
+
+CPUIDLE DRIVERS
+M: Rafael J. Wysocki <rjw@sisk.pl>
+M: Daniel Lezcano <daniel.lezcano@linaro.org>
+L: linux-pm@vger.kernel.org
+S: Maintained
+T: git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git
+F: drivers/cpuidle/*
+F: include/linux/cpuidle.h
+
CPUID/MSR DRIVER
M: "H. Peter Anvin" <hpa@zytor.com>
S: Maintained
@@ -2128,10 +2285,10 @@
F: tools/power/cpupower
CPUSETS
-M: Paul Menage <paul@paulmenage.org>
+M: Li Zefan <lizefan@huawei.com>
W: http://www.bullopensource.org/cpuset/
W: http://oss.sgi.com/projects/cpusets/
-S: Supported
+S: Maintained
F: Documentation/cgroups/cpusets.txt
F: include/linux/cpuset.h
F: kernel/cpuset.c
@@ -2175,6 +2332,11 @@
S: Maintained
F: sound/pci/cs5535audio/
+CW1200 WLAN driver
+M: Solomon Peachy <pizza@shaftnet.org>
+S: Maintained
+F: drivers/net/wireless/cw1200/
+
CX18 VIDEO4LINUX DRIVER
M: Andy Walls <awalls@md.metrocast.net>
L: ivtv-devel@ivtvdriver.org (moderated for non-subscribers)
@@ -2187,8 +2349,17 @@
F: drivers/media/pci/cx18/
F: include/uapi/linux/ivtv*
+CX2341X MPEG ENCODER HELPER MODULE
+M: Hans Verkuil <hverkuil@xs4all.nl>
+L: linux-media@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+W: http://linuxtv.org
+S: Maintained
+F: drivers/media/common/cx2341x*
+F: include/media/cx2341x*
+
CX88 VIDEO4LINUX DRIVER
-M: Mauro Carvalho Chehab <mchehab@redhat.com>
+M: Mauro Carvalho Chehab <m.chehab@samsung.com>
L: linux-media@vger.kernel.org
W: http://linuxtv.org
T: git git://linuxtv.org/media_tree.git
@@ -2255,23 +2426,28 @@
S: Maintained
F: drivers/video/cyber2000fb.*
-CYCLADES 2X SYNC CARD DRIVER
-M: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
-W: http://oops.ghostprotocols.net:81/blog
-S: Maintained
-F: drivers/net/wan/cycx*
-
CYCLADES ASYNC MUX DRIVER
W: http://www.cyclades.com/
S: Orphan
F: drivers/tty/cyclades.c
F: include/linux/cyclades.h
+F: include/uapi/linux/cyclades.h
CYCLADES PC300 DRIVER
W: http://www.cyclades.com/
S: Orphan
F: drivers/net/wan/pc300*
+CYPRESS_FIRMWARE MEDIA DRIVER
+M: Antti Palosaari <crope@iki.fi>
+L: linux-media@vger.kernel.org
+W: http://linuxtv.org/
+W: http://palosaari.fi/linux/
+Q: http://patchwork.linuxtv.org/project/linux-media/list/
+T: git git://linuxtv.org/anttip/media_tree.git
+S: Maintained
+F: drivers/media/common/cypress_firmware*
+
CYTTSP TOUCHSCREEN DRIVER
M: Javier Martinez Canillas <javier@dowhile0.org>
L: linux-input@vger.kernel.org
@@ -2323,6 +2499,7 @@
W: http://www.linuxfoundation.org/collaborate/workgroups/networking/dccp
S: Maintained
F: include/linux/dccp.h
+F: include/uapi/linux/dccp.h
F: include/linux/tfrc.h
F: net/dccp/
@@ -2345,11 +2522,9 @@
F: drivers/platform/x86/dell-laptop.c
DELL LAPTOP SMM DRIVER
-M: Massimo Dal Zotto <dz@debian.org>
-W: http://www.debian.org/~dz/i8k/
-S: Maintained
+S: Orphan
F: drivers/char/i8k.c
-F: include/linux/i8k.h
+F: include/uapi/linux/i8k.h
DELL SYSTEMS MANAGEMENT BASE DRIVER (dcdbas)
M: Doug Warzecha <Douglas_Warzecha@dell.com>
@@ -2362,6 +2537,12 @@
S: Maintained
F: drivers/platform/x86/dell-wmi.c
+DESIGNWARE USB2 DRD IP DRIVER
+M: Paul Zimmerman <paulz@synopsys.com>
+L: linux-usb@vger.kernel.org
+S: Maintained
+F: drivers/staging/dwc2/
+
DESIGNWARE USB3 DRD IP DRIVER
M: Felipe Balbi <balbi@ti.com>
L: linux-usb@vger.kernel.org
@@ -2373,7 +2554,7 @@
DEVICE FREQUENCY (DEVFREQ)
M: MyungJoo Ham <myungjoo.ham@samsung.com>
M: Kyungmin Park <kyungmin.park@samsung.com>
-L: linux-kernel@vger.kernel.org
+L: linux-pm@vger.kernel.org
S: Maintained
F: drivers/devfreq/
@@ -2384,6 +2565,7 @@
DEVICE-MAPPER (LVM)
M: Alasdair Kergon <agk@redhat.com>
+M: Mike Snitzer <snitzer@redhat.com>
M: dm-devel@redhat.com
L: dm-devel@redhat.com
W: http://sources.redhat.com/dm
@@ -2395,6 +2577,7 @@
F: drivers/md/persistent-data/
F: include/linux/device-mapper.h
F: include/linux/dm-*.h
+F: include/uapi/linux/dm-*.h
DIOLAN U2C-12 I2C DRIVER
M: Guenter Roeck <linux@roeck-us.net>
@@ -2422,6 +2605,7 @@
F: Documentation/filesystems/quota.txt
F: fs/quota/
F: include/linux/quota*.h
+F: include/uapi/linux/quota*.h
DISPLAYLINK USB 2.0 FRAMEBUFFER DRIVER (UDLFB)
M: Bernie Thompson <bernie@plugable.com>
@@ -2528,15 +2712,17 @@
S: Maintained
F: drivers/gpu/drm/
F: include/drm/
+F: include/uapi/drm/
INTEL DRM DRIVERS (excluding Poulsbo, Moorestown and derivative chipsets)
M: Daniel Vetter <daniel.vetter@ffwll.ch>
-L: intel-gfx@lists.freedesktop.org (subscribers-only)
+L: intel-gfx@lists.freedesktop.org
L: dri-devel@lists.freedesktop.org
T: git git://people.freedesktop.org/~danvet/drm-intel
S: Supported
F: drivers/gpu/drm/i915
F: include/drm/i915*
+F: include/uapi/drm/i915*
DRM DRIVERS FOR EXYNOS
M: Inki Dae <inki.dae@samsung.com>
@@ -2548,16 +2734,26 @@
S: Supported
F: drivers/gpu/drm/exynos
F: include/drm/exynos*
+F: include/uapi/drm/exynos*
DRM DRIVERS FOR NVIDIA TEGRA
-M: Thierry Reding <thierry.reding@avionic-design.de>
+M: Thierry Reding <thierry.reding@gmail.com>
+M: Terje Bergström <tbergstrom@nvidia.com>
L: dri-devel@lists.freedesktop.org
L: linux-tegra@vger.kernel.org
-T: git git://gitorious.org/thierryreding/linux.git
+T: git git://anongit.freedesktop.org/tegra/linux.git
S: Maintained
-F: drivers/gpu/drm/tegra/
+F: drivers/gpu/host1x/
+F: include/uapi/drm/tegra_drm.h
F: Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt
+DSBR100 USB FM RADIO DRIVER
+M: Alexey Klimov <klimov.linux@gmail.com>
+L: linux-media@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+S: Maintained
+F: drivers/media/radio/dsbr100.c
+
DSCC4 DRIVER
M: Francois Romieu <romieu@fr.zoreil.com>
L: netdev@vger.kernel.org
@@ -2622,17 +2818,7 @@
Q: http://patchwork.linuxtv.org/project/linux-media/list/
T: git git://linuxtv.org/media_tree.git
S: Maintained
-F: drivers/media/usb/dvb-usb-v2/cxusb*
-
-DVB_USB_CYPRESS_FIRMWARE MEDIA DRIVER
-M: Antti Palosaari <crope@iki.fi>
-L: linux-media@vger.kernel.org
-W: http://linuxtv.org/
-W: http://palosaari.fi/linux/
-Q: http://patchwork.linuxtv.org/project/linux-media/list/
-T: git git://linuxtv.org/anttip/media_tree.git
-S: Maintained
-F: drivers/media/usb/dvb-usb-v2/cypress_firmware*
+F: drivers/media/usb/dvb-usb/cxusb*
DVB_USB_EC168 MEDIA DRIVER
M: Antti Palosaari <crope@iki.fi>
@@ -2644,6 +2830,15 @@
S: Maintained
F: drivers/media/usb/dvb-usb-v2/ec168*
+DVB_USB_GL861 MEDIA DRIVER
+M: Antti Palosaari <crope@iki.fi>
+L: linux-media@vger.kernel.org
+W: http://linuxtv.org/
+Q: http://patchwork.linuxtv.org/project/linux-media/list/
+T: git git://linuxtv.org/anttip/media_tree.git
+S: Maintained
+F: drivers/media/usb/dvb-usb-v2/gl861*
+
DVB_USB_MXL111SF MEDIA DRIVER
M: Michael Krufky <mkrufky@linuxtv.org>
L: linux-media@vger.kernel.org
@@ -2722,6 +2917,7 @@
W: http://ebtables.sourceforge.net/
S: Maintained
F: include/linux/netfilter_bridge/ebt_*.h
+F: include/uapi/linux/netfilter_bridge/ebt_*.h
F: net/bridge/netfilter/ebt*.c
EC100 MEDIA DRIVER
@@ -2736,8 +2932,8 @@
ECRYPT FILE SYSTEM
M: Tyler Hicks <tyhicks@canonical.com>
-M: Dustin Kirkland <dustin.kirkland@gazzang.com>
L: ecryptfs@vger.kernel.org
+W: http://ecryptfs.org
W: https://launchpad.net/ecryptfs
S: Supported
F: Documentation/filesystems/ecryptfs.txt
@@ -2784,6 +2980,13 @@
S: Maintained
F: drivers/edac/e7xxx_edac.c
+EDAC-GHES
+M: Mauro Carvalho Chehab <m.chehab@samsung.com>
+L: linux-edac@vger.kernel.org
+W: bluesmoke.sourceforge.net
+S: Maintained
+F: drivers/edac/ghes-edac.c
+
EDAC-I82443BXGX
M: Tim Small <tim@buttersideup.com>
L: linux-edac@vger.kernel.org
@@ -2806,21 +3009,21 @@
F: drivers/edac/i5000_edac.c
EDAC-I5400
-M: Mauro Carvalho Chehab <mchehab@redhat.com>
+M: Mauro Carvalho Chehab <m.chehab@samsung.com>
L: linux-edac@vger.kernel.org
W: bluesmoke.sourceforge.net
S: Maintained
F: drivers/edac/i5400_edac.c
EDAC-I7300
-M: Mauro Carvalho Chehab <mchehab@redhat.com>
+M: Mauro Carvalho Chehab <m.chehab@samsung.com>
L: linux-edac@vger.kernel.org
W: bluesmoke.sourceforge.net
S: Maintained
F: drivers/edac/i7300_edac.c
EDAC-I7CORE
-M: Mauro Carvalho Chehab <mchehab@redhat.com>
+M: Mauro Carvalho Chehab <m.chehab@samsung.com>
L: linux-edac@vger.kernel.org
W: bluesmoke.sourceforge.net
S: Maintained
@@ -2849,7 +3052,7 @@
F: drivers/edac/r82600_edac.c
EDAC-SBRIDGE
-M: Mauro Carvalho Chehab <mchehab@redhat.com>
+M: Mauro Carvalho Chehab <m.chehab@samsung.com>
L: linux-edac@vger.kernel.org
W: bluesmoke.sourceforge.net
S: Maintained
@@ -2872,9 +3075,18 @@
F: arch/x86/boot/compressed/eboot.[ch]
F: arch/x86/include/asm/efi.h
F: arch/x86/platform/efi/*
-F: drivers/firmware/efivars.c
+F: drivers/firmware/efi/*
F: include/linux/efi*.h
+EFI VARIABLE FILESYSTEM
+M: Matthew Garrett <matthew.garrett@nebula.com>
+M: Jeremy Kerr <jk@ozlabs.org>
+M: Matt Fleming <matt.fleming@intel.com>
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git
+L: linux-efi@vger.kernel.org
+S: Maintained
+F: fs/efivarfs/
+
EFIFB FRAMEBUFFER DRIVER
L: linux-fbdev@vger.kernel.org
M: Peter Jones <pjones@redhat.com>
@@ -2900,7 +3112,7 @@
F: drivers/net/ethernet/ibm/ehea/
EM28XX VIDEO4LINUX DRIVER
-M: Mauro Carvalho Chehab <mchehab@redhat.com>
+M: Mauro Carvalho Chehab <m.chehab@samsung.com>
L: linux-media@vger.kernel.org
W: http://linuxtv.org
T: git git://linuxtv.org/media_tree.git
@@ -2933,11 +3145,12 @@
S: Maintained
F: drivers/media/rc/ene_ir.*
-EPSON 1355 FRAMEBUFFER DRIVER
-M: Christopher Hoover <ch@murgatroid.com>
-M: Christopher Hoover <ch@hpl.hp.com>
-S: Maintained
-F: drivers/video/epson1355fb.c
+ENHANCED ERROR HANDLING (EEH)
+M: Gavin Shan <shangw@linux.vnet.ibm.com>
+L: linuxppc-dev@lists.ozlabs.org
+S: Supported
+F: Documentation/powerpc/eeh-pci-error-recovery.txt
+F: arch/powerpc/kernel/eeh*.c
EPSON S1D13XXX FRAMEBUFFER DRIVER
M: Kristoffer Ericson <kristoffer.ericson@gmail.com>
@@ -2946,14 +3159,8 @@
F: drivers/video/s1d13xxxfb.c
F: include/video/s1d13xxxfb.h
-ETHEREXPRESS-16 NETWORK DRIVER
-M: Philip Blundell <philb@gnu.org>
-L: netdev@vger.kernel.org
-S: Maintained
-F: drivers/net/ethernet/i825xx/eexpress.*
-
ETHERNET BRIDGE
-M: Stephen Hemminger <shemminger@vyatta.com>
+M: Stephen Hemminger <stephen@networkplumber.org>
L: bridge@lists.linux-foundation.org
L: netdev@vger.kernel.org
W: http://www.linuxfoundation.org/en/Net:Bridge
@@ -2961,11 +3168,6 @@
F: include/linux/netfilter_bridge/
F: net/bridge/
-ETHERTEAM 16I DRIVER
-M: Mika Kuoppala <miku@iki.fi>
-S: Maintained
-F: drivers/net/ethernet/fujitsu/eth16i.c
-
EXT2 FILE SYSTEM
M: Jan Kara <jack@suse.cz>
L: linux-ext4@vger.kernel.org
@@ -3051,6 +3253,7 @@
S: Maintained
F: fs/notify/fanotify/
F: include/linux/fanotify.h
+F: include/uapi/linux/fanotify.h
FARSYNC SYNCHRONOUS DRIVER
M: Kevin Curtis <kevin.curtis@farsite.co.uk>
@@ -3066,7 +3269,7 @@
FCOE SUBSYSTEM (libfc, libfcoe, fcoe)
M: Robert Love <robert.w.love@intel.com>
-L: devel@open-fcoe.org
+L: fcoe-devel@open-fcoe.org
W: www.Open-FCoE.org
S: Supported
F: drivers/scsi/libfc/
@@ -3074,6 +3277,7 @@
F: include/scsi/fc/
F: include/scsi/libfc.h
F: include/scsi/libfcoe.h
+F: include/uapi/scsi/fc/
FILE LOCKING (flock() and fcntl()/lockf())
M: Matthew Wilcox <matthew@wil.cx>
@@ -3081,6 +3285,8 @@
S: Maintained
F: include/linux/fcntl.h
F: include/linux/fs.h
+F: include/uapi/linux/fcntl.h
+F: include/uapi/linux/fs.h
F: fs/fcntl.c
F: fs/locks.c
@@ -3140,12 +3346,27 @@
F: drivers/base/firmware*.c
F: include/linux/firmware.h
+FLASHSYSTEM DRIVER (IBM FlashSystem 70/80 PCI SSD Flash Card)
+M: Joshua Morris <josh.h.morris@us.ibm.com>
+M: Philip Kelleher <pjk1939@linux.vnet.ibm.com>
+S: Maintained
+F: drivers/block/rsxx/
+
FLOPPY DRIVER
M: Jiri Kosina <jkosina@suse.cz>
T: git git://git.kernel.org/pub/scm/linux/kernel/git/jikos/floppy.git
S: Odd fixes
F: drivers/block/floppy.c
+FMC SUBSYSTEM
+M: Alessandro Rubini <rubini@gnudd.com>
+W: http://www.ohwr.org/projects/fmc-bus
+S: Supported
+F: drivers/fmc/
+F: include/linux/fmc*.h
+F: include/linux/ipmi-fru.h
+K: fmc_d.*register
+
FPU EMULATOR
M: Bill Metzenthen <billm@melbpc.org.au>
W: http://floatingpoint.sourceforge.net/emulator/index.html
@@ -3159,22 +3380,25 @@
F: drivers/net/wan/sdla.c
FRAMEBUFFER LAYER
-M: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
+M: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
+M: Tomi Valkeinen <tomi.valkeinen@ti.com>
L: linux-fbdev@vger.kernel.org
W: http://linux-fbdev.sourceforge.net/
Q: http://patchwork.kernel.org/project/linux-fbdev/list/
-T: git git://github.com/schandinat/linux-2.6.git fbdev-next
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/plagnioj/linux-fbdev.git
S: Maintained
F: Documentation/fb/
F: Documentation/devicetree/bindings/fb/
F: drivers/video/
F: include/video/
F: include/linux/fb.h
+F: include/uapi/video/
+F: include/uapi/linux/fb.h
FREESCALE DIU FRAMEBUFFER DRIVER
-M: Timur Tabi <timur@freescale.com>
+M: Timur Tabi <timur@tabi.org>
L: linux-fbdev@vger.kernel.org
-S: Supported
+S: Maintained
F: drivers/video/fsl-diu-fb.*
FREESCALE DMA DRIVER
@@ -3196,7 +3420,7 @@
L: linux-fbdev@vger.kernel.org
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
-F: arch/arm/plat-mxc/include/mach/imxfb.h
+F: include/linux/platform_data/video-imxfb.h
F: drivers/video/imxfb.c
FREESCALE SOC FS_ENET DRIVER
@@ -3209,9 +3433,8 @@
F: include/linux/fs_enet_pd.h
FREESCALE QUICC ENGINE LIBRARY
-M: Timur Tabi <timur@freescale.com>
L: linuxppc-dev@lists.ozlabs.org
-S: Supported
+S: Orphan
F: arch/powerpc/sysdev/qe_lib/
F: arch/powerpc/include/asm/*qe.h
@@ -3230,16 +3453,16 @@
F: drivers/net/ethernet/freescale/ucc_geth*
FREESCALE QUICC ENGINE UCC UART DRIVER
-M: Timur Tabi <timur@freescale.com>
+M: Timur Tabi <timur@tabi.org>
L: linuxppc-dev@lists.ozlabs.org
-S: Supported
+S: Maintained
F: drivers/tty/serial/ucc_uart.c
FREESCALE SOC SOUND DRIVERS
-M: Timur Tabi <timur@freescale.com>
+M: Timur Tabi <timur@tabi.org>
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
L: linuxppc-dev@lists.ozlabs.org
-S: Supported
+S: Maintained
F: sound/soc/fsl/fsl*
F: sound/soc/fsl/mpc8610_hpcd.c
@@ -3273,6 +3496,16 @@
F: fs/fscache/
F: include/linux/fscache*.h
+F2FS FILE SYSTEM
+M: Jaegeuk Kim <jaegeuk.kim@samsung.com>
+L: linux-f2fs-devel@lists.sourceforge.net
+W: http://en.wikipedia.org/wiki/F2FS
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git
+S: Maintained
+F: Documentation/filesystems/f2fs.txt
+F: fs/f2fs/
+F: include/linux/f2fs_fs.h
+
FUJITSU FR-V (FRV) PORT
M: David Howells <dhowells@redhat.com>
S: Maintained
@@ -3304,7 +3537,7 @@
W: http://fuse.sourceforge.net/
S: Maintained
F: fs/fuse/
-F: include/linux/fuse.h
+F: include/uapi/linux/fuse.h
FUTURE DOMAIN TMC-16x0 SCSI DRIVER (16-bit)
M: Rik Faith <faith@cs.unc.edu>
@@ -3319,6 +3552,14 @@
S: Supported
F: drivers/scsi/gdt*
+GEMTEK FM RADIO RECEIVER DRIVER
+M: Hans Verkuil <hverkuil@xs4all.nl>
+L: linux-media@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+W: http://linuxtv.org
+S: Maintained
+F: drivers/media/radio/radio-gemtek*
+
GENERIC GPIO I2C DRIVER
M: Haavard Skinnemoen <hskinnemoen@gmail.com>
S: Supported
@@ -3351,6 +3592,7 @@
T: git git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic.git
S: Maintained
F: include/asm-generic
+F: include/uapi/asm-generic
GENERIC UIO DRIVER FOR PCI DEVICES
M: "Michael S. Tsirkin" <mst@redhat.com>
@@ -3367,7 +3609,7 @@
S: Supported
F: Documentation/filesystems/gfs2*.txt
F: fs/gfs2/
-F: include/linux/gfs2_ondisk.h
+F: include/uapi/linux/gfs2_ondisk.h
GIGASET ISDN DRIVERS
M: Hansjoerg Lipp <hjlipp@web.de>
@@ -3377,12 +3619,13 @@
S: Maintained
F: Documentation/isdn/README.gigaset
F: drivers/isdn/gigaset/
-F: include/linux/gigaset_dev.h
+F: include/uapi/linux/gigaset_dev.h
GPIO SUBSYSTEM
-M: Grant Likely <grant.likely@secretlab.ca>
+M: Grant Likely <grant.likely@linaro.org>
M: Linus Walleij <linus.walleij@linaro.org>
S: Maintained
+L: linux-gpio@vger.kernel.org
T: git git://git.secretlab.ca/git/linux-2.6.git
F: Documentation/gpio.txt
F: drivers/gpio/
@@ -3465,6 +3708,14 @@
S: Maintained
F: drivers/platform/x86/hdaps.c
+HDPVR USB VIDEO ENCODER DRIVER
+M: Hans Verkuil <hverkuil@xs4all.nl>
+L: linux-media@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+W: http://linuxtv.org
+S: Odd Fixes
+F: drivers/media/usb/hdpvr
+
HWPOISON MEMORY FAILURE HANDLING
M: Andi Kleen <andi@firstfloor.org>
L: linux-mm@kvack.org
@@ -3534,6 +3785,7 @@
F: Documentation/scsi/hpsa.txt
F: drivers/scsi/hpsa*.[ch]
F: include/linux/cciss*.h
+F: include/uapi/linux/cciss*.h
HEWLETT-PACKARD SMART CISS RAID DRIVER (cciss)
M: Mike Miller <mike.miller@hp.com>
@@ -3542,6 +3794,7 @@
F: Documentation/blockdev/cciss.txt
F: drivers/block/cciss*
F: include/linux/cciss_ioctl.h
+F: include/uapi/linux/cciss_ioctl.h
HFS FILESYSTEM
L: linux-fsdevel@vger.kernel.org
@@ -3576,6 +3829,7 @@
S: Maintained
F: drivers/hid/
F: include/linux/hid*
+F: include/uapi/linux/hid*
HIGH-RESOLUTION TIMERS, CLOCKEVENTS, DYNTICKS
M: Thomas Gleixner <tglx@linutronix.de>
@@ -3607,7 +3861,7 @@
L: linux-hippi@sunsite.dk
S: Maintained
F: include/linux/hippidevice.h
-F: include/linux/if_hippi.h
+F: include/uapi/linux/if_hippi.h
F: net/802/hippi.c
F: drivers/net/hippi/
@@ -3635,6 +3889,7 @@
F: Documentation/timers/hpet.txt
F: drivers/char/hpet.c
F: include/linux/hpet.h
+F: include/uapi/linux/hpet.h
HPET: x86
M: "Venkatesh Pallipadi (Venki)" <venki@google.com>
@@ -3670,9 +3925,16 @@
M: Haiyang Zhang <haiyangz@microsoft.com>
L: devel@linuxdriverproject.org
S: Maintained
-F: drivers/hv/
+F: arch/x86/include/asm/mshyperv.h
+F: arch/x86/include/uapi/asm/hyperv.h
+F: arch/x86/kernel/cpu/mshyperv.c
F: drivers/hid/hid-hyperv.c
+F: drivers/hv/
F: drivers/net/hyperv/
+F: drivers/scsi/storvsc_drv.c
+F: drivers/video/hyperv_fb.c
+F: include/linux/hyperv.h
+F: tools/hv/
I2C OVER PARALLEL PORT
M: Jean Delvare <khali@linux-fr.org>
@@ -3717,24 +3979,31 @@
F: drivers/i2c/busses/i2c-via.c
F: drivers/i2c/busses/i2c-viapro.c
+I2C/SMBUS ISMT DRIVER
+M: Seth Heasley <seth.heasley@intel.com>
+M: Neil Horman <nhorman@tuxdriver.com>
+L: linux-i2c@vger.kernel.org
+F: drivers/i2c/busses/i2c-ismt.c
+F: Documentation/i2c/busses/i2c-ismt
+
I2C/SMBUS STUB DRIVER
-M: "Mark M. Hoffman" <mhoffman@lightlink.com>
+M: Jean Delvare <khali@linux-fr.org>
L: linux-i2c@vger.kernel.org
S: Maintained
F: drivers/i2c/i2c-stub.c
I2C SUBSYSTEM
-M: Wolfram Sang <w.sang@pengutronix.de>
-M: "Ben Dooks (embedded platforms)" <ben-linux@fluff.org>
+M: Wolfram Sang <wsa@the-dreams.de>
L: linux-i2c@vger.kernel.org
W: http://i2c.wiki.kernel.org/
-T: quilt kernel.org/pub/linux/kernel/people/jdelvare/linux-2.6/jdelvare-i2c/
-T: git git://git.pengutronix.de/git/wsa/linux.git
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git
S: Maintained
F: Documentation/i2c/
F: drivers/i2c/
F: include/linux/i2c.h
F: include/linux/i2c-*.h
+F: include/uapi/linux/i2c.h
+F: include/uapi/linux/i2c-*.h
I2C-TAOS-EVM DRIVER
M: Jean Delvare <khali@linux-fr.org>
@@ -3769,7 +4038,8 @@
F: arch/ia64/
IBM Power in-Nest Crypto Acceleration
-M: Kent Yoder <key@linux.vnet.ibm.com>
+M: Marcelo Henrique Cerri <mhcerri@linux.vnet.ibm.com>
+M: Fionnuala Gunter <fin@linux.vnet.ibm.com>
L: linux-crypto@vger.kernel.org
S: Supported
F: drivers/crypto/nx/
@@ -3850,7 +4120,7 @@
S: Maintained
F: net/ieee802154/
F: net/mac802154/
-F: drivers/ieee802154/
+F: drivers/net/ieee802154/
IGUANAWORKS USB IR TRANSCEIVER
M: Sean Young <sean@mess.org>
@@ -3871,6 +4141,22 @@
S: Maintained
F: drivers/usb/atm/ueagle-atm.c
+INA209 HARDWARE MONITOR DRIVER
+M: Guenter Roeck <linux@roeck-us.net>
+L: lm-sensors@lm-sensors.org
+S: Maintained
+F: Documentation/hwmon/ina209
+F: Documentation/devicetree/bindings/i2c/ina209.txt
+F: drivers/hwmon/ina209.c
+
+INA2XX HARDWARE MONITOR DRIVER
+M: Guenter Roeck <linux@roeck-us.net>
+L: lm-sensors@lm-sensors.org
+S: Maintained
+F: Documentation/hwmon/ina2xx
+F: drivers/hwmon/ina2xx.c
+F: include/linux/platform_data/ina2xx.h
+
INDUSTRY PACK SUBSYSTEM (IPACK)
M: Samuel Iglesias Gonsalvez <siglesias@igalia.com>
M: Jens Taprogge <jens.taprogge@taprogge.org>
@@ -3882,6 +4168,7 @@
INTEGRITY MEASUREMENT ARCHITECTURE (IMA)
M: Mimi Zohar <zohar@us.ibm.com>
+M: Dmitry Kasatkin <d.kasatkin@samsung.com>
S: Supported
F: security/integrity/ima/
@@ -3901,7 +4188,7 @@
S: Supported
F: Documentation/infiniband/
F: drivers/infiniband/
-F: include/linux/if_infiniband.h
+F: include/uapi/linux/if_infiniband.h
INOTIFY
M: John McCutchan <john@johnmccutchan.com>
@@ -3911,6 +4198,7 @@
F: Documentation/filesystems/inotify.txt
F: fs/notify/inotify/
F: include/linux/inotify.h
+F: include/uapi/linux/inotify.h
INPUT (KEYBOARD, MOUSE, JOYSTICK, TOUCHSCREEN) DRIVERS
M: Dmitry Torokhov <dmitry.torokhov@gmail.com>
@@ -3921,6 +4209,7 @@
S: Maintained
F: drivers/input/
F: include/linux/input.h
+F: include/uapi/linux/input.h
F: include/linux/input/
INPUT MULTITOUCH (MT) PROTOCOL
@@ -3941,7 +4230,6 @@
T: git git://git.code.sf.net/p/intel-sas/isci
S: Supported
F: drivers/scsi/isci/
-F: firmware/isci/
INTEL IDLE DRIVER
M: Len Brown <lenb@kernel.org>
@@ -4036,12 +4324,6 @@
F: Documentation/networking/ixgbevf.txt
F: drivers/net/ethernet/intel/
-INTEL MRST PMU DRIVER
-M: Len Brown <len.brown@intel.com>
-L: linux-pm@vger.kernel.org
-S: Supported
-F: arch/x86/platform/mrst/pmu.*
-
INTEL PRO/WIRELESS 2100, 2200BG, 2915ABG NETWORK CONNECTION SUPPORT
M: Stanislav Yakovlev <stas.yakovlev@gmail.com>
L: linux-wireless@vger.kernel.org
@@ -4070,7 +4352,7 @@
W: http://linuxwimax.org
F: Documentation/wimax/README.i2400m
F: drivers/net/wimax/i2400m/
-F: include/linux/wimax/i2400m.h
+F: include/uapi/linux/wimax/i2400m.h
INTEL WIRELESS 3945ABG/BG, 4965AGN (iwlegacy)
M: Stanislaw Gruszka <sgruszka@redhat.com>
@@ -4092,9 +4374,9 @@
M: Tomas Winkler <tomas.winkler@intel.com>
L: linux-kernel@vger.kernel.org
S: Supported
-F: include/linux/mei.h
+F: include/uapi/linux/mei.h
F: drivers/misc/mei/*
-F: Documentation/mei/*
+F: Documentation/misc-devices/mei/*
IOC3 ETHERNET DRIVER
M: Ralf Baechle <ralf@linux-mips.org>
@@ -4134,6 +4416,7 @@
F: Documentation/IPMI.txt
F: drivers/char/ipmi/
F: include/linux/ipmi*
+F: include/uapi/linux/ipmi*
IPS SCSI RAID DRIVER
M: Adaptec OEM Raid Solutions <aacraid@adaptec.com>
@@ -4151,7 +4434,7 @@
S: Maintained
F: Documentation/networking/ipvs-sysctl.txt
F: include/net/ip_vs.h
-F: include/linux/ip_vs.h
+F: include/uapi/linux/ip_vs.h
F: net/netfilter/ipvs/
IPWIRELESS DRIVER
@@ -4164,8 +4447,8 @@
M: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
L: netdev@vger.kernel.org
S: Maintained
-F: include/linux/ipx.h
F: include/net/ipx.h
+F: include/uapi/linux/ipx.h
F: net/ipx/
IRDA SUBSYSTEM
@@ -4185,10 +4468,11 @@
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git irq/core
F: kernel/irq/
+F: drivers/irqchip/
IRQ DOMAINS (IRQ NUMBER MAPPING LIBRARY)
M: Benjamin Herrenschmidt <benh@kernel.crashing.org>
-M: Grant Likely <grant.likely@secretlab.ca>
+M: Grant Likely <grant.likely@linaro.org>
T: git git://git.secretlab.ca/git/linux-2.6.git irqdomain/next
S: Maintained
F: Documentation/IRQ-domain.txt
@@ -4202,6 +4486,14 @@
F: drivers/pnp/isapnp/
F: include/linux/isapnp.h
+ISA RADIO MODULE
+M: Hans Verkuil <hverkuil@xs4all.nl>
+L: linux-media@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+W: http://linuxtv.org
+S: Maintained
+F: drivers/media/radio/radio-isa*
+
iSCSI BOOT FIRMWARE TABLE (iBFT) DRIVER
M: Peter Jones <pjones@redhat.com>
M: Konrad Rzeszutek Wilk <konrad@kernel.org>
@@ -4217,6 +4509,16 @@
F: drivers/scsi/*iscsi*
F: include/scsi/*iscsi*
+ISCSI EXTENSIONS FOR RDMA (ISER) INITIATOR
+M: Or Gerlitz <ogerlitz@mellanox.com>
+M: Roi Dayan <roid@mellanox.com>
+L: linux-rdma@vger.kernel.org
+S: Supported
+W: http://www.openfabrics.org
+W: www.open-iscsi.org
+Q: http://patchwork.kernel.org/project/linux-rdma/list/
+F: drivers/infiniband/ulp/iser
+
ISDN SUBSYSTEM
M: Karsten Keil <isdn@linux-pingi.de>
L: isdn4linux@listserv.isdn4linux.de (subscribers-only)
@@ -4228,6 +4530,8 @@
F: drivers/isdn/
F: include/linux/isdn.h
F: include/linux/isdn/
+F: include/uapi/linux/isdn.h
+F: include/uapi/linux/isdn/
ISDN SUBSYSTEM (Eicon active card driver)
M: Armin Schindler <mac@melware.de>
@@ -4259,6 +4563,16 @@
S: Maintained
F: drivers/media/dvb-frontends/it913x-fe*
+IT913X MEDIA DRIVER
+M: Antti Palosaari <crope@iki.fi>
+L: linux-media@vger.kernel.org
+W: http://linuxtv.org/
+W: http://palosaari.fi/linux/
+Q: http://patchwork.linuxtv.org/project/linux-media/list/
+T: git git://linuxtv.org/anttip/media_tree.git
+S: Maintained
+F: drivers/media/tuners/it913x*
+
IVTV VIDEO4LINUX DRIVER
M: Andy Walls <awalls@md.metrocast.net>
L: ivtv-devel@ivtvdriver.org (moderated for non-subscribers)
@@ -4268,7 +4582,7 @@
S: Maintained
F: Documentation/video4linux/*.ivtv
F: drivers/media/pci/ivtv/
-F: include/linux/ivtv*
+F: include/uapi/linux/ivtv*
IX2505V MEDIA DRIVER
M: Malcolm Priestley <tvboxspy@gmail.com>
@@ -4306,7 +4620,7 @@
W: http://www.linux-mtd.infradead.org/doc/jffs2.html
S: Maintained
F: fs/jffs2/
-F: include/linux/jffs2.h
+F: include/uapi/linux/jffs2.h
JOURNALLING LAYER FOR BLOCK DEVICES (JBD)
M: Andrew Morton <akpm@linux-foundation.org>
@@ -4324,7 +4638,7 @@
F: include/linux/jbd2.h
JSM Neo PCI based serial card
-M: Lucas Tavares <lucaskt@linux.vnet.ibm.com>
+M: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
L: linux-serial@vger.kernel.org
S: Maintained
F: drivers/tty/serial/jsm/
@@ -4358,6 +4672,14 @@
S: Maintained
F: Documentation/kdump/
+KEENE FM RADIO TRANSMITTER DRIVER
+M: Hans Verkuil <hverkuil@xs4all.nl>
+L: linux-media@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+W: http://linuxtv.org
+S: Maintained
+F: drivers/media/radio/radio-keene*
+
KERNEL AUTOMOUNTER v4 (AUTOFS4)
M: Ian Kent <raven@themaw.net>
L: autofs@vger.kernel.org
@@ -4389,22 +4711,26 @@
S: Supported
F: fs/nfsd/
F: include/linux/nfsd/
+F: include/uapi/linux/nfsd/
F: fs/lockd/
F: fs/nfs_common/
F: net/sunrpc/
F: include/linux/lockd/
F: include/linux/sunrpc/
+F: include/uapi/linux/sunrpc/
KERNEL VIRTUAL MACHINE (KVM)
-M: Marcelo Tosatti <mtosatti@redhat.com>
M: Gleb Natapov <gleb@redhat.com>
+M: Paolo Bonzini <pbonzini@redhat.com>
L: kvm@vger.kernel.org
-W: http://kvm.qumranet.com
+W: http://linux-kvm.org
S: Supported
-F: Documentation/*/kvm.txt
+F: Documentation/*/kvm*.txt
+F: Documentation/virtual/kvm/
F: arch/*/kvm/
F: arch/*/include/asm/kvm*
F: include/linux/kvm*
+F: include/uapi/linux/kvm*
F: virt/kvm/
KERNEL VIRTUAL MACHINE (KVM) FOR AMD-V
@@ -4445,12 +4771,31 @@
F: arch/s390/kvm/
F: drivers/s390/kvm/
+KERNEL VIRTUAL MACHINE (KVM) FOR ARM
+M: Christoffer Dall <christoffer.dall@linaro.org>
+L: kvmarm@lists.cs.columbia.edu
+W: http://systems.cs.columbia.edu/projects/kvm-arm
+S: Supported
+F: arch/arm/include/uapi/asm/kvm*
+F: arch/arm/include/asm/kvm*
+F: arch/arm/kvm/
+
+KERNEL VIRTUAL MACHINE FOR ARM64 (KVM/arm64)
+M: Marc Zyngier <marc.zyngier@arm.com>
+L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
+L: kvmarm@lists.cs.columbia.edu
+S: Maintained
+F: arch/arm64/include/uapi/asm/kvm*
+F: arch/arm64/include/asm/kvm*
+F: arch/arm64/kvm/
+
KEXEC
M: Eric Biederman <ebiederm@xmission.com>
W: http://kernel.org/pub/linux/utils/kernel/kexec/
L: kexec@lists.infradead.org
S: Maintained
F: include/linux/kexec.h
+F: include/uapi/linux/kexec.h
F: kernel/kexec.c
KEYS/KEYRINGS:
@@ -4644,11 +4989,8 @@
F: arch/powerpc/platforms/44x/
LINUX FOR POWERPC EMBEDDED XILINX VIRTEX
-M: Grant Likely <grant.likely@secretlab.ca>
-W: http://wiki.secretlab.ca/index.php/Linux_on_Xilinx_Virtex
L: linuxppc-dev@lists.ozlabs.org
-T: git git://git.secretlab.ca/git/linux-2.6.git
-S: Maintained
+S: Unmaintained
F: arch/powerpc/*/*virtex*
F: arch/powerpc/*/*/*virtex*
@@ -4692,6 +5034,7 @@
M: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
S: Maintained
F: include/linux/llc.h
+F: include/uapi/linux/llc.h
F: include/net/llc*
F: net/llc/
@@ -4722,6 +5065,13 @@
F: Documentation/hwmon/lm90
F: drivers/hwmon/lm90.c
+LM95234 HARDWARE MONITOR DRIVER
+M: Guenter Roeck <linux@roeck-us.net>
+L: lm-sensors@lm-sensors.org
+S: Maintained
+F: Documentation/hwmon/lm95234
+F: drivers/hwmon/lm95234.c
+
LME2510 MEDIA DRIVER
M: Malcolm Priestley <tvboxspy@gmail.com>
L: linux-media@vger.kernel.org
@@ -4756,6 +5106,12 @@
S: Maintained
F: fs/logfs/
+LPC32XX MACHINE SUPPORT
+M: Roland Stigge <stigge@antcom.de>
+L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
+S: Maintained
+F: arch/arm/mach-lpc32xx/
+
LSILOGIC MPT FUSION DRIVERS (FC/SAS/SPI)
M: Nagalakshmi Nandigama <Nagalakshmi.Nandigama@lsi.com>
M: Sreekanth Reddy <Sreekanth.Reddy@lsi.com>
@@ -4831,6 +5187,13 @@
S: Maintained
F: drivers/media/dvb-frontends/m88rs2000*
+MA901 MASTERKIT USB FM RADIO DRIVER
+M: Alexey Klimov <klimov.linux@gmail.com>
+L: linux-media@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+S: Maintained
+F: drivers/media/radio/radio-ma901.c
+
MAC80211
M: Johannes Berg <johannes@sipsolutions.net>
L: linux-wireless@vger.kernel.org
@@ -4867,15 +5230,14 @@
MARVELL GIGABIT ETHERNET DRIVERS (skge/sky2)
M: Mirko Lindner <mlindner@marvell.com>
-M: Stephen Hemminger <shemminger@vyatta.com>
+M: Stephen Hemminger <stephen@networkplumber.org>
L: netdev@vger.kernel.org
S: Maintained
F: drivers/net/ethernet/marvell/sk*
MARVELL LIBERTAS WIRELESS DRIVER
-M: Dan Williams <dcbw@redhat.com>
L: libertas-dev@lists.infradead.org
-S: Maintained
+S: Orphan
F: drivers/net/wireless/libertas/
MARVELL MV643XX ETHERNET DRIVER
@@ -4912,7 +5274,7 @@
L: linux-fbdev@vger.kernel.org
S: Orphan
F: drivers/video/matrox/matroxfb_*
-F: include/linux/matroxfb.h
+F: include/uapi/linux/matroxfb.h
MAX16065 HARDWARE MONITOR DRIVER
M: Guenter Roeck <linux@roeck-us.net>
@@ -4928,8 +5290,25 @@
F: Documentation/hwmon/max6650
F: drivers/hwmon/max6650.c
+MAX6697 HARDWARE MONITOR DRIVER
+M: Guenter Roeck <linux@roeck-us.net>
+L: lm-sensors@lm-sensors.org
+S: Maintained
+F: Documentation/hwmon/max6697
+F: Documentation/devicetree/bindings/i2c/max6697.txt
+F: drivers/hwmon/max6697.c
+F: include/linux/platform_data/max6697.h
+
+MAXIRADIO FM RADIO RECEIVER DRIVER
+M: Hans Verkuil <hverkuil@xs4all.nl>
+L: linux-media@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+W: http://linuxtv.org
+S: Maintained
+F: drivers/media/radio/radio-maxiradio*
+
MEDIA INPUT INFRASTRUCTURE (V4L/DVB)
-M: Mauro Carvalho Chehab <mchehab@redhat.com>
+M: Mauro Carvalho Chehab <m.chehab@samsung.com>
P: LinuxTV.org Project
L: linux-media@vger.kernel.org
W: http://linuxtv.org
@@ -4950,6 +5329,14 @@
F: include/uapi/linux/ivtv*
F: include/uapi/linux/uvcvideo.h
+MEDIAVISION PRO MOVIE STUDIO DRIVER
+M: Hans Verkuil <hverkuil@xs4all.nl>
+L: linux-media@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+W: http://linuxtv.org
+S: Odd Fixes
+F: drivers/media/parport/pms*
+
MEGARAID SCSI DRIVERS
M: Neela Syam Kolli <megaraidlinux@lsi.com>
L: linux-scsi@vger.kernel.org
@@ -4972,6 +5359,10 @@
W: http://www.linux-mm.org
S: Maintained
F: include/linux/mm.h
+F: include/linux/gfp.h
+F: include/linux/mmzone.h
+F: include/linux/memory_hotplug.h
+F: include/linux/vmalloc.h
F: mm/
MEMORY RESOURCE CONTROLLER
@@ -4994,7 +5385,25 @@
S: Maintained
F: drivers/mtd/
F: include/linux/mtd/
-F: include/mtd/
+F: include/uapi/mtd/
+
+MEN A21 WATCHDOG DRIVER
+M: Johannes Thumshirn <johannes.thumshirn@men.de>
+L: linux-watchdog@vger.kernel.org
+S: Supported
+F: drivers/watchdog/mena21_wdt.c
+
+METAG ARCHITECTURE
+M: James Hogan <james.hogan@imgtec.com>
+S: Supported
+F: arch/metag/
+F: Documentation/metag/
+F: Documentation/devicetree/bindings/metag/
+F: drivers/clocksource/metag_generic.c
+F: drivers/irqchip/irq-metag.c
+F: drivers/irqchip/irq-metag-ext.c
+F: drivers/tty/metag_da.c
+F: fs/imgdafs/
MICROBLAZE ARCHITECTURE
M: Michal Simek <monstr@monstr.eu>
@@ -5019,6 +5428,36 @@
F: Documentation/mips/
F: arch/mips/
+MIROSOUND PCM20 FM RADIO RECEIVER DRIVER
+M: Hans Verkuil <hverkuil@xs4all.nl>
+L: linux-media@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+W: http://linuxtv.org
+S: Odd Fixes
+F: drivers/media/radio/radio-miropcm20*
+
+Mellanox MLX5 core VPI driver
+M: Eli Cohen <eli@mellanox.com>
+L: netdev@vger.kernel.org
+L: linux-rdma@vger.kernel.org
+W: http://www.mellanox.com
+Q: http://patchwork.ozlabs.org/project/netdev/list/
+Q: http://patchwork.kernel.org/project/linux-rdma/list/
+T: git://openfabrics.org/~eli/connect-ib.git
+S: Supported
+F: drivers/net/ethernet/mellanox/mlx5/core/
+F: include/linux/mlx5/
+
+Mellanox MLX5 IB driver
+M: Eli Cohen <eli@mellanox.com>
+L: linux-rdma@vger.kernel.org
+W: http://www.mellanox.com
+Q: http://patchwork.kernel.org/project/linux-rdma/list/
+T: git://openfabrics.org/~eli/connect-ib.git
+S: Supported
+F: include/linux/mlx5/
+F: drivers/infiniband/hw/mlx5/
+
MODULE SUPPORT
M: Rusty Russell <rusty@rustcorp.com.au>
S: Maintained
@@ -5032,12 +5471,6 @@
F: drivers/media/pci/meye/
F: include/uapi/linux/meye.h
-MOTOROLA IMX MMC/SD HOST CONTROLLER INTERFACE DRIVER
-M: Pavel Pisa <ppisa@pikron.com>
-L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
-S: Maintained
-F: drivers/mmc/host/imxmmc.*
-
MOXA SMARTIO/INDUSTIO/INTELLIO SERIAL CARD
M: Jiri Slaby <jirislaby@gmail.com>
S: Maintained
@@ -5052,7 +5485,7 @@
F: drivers/media/radio/radio-mr800.c
MSI LAPTOP SUPPORT
-M: "Lee, Chun-Yi" <jlee@novell.com>
+M: "Lee, Chun-Yi" <jlee@suse.com>
L: platform-driver-x86@vger.kernel.org
S: Maintained
F: drivers/platform/x86/msi-laptop.c
@@ -5063,11 +5496,46 @@
S: Supported
F: drivers/platform/x86/msi-wmi.c
+MT9M032 SENSOR DRIVER
+M: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+L: linux-media@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+S: Maintained
+F: drivers/media/i2c/mt9m032.c
+F: include/media/mt9m032.h
+
+MT9P031 SENSOR DRIVER
+M: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+L: linux-media@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+S: Maintained
+F: drivers/media/i2c/mt9p031.c
+F: include/media/mt9p031.h
+
+MT9T001 SENSOR DRIVER
+M: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+L: linux-media@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+S: Maintained
+F: drivers/media/i2c/mt9t001.c
+F: include/media/mt9t001.h
+
+MT9V032 SENSOR DRIVER
+M: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+L: linux-media@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+S: Maintained
+F: drivers/media/i2c/mt9v032.c
+F: include/media/mt9v032.h
+
MULTIFUNCTION DEVICES (MFD)
M: Samuel Ortiz <sameo@linux.intel.com>
-T: git git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6.git
+M: Lee Jones <lee.jones@linaro.org>
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-next.git
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-fixes.git
S: Supported
F: drivers/mfd/
+F: include/linux/mfd/
MULTIMEDIA CARD (MMC), SECURE DIGITAL (SD) AND SDIO SUBSYSTEM
M: Chris Ball <cjb@laptop.org>
@@ -5076,6 +5544,7 @@
S: Maintained
F: drivers/mmc/
F: include/linux/mmc/
+F: include/uapi/linux/mmc/
MULTIMEDIA CARD (MMC) ETC. OVER SPI
S: Orphan
@@ -5139,6 +5608,13 @@
S: Maintained
F: drivers/scsi/NCR_D700.*
+NCT6775 HARDWARE MONITOR DRIVER
+M: Guenter Roeck <linux@roeck-us.net>
+L: lm-sensors@lm-sensors.org
+S: Maintained
+F: Documentation/hwmon/nct6775
+F: drivers/hwmon/nct6775.c
+
NETEFFECT IWARP RNIC DRIVER (IW_NES)
M: Faisal Latif <faisal.latif@intel.com>
L: linux-rdma@vger.kernel.org
@@ -5147,7 +5623,7 @@
F: drivers/infiniband/hw/nes/
NETEM NETWORK EMULATOR
-M: Stephen Hemminger <shemminger@vyatta.com>
+M: Stephen Hemminger <stephen@networkplumber.org>
L: netem@lists.linux-foundation.org
S: Maintained
F: net/sched/sch_netem.c
@@ -5160,22 +5636,24 @@
F: Documentation/networking/vxge.txt
F: drivers/net/ethernet/neterion/
-NETFILTER/IPTABLES/IPCHAINS
-P: Harald Welte
-P: Jozsef Kadlecsik
+NETFILTER/IPTABLES
M: Pablo Neira Ayuso <pablo@netfilter.org>
M: Patrick McHardy <kaber@trash.net>
+M: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
L: netfilter-devel@vger.kernel.org
L: netfilter@vger.kernel.org
L: coreteam@netfilter.org
W: http://www.netfilter.org/
W: http://www.iptables.org/
-T: git git://1984.lsi.us.es/nf
-T: git git://1984.lsi.us.es/nf-next
+Q: http://patchwork.ozlabs.org/project/netfilter-devel/list/
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf.git
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf-next.git
S: Supported
F: include/linux/netfilter*
F: include/linux/netfilter/
F: include/net/netfilter/
+F: include/uapi/linux/netfilter*
+F: include/uapi/linux/netfilter/
F: net/*/netfilter.c
F: net/*/netfilter/
F: net/netfilter/
@@ -5194,16 +5672,18 @@
L: linux-hams@vger.kernel.org
W: http://www.linux-ax25.org/
S: Maintained
-F: include/linux/netrom.h
F: include/net/netrom.h
+F: include/uapi/linux/netrom.h
F: net/netrom/
NETWORK BLOCK DEVICE (NBD)
M: Paul Clements <Paul.Clements@steeleye.com>
S: Maintained
+L: nbd-general@lists.sourceforge.net
F: Documentation/blockdev/nbd.txt
F: drivers/block/nbd.c
F: include/linux/nbd.h
+F: include/uapi/linux/nbd.h
NETWORK DROP MONITOR
M: Neil Horman <nhorman@tuxdriver.com>
@@ -5225,6 +5705,9 @@
F: include/linux/in.h
F: include/linux/net.h
F: include/linux/netdevice.h
+F: include/uapi/linux/in.h
+F: include/uapi/linux/net.h
+F: include/uapi/linux/netdevice.h
NETWORKING [IPv4/IPv6]
M: "David S. Miller" <davem@davemloft.net>
@@ -5270,6 +5753,7 @@
F: net/wireless/
F: include/net/ieee80211*
F: include/linux/wireless.h
+F: include/uapi/linux/wireless.h
F: include/net/iw_handler.h
F: drivers/net/wireless/
@@ -5289,8 +5773,11 @@
F: include/linux/fddidevice.h
F: include/linux/hippidevice.h
F: include/linux/inetdevice.h
+F: include/uapi/linux/if_*
+F: include/uapi/linux/netdevice.h
NETXEN (1/10) GbE SUPPORT
+M: Manish Chopra <manish.chopra@qlogic.com>
M: Sony Chacko <sony.chacko@qlogic.com>
M: Rajesh Borundia <rajesh.borundia@qlogic.com>
L: netdev@vger.kernel.org
@@ -5306,8 +5793,8 @@
L: linux-nfc@lists.01.org (moderated for non-subscribers)
S: Maintained
F: net/nfc/
-F: include/linux/nfc.h
F: include/net/nfc/
+F: include/uapi/linux/nfc.h
F: drivers/nfc/
F: include/linux/platform_data/pn544.h
@@ -5324,13 +5811,8 @@
F: include/linux/lockd/
F: include/linux/nfs*
F: include/linux/sunrpc/
-
-NI5010 NETWORK DRIVER
-M: Jan-Pascal van Best <janpascal@vanbest.org>
-M: Andreas Mohr <andi@lisas.de>
-L: netdev@vger.kernel.org
-S: Maintained
-F: drivers/net/ethernet/racal/ni5010.*
+F: include/uapi/linux/nfs*
+F: include/uapi/linux/sunrpc/
NILFS2 FILESYSTEM
M: KONISHI Ryusuke <konishi.ryusuke@lab.ntt.co.jp>
@@ -5357,6 +5839,13 @@
F: Documentation/scsi/NinjaSCSI.txt
F: drivers/scsi/nsp32*
+NTB DRIVER
+M: Jon Mason <jon.mason@intel.com>
+S: Supported
+F: drivers/ntb/
+F: drivers/net/ntb_netdev.c
+F: include/linux/ntb.h
+
NTFS FILESYSTEM
M: Anton Altaparmakov <anton@tuxera.com>
L: linux-ntfs-dev@lists.sourceforge.net
@@ -5373,6 +5862,14 @@
F: drivers/video/riva/
F: drivers/video/nvidia/
+NVM EXPRESS DRIVER
+M: Matthew Wilcox <willy@linux.intel.com>
+L: linux-nvme@lists.infradead.org
+T: git git://git.infradead.org/users/willy/linux-nvme.git
+S: Supported
+F: drivers/block/nvme*
+F: include/linux/nvme.h
+
OMAP SUPPORT
M: Tony Lindgren <tony@atomide.com>
L: linux-omap@vger.kernel.org
@@ -5385,6 +5882,15 @@
F: drivers/i2c/busses/i2c-omap.c
F: include/linux/i2c-omap.h
+OMAP DEVICE TREE SUPPORT
+M: Benoît Cousson <b-cousson@ti.com>
+M: Tony Lindgren <tony@atomide.com>
+L: linux-omap@vger.kernel.org
+L: devicetree-discuss@lists.ozlabs.org (moderated for non-subscribers)
+S: Maintained
+F: arch/arm/boot/dts/*omap*
+F: arch/arm/boot/dts/*am3*
+
OMAP CLOCK FRAMEWORK SUPPORT
M: Paul Walmsley <paul@pwsan.com>
L: linux-omap@vger.kernel.org
@@ -5392,7 +5898,7 @@
F: arch/arm/*omap*/*clock*
OMAP POWER MANAGEMENT SUPPORT
-M: Kevin Hilman <khilman@ti.com>
+M: Kevin Hilman <khilman@deeprootsystems.com>
L: linux-omap@vger.kernel.org
S: Maintained
F: arch/arm/*omap*/*pm*
@@ -5445,7 +5951,7 @@
F: drivers/mmc/host/omap.c
OMAP HS MMC SUPPORT
-M: Venkatraman S <svenkatr@ti.com>
+M: Balaji T K <balajitk@ti.com>
L: linux-mmc@vger.kernel.org
L: linux-omap@vger.kernel.org
S: Maintained
@@ -5461,8 +5967,7 @@
M: Paul Walmsley <paul@pwsan.com>
L: linux-omap@vger.kernel.org
S: Maintained
-F: arch/arm/mach-omap2/omap_hwmod.c
-F: arch/arm/plat-omap/include/plat/omap_hwmod.h
+F: arch/arm/mach-omap2/omap_hwmod.*
OMAP HWMOD DATA FOR OMAP4-BASED DEVICES
M: Benoît Cousson <b-cousson@ti.com>
@@ -5487,7 +5992,7 @@
OMAP GPIO DRIVER
M: Santosh Shilimkar <santosh.shilimkar@ti.com>
-M: Kevin Hilman <khilman@ti.com>
+M: Kevin Hilman <khilman@deeprootsystems.com>
L: linux-omap@vger.kernel.org
S: Maintained
F: drivers/gpio/gpio-omap.c
@@ -5504,6 +6009,7 @@
S: Maintained
F: drivers/char/pcmcia/cm4000_cs.c
F: include/linux/cm4000_cs.h
+F: include/uapi/linux/cm4000_cs.h
OMNIKEY CARDMAN 4040 DRIVER
M: Harald Welte <laforge@gnumonks.org>
@@ -5529,8 +6035,10 @@
L: osst-users@lists.sourceforge.net
L: linux-scsi@vger.kernel.org
S: Maintained
-F: drivers/scsi/osst*
-F: drivers/scsi/st*
+F: Documentation/scsi/osst.txt
+F: drivers/scsi/osst.*
+F: drivers/scsi/osst_*.h
+F: drivers/scsi/st.h
OPENCORES I2C BUS DRIVER
M: Peter Korsgaard <jacmet@sunsite.dk>
@@ -5540,7 +6048,7 @@
F: drivers/i2c/busses/i2c-ocores.c
OPEN FIRMWARE AND FLATTENED DEVICE TREE
-M: Grant Likely <grant.likely@secretlab.ca>
+M: Grant Likely <grant.likely@linaro.org>
M: Rob Herring <rob.herring@calxeda.com>
L: devicetree-discuss@lists.ozlabs.org (moderated for non-subscribers)
W: http://fdt.secretlab.ca
@@ -5662,7 +6170,7 @@
F: drivers/parport/
F: include/linux/parport*.h
F: drivers/char/ppdev.c
-F: include/linux/ppdev.h
+F: include/uapi/linux/ppdev.h
PARAVIRT_OPS INTERFACE
M: Jeremy Fitzhardinge <jeremy@goop.org>
@@ -5690,9 +6198,18 @@
W: http://www.parisc-linux.org/
Q: http://patchwork.kernel.org/project/linux-parisc/list/
T: git git://git.kernel.org/pub/scm/linux/kernel/git/jejb/parisc-2.6.git
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git
S: Maintained
F: arch/parisc/
+F: Documentation/parisc/
F: drivers/parisc/
+F: drivers/char/agp/parisc-agp.c
+F: drivers/input/serio/gscps2.c
+F: drivers/parport/parport_gsc.*
+F: drivers/tty/serial/8250/8250_gsc.c
+F: drivers/video/sti*
+F: drivers/video/console/sti*
+F: drivers/video/logo/logo_parisc*
PC87360 HARDWARE MONITORING DRIVER
M: Jim Cromie <jim.cromie@gmail.com>
@@ -5725,15 +6242,6 @@
S: Maintained
F: drivers/i2c/muxes/i2c-mux-pca9541.c
-PCA9564/PCA9665 I2C BUS DRIVER
-M: Wolfram Sang <w.sang@pengutronix.de>
-L: linux-i2c@vger.kernel.org
-S: Maintained
-F: drivers/i2c/algos/i2c-algo-pca.c
-F: drivers/i2c/busses/i2c-pca-*
-F: include/linux/i2c-algo-pca.h
-F: include/linux/i2c-pca-platform.h
-
PCDP - PRIMARY CONSOLE AND DEBUG PORT
M: Khalid Aziz <khalid@gonehiking.org>
S: Maintained
@@ -5744,7 +6252,6 @@
L: linux-pci@vger.kernel.org
S: Supported
F: Documentation/PCI/pci-error-recovery.txt
-F: Documentation/powerpc/eeh-pci-error-recovery.txt
PCI SUBSYSTEM
M: Bjorn Helgaas <bhelgaas@google.com>
@@ -5803,11 +6310,11 @@
S: Supported
F: kernel/events/*
F: include/linux/perf_event.h
+F: include/uapi/linux/perf_event.h
F: arch/*/kernel/perf_event*.c
F: arch/*/kernel/*/perf_event*.c
F: arch/*/kernel/*/*/perf_event*.c
F: arch/*/include/asm/perf_event.h
-F: arch/*/lib/perf_event*.c
F: arch/*/kernel/perf_callchain.c
F: tools/perf/
@@ -5816,6 +6323,7 @@
L: linux-abi-devel@lists.sourceforge.net
S: Maintained
F: include/linux/personality.h
+F: include/uapi/linux/personality.h
PHONET PROTOCOL
M: Remi Denis-Courmont <courmisch@gmail.com>
@@ -5823,6 +6331,7 @@
F: Documentation/networking/phonet.txt
F: include/linux/phonet.h
F: include/net/phonet/
+F: include/uapi/linux/phonet.h
F: net/phonet/
PHRAM MTD DRIVER
@@ -5858,6 +6367,16 @@
S: Maintained
F: drivers/pinctrl/pinctrl-at91.c
+PIN CONTROLLER - SAMSUNG
+M: Tomasz Figa <t.figa@samsung.com>
+M: Thomas Abraham <thomas.abraham@linaro.org>
+L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
+L: linux-samsung-soc@vger.kernel.org (moderated for non-subscribers)
+S: Maintained
+F: drivers/pinctrl/pinctrl-exynos.*
+F: drivers/pinctrl/pinctrl-s3c*
+F: drivers/pinctrl/pinctrl-samsung.*
+
PIN CONTROLLER - ST SPEAR
M: Viresh Kumar <viresh.linux@gmail.com>
L: spear-devel@list.st.com
@@ -5871,6 +6390,7 @@
S: Maintained
F: drivers/block/pktcdvd.c
F: include/linux/pktcdvd.h
+F: include/uapi/linux/pktcdvd.h
PKUNITY SOC DRIVERS
M: Guan Xuetao <gxt@mprc.pku.edu.cn>
@@ -5901,7 +6421,7 @@
F: drivers/scsi/pmcraid.*
PMC SIERRA PM8001 DRIVER
-M: jack_wang@usish.com
+M: xjtuwjp@gmail.com
M: lindar_liu@usish.com
L: linux-scsi@vger.kernel.org
S: Supported
@@ -5916,7 +6436,7 @@
F: kernel/*timer*
POWER SUPPLY CLASS/SUBSYSTEM and DRIVERS
-M: Anton Vorontsov <cbou@mail.ru>
+M: Anton Vorontsov <anton@enomsg.org>
M: David Woodhouse <dwmw2@infradead.org>
T: git git://git.infradead.org/battery-2.6.git
S: Maintained
@@ -5924,7 +6444,7 @@
F: drivers/power/
PNP SUPPORT
-M: Adam Belay <abelay@mit.edu>
+M: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
M: Bjorn Helgaas <bhelgaas@google.com>
S: Maintained
F: drivers/pnp/
@@ -5945,7 +6465,7 @@
M: Mitchell Blank Jr <mitch@sfgoth.com>
S: Maintained
F: net/atm/pppoatm.c
-F: include/linux/atmppp.h
+F: include/uapi/linux/atmppp.h
PPP OVER ETHERNET
M: Michal Ostrowski <mostrows@earthlink.net>
@@ -5958,6 +6478,7 @@
S: Maintained
F: net/l2tp/l2tp_ppp.c
F: include/linux/if_pppol2tp.h
+F: include/uapi/linux/if_pppol2tp.h
PPS SUPPORT
M: Rodolfo Giometti <giometti@enneenne.com>
@@ -6025,7 +6546,7 @@
F: drivers/block/ps3vram.c
PSTORE FILESYSTEM
-M: Anton Vorontsov <cbouatmailru@gmail.com>
+M: Anton Vorontsov <anton@enomsg.org>
M: Colin Cross <ccross@android.com>
M: Kees Cook <keescook@chromium.org>
M: Tony Luck <tony.luck@intel.com>
@@ -6033,11 +6554,12 @@
T: git git://git.infradead.org/users/cbou/linux-pstore.git
F: fs/pstore/
F: include/linux/pstore*
-F: drivers/firmware/efivars.c
+F: drivers/firmware/efi/efi-pstore.c
F: drivers/acpi/apei/erst.c
PTP HARDWARE CLOCK SUPPORT
M: Richard Cochran <richardcochran@gmail.com>
+L: netdev@vger.kernel.org
S: Maintained
W: http://linuxptp.sourceforge.net/
F: Documentation/ABI/testing/sysfs-ptp
@@ -6055,6 +6577,7 @@
F: include/linux/ptrace.h
F: include/linux/regset.h
F: include/linux/tracehook.h
+F: include/uapi/linux/ptrace.h
F: kernel/ptrace.c
PVRUSB2 VIDEO4LINUX DRIVER
@@ -6075,15 +6598,14 @@
F: drivers/media/usb/pwc/*
PWM SUBSYSTEM
-M: Thierry Reding <thierry.reding@avionic-design.de>
-L: linux-kernel@vger.kernel.org
+M: Thierry Reding <thierry.reding@gmail.com>
+L: linux-pwm@vger.kernel.org
S: Maintained
W: http://gitorious.org/linux-pwm
T: git git://gitorious.org/linux-pwm/linux-pwm.git
F: Documentation/pwm.txt
F: Documentation/devicetree/bindings/pwm/
F: include/linux/pwm.h
-F: include/linux/of_pwm.h
F: drivers/pwm/
F: drivers/video/backlight/pwm_bl.c
F: include/linux/pwm_backlight.h
@@ -6159,14 +6681,19 @@
F: drivers/net/ethernet/qlogic/qla3xxx.*
QLOGIC QLCNIC (1/10)Gb ETHERNET DRIVER
+M: Himanshu Madhani <himanshu.madhani@qlogic.com>
+M: Rajesh Borundia <rajesh.borundia@qlogic.com>
+M: Shahed Shaikh <shahed.shaikh@qlogic.com>
M: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
M: Sony Chacko <sony.chacko@qlogic.com>
+M: Sucheta Chakraborty <sucheta.chakraborty@qlogic.com>
M: linux-driver@qlogic.com
L: netdev@vger.kernel.org
S: Supported
F: drivers/net/ethernet/qlogic/qlcnic/
QLOGIC QLGE 10Gb ETHERNET DRIVER
+M: Shahed Shaikh <shahed.shaikh@qlogic.com>
M: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
M: Ron Mercer <ron.mercer@qlogic.com>
M: linux-driver@qlogic.com
@@ -6179,8 +6706,8 @@
W: http://www.alarsen.net/linux/qnx4fs/
S: Maintained
F: fs/qnx4/
-F: include/linux/qnx4_fs.h
-F: include/linux/qnxtypes.h
+F: include/uapi/linux/qnx4_fs.h
+F: include/uapi/linux/qnxtypes.h
QT1010 MEDIA DRIVER
M: Antti Palosaari <crope@iki.fi>
@@ -6198,6 +6725,14 @@
S: Supported
F: arch/hexagon/
+QUICKCAM PARALLEL PORT WEBCAMS
+M: Hans Verkuil <hverkuil@xs4all.nl>
+L: linux-media@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+W: http://linuxtv.org
+S: Odd Fixes
+F: drivers/media/parport/*-qcam*
+
RADOS BLOCK DEVICE (RBD)
M: Yehuda Sadeh <yehuda@inktank.com>
M: Sage Weil <sage@inktank.com>
@@ -6214,7 +6749,7 @@
L: linux-fbdev@vger.kernel.org
S: Maintained
F: drivers/video/aty/radeon*
-F: include/linux/radeonfb.h
+F: include/uapi/linux/radeonfb.h
RADIOSHARK RADIO DRIVER
M: Hans de Goede <hdegoede@redhat.com>
@@ -6315,6 +6850,7 @@
F: Documentation/rtc.txt
F: drivers/rtc/
F: include/linux/rtc.h
+F: include/uapi/linux/rtc.h
REISERFS FILE SYSTEM
L: reiserfs-devel@vger.kernel.org
@@ -6322,7 +6858,7 @@
F: fs/reiserfs/
REGISTER MAP ABSTRACTION
-M: Mark Brown <broonie@opensource.wolfsonmicro.com>
+M: Mark Brown <broonie@kernel.org>
T: git git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git
S: Supported
F: drivers/base/regmap/
@@ -6336,6 +6872,14 @@
F: Documentation/remoteproc.txt
F: include/linux/remoteproc.h
+REMOTE PROCESSOR MESSAGING (RPMSG) SUBSYSTEM
+M: Ohad Ben-Cohen <ohad@wizery.com>
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/ohad/rpmsg.git
+S: Maintained
+F: drivers/rpmsg/
+F: Documentation/rpmsg.txt
+F: include/linux/rpmsg.h
+
RFKILL
M: Johannes Berg <johannes@sipsolutions.net>
L: linux-wireless@vger.kernel.org
@@ -6369,8 +6913,8 @@
L: linux-hams@vger.kernel.org
W: http://www.linux-ax25.org/
S: Maintained
-F: include/linux/rose.h
F: include/net/rose.h
+F: include/uapi/linux/rose.h
F: net/rose/
RTL2830 MEDIA DRIVER
@@ -6383,6 +6927,16 @@
S: Maintained
F: drivers/media/dvb-frontends/rtl2830*
+RTL2832 MEDIA DRIVER
+M: Antti Palosaari <crope@iki.fi>
+L: linux-media@vger.kernel.org
+W: http://linuxtv.org/
+W: http://palosaari.fi/linux/
+Q: http://patchwork.linuxtv.org/project/linux-media/list/
+T: git git://linuxtv.org/anttip/media_tree.git
+S: Maintained
+F: drivers/media/dvb-frontends/rtl2832*
+
RTL8180 WIRELESS DRIVER
M: "John W. Linville" <linville@tuxdriver.com>
L: linux-wireless@vger.kernel.org
@@ -6440,7 +6994,7 @@
F: drivers/s390/net/
S390 ZCRYPT DRIVER
-M: Holger Dengler <hd@linux.vnet.ibm.com>
+M: Ingo Tuchscherer <ingo.tuchscherer@de.ibm.com>
M: linux390@de.ibm.com
L: linux-s390@vger.kernel.org
W: http://www.ibm.com/developerworks/linux/linux390/
@@ -6471,20 +7025,27 @@
S: Supported
F: drivers/mmc/host/s3cmci.*
+SAA6588 RDS RECEIVER DRIVER
+M: Hans Verkuil <hverkuil@xs4all.nl>
+L: linux-media@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+W: http://linuxtv.org
+S: Odd Fixes
+F: drivers/media/i2c/saa6588*
+
SAA7134 VIDEO4LINUX DRIVER
-M: Mauro Carvalho Chehab <mchehab@redhat.com>
+M: Mauro Carvalho Chehab <m.chehab@samsung.com>
L: linux-media@vger.kernel.org
W: http://linuxtv.org
T: git git://linuxtv.org/media_tree.git
S: Odd fixes
-F: Documentation/video4linux/saa7134/
+F: Documentation/video4linux/*.saa7134
F: drivers/media/pci/saa7134/
SAA7146 VIDEO4LINUX-2 DRIVER
-M: Michael Hunold <michael@mihu.de>
+M: Hans Verkuil <hverkuil@xs4all.nl>
L: linux-media@vger.kernel.org
T: git git://linuxtv.org/media_tree.git
-W: http://www.mihu.de/linux/saa7146
S: Maintained
F: drivers/media/common/saa7146/
F: drivers/media/pci/saa7146/
@@ -6518,6 +7079,15 @@
F: drivers/rtc/rtc-sec.c
F: include/linux/mfd/samsung/
+SAMSUNG S5P/EXYNOS4 SOC SERIES CAMERA SUBSYSTEM DRIVERS
+M: Kyungmin Park <kyungmin.park@samsung.com>
+M: Sylwester Nawrocki <s.nawrocki@samsung.com>
+L: linux-media@vger.kernel.org
+Q: https://patchwork.linuxtv.org/project/linux-media/list/
+S: Supported
+F: drivers/media/platform/exynos4-is/
+F: include/media/s5p_fimc.h
+
SAMSUNG S3C24XX/S3C64XX SOC SERIES CAMIF DRIVER
M: Sylwester Nawrocki <sylvester.nawrocki@gmail.com>
L: linux-media@vger.kernel.org
@@ -6526,8 +7096,15 @@
F: drivers/media/platform/s3c-camif/
F: include/media/s3c_camif.h
+SAMSUNG S5C73M3 CAMERA DRIVER
+M: Kyungmin Park <kyungmin.park@samsung.com>
+M: Andrzej Hajda <a.hajda@samsung.com>
+L: linux-media@vger.kernel.org
+S: Supported
+F: drivers/media/i2c/s5c73m3/*
+
SERIAL DRIVERS
-M: Alan Cox <alan@linux.intel.com>
+M: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
L: linux-serial@vger.kernel.org
S: Maintained
F: drivers/tty/serial
@@ -6536,17 +7113,26 @@
M: Viresh Kumar <viresh.linux@gmail.com>
S: Maintained
F: include/linux/dw_dmac.h
-F: drivers/dma/dw_dmac_regs.h
-F: drivers/dma/dw_dmac.c
+F: drivers/dma/dw/
+
+SYNOPSYS DESIGNWARE MMC/SD/SDIO DRIVER
+M: Seungwon Jeon <tgih.jun@samsung.com>
+M: Jaehoon Chung <jh80.chung@samsung.com>
+L: linux-mmc@vger.kernel.org
+S: Maintained
+F: include/linux/mmc/dw_mmc.h
+F: drivers/mmc/host/dw_mmc*
TIMEKEEPING, NTP
-M: John Stultz <johnstul@us.ibm.com>
+M: John Stultz <john.stultz@linaro.org>
M: Thomas Gleixner <tglx@linutronix.de>
T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers/core
S: Supported
F: include/linux/clocksource.h
F: include/linux/time.h
F: include/linux/timex.h
+F: include/uapi/linux/time.h
+F: include/uapi/linux/timex.h
F: kernel/time/clocksource.c
F: kernel/time/time*.c
F: kernel/time/ntp.c
@@ -6554,9 +7140,8 @@
TLG2300 VIDEO4LINUX-2 DRIVER
M: Huang Shijie <shijie8@gmail.com>
-M: Kang Yong <kangyong@telegent.com>
-M: Zhang Xiaobing <xbzhang@telegent.com>
-S: Supported
+M: Hans Verkuil <hverkuil@xs4all.nl>
+S: Odd Fixes
F: drivers/media/usb/tlg2300
SC1200 WDT DRIVER
@@ -6571,6 +7156,7 @@
S: Maintained
F: kernel/sched/
F: include/linux/sched.h
+F: include/uapi/linux/sched.h
SCORE ARCHITECTURE
M: Chen Liqin <liqin.chen@sunplusct.com>
@@ -6619,11 +7205,11 @@
L: linux-scsi@vger.kernel.org
S: Maintained
F: Documentation/scsi/st.txt
-F: drivers/scsi/st*
+F: drivers/scsi/st.*
+F: drivers/scsi/st_*.h
SCTP PROTOCOL
M: Vlad Yasevich <vyasevich@gmail.com>
-M: Sridhar Samudrala <sri@us.ibm.com>
M: Neil Horman <nhorman@tuxdriver.com>
L: linux-sctp@vger.kernel.org
W: http://lksctp.sourceforge.net
@@ -6669,7 +7255,7 @@
F: drivers/mmc/host/sdhci-pltfm.[ch]
SECURE DIGITAL HOST CONTROLLER INTERFACE, OPEN FIRMWARE BINDINGS (SDHCI-OF)
-M: Anton Vorontsov <avorontsov@ru.mvista.com>
+M: Anton Vorontsov <anton@enomsg.org>
L: linuxppc-dev@lists.ozlabs.org
L: linux-mmc@vger.kernel.org
S: Maintained
@@ -6724,12 +7310,12 @@
M: Jiri Slaby <jirislaby@gmail.com>
S: Maintained
F: drivers/misc/phantom.c
-F: include/linux/phantom.h
+F: include/uapi/linux/phantom.h
SERIAL ATA (SATA) SUBSYSTEM
-M: Jeff Garzik <jgarzik@pobox.com>
+M: Tejun Heo <tj@kernel.org>
L: linux-ide@vger.kernel.org
-T: git git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata.git
S: Supported
F: drivers/ata/
F: include/linux/ata.h
@@ -6759,7 +7345,8 @@
F: drivers/net/ethernet/sfc/
SGI GRU DRIVER
-M: Jack Steiner <steiner@sgi.com>
+M: Dimitri Sivanich <sivanich@sgi.com>
+M: Robin Holt <holt@sgi.com>
S: Maintained
F: drivers/misc/sgi-gru/
@@ -6783,6 +7370,64 @@
S: Maintained
F: drivers/misc/sgi-xp/
+SI470X FM RADIO RECEIVER I2C DRIVER
+M: Hans Verkuil <hverkuil@xs4all.nl>
+L: linux-media@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+W: http://linuxtv.org
+S: Odd Fixes
+F: drivers/media/radio/si470x/radio-si470x-i2c.c
+
+SI470X FM RADIO RECEIVER USB DRIVER
+M: Hans Verkuil <hverkuil@xs4all.nl>
+L: linux-media@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+W: http://linuxtv.org
+S: Maintained
+F: drivers/media/radio/si470x/radio-si470x-common.c
+F: drivers/media/radio/si470x/radio-si470x.h
+F: drivers/media/radio/si470x/radio-si470x-usb.c
+
+SI4713 FM RADIO TRANSMITTER I2C DRIVER
+M: Eduardo Valentin <edubezval@gmail.com>
+L: linux-media@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+W: http://linuxtv.org
+S: Odd Fixes
+F: drivers/media/radio/si4713-i2c.?
+
+SI4713 FM RADIO TRANSMITTER PLATFORM DRIVER
+M: Eduardo Valentin <edubezval@gmail.com>
+L: linux-media@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+W: http://linuxtv.org
+S: Odd Fixes
+F: drivers/media/radio/radio-si4713.h
+
+SIANO DVB DRIVER
+M: Mauro Carvalho Chehab <m.chehab@samsung.com>
+L: linux-media@vger.kernel.org
+W: http://linuxtv.org
+T: git git://linuxtv.org/media_tree.git
+S: Odd fixes
+F: drivers/media/common/siano/
+F: drivers/media/dvb/siano/
+F: drivers/media/usb/siano/
+F: drivers/media/mmc/siano
+
+SH_VEU V4L2 MEM2MEM DRIVER
+M: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
+L: linux-media@vger.kernel.org
+S: Maintained
+F: drivers/media/platform/sh_veu.c
+
+SH_VOU V4L2 OUTPUT DRIVER
+M: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
+L: linux-media@vger.kernel.org
+S: Odd Fixes
+F: drivers/media/platform/sh_vou.c
+F: include/media/sh_vou.h
+
SIMPLE FIRMWARE INTERFACE (SFI)
M: Len Brown <lenb@kernel.org>
L: sfi-devel@simplefirmware.org
@@ -6812,7 +7457,7 @@
TI DAVINCI MACHINE SUPPORT
M: Sekhar Nori <nsekhar@ti.com>
-M: Kevin Hilman <khilman@ti.com>
+M: Kevin Hilman <khilman@deeprootsystems.com>
L: davinci-linux-open-source@linux.davincidsp.com (moderated for non-subscribers)
T: git git://gitorious.org/linux-davinci/linux-davinci.git
Q: http://patchwork.kernel.org/project/linux-davinci/list/
@@ -6821,14 +7466,13 @@
F: drivers/i2c/busses/i2c-davinci.c
TI DAVINCI SERIES MEDIA DRIVER
-M: Manjunath Hadli <manjunath.hadli@ti.com>
-M: Prabhakar Lad <prabhakar.lad@ti.com>
+M: Lad, Prabhakar <prabhakar.csengg@gmail.com>
L: linux-media@vger.kernel.org
L: davinci-linux-open-source@linux.davincidsp.com (moderated for non-subscribers)
W: http://linuxtv.org/
Q: http://patchwork.linuxtv.org/project/linux-media/list/
T: git git://linuxtv.org/mhadli/v4l-dvb-davinci_devices.git
-S: Supported
+S: Maintained
F: drivers/media/platform/davinci/
F: include/media/davinci/
@@ -6845,13 +7489,6 @@
S: Maintained
F: drivers/net/ethernet/sis/sis900.*
-SIS 96X I2C/SMBUS DRIVER
-M: "Mark M. Hoffman" <mhoffman@lightlink.com>
-L: linux-i2c@vger.kernel.org
-S: Maintained
-F: Documentation/i2c/busses/i2c-sis96x
-F: drivers/i2c/busses/i2c-sis96x.c
-
SIS FRAMEBUFFER DRIVER
M: Thomas Winischhofer <thomas@winischhofer.net>
W: http://www.winischhofer.net/linuxsisvga.shtml
@@ -6929,7 +7566,7 @@
F: drivers/hwmon/sch5627.c
SMSC47B397 HARDWARE MONITOR DRIVER
-M: "Mark M. Hoffman" <mhoffman@lightlink.com>
+M: Jean Delvare <khali@linux-fr.org>
L: lm-sensors@lm-sensors.org
S: Maintained
F: Documentation/hwmon/smsc47b397
@@ -6954,14 +7591,6 @@
S: Maintained
F: drivers/video/smscufx.c
-SN-IA64 (Itanium) SUB-PLATFORM
-M: Jes Sorensen <jes@sgi.com>
-L: linux-altix@sgi.com
-L: linux-ia64@vger.kernel.org
-W: http://www.sgi.com/altix
-S: Maintained
-F: arch/ia64/sn/
-
SOC-CAMERA V4L2 SUBSYSTEM
M: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
L: linux-media@vger.kernel.org
@@ -6982,6 +7611,7 @@
S: Supported
F: drivers/md/
F: include/linux/raid/
+F: include/uapi/linux/raid/
SONIC NETWORK DRIVER
M: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
@@ -7022,11 +7652,12 @@
S: Maintained
F: Documentation/sound/
F: include/sound/
+F: include/uapi/sound/
F: sound/
SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEMENT (ASoC)
-M: Liam Girdwood <lrg@ti.com>
-M: Mark Brown <broonie@opensource.wolfsonmicro.com>
+M: Liam Girdwood <lgirdwood@gmail.com>
+M: Mark Brown <broonie@kernel.org>
T: git git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
W: http://alsa-project.org/main/index.php/ASoC
@@ -7114,14 +7745,16 @@
F: drivers/clk/spear/
SPI SUBSYSTEM
-M: Grant Likely <grant.likely@secretlab.ca>
-L: spi-devel-general@lists.sourceforge.net
+M: Mark Brown <broonie@kernel.org>
+M: Grant Likely <grant.likely@linaro.org>
+L: linux-spi@vger.kernel.org
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
Q: http://patchwork.kernel.org/project/spi-devel-general/list/
-T: git git://git.secretlab.ca/git/linux-2.6.git
S: Maintained
F: Documentation/spi/
F: drivers/spi/
F: include/linux/spi/
+F: include/uapi/linux/spi/
SPIDERNET NETWORK DRIVER for CELL
M: Ishizaki Kou <kou.ishizaki@toshiba.co.jp>
@@ -7157,6 +7790,7 @@
M: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
L: stable@vger.kernel.org
S: Supported
+F: Documentation/stable_kernel_rules.txt
STAGING SUBSYSTEM
M: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
@@ -7211,6 +7845,11 @@
S: Odd Fixes
F: drivers/staging/frontier/
+STAGING - GO7007 MPEG CODEC
+M: Hans Verkuil <hans.verkuil@cisco.com>
+S: Maintained
+F: drivers/staging/media/go7007/
+
STAGING - INDUSTRIAL IO
M: Jonathan Cameron <jic23@cam.ac.uk>
L: linux-iio@vger.kernel.org
@@ -7227,6 +7866,7 @@
M: Julian Andres Klode <jak@jak-linux.org>
M: Marc Dietrich <marvin24@gmx.de>
L: ac100@lists.launchpad.net (moderated for non-subscribers)
+L: linux-tegra@vger.kernel.org
S: Maintained
F: drivers/staging/nvec/
@@ -7239,8 +7879,7 @@
F: drivers/staging/olpc_dcon/
STAGING - OZMO DEVICES USB OVER WIFI DRIVER
-M: Rupesh Gujare <rgujare@ozmodevices.com>
-M: Chris Kelly <ckelly@ozmodevices.com>
+M: Rupesh Gujare <rupesh.gujare@atmel.com>
S: Maintained
F: drivers/staging/ozwpan/
@@ -7258,17 +7897,17 @@
STAGING - SILICON MOTION SM7XX FRAME BUFFER DRIVER
M: Teddy Wang <teddy.wang@siliconmotion.com.cn>
S: Odd Fixes
-F: drivers/staging/sm7xx/
+F: drivers/staging/sm7xxfb/
STAGING - SOFTLOGIC 6x10 MPEG CODEC
-M: Ben Collins <bcollins@bluecherry.net>
-S: Odd Fixes
+M: Ismael Luceno <ismael.luceno@corp.bluecherry.net>
+S: Supported
F: drivers/staging/media/solo6x10/
STAGING - SPEAKUP CONSOLE SPEECH DRIVER
M: William Hubbs <w.d.hubbs@gmail.com>
M: Chris Brannon <chris@the-brannons.com>
-M: Kirk Reiser <kirk@braille.uwo.ca>
+M: Kirk Reiser <kirk@reisers.ca>
M: Samuel Thibault <samuel.thibault@ens-lyon.org>
L: speakup@braille.uwo.ca
W: http://www.linux-speakup.org/
@@ -7276,7 +7915,7 @@
F: drivers/staging/speakup/
STAGING - TI DSP BRIDGE DRIVERS
-M: Omar Ramirez Luna <omar.ramirez@ti.com>
+M: Omar Ramirez Luna <omar.ramirez@copitl.com>
S: Odd Fixes
F: drivers/staging/tidspbridge/
@@ -7354,6 +7993,13 @@
F: arch/*/kernel/pci-swiotlb.c
F: include/linux/swiotlb.h
+SYNOPSYS ARC ARCHITECTURE
+M: Vineet Gupta <vgupta@synopsys.com>
+S: Supported
+F: arch/arc/
+F: Documentation/devicetree/bindings/arc/
+F: drivers/tty/serial/arc-uart.c
+
SYSV FILESYSTEM
M: Christoph Hellwig <hch@infradead.org>
S: Maintained
@@ -7367,7 +8013,7 @@
L: target-devel@vger.kernel.org
L: http://groups.google.com/group/linux-iscsi-target-dev
W: http://www.linux-iscsi.org
-T: git git://git.kernel.org/pub/scm/linux/kernel/git/nab/lio-core.git master
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git master
S: Supported
F: drivers/target/
F: include/target/
@@ -7384,8 +8030,8 @@
M: Jamal Hadi Salim <jhs@mojatatu.com>
L: netdev@vger.kernel.org
S: Maintained
-F: include/linux/pkt_cls.h
F: include/net/pkt_cls.h
+F: include/uapi/linux/pkt_cls.h
F: net/sched/
TCP LOW PRIORITY MODULE
@@ -7455,8 +8101,16 @@
S: Maintained
F: drivers/media/tuners/tda8290.*
+TDA9840 MEDIA DRIVER
+M: Hans Verkuil <hverkuil@xs4all.nl>
+L: linux-media@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+W: http://linuxtv.org
+S: Maintained
+F: drivers/media/i2c/tda9840*
+
TEA5761 TUNER DRIVER
-M: Mauro Carvalho Chehab <mchehab@redhat.com>
+M: Mauro Carvalho Chehab <m.chehab@samsung.com>
L: linux-media@vger.kernel.org
W: http://linuxtv.org
T: git git://linuxtv.org/media_tree.git
@@ -7464,19 +8118,41 @@
F: drivers/media/tuners/tea5761.*
TEA5767 TUNER DRIVER
-M: Mauro Carvalho Chehab <mchehab@redhat.com>
+M: Mauro Carvalho Chehab <m.chehab@samsung.com>
L: linux-media@vger.kernel.org
W: http://linuxtv.org
T: git git://linuxtv.org/media_tree.git
S: Maintained
F: drivers/media/tuners/tea5767.*
+TEA6415C MEDIA DRIVER
+M: Hans Verkuil <hverkuil@xs4all.nl>
+L: linux-media@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+W: http://linuxtv.org
+S: Maintained
+F: drivers/media/i2c/tea6415c*
+
+TEA6420 MEDIA DRIVER
+M: Hans Verkuil <hverkuil@xs4all.nl>
+L: linux-media@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+W: http://linuxtv.org
+S: Maintained
+F: drivers/media/i2c/tea6420*
+
TEAM DRIVER
-M: Jiri Pirko <jpirko@redhat.com>
+M: Jiri Pirko <jiri@resnulli.us>
L: netdev@vger.kernel.org
S: Supported
F: drivers/net/team/
F: include/linux/if_team.h
+F: include/uapi/linux/if_team.h
+
+TECHNOLOGIC SYSTEMS TS-5500 PLATFORM SUPPORT
+M: Savoir-faire Linux Inc. <kernel@savoirfairelinux.com>
+S: Maintained
+F: arch/x86/platform/ts5500/
TECHNOTREND USB IR RECEIVER
M: Sean Young <sean@mess.org>
@@ -7490,9 +8166,7 @@
Q: http://patchwork.ozlabs.org/project/linux-tegra/list/
T: git git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git
S: Supported
-F: arch/arm/mach-tegra
-F: arch/arm/boot/dts/tegra*
-F: arch/arm/configs/tegra_defconfig
+N: [^a-z]tegra
TEHUTI ETHERNET DRIVER
M: Andy Gospodarek <andy@greyhouse.net>
@@ -7514,11 +8188,20 @@
THERMAL
M: Zhang Rui <rui.zhang@intel.com>
+M: Eduardo Valentin <eduardo.valentin@ti.com>
L: linux-pm@vger.kernel.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal.git
+Q: https://patchwork.kernel.org/project/linux-pm/list/
S: Supported
F: drivers/thermal/
F: include/linux/thermal.h
+F: include/linux/cpu_cooling.h
+
+THINGM BLINK(1) USB RGB LED DRIVER
+M: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
+S: Maintained
+F: drivers/hid/hid-thingm.c
THINKPAD ACPI EXTRAS DRIVER
M: Henrique de Moraes Holschuh <ibm-acpi@hmh.eng.br>
@@ -7530,6 +8213,12 @@
S: Maintained
F: drivers/platform/x86/thinkpad_acpi.c
+TI BANDGAP AND THERMAL DRIVER
+M: Eduardo Valentin <eduardo.valentin@ti.com>
+L: linux-pm@vger.kernel.org
+S: Supported
+F: drivers/thermal/ti-soc-thermal/
+
TI FLASH MEDIA INTERFACE DRIVER
M: Alex Dubov <oakad@yahoo.com>
S: Maintained
@@ -7552,6 +8241,22 @@
F: drivers/video/backlight/lp855x_bl.c
F: include/linux/platform_data/lp855x.h
+TI LP8727 CHARGER DRIVER
+M: Milo Kim <milo.kim@ti.com>
+S: Maintained
+F: drivers/power/lp8727_charger.c
+F: include/linux/platform_data/lp8727.h
+
+TI LP8788 MFD DRIVER
+M: Milo Kim <milo.kim@ti.com>
+S: Maintained
+F: drivers/iio/adc/lp8788_adc.c
+F: drivers/leds/leds-lp8788.c
+F: drivers/mfd/lp8788*.c
+F: drivers/power/lp8788-charger.c
+F: drivers/regulator/lp8788-*.c
+F: include/linux/mfd/lp8788*.h
+
TI TWL4030 SERIES SOC CODEC DRIVER
M: Peter Ujfalusi <peter.ujfalusi@ti.com>
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
@@ -7575,7 +8280,7 @@
L: tipc-discussion@lists.sourceforge.net (user apps, general discussion)
W: http://tipc.sourceforge.net/
S: Maintained
-F: include/linux/tipc*.h
+F: include/uapi/linux/tipc*.h
F: net/tipc/
TILE ARCHITECTURE
@@ -7625,6 +8330,7 @@
S: Maintained
F: drivers/char/toshiba.c
F: include/linux/toshiba.h
+F: include/uapi/linux/toshiba.h
TMIO MMC DRIVER
M: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
@@ -7636,6 +8342,13 @@
F: include/linux/mmc/tmio.h
F: include/linux/mmc/sh_mobile_sdhi.h
+TMP401 HARDWARE MONITOR DRIVER
+M: Guenter Roeck <linux@roeck-us.net>
+L: lm-sensors@lm-sensors.org
+S: Maintained
+F: Documentation/hwmon/tmp401
+F: drivers/hwmon/tmp401.c
+
TMPFS (SHMEM FILESYSTEM)
M: Hugh Dickins <hughd@google.com>
L: linux-mm@kvack.org
@@ -7644,7 +8357,7 @@
F: mm/shmem.c
TM6000 VIDEO4LINUX DRIVER
-M: Mauro Carvalho Chehab <mchehab@redhat.com>
+M: Mauro Carvalho Chehab <m.chehab@samsung.com>
L: linux-media@vger.kernel.org
W: http://linuxtv.org
T: git git://linuxtv.org/media_tree.git
@@ -7652,7 +8365,8 @@
F: drivers/media/usb/tm6000/
TPM DEVICE DRIVER
-M: Kent Yoder <key@linux.vnet.ibm.com>
+M: Leonidas Da Silva Barbosa <leosilva@linux.vnet.ibm.com>
+M: Ashley Lai <ashley@ashleylai.com>
M: Rajiv Andrade <mail@srajiv.net>
W: http://tpmdd.sourceforge.net
M: Marcel Selhorst <tpmdd@selhorst.net>
@@ -7692,6 +8406,9 @@
F: include/linux/serial_core.h
F: include/linux/serial.h
F: include/linux/tty.h
+F: include/uapi/linux/serial_core.h
+F: include/uapi/linux/serial.h
+F: include/uapi/linux/tty.h
TUA9001 MEDIA DRIVER
M: Antti Palosaari <crope@iki.fi>
@@ -7771,7 +8488,7 @@
L: linux-input@vger.kernel.org
S: Maintained
F: drivers/hid/uhid.c
-F: include/linux/uhid.h
+F: include/uapi/linux/uhid.h
ULTRA-WIDEBAND (UWB) SUBSYSTEM:
L: linux-usb@vger.kernel.org
@@ -7800,6 +8517,7 @@
F: Documentation/cdrom/
F: drivers/cdrom/cdrom.c
F: include/linux/cdrom.h
+F: include/uapi/linux/cdrom.h
UNIVERSAL FLASH STORAGE HOST CONTROLLER DRIVER
M: Vinayak Holikatti <vinholikatti@gmail.com>
@@ -7817,7 +8535,7 @@
S: Maintained
F: drivers/mtd/ubi/
F: include/linux/mtd/ubi.h
-F: include/mtd/ubi-user.h
+F: include/uapi/mtd/ubi-user.h
UNSORTED BLOCK IMAGES (UBI) Fastmap
M: Richard Weinberger <richard@nod.at>
@@ -7841,9 +8559,10 @@
USB ATTACHED SCSI
M: Matthew Wilcox <willy@linux.intel.com>
M: Sarah Sharp <sarah.a.sharp@linux.intel.com>
+M: Gerd Hoffmann <kraxel@redhat.com>
L: linux-usb@vger.kernel.org
L: linux-scsi@vger.kernel.org
-S: Supported
+S: Maintained
F: drivers/usb/storage/uas.c
USB CDC ETHERNET DRIVER
@@ -7851,7 +8570,7 @@
L: linux-usb@vger.kernel.org
S: Maintained
F: drivers/net/usb/cdc_*.c
-F: include/linux/usb/cdc.h
+F: include/uapi/linux/usb/cdc.h
USB CYPRESS C67X00 DRIVER
M: Peter Korsgaard <jacmet@sunsite.dk>
@@ -7945,9 +8664,10 @@
F: drivers/usb/serial/option.c
USB PEGASUS DRIVER
-M: Petko Manolov <petkan@users.sourceforge.net>
+M: Petko Manolov <petkan@nucleusys.com>
L: linux-usb@vger.kernel.org
L: netdev@vger.kernel.org
+T: git git://git.code.sf.net/p/pegasus2/git
W: http://pegasus2.sourceforge.net/
S: Maintained
F: drivers/net/usb/pegasus.*
@@ -7967,9 +8687,10 @@
F: drivers/usb/class/usblp.c
USB RTL8150 DRIVER
-M: Petko Manolov <petkan@users.sourceforge.net>
+M: Petko Manolov <petkan@nucleusys.com>
L: linux-usb@vger.kernel.org
L: netdev@vger.kernel.org
+T: git git://git.code.sf.net/p/pegasus2/git
W: http://pegasus2.sourceforge.net/
S: Maintained
F: drivers/net/usb/rtl8150.c
@@ -8087,6 +8808,14 @@
F: drivers/media/usb/uvc/
F: include/uapi/linux/uvcvideo.h
+USB VISION DRIVER
+M: Hans Verkuil <hverkuil@xs4all.nl>
+L: linux-media@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+W: http://linuxtv.org
+S: Odd Fixes
+F: drivers/media/usb/usbvision/
+
USB WEBCAM GADGET
M: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
L: linux-usb@vger.kernel.org
@@ -8095,7 +8824,7 @@
F: drivers/usb/gadget/webcam.c
USB WIRELESS RNDIS DRIVER (rndis_wlan)
-M: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
+M: Jussi Kivilinna <jussi.kivilinna@iki.fi>
L: linux-wireless@vger.kernel.org
S: Maintained
F: drivers/net/wireless/rndis_wlan.c
@@ -8172,6 +8901,7 @@
F: Documentation/vfio.txt
F: drivers/vfio/
F: include/linux/vfio.h
+F: include/uapi/linux/vfio.h
VIDEOBUF2 FRAMEWORK
M: Pawel Osciak <pawel@osciak.com>
@@ -8188,6 +8918,7 @@
S: Maintained
F: drivers/char/virtio_console.c
F: include/linux/virtio_console.h
+F: include/uapi/linux/virtio_console.h
VIRTIO CORE, NET AND BLOCK DRIVERS
M: Rusty Russell <rusty@rustcorp.com.au>
@@ -8195,9 +8926,11 @@
L: virtualization@lists.linux-foundation.org
S: Maintained
F: drivers/virtio/
+F: tools/virtio/
F: drivers/net/virtio_net.c
F: drivers/block/virtio_blk.c
F: include/linux/virtio_*.h
+F: include/uapi/linux/virtio_*.h
VIRTIO HOST (VHOST)
M: "Michael S. Tsirkin" <mst@redhat.com>
@@ -8206,7 +8939,7 @@
L: netdev@vger.kernel.org
S: Maintained
F: drivers/vhost/
-F: include/linux/vhost.h
+F: include/uapi/linux/vhost.h
VIA RHINE NETWORK DRIVER
M: Roger Luethi <rl@hellgate.ch>
@@ -8234,6 +8967,14 @@
S: Maintained
F: drivers/net/ethernet/via/via-velocity.*
+VIVI VIRTUAL VIDEO DRIVER
+M: Hans Verkuil <hverkuil@xs4all.nl>
+L: linux-media@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+W: http://linuxtv.org
+S: Maintained
+F: drivers/media/platform/vivi*
+
VLAN (802.1Q)
M: Patrick McHardy <kaber@trash.net>
L: netdev@vger.kernel.org
@@ -8277,11 +9018,11 @@
F: drivers/scsi/vmw_pvscsi.h
VOLTAGE AND CURRENT REGULATOR FRAMEWORK
-M: Liam Girdwood <lrg@ti.com>
-M: Mark Brown <broonie@opensource.wolfsonmicro.com>
+M: Liam Girdwood <lgirdwood@gmail.com>
+M: Mark Brown <broonie@kernel.org>
W: http://opensource.wolfsonmicro.com/node/15
W: http://www.slimlogic.co.uk/?p=48
-T: git git://git.kernel.org/pub/scm/linux/kernel/git/lrg/regulator.git
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
S: Supported
F: drivers/regulator/
F: include/linux/regulator/
@@ -8346,6 +9087,7 @@
F: Documentation/watchdog/
F: drivers/watchdog/
F: include/linux/watchdog.h
+F: include/uapi/linux/watchdog.h
WD7000 SCSI DRIVER
M: Miroslav Zagorac <zaga@fly.cc.fer.hr>
@@ -8371,9 +9113,9 @@
S: Supported
W: http://linuxwimax.org
F: Documentation/wimax/README.wimax
-F: include/linux/wimax.h
F: include/linux/wimax/debug.h
F: include/net/wimax.h
+F: include/uapi/linux/wimax.h
F: net/wimax/
WISTRON LAPTOP BUTTON DRIVER
@@ -8389,7 +9131,7 @@
F: drivers/net/wireless/wl3501*
WM97XX TOUCHSCREEN DRIVERS
-M: Mark Brown <broonie@opensource.wolfsonmicro.com>
+M: Mark Brown <broonie@kernel.org>
M: Liam Girdwood <lrg@slimlogic.co.uk>
L: linux-input@vger.kernel.org
T: git git://opensource.wolfsonmicro.com/linux-2.6-touch
@@ -8399,7 +9141,6 @@
F: include/linux/wm97xx.h
WOLFSON MICROELECTRONICS DRIVERS
-M: Mark Brown <broonie@opensource.wolfsonmicro.com>
L: patches@opensource.wolfsonmicro.com
T: git git://opensource.wolfsonmicro.com/linux-2.6-asoc
T: git git://opensource.wolfsonmicro.com/linux-2.6-audioplus
@@ -8459,7 +9200,7 @@
F: arch/x86/
X86 PLATFORM DRIVERS
-M: Matthew Garrett <mjg@redhat.com>
+M: Matthew Garrett <matthew.garrett@nebula.com>
L: platform-driver-x86@vger.kernel.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mjg59/platform-drivers-x86.git
S: Maintained
@@ -8473,7 +9214,7 @@
F: arch/x86/kernel/cpu/mcheck/*
XC2028/3028 TUNER DRIVER
-M: Mauro Carvalho Chehab <mchehab@redhat.com>
+M: Mauro Carvalho Chehab <m.chehab@samsung.com>
L: linux-media@vger.kernel.org
W: http://linuxtv.org
T: git git://linuxtv.org/media_tree.git
@@ -8491,6 +9232,7 @@
F: drivers/xen/
F: arch/x86/include/asm/xen/
F: include/xen/
+F: include/uapi/xen/
XEN HYPERVISOR ARM
M: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
@@ -8499,6 +9241,13 @@
F: arch/arm/xen/
F: arch/arm/include/asm/xen/
+XEN HYPERVISOR ARM64
+M: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
+L: xen-devel@lists.xensource.com (moderated for non-subscribers)
+S: Supported
+F: arch/arm64/xen/
+F: arch/arm64/include/asm/xen/
+
XEN NETWORK BACKEND DRIVER
M: Ian Campbell <ian.campbell@citrix.com>
L: xen-devel@lists.xensource.com (moderated for non-subscribers)
@@ -8539,9 +9288,7 @@
F: drivers/net/ethernet/xilinx/xilinx_axienet*
XILINX SYSTEMACE DRIVER
-M: Grant Likely <grant.likely@secretlab.ca>
-W: http://www.secretlab.ca/
-S: Maintained
+S: Unmaintained
F: drivers/block/xsysace.c
XILINX UARTLITE SERIAL DRIVER
@@ -8574,6 +9321,13 @@
F: drivers/net/hamradio/*scc.c
F: drivers/net/hamradio/z8530.h
+ZBUD COMPRESSED PAGE ALLOCATOR
+M: Seth Jennings <sjenning@linux.vnet.ibm.com>
+L: linux-mm@kvack.org
+S: Maintained
+F: mm/zbud.c
+F: include/linux/zbud.h
+
ZD1211RW WIRELESS DRIVER
M: Daniel Drake <dsd@gentoo.org>
M: Ulrich Kunitz <kune@deine-taler.de>
@@ -8596,6 +9350,12 @@
S: Maintained
F: drivers/tty/serial/zs.*
+ZSWAP COMPRESSED SWAP CACHING
+M: Seth Jennings <sjenning@linux.vnet.ibm.com>
+L: linux-mm@kvack.org
+S: Maintained
+F: mm/zswap.c
+
THE REST
M: Linus Torvalds <torvalds@linux-foundation.org>
L: linux-kernel@vger.kernel.org
diff --git a/Makefile b/Makefile
index 275b9567..4e3575c 100644
--- a/Makefile
+++ b/Makefile
@@ -1,8 +1,8 @@
VERSION = 3
-PATCHLEVEL = 8
+PATCHLEVEL = 10
SUBLEVEL = 0
-EXTRAVERSION = -rc1
-NAME = Terrified Chipmunk
+EXTRAVERSION =
+NAME = Unicycling Gorilla
# *DOCUMENTATION*
# To see a list of typical targets execute "make help"
@@ -165,11 +165,12 @@
# then ARCH is assigned, getting whatever value it gets normally, and
# SUBARCH is subsequently ignored.
-SUBARCH := $(shell uname -m | sed -e s/i.86/i386/ -e s/sun4u/sparc64/ \
+SUBARCH := $(shell uname -m | sed -e s/i.86/x86/ -e s/x86_64/x86/ \
+ -e s/sun4u/sparc64/ \
-e s/arm.*/arm/ -e s/sa110/arm/ \
-e s/s390x/s390/ -e s/parisc64/parisc/ \
-e s/ppc.*/powerpc/ -e s/mips.*/mips/ \
- -e s/sh[234].*/sh/ )
+ -e s/sh[234].*/sh/ -e s/aarch64.*/arm64/ )
# Cross compiling and selecting different set of gcc/bin-utils
# ---------------------------------------------------------------------------
@@ -191,7 +192,6 @@
# "make" in the configured kernel build directory always uses that.
# Default value for CROSS_COMPILE is not to prefix executables
# Note: Some architectures assign CROSS_COMPILE in their arch/*/Makefile
-export KBUILD_BUILDHOST := $(SUBARCH)
ARCH ?= $(SUBARCH)
CROSS_COMPILE ?= $(CONFIG_CROSS_COMPILE:"%"=%)
@@ -513,7 +513,8 @@
# Carefully list dependencies so we do not try to build scripts twice
# in parallel
PHONY += scripts
-scripts: scripts_basic include/config/auto.conf include/config/tristate.conf
+scripts: scripts_basic include/config/auto.conf include/config/tristate.conf \
+ asm-generic
$(Q)$(MAKE) $(build)=$(@)
# Objects we will link into vmlinux / subdirs we need to visit
@@ -570,7 +571,7 @@
all: vmlinux
ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE
-KBUILD_CFLAGS += -Os
+KBUILD_CFLAGS += -Os $(call cc-disable-warning,maybe-uninitialized,)
else
KBUILD_CFLAGS += -O2
endif
@@ -619,7 +620,8 @@
endif
ifdef CONFIG_DEBUG_INFO_REDUCED
-KBUILD_CFLAGS += $(call cc-option, -femit-struct-debug-baseonly)
+KBUILD_CFLAGS += $(call cc-option, -femit-struct-debug-baseonly) \
+ $(call cc-option,-fno-var-tracking)
endif
ifdef CONFIG_FUNCTION_TRACER
@@ -719,11 +721,11 @@
export mod_strip_cmd
-ifeq ($(CONFIG_MODULE_SIG),y)
+ifdef CONFIG_MODULE_SIG_ALL
MODSECKEY = ./signing_key.priv
MODPUBKEY = ./signing_key.x509
export MODPUBKEY
-mod_sign_cmd = perl $(srctree)/scripts/sign-file $(MODSECKEY) $(MODPUBKEY)
+mod_sign_cmd = perl $(srctree)/scripts/sign-file $(CONFIG_MODULE_SIG_HASH) $(MODSECKEY) $(MODPUBKEY)
else
mod_sign_cmd = true
endif
@@ -755,6 +757,8 @@
export KBUILD_VMLINUX_MAIN := $(core-y) $(libs-y) $(drivers-y) $(net-y)
export KBUILD_LDS := arch/$(SRCARCH)/kernel/vmlinux.lds
export LDFLAGS_vmlinux
+# used by scripts/pacmage/Makefile
+export KBUILD_ALLDIRS := $(sort $(filter-out arch/%,$(vmlinux-alldirs)) arch Documentation include samples scripts tools virt)
vmlinux-deps := $(KBUILD_LDS) $(KBUILD_VMLINUX_INIT) $(KBUILD_VMLINUX_MAIN)
@@ -790,7 +794,7 @@
$(vmlinux-dirs): prepare scripts
$(Q)$(MAKE) $(build)=$@
-# Store (new) KERNELRELASE string in include/config/kernel.release
+# Store (new) KERNELRELEASE string in include/config/kernel.release
include/config/kernel.release: include/config/auto.conf FORCE
$(Q)rm -f $@
$(Q)echo "$(KERNELVERSION)$$($(CONFIG_SHELL) $(srctree)/scripts/setlocalversion $(srctree))" > $@
@@ -1112,6 +1116,7 @@
@echo ' gtags - Generate GNU GLOBAL index'
@echo ' kernelrelease - Output the release version string'
@echo ' kernelversion - Output the version stored in Makefile'
+ @echo ' image_name - Output the image name'
@echo ' headers_install - Install sanitised kernel headers to INSTALL_HDR_PATH'; \
echo ' (default: $(INSTALL_HDR_PATH))'; \
echo ''
@@ -1306,7 +1311,7 @@
endif #ifeq ($(config-targets),1)
endif #ifeq ($(mixed-targets),1)
-PHONY += checkstack kernelrelease kernelversion
+PHONY += checkstack kernelrelease kernelversion image_name
# UML needs a little special treatment here. It wants to use the host
# toolchain, so needs $(SUBARCH) passed to checkstack.pl. Everyone
@@ -1327,14 +1332,17 @@
kernelversion:
@echo $(KERNELVERSION)
+image_name:
+ @echo $(KBUILD_IMAGE)
+
# Clear a bunch of variables before executing the submake
tools/: FORCE
$(Q)mkdir -p $(objtree)/tools
- $(Q)$(MAKE) LDFLAGS= MAKEFLAGS= O=$(objtree) subdir=tools -C $(src)/tools/
+ $(Q)$(MAKE) LDFLAGS= MAKEFLAGS="$(filter --j% -j,$(MAKEFLAGS))" O=$(objtree) subdir=tools -C $(src)/tools/
tools/%: FORCE
$(Q)mkdir -p $(objtree)/tools
- $(Q)$(MAKE) LDFLAGS= MAKEFLAGS= O=$(objtree) subdir=tools -C $(src)/tools/ $*
+ $(Q)$(MAKE) LDFLAGS= MAKEFLAGS="$(filter --j% -j,$(MAKEFLAGS))" O=$(objtree) subdir=tools -C $(src)/tools/ $*
# Single targets
# ---------------------------------------------------------------------------
@@ -1397,7 +1405,7 @@
# Run depmod only if we have System.map and depmod is executable
quiet_cmd_depmod = DEPMOD $(KERNELRELEASE)
cmd_depmod = $(CONFIG_SHELL) $(srctree)/scripts/depmod.sh $(DEPMOD) \
- $(KERNELRELEASE)
+ $(KERNELRELEASE) "$(patsubst y,_,$(CONFIG_HAVE_UNDERSCORE_SYMBOL_PREFIX))"
# Create temporary dir for module support files
# clean it up only when building all modules
diff --git a/REPORTING-BUGS b/REPORTING-BUGS
index 55a6074..0cb8cdf 100644
--- a/REPORTING-BUGS
+++ b/REPORTING-BUGS
@@ -1,39 +1,103 @@
-[Some of this is taken from Frohwalt Egerer's original linux-kernel FAQ]
+Background
+==========
- What follows is a suggested procedure for reporting Linux bugs. You
-aren't obliged to use the bug reporting format, it is provided as a guide
-to the kind of information that can be useful to developers - no more.
+The upstream Linux kernel maintainers only fix bugs for specific kernel
+versions. Those versions include the current "release candidate" (or -rc)
+kernel, any "stable" kernel versions, and any "long term" kernels.
- If the failure includes an "OOPS:" type message in your log or on
-screen please read "Documentation/oops-tracing.txt" before posting your
+Please see https://www.kernel.org/ for a list of supported kernels. Any
+kernel marked with [EOL] is "end of life" and will not have any fixes
+backported to it.
+
+If you've found a bug on a kernel version isn't listed on kernel.org,
+contact your Linux distribution or embedded vendor for support.
+Alternatively, you can attempt to run one of the supported stable or -rc
+kernels, and see if you can reproduce the bug on that. It's preferable
+to reproduce the bug on the latest -rc kernel.
+
+
+How to report Linux kernel bugs
+===============================
+
+
+Identify the problematic subsystem
+----------------------------------
+
+Identifying which part of the Linux kernel might be causing your issue
+increases your chances of getting your bug fixed. Simply posting to the
+generic linux-kernel mailing list (LKML) may cause your bug report to be
+lost in the noise of a mailing list that gets 1000+ emails a day.
+
+Instead, try to figure out which kernel subsystem is causing the issue,
+and email that subsystem's maintainer and mailing list. If the subsystem
+maintainer doesn't answer, then expand your scope to mailing lists like
+LKML.
+
+
+Identify who to notify
+----------------------
+
+Once you know the subsystem that is causing the issue, you should send a
+bug report. Some maintainers prefer bugs to be reported via bugzilla
+(https://bugzilla.kernel.org), while others prefer that bugs be reported
+via the subsystem mailing list.
+
+To find out where to send an emailed bug report, find your subsystem or
+device driver in the MAINTAINERS file. Search in the file for relevant
+entries, and send your bug report to the person(s) listed in the "M:"
+lines, making sure to Cc the mailing list(s) in the "L:" lines. When the
+maintainer replies to you, make sure to 'Reply-all' in order to keep the
+public mailing list(s) in the email thread.
+
+If you know which driver is causing issues, you can pass one of the driver
+files to the get_maintainer.pl script:
+ perl scripts/get_maintainer.pl -f <filename>
+
+If it is a security bug, please copy the Security Contact listed in the
+MAINTAINERS file. They can help coordinate bugfix and disclosure. See
+Documentation/SecurityBugs for more information.
+
+If you can't figure out which subsystem caused the issue, you should file
+a bug in kernel.org bugzilla and send email to
+linux-kernel@vger.kernel.org, referencing the bugzilla URL. (For more
+information on the linux-kernel mailing list see
+http://www.tux.org/lkml/).
+
+
+Tips for reporting bugs
+-----------------------
+
+If you haven't reported a bug before, please read:
+
+http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
+http://www.catb.org/esr/faqs/smart-questions.html
+
+It's REALLY important to report bugs that seem unrelated as separate email
+threads or separate bugzilla entries. If you report several unrelated
+bugs at once, it's difficult for maintainers to tease apart the relevant
+data.
+
+
+Gather information
+------------------
+
+The most important information in a bug report is how to reproduce the
+bug. This includes system information, and (most importantly)
+step-by-step instructions for how a user can trigger the bug.
+
+If the failure includes an "OOPS:", take a picture of the screen, capture
+a netconsole trace, or type the message from your screen into the bug
+report. Please read "Documentation/oops-tracing.txt" before posting your
bug report. This explains what you should do with the "Oops" information
to make it useful to the recipient.
- Send the output to the maintainer of the kernel area that seems to
-be involved with the problem, and cc the relevant mailing list. Don't
-worry too much about getting the wrong person. If you are unsure send it
-to the person responsible for the code relevant to what you were doing.
-If it occurs repeatably try and describe how to recreate it. That is
-worth even more than the oops itself. The list of maintainers and
-mailing lists is in the MAINTAINERS file in this directory. If you
-know the file name that causes the problem you can use the following
-command in this directory to find some of the maintainers of that file:
- perl scripts/get_maintainer.pl -f <filename>
-
- If it is a security bug, please copy the Security Contact listed
-in the MAINTAINERS file. They can help coordinate bugfix and disclosure.
-See Documentation/SecurityBugs for more information.
-
- If you are totally stumped as to whom to send the report, send it to
-linux-kernel@vger.kernel.org. (For more information on the linux-kernel
-mailing list see http://www.tux.org/lkml/).
-
-This is a suggested format for a bug report sent to the Linux kernel mailing
-list. Having a standardized bug report form makes it easier for you not to
+This is a suggested format for a bug report sent via email or bugzilla.
+Having a standardized bug report form makes it easier for you not to
overlook things, and easier for the developers to find the pieces of
-information they're really interested in. Don't feel you have to follow it.
+information they're really interested in. If some information is not
+relevant to your bug, feel free to exclude it.
- First run the ver_linux script included as scripts/ver_linux, which
+First run the ver_linux script included as scripts/ver_linux, which
reports the version of some important subsystems. Run this script with
the command "sh scripts/ver_linux".
@@ -65,4 +129,46 @@
[X.] Other notes, patches, fixes, workarounds:
-Thank you
+Follow up
+=========
+
+Expectations for bug reporters
+------------------------------
+
+Linux kernel maintainers expect bug reporters to be able to follow up on
+bug reports. That may include running new tests, applying patches,
+recompiling your kernel, and/or re-triggering your bug. The most
+frustrating thing for maintainers is for someone to report a bug, and then
+never follow up on a request to try out a fix.
+
+That said, it's still useful for a kernel maintainer to know a bug exists
+on a supported kernel, even if you can't follow up with retests. Follow
+up reports, such as replying to the email thread with "I tried the latest
+kernel and I can't reproduce my bug anymore" are also helpful, because
+maintainers have to assume silence means things are still broken.
+
+Expectations for kernel maintainers
+-----------------------------------
+
+Linux kernel maintainers are busy, overworked human beings. Some times
+they may not be able to address your bug in a day, a week, or two weeks.
+If they don't answer your email, they may be on vacation, or at a Linux
+conference. Check the conference schedule at LWN.net for more info:
+ https://lwn.net/Calendar/
+
+In general, kernel maintainers take 1 to 5 business days to respond to
+bugs. The majority of kernel maintainers are employed to work on the
+kernel, and they may not work on the weekends. Maintainers are scattered
+around the world, and they may not work in your time zone. Unless you
+have a high priority bug, please wait at least a week after the first bug
+report before sending the maintainer a reminder email.
+
+The exceptions to this rule are regressions, kernel crashes, security holes,
+or userspace breakage caused by new kernel behavior. Those bugs should be
+addressed by the maintainers ASAP. If you suspect a maintainer is not
+responding to these types of bugs in a timely manner (especially during a
+merge window), escalate the bug to LKML and Linus Torvalds.
+
+Thank you!
+
+[Some of this is taken from Frohwalt Egerer's original linux-kernel FAQ]
diff --git a/arch/Kconfig b/arch/Kconfig
index 7f8f281..8d2ae24 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -76,6 +76,15 @@
depends on KPROBES && HAVE_OPTPROBES
depends on !PREEMPT
+config KPROBES_ON_FTRACE
+ def_bool y
+ depends on KPROBES && HAVE_KPROBES_ON_FTRACE
+ depends on DYNAMIC_FTRACE_WITH_REGS
+ help
+ If function tracer is enabled and the arch supports full
+ passing of pt_regs to function tracing, then kprobes can
+ optimize on top of function tracing.
+
config UPROBES
bool "Transparent user-space probes (EXPERIMENTAL)"
depends on UPROBE_EVENT && PERF_EVENTS
@@ -94,6 +103,22 @@
If in doubt, say "N".
+config HAVE_64BIT_ALIGNED_ACCESS
+ def_bool 64BIT && !HAVE_EFFICIENT_UNALIGNED_ACCESS
+ help
+ Some architectures require 64 bit accesses to be 64 bit
+ aligned, which also requires structs containing 64 bit values
+ to be 64 bit aligned too. This includes some 32 bit
+ architectures which can do 64 bit accesses, as well as 64 bit
+ architectures without unaligned access.
+
+ This symbol should be selected by an architecture if 64 bit
+ accesses are required to be 64 bit aligned in this way even
+ though it is not a 64 bit architecture.
+
+ See Documentation/unaligned-memory-access.txt for more
+ information on the topic of unaligned memory accesses.
+
config HAVE_EFFICIENT_UNALIGNED_ACCESS
bool
help
@@ -132,9 +157,6 @@
instructions should set this. And it shouldn't hurt to set it
on architectures that don't have such instructions.
-config HAVE_SYSCALL_WRAPPERS
- bool
-
config KRETPROBES
def_bool y
depends on KPROBES && HAVE_KRETPROBES
@@ -158,6 +180,9 @@
config HAVE_OPTPROBES
bool
+config HAVE_KPROBES_ON_FTRACE
+ bool
+
config HAVE_NMI_WATCHDOG
bool
#
@@ -188,6 +213,9 @@
config GENERIC_SMP_IDLE_THREAD
bool
+config GENERIC_IDLE_POLL_SETUP
+ bool
+
# Select if arch init_task initializer is different to init/init_task.c
config ARCH_INIT_TASK
bool
@@ -337,6 +365,9 @@
config HAVE_ARCH_TRANSPARENT_HUGEPAGE
bool
+config HAVE_ARCH_SOFT_DIRTY
+ bool
+
config HAVE_MOD_ARCH_SPECIFIC
bool
help
@@ -356,8 +387,11 @@
Modules only use ELF REL relocations. Modules with ELF RELA
relocations will give an error.
-config GENERIC_SIGALTSTACK
+config HAVE_UNDERSCORE_SYMBOL_PREFIX
bool
+ help
+ Some architectures generate an _ in front of C symbols; things like
+ module loading and assembly files need to know about this.
#
# ABI hall of shame
@@ -373,4 +407,30 @@
help
Architecture has the first two arguments of clone(2) swapped.
+config ODD_RT_SIGACTION
+ bool
+ help
+ Architecture has unusual rt_sigaction(2) arguments
+
+config OLD_SIGSUSPEND
+ bool
+ help
+ Architecture has old sigsuspend(2) syscall, of one-argument variety
+
+config OLD_SIGSUSPEND3
+ bool
+ help
+ Even weirder antique ABI - three-argument sigsuspend(2)
+
+config OLD_SIGACTION
+ bool
+ help
+ Architecture has old sigaction(2) syscall. Nope, not the same
+ as OLD_SIGSUSPEND | OLD_SIGSUSPEND3 - alpha has sigsuspend(2),
+ but fairly different variant of sigaction(2), thanks to OSF/1
+ compatibility...
+
+config COMPAT_OLD_SIGACTION
+ bool
+
source "kernel/gcov/Kconfig"
diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig
index 9d5904c..837a1f2 100644
--- a/arch/alpha/Kconfig
+++ b/arch/alpha/Kconfig
@@ -4,12 +4,11 @@
select HAVE_AOUT
select HAVE_IDE
select HAVE_OPROFILE
- select HAVE_SYSCALL_WRAPPERS
- select HAVE_IRQ_WORK
select HAVE_PCSPKR_PLATFORM
select HAVE_PERF_EVENTS
select HAVE_DMA_ATTRS
select HAVE_GENERIC_HARDIRQS
+ select VIRT_TO_BUS
select GENERIC_IRQ_PROBE
select AUTO_IRQ_AFFINITY if SMP
select GENERIC_IRQ_SHOW
@@ -22,7 +21,8 @@
select GENERIC_STRNLEN_USER
select HAVE_MOD_ARCH_SPECIFIC
select MODULES_USE_ELF_RELA
- select GENERIC_SIGALTSTACK
+ select ODD_RT_SIGACTION
+ select OLD_SIGSUSPEND
help
The Alpha is a 64-bit general-purpose processor designed and
marketed by the Digital Equipment Corporation of blessed memory,
@@ -55,9 +55,6 @@
bool
default y
-config GENERIC_GPIO
- bool
-
config ZONE_DMA
bool
default y
@@ -125,6 +122,7 @@
config ALPHA_GENERIC
bool "Generic"
+ depends on TTY
help
A generic kernel will run on all supported Alpha hardware.
@@ -491,6 +489,7 @@
config ALPHA_SRM
bool "Use SRM as bootloader" if ALPHA_CABRIOLET || ALPHA_AVANTI_CH || ALPHA_EB64P || ALPHA_PC164 || ALPHA_TAKARA || ALPHA_EB164 || ALPHA_ALCOR || ALPHA_MIATA || ALPHA_LX164 || ALPHA_SX164 || ALPHA_NAUTILUS || ALPHA_NONAME
+ depends on TTY
default y if ALPHA_JENSEN || ALPHA_MIKASA || ALPHA_SABLE || ALPHA_LYNX || ALPHA_NORITAKE || ALPHA_DP264 || ALPHA_RAWHIDE || ALPHA_EIGER || ALPHA_WILDFIRE || ALPHA_TITAN || ALPHA_SHARK || ALPHA_MARVEL
---help---
There are two different types of booting firmware on Alphas: SRM,
@@ -556,8 +555,7 @@
with working support have a maximum of 4 CPUs.
config ARCH_DISCONTIGMEM_ENABLE
- bool "Discontiguous Memory Support (EXPERIMENTAL)"
- depends on EXPERIMENTAL
+ bool "Discontiguous Memory Support"
help
Say Y to support efficient handling of discontiguous physical memory,
for architectures which are either NUMA (Non-Uniform Memory Access)
diff --git a/arch/alpha/Makefile b/arch/alpha/Makefile
index 4759fe7..2cc3cc5 100644
--- a/arch/alpha/Makefile
+++ b/arch/alpha/Makefile
@@ -12,7 +12,7 @@
LDFLAGS_vmlinux := -static -N #-relax
CHECKFLAGS += -D__alpha__ -m64
-cflags-y := -pipe -mno-fp-regs -ffixed-8 -msmall-data
+cflags-y := -pipe -mno-fp-regs -ffixed-8
cflags-y += $(call cc-option, -fno-jump-tables)
cpuflags-$(CONFIG_ALPHA_EV4) := -mcpu=ev4
diff --git a/arch/alpha/boot/head.S b/arch/alpha/boot/head.S
index b06812b..8efb266 100644
--- a/arch/alpha/boot/head.S
+++ b/arch/alpha/boot/head.S
@@ -4,6 +4,7 @@
* initial bootloader stuff..
*/
+#include <asm/pal.h>
.set noreorder
.globl __start
diff --git a/arch/alpha/include/asm/floppy.h b/arch/alpha/include/asm/floppy.h
index 46cefbd..bae97eb 100644
--- a/arch/alpha/include/asm/floppy.h
+++ b/arch/alpha/include/asm/floppy.h
@@ -26,7 +26,7 @@
#define fd_disable_irq() disable_irq(FLOPPY_IRQ)
#define fd_cacheflush(addr,size) /* nothing */
#define fd_request_irq() request_irq(FLOPPY_IRQ, floppy_interrupt,\
- IRQF_DISABLED, "floppy", NULL)
+ 0, "floppy", NULL)
#define fd_free_irq() free_irq(FLOPPY_IRQ, NULL)
#ifdef CONFIG_PCI
diff --git a/arch/alpha/include/asm/linkage.h b/arch/alpha/include/asm/linkage.h
index 291c2d0..7cfd06e 100644
--- a/arch/alpha/include/asm/linkage.h
+++ b/arch/alpha/include/asm/linkage.h
@@ -1,6 +1,8 @@
#ifndef __ASM_LINKAGE_H
#define __ASM_LINKAGE_H
-/* Nothing to see here... */
+#define cond_syscall(x) asm(".weak\t" #x "\n" #x " = sys_ni_syscall")
+#define SYSCALL_ALIAS(alias, name) \
+ asm ( #alias " = " #name "\n\t.globl " #alias)
#endif
diff --git a/arch/alpha/include/asm/mmzone.h b/arch/alpha/include/asm/mmzone.h
index c5b5d6b..14ce27b 100644
--- a/arch/alpha/include/asm/mmzone.h
+++ b/arch/alpha/include/asm/mmzone.h
@@ -71,8 +71,6 @@
#define virt_to_page(kaddr) pfn_to_page(__pa(kaddr) >> PAGE_SHIFT)
-#define VALID_PAGE(page) (((page) - mem_map) < max_mapnr)
-
#define pmd_page(pmd) (pfn_to_page(pmd_val(pmd) >> 32))
#define pgd_page(pgd) (pfn_to_page(pgd_val(pgd) >> 32))
#define pte_pfn(pte) (pte_val(pte) >> 32)
diff --git a/arch/alpha/include/asm/parport.h b/arch/alpha/include/asm/parport.h
index c5ee7cb..6abd0af1 100644
--- a/arch/alpha/include/asm/parport.h
+++ b/arch/alpha/include/asm/parport.h
@@ -9,8 +9,8 @@
#ifndef _ASM_AXP_PARPORT_H
#define _ASM_AXP_PARPORT_H 1
-static int __devinit parport_pc_find_isa_ports (int autoirq, int autodma);
-static int __devinit parport_pc_find_nonpci_ports (int autoirq, int autodma)
+static int parport_pc_find_isa_ports (int autoirq, int autodma);
+static int parport_pc_find_nonpci_ports (int autoirq, int autodma)
{
return parport_pc_find_isa_ports (autoirq, autodma);
}
diff --git a/arch/alpha/include/asm/pgtable.h b/arch/alpha/include/asm/pgtable.h
index 81a4342..d8f9b7e 100644
--- a/arch/alpha/include/asm/pgtable.h
+++ b/arch/alpha/include/asm/pgtable.h
@@ -354,9 +354,6 @@
#define kern_addr_valid(addr) (1)
#endif
-#define io_remap_pfn_range(vma, start, pfn, size, prot) \
- remap_pfn_range(vma, start, pfn, size, prot)
-
#define pte_ERROR(e) \
printk("%s:%d: bad pte %016lx.\n", __FILE__, __LINE__, pte_val(e))
#define pmd_ERROR(e) \
diff --git a/arch/alpha/include/asm/signal.h b/arch/alpha/include/asm/signal.h
index 8a1ac28..963f049 100644
--- a/arch/alpha/include/asm/signal.h
+++ b/arch/alpha/include/asm/signal.h
@@ -22,15 +22,6 @@
int sa_flags;
};
-struct sigaction {
- __sighandler_t sa_handler;
- unsigned long sa_flags;
- sigset_t sa_mask; /* mask last for extensibility */
-};
-
-struct k_sigaction {
- struct sigaction sa;
- __sigrestore_t ka_restorer;
-};
+#define __ARCH_HAS_KA_RESTORER
#include <asm/sigcontext.h>
#endif
diff --git a/arch/alpha/include/asm/thread_info.h b/arch/alpha/include/asm/thread_info.h
index 1f8c729..52cd2a4 100644
--- a/arch/alpha/include/asm/thread_info.h
+++ b/arch/alpha/include/asm/thread_info.h
@@ -95,8 +95,6 @@
#define TS_POLLING 0x0010 /* idle task polling need_resched,
skip sending interrupt */
-#define tsk_is_polling(t) (task_thread_info(t)->status & TS_POLLING)
-
#ifndef __ASSEMBLY__
#define HAVE_SET_RESTORE_SIGMASK 1
static inline void set_restore_sigmask(void)
diff --git a/arch/alpha/include/asm/unistd.h b/arch/alpha/include/asm/unistd.h
index b3396ee..43baee1 100644
--- a/arch/alpha/include/asm/unistd.h
+++ b/arch/alpha/include/asm/unistd.h
@@ -14,21 +14,8 @@
#define __ARCH_WANT_SYS_OLD_GETRLIMIT
#define __ARCH_WANT_SYS_OLDUMOUNT
#define __ARCH_WANT_SYS_SIGPENDING
-#define __ARCH_WANT_SYS_RT_SIGSUSPEND
#define __ARCH_WANT_SYS_FORK
#define __ARCH_WANT_SYS_VFORK
#define __ARCH_WANT_SYS_CLONE
-/* "Conditional" syscalls. What we want is
-
- __attribute__((weak,alias("sys_ni_syscall")))
-
- but that raises the problem of what type to give the symbol. If we use
- a prototype, it'll conflict with the definition given in this file and
- others. If we use __typeof, we discover that not all symbols actually
- have declarations. If we use no prototype, then we get warnings from
- -Wstrict-prototypes. Ho hum. */
-
-#define cond_syscall(x) asm(".weak\t" #x "\n" #x " = sys_ni_syscall")
-
#endif /* _ALPHA_UNISTD_H */
diff --git a/arch/alpha/include/uapi/asm/fcntl.h b/arch/alpha/include/uapi/asm/fcntl.h
index 6d9e805..09f49a6 100644
--- a/arch/alpha/include/uapi/asm/fcntl.h
+++ b/arch/alpha/include/uapi/asm/fcntl.h
@@ -32,6 +32,7 @@
#define O_SYNC (__O_SYNC|O_DSYNC)
#define O_PATH 040000000
+#define __O_TMPFILE 0100000000
#define F_GETLK 7
#define F_SETLK 8
diff --git a/arch/alpha/include/uapi/asm/socket.h b/arch/alpha/include/uapi/asm/socket.h
index 097c157..467de01 100644
--- a/arch/alpha/include/uapi/asm/socket.h
+++ b/arch/alpha/include/uapi/asm/socket.h
@@ -19,7 +19,7 @@
#define SO_BROADCAST 0x0020
#define SO_LINGER 0x0080
#define SO_OOBINLINE 0x0100
-/* To add :#define SO_REUSEPORT 0x0200 */
+#define SO_REUSEPORT 0x0200
#define SO_TYPE 0x1008
#define SO_ERROR 0x1007
@@ -77,5 +77,10 @@
/* Instruct lower device to use last 4-bytes of skb data as FCS */
#define SO_NOFCS 43
+#define SO_LOCK_FILTER 44
+
+#define SO_SELECT_ERR_QUEUE 45
+
+#define SO_BUSY_POLL 46
#endif /* _UAPI_ASM_SOCKET_H */
diff --git a/arch/alpha/kernel/console.c b/arch/alpha/kernel/console.c
index da711e3..6a61dee 100644
--- a/arch/alpha/kernel/console.c
+++ b/arch/alpha/kernel/console.c
@@ -61,7 +61,9 @@
/* Set the VGA hose and init the new console. */
pci_vga_hose = hose;
- take_over_console(&vga_con, 0, MAX_NR_CONSOLES-1, 1);
+ console_lock();
+ do_take_over_console(&vga_con, 0, MAX_NR_CONSOLES-1, 1);
+ console_unlock();
}
void __init
diff --git a/arch/alpha/kernel/irq.c b/arch/alpha/kernel/irq.c
index 2872acc..7b2be25 100644
--- a/arch/alpha/kernel/irq.c
+++ b/arch/alpha/kernel/irq.c
@@ -117,13 +117,6 @@
return;
}
- /*
- * From here we must proceed with IPL_MAX. Note that we do not
- * explicitly enable interrupts afterwards - some MILO PALcode
- * (namely LX164 one) seems to have severe problems with RTI
- * at IPL 0.
- */
- local_irq_disable();
irq_enter();
generic_handle_irq_desc(irq, desc);
irq_exit();
diff --git a/arch/alpha/kernel/irq_alpha.c b/arch/alpha/kernel/irq_alpha.c
index 772ddfdb..f433fc1 100644
--- a/arch/alpha/kernel/irq_alpha.c
+++ b/arch/alpha/kernel/irq_alpha.c
@@ -45,6 +45,14 @@
unsigned long la_ptr, struct pt_regs *regs)
{
struct pt_regs *old_regs;
+
+ /*
+ * Disable interrupts during IRQ handling.
+ * Note that there is no matching local_irq_enable() due to
+ * severe problems with RTI at IPL0 and some MILO PALcode
+ * (namely LX164).
+ */
+ local_irq_disable();
switch (type) {
case 0:
#ifdef CONFIG_SMP
@@ -62,7 +70,6 @@
{
long cpu;
- local_irq_disable();
smp_percpu_timer_interrupt(regs);
cpu = smp_processor_id();
if (cpu != boot_cpuid) {
@@ -222,7 +229,6 @@
struct irqaction timer_irqaction = {
.handler = timer_interrupt,
- .flags = IRQF_DISABLED,
.name = "timer",
};
diff --git a/arch/alpha/kernel/osf_sys.c b/arch/alpha/kernel/osf_sys.c
index 14db93e..1402fcc 100644
--- a/arch/alpha/kernel/osf_sys.c
+++ b/arch/alpha/kernel/osf_sys.c
@@ -96,6 +96,7 @@
};
struct osf_dirent_callback {
+ struct dir_context ctx;
struct osf_dirent __user *dirent;
long __user *basep;
unsigned int count;
@@ -146,17 +147,17 @@
{
int error;
struct fd arg = fdget(fd);
- struct osf_dirent_callback buf;
+ struct osf_dirent_callback buf = {
+ .ctx.actor = osf_filldir,
+ .dirent = dirent,
+ .basep = basep,
+ .count = count
+ };
if (!arg.file)
return -EBADF;
- buf.dirent = dirent;
- buf.basep = basep;
- buf.count = count;
- buf.error = 0;
-
- error = vfs_readdir(arg.file, osf_filldir, &buf);
+ error = iterate_dir(arg.file, &buf.ctx);
if (error >= 0)
error = buf.error;
if (count != buf.count)
@@ -1139,6 +1140,7 @@
SYSCALL_DEFINE2(osf_getrusage, int, who, struct rusage32 __user *, ru)
{
struct rusage32 r;
+ cputime_t utime, stime;
if (who != RUSAGE_SELF && who != RUSAGE_CHILDREN)
return -EINVAL;
@@ -1146,8 +1148,9 @@
memset(&r, 0, sizeof(r));
switch (who) {
case RUSAGE_SELF:
- jiffies_to_timeval32(current->utime, &r.ru_utime);
- jiffies_to_timeval32(current->stime, &r.ru_stime);
+ task_cputime(current, &utime, &stime);
+ jiffies_to_timeval32(utime, &r.ru_utime);
+ jiffies_to_timeval32(stime, &r.ru_stime);
r.ru_minflt = current->min_flt;
r.ru_majflt = current->maj_flt;
break;
@@ -1298,17 +1301,15 @@
arch_get_unmapped_area_1(unsigned long addr, unsigned long len,
unsigned long limit)
{
- struct vm_area_struct *vma = find_vma(current->mm, addr);
+ struct vm_unmapped_area_info info;
- while (1) {
- /* At this point: (!vma || addr < vma->vm_end). */
- if (limit - len < addr)
- return -ENOMEM;
- if (!vma || addr + len <= vma->vm_start)
- return addr;
- addr = vma->vm_end;
- vma = vma->vm_next;
- }
+ info.flags = 0;
+ info.length = len;
+ info.low_limit = addr;
+ info.high_limit = limit;
+ info.align_mask = 0;
+ info.align_offset = 0;
+ return vm_unmapped_area(&info);
}
unsigned long
diff --git a/arch/alpha/kernel/pci-sysfs.c b/arch/alpha/kernel/pci-sysfs.c
index b51f7b4..2b183b0 100644
--- a/arch/alpha/kernel/pci-sysfs.c
+++ b/arch/alpha/kernel/pci-sysfs.c
@@ -26,7 +26,6 @@
base = sparse ? hose->sparse_io_base : hose->dense_io_base;
vma->vm_pgoff += base >> PAGE_SHIFT;
- vma->vm_flags |= VM_IO | VM_DONTEXPAND | VM_DONTDUMP;
return io_remap_pfn_range(vma, vma->vm_start, vma->vm_pgoff,
vma->vm_end - vma->vm_start,
diff --git a/arch/alpha/kernel/pci.c b/arch/alpha/kernel/pci.c
index ef757147..edb4e00 100644
--- a/arch/alpha/kernel/pci.c
+++ b/arch/alpha/kernel/pci.c
@@ -59,13 +59,13 @@
* Quirks.
*/
-static void __devinit quirk_isa_bridge(struct pci_dev *dev)
+static void quirk_isa_bridge(struct pci_dev *dev)
{
dev->class = PCI_CLASS_BRIDGE_ISA << 8;
}
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82378, quirk_isa_bridge);
-static void __devinit quirk_cypress(struct pci_dev *dev)
+static void quirk_cypress(struct pci_dev *dev)
{
/* The Notorious Cy82C693 chip. */
@@ -104,7 +104,7 @@
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_CONTAQ, PCI_DEVICE_ID_CONTAQ_82C693, quirk_cypress);
/* Called for each device after PCI setup is done. */
-static void __devinit pcibios_fixup_final(struct pci_dev *dev)
+static void pcibios_fixup_final(struct pci_dev *dev)
{
unsigned int class = dev->class >> 8;
@@ -198,8 +198,7 @@
#ifdef ALPHA_RESTORE_SRM_SETUP
static struct pdev_srm_saved_conf *srm_saved_configs;
-void __devinit
-pdev_save_srm_config(struct pci_dev *dev)
+void pdev_save_srm_config(struct pci_dev *dev)
{
struct pdev_srm_saved_conf *tmp;
static int printed = 0;
@@ -241,8 +240,7 @@
}
#endif
-void __devinit
-pcibios_fixup_bus(struct pci_bus *bus)
+void pcibios_fixup_bus(struct pci_bus *bus)
{
struct pci_dev *dev = bus->self;
diff --git a/arch/alpha/kernel/process.c b/arch/alpha/kernel/process.c
index b5d0d09..f2360a7 100644
--- a/arch/alpha/kernel/process.c
+++ b/arch/alpha/kernel/process.c
@@ -46,25 +46,6 @@
void (*pm_power_off)(void) = machine_power_off;
EXPORT_SYMBOL(pm_power_off);
-void
-cpu_idle(void)
-{
- current_thread_info()->status |= TS_POLLING;
-
- while (1) {
- /* FIXME -- EV6 and LCA45 know how to power down
- the CPU. */
-
- rcu_idle_enter();
- while (!need_resched())
- cpu_relax();
-
- rcu_idle_exit();
- schedule_preempt_disabled();
- }
-}
-
-
struct halt_info {
int mode;
char *restart_cmd;
@@ -136,7 +117,9 @@
if (in_interrupt())
irq_exit();
/* This has the effect of resetting the VGA video origin. */
- take_over_console(&dummy_con, 0, MAX_NR_CONSOLES-1, 1);
+ console_lock();
+ do_take_over_console(&dummy_con, 0, MAX_NR_CONSOLES-1, 1);
+ console_unlock();
#endif
pci_restore_srm_config();
set_hae(srm_hae);
@@ -194,6 +177,7 @@
void
show_regs(struct pt_regs *regs)
{
+ show_regs_print_info(KERN_DEFAULT);
dik_show_regs(regs, NULL);
}
@@ -250,7 +234,6 @@
struct pt_regs *childregs = task_pt_regs(p);
struct pt_regs *regs = current_pt_regs();
struct switch_stack *childstack, *stack;
- unsigned long settls;
childstack = ((struct switch_stack *) childregs) - 1;
childti->pcb.ksp = (unsigned long) childstack;
diff --git a/arch/alpha/kernel/signal.c b/arch/alpha/kernel/signal.c
index 02d02c0..6cec288 100644
--- a/arch/alpha/kernel/signal.c
+++ b/arch/alpha/kernel/signal.c
@@ -113,16 +113,6 @@
}
/*
- * Atomically swap in the new signal mask, and wait for a signal.
- */
-SYSCALL_DEFINE1(sigsuspend, old_sigset_t, mask)
-{
- sigset_t blocked;
- siginitset(&blocked, mask);
- return sigsuspend(&blocked);
-}
-
-/*
* Do a signal return; undo the signal stack.
*/
@@ -282,12 +272,9 @@
*/
static inline void __user *
-get_sigframe(struct k_sigaction *ka, unsigned long sp, size_t frame_size)
+get_sigframe(struct ksignal *ksig, unsigned long sp, size_t frame_size)
{
- if ((ka->sa.sa_flags & SA_ONSTACK) != 0 && ! sas_ss_flags(sp))
- sp = current->sas_ss_sp + current->sas_ss_size;
-
- return (void __user *)((sp - frame_size) & -32ul);
+ return (void __user *)((sigsp(sp, ksig) - frame_size) & -32ul);
}
static long
@@ -348,14 +335,13 @@
}
static int
-setup_frame(int sig, struct k_sigaction *ka, sigset_t *set,
- struct pt_regs *regs)
+setup_frame(struct ksignal *ksig, sigset_t *set, struct pt_regs *regs)
{
unsigned long oldsp, r26, err = 0;
struct sigframe __user *frame;
oldsp = rdusp();
- frame = get_sigframe(ka, oldsp, sizeof(*frame));
+ frame = get_sigframe(ksig, oldsp, sizeof(*frame));
if (!access_ok(VERIFY_WRITE, frame, sizeof(*frame)))
return -EFAULT;
@@ -365,9 +351,8 @@
/* Set up to return from userspace. If provided, use a stub
already in userspace. */
- if (ka->ka_restorer) {
- r26 = (unsigned long) ka->ka_restorer;
- } else {
+ r26 = (unsigned long) ksig->ka.ka_restorer;
+ if (!r26) {
err |= __put_user(INSN_MOV_R30_R16, frame->retcode+0);
err |= __put_user(INSN_LDI_R0+__NR_sigreturn, frame->retcode+1);
err |= __put_user(INSN_CALLSYS, frame->retcode+2);
@@ -381,8 +366,8 @@
/* "Return" to the handler */
regs->r26 = r26;
- regs->r27 = regs->pc = (unsigned long) ka->sa.sa_handler;
- regs->r16 = sig; /* a0: signal number */
+ regs->r27 = regs->pc = (unsigned long) ksig->ka.sa.sa_handler;
+ regs->r16 = ksig->sig; /* a0: signal number */
regs->r17 = 0; /* a1: exception code */
regs->r18 = (unsigned long) &frame->sc; /* a2: sigcontext pointer */
wrusp((unsigned long) frame);
@@ -395,18 +380,17 @@
}
static int
-setup_rt_frame(int sig, struct k_sigaction *ka, siginfo_t *info,
- sigset_t *set, struct pt_regs *regs)
+setup_rt_frame(struct ksignal *ksig, sigset_t *set, struct pt_regs *regs)
{
unsigned long oldsp, r26, err = 0;
struct rt_sigframe __user *frame;
oldsp = rdusp();
- frame = get_sigframe(ka, oldsp, sizeof(*frame));
+ frame = get_sigframe(ksig, oldsp, sizeof(*frame));
if (!access_ok(VERIFY_WRITE, frame, sizeof(*frame)))
return -EFAULT;
- err |= copy_siginfo_to_user(&frame->info, info);
+ err |= copy_siginfo_to_user(&frame->info, &ksig->info);
/* Create the ucontext. */
err |= __put_user(0, &frame->uc.uc_flags);
@@ -421,9 +405,8 @@
/* Set up to return from userspace. If provided, use a stub
already in userspace. */
- if (ka->ka_restorer) {
- r26 = (unsigned long) ka->ka_restorer;
- } else {
+ r26 = (unsigned long) ksig->ka.ka_restorer;
+ if (!r26) {
err |= __put_user(INSN_MOV_R30_R16, frame->retcode+0);
err |= __put_user(INSN_LDI_R0+__NR_rt_sigreturn,
frame->retcode+1);
@@ -437,8 +420,8 @@
/* "Return" to the handler */
regs->r26 = r26;
- regs->r27 = regs->pc = (unsigned long) ka->sa.sa_handler;
- regs->r16 = sig; /* a0: signal number */
+ regs->r27 = regs->pc = (unsigned long) ksig->ka.sa.sa_handler;
+ regs->r16 = ksig->sig; /* a0: signal number */
regs->r17 = (unsigned long) &frame->info; /* a1: siginfo pointer */
regs->r18 = (unsigned long) &frame->uc; /* a2: ucontext pointer */
wrusp((unsigned long) frame);
@@ -456,22 +439,17 @@
* OK, we're invoking a handler.
*/
static inline void
-handle_signal(int sig, struct k_sigaction *ka, siginfo_t *info,
- struct pt_regs * regs)
+handle_signal(struct ksignal *ksig, struct pt_regs *regs)
{
sigset_t *oldset = sigmask_to_save();
int ret;
- if (ka->sa.sa_flags & SA_SIGINFO)
- ret = setup_rt_frame(sig, ka, info, oldset, regs);
+ if (ksig->ka.sa.sa_flags & SA_SIGINFO)
+ ret = setup_rt_frame(ksig, oldset, regs);
else
- ret = setup_frame(sig, ka, oldset, regs);
+ ret = setup_frame(ksig, oldset, regs);
- if (ret) {
- force_sigsegv(sig, current);
- return;
- }
- signal_delivered(sig, info, ka, regs, 0);
+ signal_setup_done(ret, ksig, 0);
}
static inline void
@@ -514,47 +492,38 @@
static void
do_signal(struct pt_regs *regs, unsigned long r0, unsigned long r19)
{
- siginfo_t info;
- int signr;
unsigned long single_stepping = ptrace_cancel_bpt(current);
- struct k_sigaction ka;
+ struct ksignal ksig;
/* This lets the debugger run, ... */
- signr = get_signal_to_deliver(&info, &ka, regs, NULL);
-
- /* ... so re-check the single stepping. */
- single_stepping |= ptrace_cancel_bpt(current);
-
- if (signr > 0) {
+ if (get_signal(&ksig)) {
+ /* ... so re-check the single stepping. */
+ single_stepping |= ptrace_cancel_bpt(current);
/* Whee! Actually deliver the signal. */
if (r0)
- syscall_restart(r0, r19, regs, &ka);
- handle_signal(signr, &ka, &info, regs);
- if (single_stepping)
- ptrace_set_bpt(current); /* re-set bpt */
- return;
- }
-
- if (r0) {
- switch (regs->r0) {
- case ERESTARTNOHAND:
- case ERESTARTSYS:
- case ERESTARTNOINTR:
- /* Reset v0 and a3 and replay syscall. */
- regs->r0 = r0;
- regs->r19 = r19;
- regs->pc -= 4;
- break;
- case ERESTART_RESTARTBLOCK:
- /* Force v0 to the restart syscall and reply. */
- regs->r0 = __NR_restart_syscall;
- regs->pc -= 4;
- break;
+ syscall_restart(r0, r19, regs, &ksig.ka);
+ handle_signal(&ksig, regs);
+ } else {
+ single_stepping |= ptrace_cancel_bpt(current);
+ if (r0) {
+ switch (regs->r0) {
+ case ERESTARTNOHAND:
+ case ERESTARTSYS:
+ case ERESTARTNOINTR:
+ /* Reset v0 and a3 and replay syscall. */
+ regs->r0 = r0;
+ regs->r19 = r19;
+ regs->pc -= 4;
+ break;
+ case ERESTART_RESTARTBLOCK:
+ /* Set v0 to the restart_syscall and replay */
+ regs->r0 = __NR_restart_syscall;
+ regs->pc -= 4;
+ break;
+ }
}
+ restore_saved_sigmask();
}
-
- /* If there's no signal to deliver, we just restore the saved mask. */
- restore_saved_sigmask();
if (single_stepping)
ptrace_set_bpt(current); /* re-set breakpoint */
}
diff --git a/arch/alpha/kernel/smp.c b/arch/alpha/kernel/smp.c
index a41ad90..7b60834 100644
--- a/arch/alpha/kernel/smp.c
+++ b/arch/alpha/kernel/smp.c
@@ -68,7 +68,7 @@
};
/* Set to a secondary's cpuid when it comes online. */
-static int smp_secondary_alive __devinitdata = 0;
+static int smp_secondary_alive = 0;
int smp_num_probed; /* Internal processor count */
int smp_num_cpus = 1; /* Number that came online. */
@@ -167,12 +167,11 @@
cpuid, current, current->active_mm));
preempt_disable();
- /* Do nothing. */
- cpu_idle();
+ cpu_startup_entry(CPUHP_ONLINE);
}
/* Wait until hwrpb->txrdy is clear for cpu. Return -1 on timeout. */
-static int __devinit
+static int
wait_for_txrdy (unsigned long cpumask)
{
unsigned long timeout;
@@ -468,7 +467,7 @@
smp_num_cpus = smp_num_probed;
}
-void __devinit
+void
smp_prepare_boot_cpu(void)
{
}
diff --git a/arch/alpha/kernel/srm_env.c b/arch/alpha/kernel/srm_env.c
index b9fc6c3..ffe996a 100644
--- a/arch/alpha/kernel/srm_env.c
+++ b/arch/alpha/kernel/srm_env.c
@@ -51,13 +51,11 @@
typedef struct _srm_env {
char *name;
unsigned long id;
- struct proc_dir_entry *proc_entry;
} srm_env_t;
static struct proc_dir_entry *base_dir;
static struct proc_dir_entry *named_dir;
static struct proc_dir_entry *numbered_dir;
-static char number[256][4];
static srm_env_t srm_named_entries[] = {
{ "auto_action", ENV_AUTO_ACTION },
@@ -77,21 +75,18 @@
{ "tty_dev", ENV_TTY_DEV },
{ NULL, 0 },
};
-static srm_env_t srm_numbered_entries[256];
-
static int srm_env_proc_show(struct seq_file *m, void *v)
{
unsigned long ret;
- srm_env_t *entry;
+ unsigned long id = (unsigned long)m->private;
char *page;
- entry = m->private;
page = (char *)__get_free_page(GFP_USER);
if (!page)
return -ENOMEM;
- ret = callback_getenv(entry->id, page, PAGE_SIZE);
+ ret = callback_getenv(id, page, PAGE_SIZE);
if ((ret >> 61) == 0) {
seq_write(m, page, ret);
@@ -104,14 +99,14 @@
static int srm_env_proc_open(struct inode *inode, struct file *file)
{
- return single_open(file, srm_env_proc_show, PDE(inode)->data);
+ return single_open(file, srm_env_proc_show, PDE_DATA(inode));
}
static ssize_t srm_env_proc_write(struct file *file, const char __user *buffer,
size_t count, loff_t *pos)
{
int res;
- srm_env_t *entry = PDE(file->f_path.dentry->d_inode)->data;
+ unsigned long id = (unsigned long)PDE_DATA(file_inode(file));
char *buf = (char *) __get_free_page(GFP_USER);
unsigned long ret1, ret2;
@@ -127,7 +122,7 @@
goto out;
buf[count] = '\0';
- ret1 = callback_setenv(entry->id, buf, count);
+ ret1 = callback_setenv(id, buf, count);
if ((ret1 >> 61) == 0) {
do
ret2 = callback_save_env();
@@ -149,52 +144,6 @@
.write = srm_env_proc_write,
};
-static void
-srm_env_cleanup(void)
-{
- srm_env_t *entry;
- unsigned long var_num;
-
- if (base_dir) {
- /*
- * Remove named entries
- */
- if (named_dir) {
- entry = srm_named_entries;
- while (entry->name != NULL && entry->id != 0) {
- if (entry->proc_entry) {
- remove_proc_entry(entry->name,
- named_dir);
- entry->proc_entry = NULL;
- }
- entry++;
- }
- remove_proc_entry(NAMED_DIR, base_dir);
- }
-
- /*
- * Remove numbered entries
- */
- if (numbered_dir) {
- for (var_num = 0; var_num <= 255; var_num++) {
- entry = &srm_numbered_entries[var_num];
-
- if (entry->proc_entry) {
- remove_proc_entry(entry->name,
- numbered_dir);
- entry->proc_entry = NULL;
- entry->name = NULL;
- }
- }
- remove_proc_entry(NUMBERED_DIR, base_dir);
- }
-
- remove_proc_entry(BASE_DIR, NULL);
- }
-
- return;
-}
-
static int __init
srm_env_init(void)
{
@@ -213,19 +162,13 @@
}
/*
- * Init numbers
- */
- for (var_num = 0; var_num <= 255; var_num++)
- sprintf(number[var_num], "%ld", var_num);
-
- /*
* Create base directory
*/
base_dir = proc_mkdir(BASE_DIR, NULL);
if (!base_dir) {
printk(KERN_ERR "Couldn't create base dir /proc/%s\n",
BASE_DIR);
- goto cleanup;
+ return -ENOMEM;
}
/*
@@ -254,9 +197,8 @@
*/
entry = srm_named_entries;
while (entry->name && entry->id) {
- entry->proc_entry = proc_create_data(entry->name, 0644, named_dir,
- &srm_env_proc_fops, entry);
- if (!entry->proc_entry)
+ if (!proc_create_data(entry->name, 0644, named_dir,
+ &srm_env_proc_fops, (void *)entry->id))
goto cleanup;
entry++;
}
@@ -265,15 +207,11 @@
* Create all numbered nodes
*/
for (var_num = 0; var_num <= 255; var_num++) {
- entry = &srm_numbered_entries[var_num];
- entry->name = number[var_num];
-
- entry->proc_entry = proc_create_data(entry->name, 0644, numbered_dir,
- &srm_env_proc_fops, entry);
- if (!entry->proc_entry)
+ char name[4];
+ sprintf(name, "%ld", var_num);
+ if (!proc_create_data(name, 0644, numbered_dir,
+ &srm_env_proc_fops, (void *)var_num))
goto cleanup;
-
- entry->id = var_num;
}
printk(KERN_INFO "%s: version %s loaded successfully\n", NAME,
@@ -282,18 +220,15 @@
return 0;
cleanup:
- srm_env_cleanup();
-
+ remove_proc_subtree(BASE_DIR, NULL);
return -ENOMEM;
}
static void __exit
srm_env_exit(void)
{
- srm_env_cleanup();
+ remove_proc_subtree(BASE_DIR, NULL);
printk(KERN_INFO "%s: unloaded successfully\n", NAME);
-
- return;
}
module_init(srm_env_init);
diff --git a/arch/alpha/kernel/srmcons.c b/arch/alpha/kernel/srmcons.c
index 59b7bba..6f01d9a 100644
--- a/arch/alpha/kernel/srmcons.c
+++ b/arch/alpha/kernel/srmcons.c
@@ -44,7 +44,7 @@
/* called with callback_lock held */
static int
-srmcons_do_receive_chars(struct tty_struct *tty)
+srmcons_do_receive_chars(struct tty_port *port)
{
srmcons_result result;
int count = 0, loops = 0;
@@ -52,13 +52,13 @@
do {
result.as_long = callback_getc(0);
if (result.bits.status < 2) {
- tty_insert_flip_char(tty, (char)result.bits.c, 0);
+ tty_insert_flip_char(port, (char)result.bits.c, 0);
count++;
}
} while((result.bits.status & 1) && (++loops < 10));
if (count)
- tty_schedule_flip(tty);
+ tty_schedule_flip(port);
return count;
}
@@ -73,7 +73,7 @@
local_irq_save(flags);
if (spin_trylock(&srmcons_callback_lock)) {
- if (!srmcons_do_receive_chars(port->tty))
+ if (!srmcons_do_receive_chars(port))
incr = 100;
spin_unlock(&srmcons_callback_lock);
}
@@ -88,7 +88,7 @@
/* called with callback_lock held */
static int
-srmcons_do_write(struct tty_struct *tty, const char *buf, int count)
+srmcons_do_write(struct tty_port *port, const char *buf, int count)
{
static char str_cr[1] = "\r";
long c, remaining = count;
@@ -113,10 +113,10 @@
cur += result.bits.c;
/*
- * Check for pending input iff a tty was provided
+ * Check for pending input iff a tty port was provided
*/
- if (tty)
- srmcons_do_receive_chars(tty);
+ if (port)
+ srmcons_do_receive_chars(port);
}
while (need_cr) {
@@ -135,7 +135,7 @@
unsigned long flags;
spin_lock_irqsave(&srmcons_callback_lock, flags);
- srmcons_do_write(tty, (const char *) buf, count);
+ srmcons_do_write(tty->port, (const char *) buf, count);
spin_unlock_irqrestore(&srmcons_callback_lock, flags);
return count;
diff --git a/arch/alpha/kernel/sys_nautilus.c b/arch/alpha/kernel/sys_nautilus.c
index 4d4c046..837c0fa 100644
--- a/arch/alpha/kernel/sys_nautilus.c
+++ b/arch/alpha/kernel/sys_nautilus.c
@@ -185,9 +185,12 @@
mb();
}
-extern void free_reserved_mem(void *, void *);
extern void pcibios_claim_one_bus(struct pci_bus *);
+static struct resource irongate_io = {
+ .name = "Irongate PCI IO",
+ .flags = IORESOURCE_IO,
+};
static struct resource irongate_mem = {
.name = "Irongate PCI MEM",
.flags = IORESOURCE_MEM,
@@ -209,6 +212,7 @@
irongate = pci_get_bus_and_slot(0, 0);
bus->self = irongate;
+ bus->resource[0] = &irongate_io;
bus->resource[1] = &irongate_mem;
pci_bus_size_bridges(bus);
@@ -234,8 +238,8 @@
if (pci_mem < memtop)
memtop = pci_mem;
if (memtop > alpha_mv.min_mem_address) {
- free_reserved_mem(__va(alpha_mv.min_mem_address),
- __va(memtop));
+ free_reserved_area(__va(alpha_mv.min_mem_address),
+ __va(memtop), -1, NULL);
printk("nautilus_init_pci: %ldk freed\n",
(memtop - alpha_mv.min_mem_address) >> 10);
}
diff --git a/arch/alpha/kernel/sys_titan.c b/arch/alpha/kernel/sys_titan.c
index 2533db2..a53cf03 100644
--- a/arch/alpha/kernel/sys_titan.c
+++ b/arch/alpha/kernel/sys_titan.c
@@ -280,15 +280,15 @@
* all reported to the kernel as machine checks, so the handler
* is a nop so it can be called to count the individual events.
*/
- titan_request_irq(63+16, titan_intr_nop, IRQF_DISABLED,
+ titan_request_irq(63+16, titan_intr_nop, 0,
"CChip Error", NULL);
- titan_request_irq(62+16, titan_intr_nop, IRQF_DISABLED,
+ titan_request_irq(62+16, titan_intr_nop, 0,
"PChip 0 H_Error", NULL);
- titan_request_irq(61+16, titan_intr_nop, IRQF_DISABLED,
+ titan_request_irq(61+16, titan_intr_nop, 0,
"PChip 1 H_Error", NULL);
- titan_request_irq(60+16, titan_intr_nop, IRQF_DISABLED,
+ titan_request_irq(60+16, titan_intr_nop, 0,
"PChip 0 C_Error", NULL);
- titan_request_irq(59+16, titan_intr_nop, IRQF_DISABLED,
+ titan_request_irq(59+16, titan_intr_nop, 0,
"PChip 1 C_Error", NULL);
/*
@@ -303,7 +303,7 @@
}
-static int __devinit
+static int
titan_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
{
u8 intline;
@@ -348,9 +348,9 @@
* Hook a couple of extra err interrupts that the
* common titan code won't.
*/
- titan_request_irq(53+16, titan_intr_nop, IRQF_DISABLED,
+ titan_request_irq(53+16, titan_intr_nop, 0,
"NMI", NULL);
- titan_request_irq(50+16, titan_intr_nop, IRQF_DISABLED,
+ titan_request_irq(50+16, titan_intr_nop, 0,
"Temperature Warning", NULL);
/*
diff --git a/arch/alpha/kernel/traps.c b/arch/alpha/kernel/traps.c
index 272666d..affccb9 100644
--- a/arch/alpha/kernel/traps.c
+++ b/arch/alpha/kernel/traps.c
@@ -169,13 +169,6 @@
dik_show_trace(sp);
}
-void dump_stack(void)
-{
- show_stack(NULL, NULL);
-}
-
-EXPORT_SYMBOL(dump_stack);
-
void
die_if_kernel(char * str, struct pt_regs *regs, long err, unsigned long *r9_15)
{
@@ -186,7 +179,7 @@
#endif
printk("%s(%d): %s %ld\n", current->comm, task_pid_nr(current), str, err);
dik_show_regs(regs, r9_15);
- add_taint(TAINT_DIE);
+ add_taint(TAINT_DIE, LOCKDEP_NOW_UNRELIABLE);
dik_show_trace((unsigned long *)(regs+1));
dik_show_code((unsigned int *)regs->pc);
diff --git a/arch/alpha/mm/init.c b/arch/alpha/mm/init.c
index 1ad6ca7..a1bea91 100644
--- a/arch/alpha/mm/init.c
+++ b/arch/alpha/mm/init.c
@@ -31,6 +31,7 @@
#include <asm/console.h>
#include <asm/tlb.h>
#include <asm/setup.h>
+#include <asm/sections.h>
extern void die_if_kernel(char *,struct pt_regs *,long);
@@ -275,75 +276,25 @@
}
#endif
-#ifndef CONFIG_DISCONTIGMEM
-static void __init
-printk_memory_info(void)
-{
- unsigned long codesize, reservedpages, datasize, initsize, tmp;
- extern int page_is_ram(unsigned long) __init;
- extern char _text, _etext, _data, _edata;
- extern char __init_begin, __init_end;
-
- /* printk all informations */
- reservedpages = 0;
- for (tmp = 0; tmp < max_low_pfn; tmp++)
- /*
- * Only count reserved RAM pages
- */
- if (page_is_ram(tmp) && PageReserved(mem_map+tmp))
- reservedpages++;
-
- codesize = (unsigned long) &_etext - (unsigned long) &_text;
- datasize = (unsigned long) &_edata - (unsigned long) &_data;
- initsize = (unsigned long) &__init_end - (unsigned long) &__init_begin;
-
- printk("Memory: %luk/%luk available (%luk kernel code, %luk reserved, %luk data, %luk init)\n",
- nr_free_pages() << (PAGE_SHIFT-10),
- max_mapnr << (PAGE_SHIFT-10),
- codesize >> 10,
- reservedpages << (PAGE_SHIFT-10),
- datasize >> 10,
- initsize >> 10);
-}
-
void __init
mem_init(void)
{
- max_mapnr = num_physpages = max_low_pfn;
- totalram_pages += free_all_bootmem();
+ set_max_mapnr(max_low_pfn);
high_memory = (void *) __va(max_low_pfn * PAGE_SIZE);
-
- printk_memory_info();
-}
-#endif /* CONFIG_DISCONTIGMEM */
-
-void
-free_reserved_mem(void *start, void *end)
-{
- void *__start = start;
- for (; __start < end; __start += PAGE_SIZE) {
- ClearPageReserved(virt_to_page(__start));
- init_page_count(virt_to_page(__start));
- free_page((long)__start);
- totalram_pages++;
- }
+ free_all_bootmem();
+ mem_init_print_info(NULL);
}
void
free_initmem(void)
{
- extern char __init_begin, __init_end;
-
- free_reserved_mem(&__init_begin, &__init_end);
- printk ("Freeing unused kernel memory: %ldk freed\n",
- (&__init_end - &__init_begin) >> 10);
+ free_initmem_default(-1);
}
#ifdef CONFIG_BLK_DEV_INITRD
void
free_initrd_mem(unsigned long start, unsigned long end)
{
- free_reserved_mem((void *)start, (void *)end);
- printk ("Freeing initrd memory: %ldk freed\n", (end - start) >> 10);
+ free_reserved_area((void *)start, (void *)end, -1, "initrd");
}
#endif
diff --git a/arch/alpha/mm/numa.c b/arch/alpha/mm/numa.c
index 3973ae3..d543d71 100644
--- a/arch/alpha/mm/numa.c
+++ b/arch/alpha/mm/numa.c
@@ -17,6 +17,7 @@
#include <asm/hwrpb.h>
#include <asm/pgalloc.h>
+#include <asm/sections.h>
pg_data_t node_data[MAX_NUMNODES];
EXPORT_SYMBOL(node_data);
@@ -128,8 +129,6 @@
if (node_max_pfn > max_low_pfn)
max_pfn = max_low_pfn = node_max_pfn;
- num_physpages += node_max_pfn - node_min_pfn;
-
#if 0 /* we'll try this one again in a little while */
/* Cute trick to make sure our local node data is on local memory */
node_data[nid] = (pg_data_t *)(__va(node_min_pfn << PAGE_SHIFT));
@@ -320,43 +319,3 @@
/* Initialize the kernel's ZERO_PGE. */
memset((void *)ZERO_PGE, 0, PAGE_SIZE);
}
-
-void __init mem_init(void)
-{
- unsigned long codesize, reservedpages, datasize, initsize, pfn;
- extern int page_is_ram(unsigned long) __init;
- extern char _text, _etext, _data, _edata;
- extern char __init_begin, __init_end;
- unsigned long nid, i;
- high_memory = (void *) __va(max_low_pfn << PAGE_SHIFT);
-
- reservedpages = 0;
- for_each_online_node(nid) {
- /*
- * This will free up the bootmem, ie, slot 0 memory
- */
- totalram_pages += free_all_bootmem_node(NODE_DATA(nid));
-
- pfn = NODE_DATA(nid)->node_start_pfn;
- for (i = 0; i < node_spanned_pages(nid); i++, pfn++)
- if (page_is_ram(pfn) &&
- PageReserved(nid_page_nr(nid, i)))
- reservedpages++;
- }
-
- codesize = (unsigned long) &_etext - (unsigned long) &_text;
- datasize = (unsigned long) &_edata - (unsigned long) &_data;
- initsize = (unsigned long) &__init_end - (unsigned long) &__init_begin;
-
- printk("Memory: %luk/%luk available (%luk kernel code, %luk reserved, "
- "%luk data, %luk init)\n",
- nr_free_pages() << (PAGE_SHIFT-10),
- num_physpages << (PAGE_SHIFT-10),
- codesize >> 10,
- reservedpages << (PAGE_SHIFT-10),
- datasize >> 10,
- initsize >> 10);
-#if 0
- mem_stress();
-#endif
-}
diff --git a/arch/arc/Kbuild b/arch/arc/Kbuild
new file mode 100644
index 0000000..082d329
--- /dev/null
+++ b/arch/arc/Kbuild
@@ -0,0 +1,2 @@
+obj-y += kernel/
+obj-y += mm/
diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
new file mode 100644
index 0000000..68fcbb2
--- /dev/null
+++ b/arch/arc/Kconfig
@@ -0,0 +1,443 @@
+#
+# Copyright (C) 2004, 2007-2010, 2011-2012 Synopsys, Inc. (www.synopsys.com)
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License version 2 as
+# published by the Free Software Foundation.
+#
+
+config ARC
+ def_bool y
+ select CLONE_BACKWARDS
+ # ARC Busybox based initramfs absolutely relies on DEVTMPFS for /dev
+ select DEVTMPFS if !INITRAMFS_SOURCE=""
+ select GENERIC_ATOMIC64
+ select GENERIC_CLOCKEVENTS
+ select GENERIC_FIND_FIRST_BIT
+ # for now, we don't need GENERIC_IRQ_PROBE, CONFIG_GENERIC_IRQ_CHIP
+ select GENERIC_IRQ_SHOW
+ select GENERIC_PENDING_IRQ if SMP
+ select GENERIC_SMP_IDLE_THREAD
+ select HAVE_ARCH_KGDB
+ select HAVE_ARCH_TRACEHOOK
+ select HAVE_GENERIC_HARDIRQS
+ select HAVE_IOREMAP_PROT
+ select HAVE_KPROBES
+ select HAVE_KRETPROBES
+ select HAVE_MEMBLOCK
+ select HAVE_MOD_ARCH_SPECIFIC if ARC_DW2_UNWIND
+ select HAVE_OPROFILE
+ select HAVE_PERF_EVENTS
+ select IRQ_DOMAIN
+ select MODULES_USE_ELF_RELA
+ select NO_BOOTMEM
+ select OF
+ select OF_EARLY_FLATTREE
+ select PERF_USE_VMALLOC
+ select HAVE_DEBUG_STACKOVERFLOW
+
+config SCHED_OMIT_FRAME_POINTER
+ def_bool y
+
+config GENERIC_CSUM
+ def_bool y
+
+config RWSEM_GENERIC_SPINLOCK
+ def_bool y
+
+config ARCH_FLATMEM_ENABLE
+ def_bool y
+
+config MMU
+ def_bool y
+
+config NO_IOPORT
+ def_bool y
+
+config GENERIC_CALIBRATE_DELAY
+ def_bool y
+
+config GENERIC_HWEIGHT
+ def_bool y
+
+config STACKTRACE_SUPPORT
+ def_bool y
+ select STACKTRACE
+
+config HAVE_LATENCYTOP_SUPPORT
+ def_bool y
+
+config NO_DMA
+ def_bool n
+
+source "init/Kconfig"
+source "kernel/Kconfig.freezer"
+
+menu "ARC Architecture Configuration"
+
+menu "ARC Platform/SoC/Board"
+
+source "arch/arc/plat-arcfpga/Kconfig"
+source "arch/arc/plat-tb10x/Kconfig"
+#New platform adds here
+
+endmenu
+
+menu "ARC CPU Configuration"
+
+choice
+ prompt "ARC Core"
+ default ARC_CPU_770
+
+config ARC_CPU_750D
+ bool "ARC750D"
+ help
+ Support for ARC750 core
+
+config ARC_CPU_770
+ bool "ARC770"
+ select ARC_CPU_REL_4_10
+ help
+ Support for ARC770 core introduced with Rel 4.10 (Summer 2011)
+ This core has a bunch of cool new features:
+ -MMU-v3: Variable Page Sz (4k, 8k, 16k), bigger J-TLB (128x4)
+ Shared Address Spaces (for sharing TLB entires in MMU)
+ -Caches: New Prog Model, Region Flush
+ -Insns: endian swap, load-locked/store-conditional, time-stamp-ctr
+
+endchoice
+
+config CPU_BIG_ENDIAN
+ bool "Enable Big Endian Mode"
+ default n
+ help
+ Build kernel for Big Endian Mode of ARC CPU
+
+# If a platform can't work with 0x8000_0000 based dma_addr_t
+config ARC_PLAT_NEEDS_CPU_TO_DMA
+ bool
+
+config SMP
+ bool "Symmetric Multi-Processing (Incomplete)"
+ default n
+ select USE_GENERIC_SMP_HELPERS
+ help
+ This enables support for systems with more than one CPU. If you have
+ a system with only one CPU, like most personal computers, say N. If
+ you have a system with more than one CPU, say Y.
+
+if SMP
+
+config ARC_HAS_COH_CACHES
+ def_bool n
+
+config ARC_HAS_COH_RTSC
+ def_bool n
+
+config ARC_HAS_REENTRANT_IRQ_LV2
+ def_bool n
+
+endif
+
+config NR_CPUS
+ int "Maximum number of CPUs (2-32)"
+ range 2 32
+ depends on SMP
+ default "2"
+
+menuconfig ARC_CACHE
+ bool "Enable Cache Support"
+ default y
+ # if SMP, cache enabled ONLY if ARC implementation has cache coherency
+ depends on !SMP || ARC_HAS_COH_CACHES
+
+if ARC_CACHE
+
+config ARC_CACHE_LINE_SHIFT
+ int "Cache Line Length (as power of 2)"
+ range 5 7
+ default "6"
+ help
+ Starting with ARC700 4.9, Cache line length is configurable,
+ This option specifies "N", with Line-len = 2 power N
+ So line lengths of 32, 64, 128 are specified by 5,6,7, respectively
+ Linux only supports same line lengths for I and D caches.
+
+config ARC_HAS_ICACHE
+ bool "Use Instruction Cache"
+ default y
+
+config ARC_HAS_DCACHE
+ bool "Use Data Cache"
+ default y
+
+config ARC_CACHE_PAGES
+ bool "Per Page Cache Control"
+ default y
+ depends on ARC_HAS_ICACHE || ARC_HAS_DCACHE
+ help
+ This can be used to over-ride the global I/D Cache Enable on a
+ per-page basis (but only for pages accessed via MMU such as
+ Kernel Virtual address or User Virtual Address)
+ TLB entries have a per-page Cache Enable Bit.
+ Note that Global I/D ENABLE + Per Page DISABLE works but corollary
+ Global DISABLE + Per Page ENABLE won't work
+
+config ARC_CACHE_VIPT_ALIASING
+ bool "Support VIPT Aliasing D$"
+ depends on ARC_HAS_DCACHE
+ default n
+
+endif #ARC_CACHE
+
+config ARC_HAS_ICCM
+ bool "Use ICCM"
+ help
+ Single Cycle RAMS to store Fast Path Code
+ default n
+
+config ARC_ICCM_SZ
+ int "ICCM Size in KB"
+ default "64"
+ depends on ARC_HAS_ICCM
+
+config ARC_HAS_DCCM
+ bool "Use DCCM"
+ help
+ Single Cycle RAMS to store Fast Path Data
+ default n
+
+config ARC_DCCM_SZ
+ int "DCCM Size in KB"
+ default "64"
+ depends on ARC_HAS_DCCM
+
+config ARC_DCCM_BASE
+ hex "DCCM map address"
+ default "0xA0000000"
+ depends on ARC_HAS_DCCM
+
+config ARC_HAS_HW_MPY
+ bool "Use Hardware Multiplier (Normal or Faster XMAC)"
+ default y
+ help
+ Influences how gcc generates code for MPY operations.
+ If enabled, MPYxx insns are generated, provided by Standard/XMAC
+ Multipler. Otherwise software multipy lib is used
+
+choice
+ prompt "ARC700 MMU Version"
+ default ARC_MMU_V3 if ARC_CPU_770
+ default ARC_MMU_V2 if ARC_CPU_750D
+
+config ARC_MMU_V1
+ bool "MMU v1"
+ help
+ Orig ARC700 MMU
+
+config ARC_MMU_V2
+ bool "MMU v2"
+ help
+ Fixed the deficiency of v1 - possible thrashing in memcpy sceanrio
+ when 2 D-TLB and 1 I-TLB entries index into same 2way set.
+
+config ARC_MMU_V3
+ bool "MMU v3"
+ depends on ARC_CPU_770
+ help
+ Introduced with ARC700 4.10: New Features
+ Variable Page size (1k-16k), var JTLB size 128 x (2 or 4)
+ Shared Address Spaces (SASID)
+
+endchoice
+
+
+choice
+ prompt "MMU Page Size"
+ default ARC_PAGE_SIZE_8K
+
+config ARC_PAGE_SIZE_8K
+ bool "8KB"
+ help
+ Choose between 8k vs 16k
+
+config ARC_PAGE_SIZE_16K
+ bool "16KB"
+ depends on ARC_MMU_V3
+
+config ARC_PAGE_SIZE_4K
+ bool "4KB"
+ depends on ARC_MMU_V3
+
+endchoice
+
+config ARC_COMPACT_IRQ_LEVELS
+ bool "ARCompact IRQ Priorities: High(2)/Low(1)"
+ default n
+ # Timer HAS to be high priority, for any other high priority config
+ select ARC_IRQ3_LV2
+ # if SMP, LV2 enabled ONLY if ARC implementation has LV2 re-entrancy
+ depends on !SMP || ARC_HAS_REENTRANT_IRQ_LV2
+
+if ARC_COMPACT_IRQ_LEVELS
+
+config ARC_IRQ3_LV2
+ bool
+
+config ARC_IRQ5_LV2
+ bool
+
+config ARC_IRQ6_LV2
+ bool
+
+endif
+
+config ARC_FPU_SAVE_RESTORE
+ bool "Enable FPU state persistence across context switch"
+ default n
+ help
+ Double Precision Floating Point unit had dedictaed regs which
+ need to be saved/restored across context-switch.
+ Note that ARC FPU is overly simplistic, unlike say x86, which has
+ hardware pieces to allow software to conditionally save/restore,
+ based on actual usage of FPU by a task. Thus our implemn does
+ this for all tasks in system.
+
+config ARC_CANT_LLSC
+ def_bool n
+
+menuconfig ARC_CPU_REL_4_10
+ bool "Enable support for Rel 4.10 features"
+ default n
+ help
+ -ARC770 (and dependent features) enabled
+ -ARC750 also shares some of the new features with 770
+
+config ARC_HAS_LLSC
+ bool "Insn: LLOCK/SCOND (efficient atomic ops)"
+ default y
+ depends on ARC_CPU_770 && !ARC_CANT_LLSC
+
+config ARC_HAS_SWAPE
+ bool "Insn: SWAPE (endian-swap)"
+ default y
+ depends on ARC_CPU_REL_4_10
+
+config ARC_HAS_RTSC
+ bool "Insn: RTSC (64-bit r/o cycle counter)"
+ default y
+ depends on ARC_CPU_REL_4_10
+ # if SMP, enable RTSC only if counter is coherent across cores
+ depends on !SMP || ARC_HAS_COH_RTSC
+
+endmenu # "ARC CPU Configuration"
+
+config LINUX_LINK_BASE
+ hex "Linux Link Address"
+ default "0x80000000"
+ help
+ ARC700 divides the 32 bit phy address space into two equal halves
+ -Lower 2G (0 - 0x7FFF_FFFF ) is user virtual, translated by MMU
+ -Upper 2G (0x8000_0000 onwards) is untranslated, for kernel
+ Typically Linux kernel is linked at the start of untransalted addr,
+ hence the default value of 0x8zs.
+ However some customers have peripherals mapped at this addr, so
+ Linux needs to be scooted a bit.
+ If you don't know what the above means, leave this setting alone.
+
+config ARC_CURR_IN_REG
+ bool "Dedicate Register r25 for current_task pointer"
+ default y
+ help
+ This reserved Register R25 to point to Current Task in
+ kernel mode. This saves memory access for each such access
+
+
+config ARC_MISALIGN_ACCESS
+ bool "Emulate unaligned memory access (userspace only)"
+ default N
+ select SYSCTL_ARCH_UNALIGN_NO_WARN
+ select SYSCTL_ARCH_UNALIGN_ALLOW
+ help
+ This enables misaligned 16 & 32 bit memory access from user space.
+ Use ONLY-IF-ABS-NECESSARY as it will be very slow and also can hide
+ potential bugs in code
+
+config HZ
+ int "Timer Frequency"
+ default 100
+
+config ARC_METAWARE_HLINK
+ bool "Support for Metaware debugger assisted Host access"
+ default n
+ help
+ This options allows a Linux userland apps to directly access
+ host file system (open/creat/read/write etc) with help from
+ Metaware Debugger. This can come in handy for Linux-host communication
+ when there is no real usable peripheral such as EMAC.
+
+menuconfig ARC_DBG
+ bool "ARC debugging"
+ default y
+
+config ARC_DW2_UNWIND
+ bool "Enable DWARF specific kernel stack unwind"
+ depends on ARC_DBG
+ default y
+ select KALLSYMS
+ help
+ Compiles the kernel with DWARF unwind information and can be used
+ to get stack backtraces.
+
+ If you say Y here the resulting kernel image will be slightly larger
+ but not slower, and it will give very useful debugging information.
+ If you don't debug the kernel, you can say N, but we may not be able
+ to solve problems without frame unwind information
+
+config ARC_DBG_TLB_PARANOIA
+ bool "Paranoia Checks in Low Level TLB Handlers"
+ depends on ARC_DBG
+ default n
+
+config ARC_DBG_TLB_MISS_COUNT
+ bool "Profile TLB Misses"
+ default n
+ select DEBUG_FS
+ depends on ARC_DBG
+ help
+ Counts number of I and D TLB Misses and exports them via Debugfs
+ The counters can be cleared via Debugfs as well
+
+config CMDLINE_UBOOT
+ bool "Support U-boot kernel command line passing"
+ default n
+ help
+ If you are using U-boot (www.denx.de) and wish to pass the kernel
+ command line from the U-boot environment to the Linux kernel then
+ switch this option on.
+ ARC U-boot will setup the cmdline in RAM/flash and set r2 to point
+ to it. kernel startup code will append this to DeviceTree
+ /bootargs provided cmdline args.
+
+config ARC_BUILTIN_DTB_NAME
+ string "Built in DTB"
+ help
+ Set the name of the DTB to embed in the vmlinux binary
+ Leaving it blank selects the minimal "skeleton" dtb
+
+source "kernel/Kconfig.preempt"
+
+menu "Executable file formats"
+source "fs/Kconfig.binfmt"
+endmenu
+
+endmenu # "ARC Architecture Configuration"
+
+source "mm/Kconfig"
+source "net/Kconfig"
+source "drivers/Kconfig"
+source "fs/Kconfig"
+source "arch/arc/Kconfig.debug"
+source "security/Kconfig"
+source "crypto/Kconfig"
+source "lib/Kconfig"
diff --git a/arch/arc/Kconfig.debug b/arch/arc/Kconfig.debug
new file mode 100644
index 0000000..a7fc0da
--- /dev/null
+++ b/arch/arc/Kconfig.debug
@@ -0,0 +1,27 @@
+menu "Kernel hacking"
+
+source "lib/Kconfig.debug"
+
+config EARLY_PRINTK
+ bool "Early printk" if EMBEDDED
+ default y
+ help
+ Write kernel log output directly into the VGA buffer or to a serial
+ port.
+
+ This is useful for kernel debugging when your machine crashes very
+ early before the console code is initialized. For normal operation
+ it is not recommended because it looks ugly and doesn't cooperate
+ with klogd/syslogd or the X server. You should normally N here,
+ unless you want to debug such a crash.
+
+config 16KSTACKS
+ bool "Use 16Kb for kernel stacks instead of 8Kb"
+ help
+ If you say Y here the kernel will use a 16Kb stacksize for the
+ kernel stack attached to each process/thread. The default is 8K.
+ This increases the resident kernel footprint and will cause less
+ threads to run on the system and also increase the pressure
+ on the VM subsystem for higher order allocations.
+
+endmenu
diff --git a/arch/arc/Makefile b/arch/arc/Makefile
new file mode 100644
index 0000000..8c0b1aa
--- /dev/null
+++ b/arch/arc/Makefile
@@ -0,0 +1,139 @@
+#
+# Copyright (C) 2004, 2007-2010, 2011-2012 Synopsys, Inc. (www.synopsys.com)
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License version 2 as
+# published by the Free Software Foundation.
+#
+
+UTS_MACHINE := arc
+
+ifeq ($(CROSS_COMPILE),)
+CROSS_COMPILE := arc-linux-uclibc-
+endif
+
+KBUILD_DEFCONFIG := fpga_defconfig
+
+cflags-y += -mA7 -fno-common -pipe -fno-builtin -D__linux__
+
+ifdef CONFIG_ARC_CURR_IN_REG
+# For a global register defintion, make sure it gets passed to every file
+# We had a customer reported bug where some code built in kernel was NOT using
+# any kernel headers, and missing the r25 global register
+# Can't do unconditionally because of recursive include issues
+# due to <linux/thread_info.h>
+LINUXINCLUDE += -include ${src}/arch/arc/include/asm/current.h
+endif
+
+upto_gcc42 := $(call cc-ifversion, -le, 0402, y)
+upto_gcc44 := $(call cc-ifversion, -le, 0404, y)
+atleast_gcc44 := $(call cc-ifversion, -ge, 0404, y)
+atleast_gcc48 := $(call cc-ifversion, -ge, 0408, y)
+
+cflags-$(atleast_gcc44) += -fsection-anchors
+
+cflags-$(CONFIG_ARC_HAS_LLSC) += -mlock
+cflags-$(CONFIG_ARC_HAS_SWAPE) += -mswape
+cflags-$(CONFIG_ARC_HAS_RTSC) += -mrtsc
+cflags-$(CONFIG_ARC_DW2_UNWIND) += -fasynchronous-unwind-tables
+
+# By default gcc 4.8 generates dwarf4 which kernel unwinder can't grok
+ifeq ($(atleast_gcc48),y)
+cflags-$(CONFIG_ARC_DW2_UNWIND) += -gdwarf-2
+endif
+
+ifndef CONFIG_CC_OPTIMIZE_FOR_SIZE
+# Generic build system uses -O2, we want -O3
+cflags-y += -O3
+endif
+
+# small data is default for elf32 tool-chain. If not usable, disable it
+# This also allows repurposing GP as scratch reg to gcc reg allocator
+disable_small_data := y
+cflags-$(disable_small_data) += -mno-sdata -fcall-used-gp
+
+cflags-$(CONFIG_CPU_BIG_ENDIAN) += -mbig-endian
+ldflags-$(CONFIG_CPU_BIG_ENDIAN) += -EB
+
+# STAR 9000518362: (fixed with binutils shipping with gcc 4.8)
+# arc-linux-uclibc-ld (buildroot) or arceb-elf32-ld (EZChip) don't accept
+# --build-id w/o "-marclinux". Default arc-elf32-ld is OK
+ldflags-$(upto_gcc44) += -marclinux
+
+ARC_LIBGCC := -mA7
+cflags-$(CONFIG_ARC_HAS_HW_MPY) += -multcost=16
+
+ifndef CONFIG_ARC_HAS_HW_MPY
+ cflags-y += -mno-mpy
+
+# newlib for ARC700 assumes MPY to be always present, which is generally true
+# However, if someone really doesn't want MPY, we need to use the 600 ver
+# which coupled with -mno-mpy will use mpy emulation
+# With gcc 4.4.7, -mno-mpy is enough to make any other related adjustments,
+# e.g. increased cost of MPY. With gcc 4.2.1 this had to be explicitly hinted
+
+ ifeq ($(upto_gcc42),y)
+ ARC_LIBGCC := -marc600
+ cflags-y += -multcost=30
+ endif
+endif
+
+LIBGCC := $(shell $(CC) $(ARC_LIBGCC) $(cflags-y) --print-libgcc-file-name)
+
+# Modules with short calls might break for calls into builtin-kernel
+KBUILD_CFLAGS_MODULE += -mlong-calls
+
+# Finally dump eveything into kernel build system
+KBUILD_CFLAGS += $(cflags-y)
+KBUILD_AFLAGS += $(KBUILD_CFLAGS)
+LDFLAGS += $(ldflags-y)
+
+head-y := arch/arc/kernel/head.o
+
+# See arch/arc/Kbuild for content of core part of the kernel
+core-y += arch/arc/
+
+# w/o this dtb won't embed into kernel binary
+core-y += arch/arc/boot/dts/
+
+core-$(CONFIG_ARC_PLAT_FPGA_LEGACY) += arch/arc/plat-arcfpga/
+core-$(CONFIG_ARC_PLAT_TB10X) += arch/arc/plat-tb10x/
+
+drivers-$(CONFIG_OPROFILE) += arch/arc/oprofile/
+
+libs-y += arch/arc/lib/ $(LIBGCC)
+
+boot := arch/arc/boot
+
+#default target for make without any arguements.
+KBUILD_IMAGE := bootpImage
+
+all: $(KBUILD_IMAGE)
+bootpImage: vmlinux
+
+boot_targets += uImage uImage.bin uImage.gz
+
+$(boot_targets): vmlinux
+ $(Q)$(MAKE) $(build)=$(boot) $(boot)/$@
+
+%.dtb %.dtb.S %.dtb.o: scripts
+ $(Q)$(MAKE) $(build)=$(boot)/dts $(boot)/dts/$@
+
+dtbs: scripts
+ $(Q)$(MAKE) $(build)=$(boot)/dts dtbs
+
+archclean:
+ $(Q)$(MAKE) $(clean)=$(boot)
+
+# Hacks to enable final link due to absence of link-time branch relexation
+# and gcc choosing optimal(shorter) branches at -O3
+#
+# vineetg Feb 2010: -mlong-calls switched off for overall kernel build
+# However lib/decompress_inflate.o (.init.text) calls
+# zlib_inflate_workspacesize (.text) causing relocation errors.
+# Thus forcing all exten calls in this file to be long calls
+export CFLAGS_decompress_inflate.o = -mmedium-calls
+export CFLAGS_initramfs.o = -mmedium-calls
+ifdef CONFIG_SMP
+export CFLAGS_core.o = -mmedium-calls
+endif
diff --git a/arch/arc/boot/Makefile b/arch/arc/boot/Makefile
new file mode 100644
index 0000000..e597cb34
--- /dev/null
+++ b/arch/arc/boot/Makefile
@@ -0,0 +1,35 @@
+targets := vmlinux.bin vmlinux.bin.gz uImage
+
+# uImage build relies on mkimage being availble on your host for ARC target
+# You will need to build u-boot for ARC, rename mkimage to arc-elf32-mkimage
+# and make sure it's reacable from your PATH
+
+OBJCOPYFLAGS= -O binary -R .note -R .note.gnu.build-id -R .comment -S
+
+LINUX_START_TEXT = $$(readelf -h vmlinux | \
+ grep "Entry point address" | grep -o 0x.*)
+
+UIMAGE_LOADADDR = $(CONFIG_LINUX_LINK_BASE)
+UIMAGE_ENTRYADDR = $(LINUX_START_TEXT)
+
+suffix-y := bin
+suffix-$(CONFIG_KERNEL_GZIP) := gz
+
+targets += uImage uImage.bin uImage.gz
+extra-y += vmlinux.bin vmlinux.bin.gz
+
+$(obj)/vmlinux.bin: vmlinux FORCE
+ $(call if_changed,objcopy)
+
+$(obj)/vmlinux.bin.gz: $(obj)/vmlinux.bin FORCE
+ $(call if_changed,gzip)
+
+$(obj)/uImage.bin: $(obj)/vmlinux.bin FORCE
+ $(call if_changed,uimage,none)
+
+$(obj)/uImage.gz: $(obj)/vmlinux.bin.gz FORCE
+ $(call if_changed,uimage,gzip)
+
+$(obj)/uImage: $(obj)/uImage.$(suffix-y)
+ @ln -sf $(notdir $<) $@
+ @echo ' Image $@ is ready'
diff --git a/arch/arc/boot/dts/Makefile b/arch/arc/boot/dts/Makefile
new file mode 100644
index 0000000..faf240e
--- /dev/null
+++ b/arch/arc/boot/dts/Makefile
@@ -0,0 +1,15 @@
+# Built-in dtb
+builtindtb-y := angel4
+
+ifneq ($(CONFIG_ARC_BUILTIN_DTB_NAME),"")
+ builtindtb-y := $(patsubst "%",%,$(CONFIG_ARC_BUILTIN_DTB_NAME))
+endif
+
+obj-y += $(builtindtb-y).dtb.o
+targets += $(builtindtb-y).dtb
+
+.SECONDARY: $(obj)/$(builtindtb-y).dtb.S
+
+dtbs: $(addprefix $(obj)/, $(builtindtb-y).dtb)
+
+clean-files := *.dtb *.dtb.S
diff --git a/arch/arc/boot/dts/abilis_tb100.dtsi b/arch/arc/boot/dts/abilis_tb100.dtsi
new file mode 100644
index 0000000..d9f8249
--- /dev/null
+++ b/arch/arc/boot/dts/abilis_tb100.dtsi
@@ -0,0 +1,336 @@
+/*
+ * Abilis Systems TB100 SOC device tree
+ *
+ * Copyright (C) Abilis Systems 2013
+ *
+ * Author: Christian Ruppert <christian.ruppert@abilis.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+/include/ "abilis_tb10x.dtsi"
+
+
+/ {
+ clock-frequency = <500000000>; /* 500 MHZ */
+
+ soc100 {
+ bus-frequency = <166666666>;
+
+ pll0: oscillator {
+ clock-frequency = <1000000000>;
+ };
+ cpu_clk: clkdiv_cpu {
+ clock-mult = <1>;
+ clock-div = <2>;
+ };
+ ahb_clk: clkdiv_ahb {
+ clock-mult = <1>;
+ clock-div = <6>;
+ };
+
+ iomux: iomux@FF10601c {
+ /* Port 1 */
+ pctl_tsin_s0: pctl-tsin-s0 { /* Serial TS-in 0 */
+ pingrp = "mis0_pins";
+ };
+ pctl_tsin_s1: pctl-tsin-s1 { /* Serial TS-in 1 */
+ pingrp = "mis1_pins";
+ };
+ pctl_gpio_a: pctl-gpio-a { /* GPIO bank A */
+ pingrp = "gpioa_pins";
+ };
+ pctl_tsin_p1: pctl-tsin-p1 { /* Parallel TS-in 1 */
+ pingrp = "mip1_pins";
+ };
+ /* Port 2 */
+ pctl_tsin_s2: pctl-tsin-s2 { /* Serial TS-in 2 */
+ pingrp = "mis2_pins";
+ };
+ pctl_tsin_s3: pctl-tsin-s3 { /* Serial TS-in 3 */
+ pingrp = "mis3_pins";
+ };
+ pctl_gpio_c: pctl-gpio-c { /* GPIO bank C */
+ pingrp = "gpioc_pins";
+ };
+ pctl_tsin_p3: pctl-tsin-p3 { /* Parallel TS-in 3 */
+ pingrp = "mip3_pins";
+ };
+ /* Port 3 */
+ pctl_tsin_s4: pctl-tsin-s4 { /* Serial TS-in 4 */
+ pingrp = "mis4_pins";
+ };
+ pctl_tsin_s5: pctl-tsin-s5 { /* Serial TS-in 5 */
+ pingrp = "mis5_pins";
+ };
+ pctl_gpio_e: pctl-gpio-e { /* GPIO bank E */
+ pingrp = "gpioe_pins";
+ };
+ pctl_tsin_p5: pctl-tsin-p5 { /* Parallel TS-in 5 */
+ pingrp = "mip5_pins";
+ };
+ /* Port 4 */
+ pctl_tsin_s6: pctl-tsin-s6 { /* Serial TS-in 6 */
+ pingrp = "mis6_pins";
+ };
+ pctl_tsin_s7: pctl-tsin-s7 { /* Serial TS-in 7 */
+ pingrp = "mis7_pins";
+ };
+ pctl_gpio_g: pctl-gpio-g { /* GPIO bank G */
+ pingrp = "gpiog_pins";
+ };
+ pctl_tsin_p7: pctl-tsin-p7 { /* Parallel TS-in 7 */
+ pingrp = "mip7_pins";
+ };
+ /* Port 5 */
+ pctl_gpio_j: pctl-gpio-j { /* GPIO bank J */
+ pingrp = "gpioj_pins";
+ };
+ pctl_gpio_k: pctl-gpio-k { /* GPIO bank K */
+ pingrp = "gpiok_pins";
+ };
+ pctl_ciplus: pctl-ciplus { /* CI+ interface */
+ pingrp = "ciplus_pins";
+ };
+ pctl_mcard: pctl-mcard { /* M-Card interface */
+ pingrp = "mcard_pins";
+ };
+ /* Port 6 */
+ pctl_tsout_p: pctl-tsout-p { /* Parallel TS-out */
+ pingrp = "mop_pins";
+ };
+ pctl_tsout_s0: pctl-tsout-s0 { /* Serial TS-out 0 */
+ pingrp = "mos0_pins";
+ };
+ pctl_tsout_s1: pctl-tsout-s1 { /* Serial TS-out 1 */
+ pingrp = "mos1_pins";
+ };
+ pctl_tsout_s2: pctl-tsout-s2 { /* Serial TS-out 2 */
+ pingrp = "mos2_pins";
+ };
+ pctl_tsout_s3: pctl-tsout-s3 { /* Serial TS-out 3 */
+ pingrp = "mos3_pins";
+ };
+ /* Port 7 */
+ pctl_uart0: pctl-uart0 { /* UART 0 */
+ pingrp = "uart0_pins";
+ };
+ pctl_uart1: pctl-uart1 { /* UART 1 */
+ pingrp = "uart1_pins";
+ };
+ pctl_gpio_l: pctl-gpio-l { /* GPIO bank L */
+ pingrp = "gpiol_pins";
+ };
+ pctl_gpio_m: pctl-gpio-m { /* GPIO bank M */
+ pingrp = "gpiom_pins";
+ };
+ /* Port 8 */
+ pctl_spi3: pctl-spi3 {
+ pingrp = "spi3_pins";
+ };
+ /* Port 9 */
+ pctl_spi1: pctl-spi1 {
+ pingrp = "spi1_pins";
+ };
+ pctl_gpio_n: pctl-gpio-n {
+ pingrp = "gpion_pins";
+ };
+ /* Unmuxed GPIOs */
+ pctl_gpio_b: pctl-gpio-b {
+ pingrp = "gpiob_pins";
+ };
+ pctl_gpio_d: pctl-gpio-d {
+ pingrp = "gpiod_pins";
+ };
+ pctl_gpio_f: pctl-gpio-f {
+ pingrp = "gpiof_pins";
+ };
+ pctl_gpio_h: pctl-gpio-h {
+ pingrp = "gpioh_pins";
+ };
+ pctl_gpio_i: pctl-gpio-i {
+ pingrp = "gpioi_pins";
+ };
+ };
+
+ gpioa: gpio@FF140000 {
+ compatible = "abilis,tb10x-gpio";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&tb10x_ictl>;
+ interrupts = <27 2>;
+ reg = <0xFF140000 0x1000>;
+ gpio-controller;
+ #gpio-cells = <1>;
+ gpio-base = <0>;
+ gpio-pins = <&pctl_gpio_a>;
+ };
+ gpiob: gpio@FF141000 {
+ compatible = "abilis,tb10x-gpio";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&tb10x_ictl>;
+ interrupts = <27 2>;
+ reg = <0xFF141000 0x1000>;
+ gpio-controller;
+ #gpio-cells = <1>;
+ gpio-base = <3>;
+ gpio-pins = <&pctl_gpio_b>;
+ };
+ gpioc: gpio@FF142000 {
+ compatible = "abilis,tb10x-gpio";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&tb10x_ictl>;
+ interrupts = <27 2>;
+ reg = <0xFF142000 0x1000>;
+ gpio-controller;
+ #gpio-cells = <1>;
+ gpio-base = <5>;
+ gpio-pins = <&pctl_gpio_c>;
+ };
+ gpiod: gpio@FF143000 {
+ compatible = "abilis,tb10x-gpio";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&tb10x_ictl>;
+ interrupts = <27 2>;
+ reg = <0xFF143000 0x1000>;
+ gpio-controller;
+ #gpio-cells = <1>;
+ gpio-base = <8>;
+ gpio-pins = <&pctl_gpio_d>;
+ };
+ gpioe: gpio@FF144000 {
+ compatible = "abilis,tb10x-gpio";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&tb10x_ictl>;
+ interrupts = <27 2>;
+ reg = <0xFF144000 0x1000>;
+ gpio-controller;
+ #gpio-cells = <1>;
+ gpio-base = <10>;
+ gpio-pins = <&pctl_gpio_e>;
+ };
+ gpiof: gpio@FF145000 {
+ compatible = "abilis,tb10x-gpio";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&tb10x_ictl>;
+ interrupts = <27 2>;
+ reg = <0xFF145000 0x1000>;
+ gpio-controller;
+ #gpio-cells = <1>;
+ gpio-base = <13>;
+ gpio-pins = <&pctl_gpio_f>;
+ };
+ gpiog: gpio@FF146000 {
+ compatible = "abilis,tb10x-gpio";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&tb10x_ictl>;
+ interrupts = <27 2>;
+ reg = <0xFF146000 0x1000>;
+ gpio-controller;
+ #gpio-cells = <1>;
+ gpio-base = <15>;
+ gpio-pins = <&pctl_gpio_g>;
+ };
+ gpioh: gpio@FF147000 {
+ compatible = "abilis,tb10x-gpio";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&tb10x_ictl>;
+ interrupts = <27 2>;
+ reg = <0xFF147000 0x1000>;
+ gpio-controller;
+ #gpio-cells = <1>;
+ gpio-base = <18>;
+ gpio-pins = <&pctl_gpio_h>;
+ };
+ gpioi: gpio@FF148000 {
+ compatible = "abilis,tb10x-gpio";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&tb10x_ictl>;
+ interrupts = <27 2>;
+ reg = <0xFF148000 0x1000>;
+ gpio-controller;
+ #gpio-cells = <1>;
+ gpio-base = <20>;
+ gpio-pins = <&pctl_gpio_i>;
+ };
+ gpioj: gpio@FF149000 {
+ compatible = "abilis,tb10x-gpio";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&tb10x_ictl>;
+ interrupts = <27 2>;
+ reg = <0xFF149000 0x1000>;
+ gpio-controller;
+ #gpio-cells = <1>;
+ gpio-base = <32>;
+ gpio-pins = <&pctl_gpio_j>;
+ };
+ gpiok: gpio@FF14a000 {
+ compatible = "abilis,tb10x-gpio";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&tb10x_ictl>;
+ interrupts = <27 2>;
+ reg = <0xFF14A000 0x1000>;
+ gpio-controller;
+ #gpio-cells = <1>;
+ gpio-base = <64>;
+ gpio-pins = <&pctl_gpio_k>;
+ };
+ gpiol: gpio@FF14b000 {
+ compatible = "abilis,tb10x-gpio";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&tb10x_ictl>;
+ interrupts = <27 2>;
+ reg = <0xFF14B000 0x1000>;
+ gpio-controller;
+ #gpio-cells = <1>;
+ gpio-base = <86>;
+ gpio-pins = <&pctl_gpio_l>;
+ };
+ gpiom: gpio@FF14c000 {
+ compatible = "abilis,tb10x-gpio";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&tb10x_ictl>;
+ interrupts = <27 2>;
+ reg = <0xFF14C000 0x1000>;
+ gpio-controller;
+ #gpio-cells = <1>;
+ gpio-base = <90>;
+ gpio-pins = <&pctl_gpio_m>;
+ };
+ gpion: gpio@FF14d000 {
+ compatible = "abilis,tb10x-gpio";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&tb10x_ictl>;
+ interrupts = <27 2>;
+ reg = <0xFF14D000 0x1000>;
+ gpio-controller;
+ #gpio-cells = <1>;
+ gpio-base = <94>;
+ gpio-pins = <&pctl_gpio_n>;
+ };
+ };
+};
diff --git a/arch/arc/boot/dts/abilis_tb100_dvk.dts b/arch/arc/boot/dts/abilis_tb100_dvk.dts
new file mode 100644
index 0000000..ebc313a
--- /dev/null
+++ b/arch/arc/boot/dts/abilis_tb100_dvk.dts
@@ -0,0 +1,127 @@
+/*
+ * Abilis Systems TB100 Development Kit PCB device tree
+ *
+ * Copyright (C) Abilis Systems 2013
+ *
+ * Author: Christian Ruppert <christian.ruppert@abilis.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+/dts-v1/;
+
+/include/ "abilis_tb100.dtsi"
+
+/ {
+ chosen {
+ bootargs = "earlycon=uart8250,mmio32,0xff100000,9600n8 console=ttyS0,9600n8";
+ };
+
+ aliases { };
+
+ memory {
+ device_type = "memory";
+ reg = <0x80000000 0x08000000>; /* 128M */
+ };
+
+ soc100 {
+ uart@FF100000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pctl_uart0>;
+ };
+ ethernet@FE100000 {
+ phy-mode = "rgmii";
+ };
+
+ i2c0: i2c@FF120000 {
+ i2c-sda-hold-time-ns = <432>;
+ };
+ i2c1: i2c@FF121000 {
+ i2c-sda-hold-time-ns = <432>;
+ };
+ i2c2: i2c@FF122000 {
+ i2c-sda-hold-time-ns = <432>;
+ };
+ i2c3: i2c@FF123000 {
+ i2c-sda-hold-time-ns = <432>;
+ };
+ i2c4: i2c@FF124000 {
+ i2c-sda-hold-time-ns = <432>;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ power {
+ label = "Power";
+ gpios = <&gpioi 0>;
+ linux,default-trigger = "default-on";
+ };
+ heartbeat {
+ label = "Heartbeat";
+ gpios = <&gpioi 1>;
+ linux,default-trigger = "heartbeat";
+ };
+ led2 {
+ label = "LED2";
+ gpios = <&gpioi 2>;
+ default-state = "off";
+ };
+ led3 {
+ label = "LED3";
+ gpios = <&gpioi 3>;
+ default-state = "off";
+ };
+ led4 {
+ label = "LED4";
+ gpios = <&gpioi 4>;
+ default-state = "off";
+ };
+ led5 {
+ label = "LED5";
+ gpios = <&gpioi 5>;
+ default-state = "off";
+ };
+ led6 {
+ label = "LED6";
+ gpios = <&gpioi 6>;
+ default-state = "off";
+ };
+ led7 {
+ label = "LED7";
+ gpios = <&gpioi 7>;
+ default-state = "off";
+ };
+ led8 {
+ label = "LED8";
+ gpios = <&gpioi 8>;
+ default-state = "off";
+ };
+ led9 {
+ label = "LED9";
+ gpios = <&gpioi 9>;
+ default-state = "off";
+ };
+ led10 {
+ label = "LED10";
+ gpios = <&gpioi 10>;
+ default-state = "off";
+ };
+ led11 {
+ label = "LED11";
+ gpios = <&gpioi 11>;
+ default-state = "off";
+ };
+ };
+ };
+};
diff --git a/arch/arc/boot/dts/abilis_tb101.dtsi b/arch/arc/boot/dts/abilis_tb101.dtsi
new file mode 100644
index 0000000..da8ca79
--- /dev/null
+++ b/arch/arc/boot/dts/abilis_tb101.dtsi
@@ -0,0 +1,345 @@
+/*
+ * Abilis Systems TB101 SOC device tree
+ *
+ * Copyright (C) Abilis Systems 2013
+ *
+ * Author: Christian Ruppert <christian.ruppert@abilis.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+/include/ "abilis_tb10x.dtsi"
+
+
+/ {
+ clock-frequency = <500000000>; /* 500 MHZ */
+
+ soc100 {
+ bus-frequency = <166666666>;
+
+ pll0: oscillator {
+ clock-frequency = <1000000000>;
+ };
+ cpu_clk: clkdiv_cpu {
+ clock-mult = <1>;
+ clock-div = <2>;
+ };
+ ahb_clk: clkdiv_ahb {
+ clock-mult = <1>;
+ clock-div = <6>;
+ };
+
+ iomux: iomux@FF10601c {
+ /* Port 1 */
+ pctl_tsin_s0: pctl-tsin-s0 { /* Serial TS-in 0 */
+ pingrp = "mis0_pins";
+ };
+ pctl_tsin_s1: pctl-tsin-s1 { /* Serial TS-in 1 */
+ pingrp = "mis1_pins";
+ };
+ pctl_gpio_a: pctl-gpio-a { /* GPIO bank A */
+ pingrp = "gpioa_pins";
+ };
+ pctl_tsin_p1: pctl-tsin-p1 { /* Parallel TS-in 1 */
+ pingrp = "mip1_pins";
+ };
+ /* Port 2 */
+ pctl_tsin_s2: pctl-tsin-s2 { /* Serial TS-in 2 */
+ pingrp = "mis2_pins";
+ };
+ pctl_tsin_s3: pctl-tsin-s3 { /* Serial TS-in 3 */
+ pingrp = "mis3_pins";
+ };
+ pctl_gpio_c: pctl-gpio-c { /* GPIO bank C */
+ pingrp = "gpioc_pins";
+ };
+ pctl_tsin_p3: pctl-tsin-p3 { /* Parallel TS-in 3 */
+ pingrp = "mip3_pins";
+ };
+ /* Port 3 */
+ pctl_tsin_s4: pctl-tsin-s4 { /* Serial TS-in 4 */
+ pingrp = "mis4_pins";
+ };
+ pctl_tsin_s5: pctl-tsin-s5 { /* Serial TS-in 5 */
+ pingrp = "mis5_pins";
+ };
+ pctl_gpio_e: pctl-gpio-e { /* GPIO bank E */
+ pingrp = "gpioe_pins";
+ };
+ pctl_tsin_p5: pctl-tsin-p5 { /* Parallel TS-in 5 */
+ pingrp = "mip5_pins";
+ };
+ /* Port 4 */
+ pctl_tsin_s6: pctl-tsin-s6 { /* Serial TS-in 6 */
+ pingrp = "mis6_pins";
+ };
+ pctl_tsin_s7: pctl-tsin-s7 { /* Serial TS-in 7 */
+ pingrp = "mis7_pins";
+ };
+ pctl_gpio_g: pctl-gpio-g { /* GPIO bank G */
+ pingrp = "gpiog_pins";
+ };
+ pctl_tsin_p7: pctl-tsin-p7 { /* Parallel TS-in 7 */
+ pingrp = "mip7_pins";
+ };
+ /* Port 5 */
+ pctl_gpio_j: pctl-gpio-j { /* GPIO bank J */
+ pingrp = "gpioj_pins";
+ };
+ pctl_gpio_k: pctl-gpio-k { /* GPIO bank K */
+ pingrp = "gpiok_pins";
+ };
+ pctl_ciplus: pctl-ciplus { /* CI+ interface */
+ pingrp = "ciplus_pins";
+ };
+ pctl_mcard: pctl-mcard { /* M-Card interface */
+ pingrp = "mcard_pins";
+ };
+ pctl_stc0: pctl-stc0 { /* Smart card I/F 0 */
+ pingrp = "stc0_pins";
+ };
+ pctl_stc1: pctl-stc1 { /* Smart card I/F 1 */
+ pingrp = "stc1_pins";
+ };
+ /* Port 6 */
+ pctl_tsout_p: pctl-tsout-p { /* Parallel TS-out */
+ pingrp = "mop_pins";
+ };
+ pctl_tsout_s0: pctl-tsout-s0 { /* Serial TS-out 0 */
+ pingrp = "mos0_pins";
+ };
+ pctl_tsout_s1: pctl-tsout-s1 { /* Serial TS-out 1 */
+ pingrp = "mos1_pins";
+ };
+ pctl_tsout_s2: pctl-tsout-s2 { /* Serial TS-out 2 */
+ pingrp = "mos2_pins";
+ };
+ pctl_tsout_s3: pctl-tsout-s3 { /* Serial TS-out 3 */
+ pingrp = "mos3_pins";
+ };
+ /* Port 7 */
+ pctl_uart0: pctl-uart0 { /* UART 0 */
+ pingrp = "uart0_pins";
+ };
+ pctl_uart1: pctl-uart1 { /* UART 1 */
+ pingrp = "uart1_pins";
+ };
+ pctl_gpio_l: pctl-gpio-l { /* GPIO bank L */
+ pingrp = "gpiol_pins";
+ };
+ pctl_gpio_m: pctl-gpio-m { /* GPIO bank M */
+ pingrp = "gpiom_pins";
+ };
+ /* Port 8 */
+ pctl_spi3: pctl-spi3 {
+ pingrp = "spi3_pins";
+ };
+ pctl_jtag: pctl-jtag {
+ pingrp = "jtag_pins";
+ };
+ /* Port 9 */
+ pctl_spi1: pctl-spi1 {
+ pingrp = "spi1_pins";
+ };
+ pctl_gpio_n: pctl-gpio-n {
+ pingrp = "gpion_pins";
+ };
+ /* Unmuxed GPIOs */
+ pctl_gpio_b: pctl-gpio-b {
+ pingrp = "gpiob_pins";
+ };
+ pctl_gpio_d: pctl-gpio-d {
+ pingrp = "gpiod_pins";
+ };
+ pctl_gpio_f: pctl-gpio-f {
+ pingrp = "gpiof_pins";
+ };
+ pctl_gpio_h: pctl-gpio-h {
+ pingrp = "gpioh_pins";
+ };
+ pctl_gpio_i: pctl-gpio-i {
+ pingrp = "gpioi_pins";
+ };
+ };
+
+ gpioa: gpio@FF140000 {
+ compatible = "abilis,tb10x-gpio";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&tb10x_ictl>;
+ interrupts = <27 2>;
+ reg = <0xFF140000 0x1000>;
+ gpio-controller;
+ #gpio-cells = <1>;
+ gpio-base = <0>;
+ gpio-pins = <&pctl_gpio_a>;
+ };
+ gpiob: gpio@FF141000 {
+ compatible = "abilis,tb10x-gpio";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&tb10x_ictl>;
+ interrupts = <27 2>;
+ reg = <0xFF141000 0x1000>;
+ gpio-controller;
+ #gpio-cells = <1>;
+ gpio-base = <3>;
+ gpio-pins = <&pctl_gpio_b>;
+ };
+ gpioc: gpio@FF142000 {
+ compatible = "abilis,tb10x-gpio";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&tb10x_ictl>;
+ interrupts = <27 2>;
+ reg = <0xFF142000 0x1000>;
+ gpio-controller;
+ #gpio-cells = <1>;
+ gpio-base = <5>;
+ gpio-pins = <&pctl_gpio_c>;
+ };
+ gpiod: gpio@FF143000 {
+ compatible = "abilis,tb10x-gpio";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&tb10x_ictl>;
+ interrupts = <27 2>;
+ reg = <0xFF143000 0x1000>;
+ gpio-controller;
+ #gpio-cells = <1>;
+ gpio-base = <8>;
+ gpio-pins = <&pctl_gpio_d>;
+ };
+ gpioe: gpio@FF144000 {
+ compatible = "abilis,tb10x-gpio";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&tb10x_ictl>;
+ interrupts = <27 2>;
+ reg = <0xFF144000 0x1000>;
+ gpio-controller;
+ #gpio-cells = <1>;
+ gpio-base = <10>;
+ gpio-pins = <&pctl_gpio_e>;
+ };
+ gpiof: gpio@FF145000 {
+ compatible = "abilis,tb10x-gpio";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&tb10x_ictl>;
+ interrupts = <27 2>;
+ reg = <0xFF145000 0x1000>;
+ gpio-controller;
+ #gpio-cells = <1>;
+ gpio-base = <13>;
+ gpio-pins = <&pctl_gpio_f>;
+ };
+ gpiog: gpio@FF146000 {
+ compatible = "abilis,tb10x-gpio";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&tb10x_ictl>;
+ interrupts = <27 2>;
+ reg = <0xFF146000 0x1000>;
+ gpio-controller;
+ #gpio-cells = <1>;
+ gpio-base = <15>;
+ gpio-pins = <&pctl_gpio_g>;
+ };
+ gpioh: gpio@FF147000 {
+ compatible = "abilis,tb10x-gpio";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&tb10x_ictl>;
+ interrupts = <27 2>;
+ reg = <0xFF147000 0x1000>;
+ gpio-controller;
+ #gpio-cells = <1>;
+ gpio-base = <18>;
+ gpio-pins = <&pctl_gpio_h>;
+ };
+ gpioi: gpio@FF148000 {
+ compatible = "abilis,tb10x-gpio";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&tb10x_ictl>;
+ interrupts = <27 2>;
+ reg = <0xFF148000 0x1000>;
+ gpio-controller;
+ #gpio-cells = <1>;
+ gpio-base = <20>;
+ gpio-pins = <&pctl_gpio_i>;
+ };
+ gpioj: gpio@FF149000 {
+ compatible = "abilis,tb10x-gpio";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&tb10x_ictl>;
+ interrupts = <27 2>;
+ reg = <0xFF149000 0x1000>;
+ gpio-controller;
+ #gpio-cells = <1>;
+ gpio-base = <32>;
+ gpio-pins = <&pctl_gpio_j>;
+ };
+ gpiok: gpio@FF14a000 {
+ compatible = "abilis,tb10x-gpio";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&tb10x_ictl>;
+ interrupts = <27 2>;
+ reg = <0xFF14A000 0x1000>;
+ gpio-controller;
+ #gpio-cells = <1>;
+ gpio-base = <64>;
+ gpio-pins = <&pctl_gpio_k>;
+ };
+ gpiol: gpio@FF14b000 {
+ compatible = "abilis,tb10x-gpio";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&tb10x_ictl>;
+ interrupts = <27 2>;
+ reg = <0xFF14B000 0x1000>;
+ gpio-controller;
+ #gpio-cells = <1>;
+ gpio-base = <86>;
+ gpio-pins = <&pctl_gpio_l>;
+ };
+ gpiom: gpio@FF14c000 {
+ compatible = "abilis,tb10x-gpio";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&tb10x_ictl>;
+ interrupts = <27 2>;
+ reg = <0xFF14C000 0x1000>;
+ gpio-controller;
+ #gpio-cells = <1>;
+ gpio-base = <90>;
+ gpio-pins = <&pctl_gpio_m>;
+ };
+ gpion: gpio@FF14d000 {
+ compatible = "abilis,tb10x-gpio";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&tb10x_ictl>;
+ interrupts = <27 2>;
+ reg = <0xFF14D000 0x1000>;
+ gpio-controller;
+ #gpio-cells = <1>;
+ gpio-base = <94>;
+ gpio-pins = <&pctl_gpio_n>;
+ };
+ };
+};
diff --git a/arch/arc/boot/dts/abilis_tb101_dvk.dts b/arch/arc/boot/dts/abilis_tb101_dvk.dts
new file mode 100644
index 0000000..b204657
--- /dev/null
+++ b/arch/arc/boot/dts/abilis_tb101_dvk.dts
@@ -0,0 +1,127 @@
+/*
+ * Abilis Systems TB101 Development Kit PCB device tree
+ *
+ * Copyright (C) Abilis Systems 2013
+ *
+ * Author: Christian Ruppert <christian.ruppert@abilis.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+/dts-v1/;
+
+/include/ "abilis_tb101.dtsi"
+
+/ {
+ chosen {
+ bootargs = "earlycon=uart8250,mmio32,0xff100000,9600n8 console=ttyS0,9600n8";
+ };
+
+ aliases { };
+
+ memory {
+ device_type = "memory";
+ reg = <0x80000000 0x08000000>; /* 128M */
+ };
+
+ soc100 {
+ uart@FF100000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pctl_uart0>;
+ };
+ ethernet@FE100000 {
+ phy-mode = "rgmii";
+ };
+
+ i2c0: i2c@FF120000 {
+ i2c-sda-hold-time-ns = <432>;
+ };
+ i2c1: i2c@FF121000 {
+ i2c-sda-hold-time-ns = <432>;
+ };
+ i2c2: i2c@FF122000 {
+ i2c-sda-hold-time-ns = <432>;
+ };
+ i2c3: i2c@FF123000 {
+ i2c-sda-hold-time-ns = <432>;
+ };
+ i2c4: i2c@FF124000 {
+ i2c-sda-hold-time-ns = <432>;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ power {
+ label = "Power";
+ gpios = <&gpioi 0>;
+ linux,default-trigger = "default-on";
+ };
+ heartbeat {
+ label = "Heartbeat";
+ gpios = <&gpioi 1>;
+ linux,default-trigger = "heartbeat";
+ };
+ led2 {
+ label = "LED2";
+ gpios = <&gpioi 2>;
+ default-state = "off";
+ };
+ led3 {
+ label = "LED3";
+ gpios = <&gpioi 3>;
+ default-state = "off";
+ };
+ led4 {
+ label = "LED4";
+ gpios = <&gpioi 4>;
+ default-state = "off";
+ };
+ led5 {
+ label = "LED5";
+ gpios = <&gpioi 5>;
+ default-state = "off";
+ };
+ led6 {
+ label = "LED6";
+ gpios = <&gpioi 6>;
+ default-state = "off";
+ };
+ led7 {
+ label = "LED7";
+ gpios = <&gpioi 7>;
+ default-state = "off";
+ };
+ led8 {
+ label = "LED8";
+ gpios = <&gpioi 8>;
+ default-state = "off";
+ };
+ led9 {
+ label = "LED9";
+ gpios = <&gpioi 9>;
+ default-state = "off";
+ };
+ led10 {
+ label = "LED10";
+ gpios = <&gpioi 10>;
+ default-state = "off";
+ };
+ led11 {
+ label = "LED11";
+ gpios = <&gpioi 11>;
+ default-state = "off";
+ };
+ };
+ };
+};
diff --git a/arch/arc/boot/dts/abilis_tb10x.dtsi b/arch/arc/boot/dts/abilis_tb10x.dtsi
new file mode 100644
index 0000000..edf56f4
--- /dev/null
+++ b/arch/arc/boot/dts/abilis_tb10x.dtsi
@@ -0,0 +1,241 @@
+/*
+ * Abilis Systems TB10X SOC device tree
+ *
+ * Copyright (C) Abilis Systems 2013
+ *
+ * Author: Christian Ruppert <christian.ruppert@abilis.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+
+/ {
+ compatible = "abilis,arc-tb10x";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cpu@0 {
+ device_type = "cpu";
+ compatible = "snps,arc770d";
+ reg = <0>;
+ };
+ };
+
+ soc100 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ device_type = "soc";
+ ranges = <0xfe000000 0xfe000000 0x02000000
+ 0x000F0000 0x000F0000 0x00010000>;
+ compatible = "abilis,tb10x", "simple-bus";
+
+ pll0: oscillator {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-output-names = "pll0";
+ };
+ cpu_clk: clkdiv_cpu {
+ compatible = "fixed-factor-clock";
+ #clock-cells = <0>;
+ clocks = <&pll0>;
+ clock-output-names = "cpu_clk";
+ };
+ ahb_clk: clkdiv_ahb {
+ compatible = "fixed-factor-clock";
+ #clock-cells = <0>;
+ clocks = <&pll0>;
+ clock-output-names = "ahb_clk";
+ };
+
+ iomux: iomux@FF10601c {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "abilis,tb10x-iomux";
+ reg = <0xFF10601c 0x4>;
+ };
+
+ intc: interrupt-controller {
+ compatible = "snps,arc700-intc";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
+ tb10x_ictl: pic@fe002000 {
+ compatible = "abilis,tb10x-ictl";
+ reg = <0xFE002000 0x20>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupt-parent = <&intc>;
+ interrupts = <5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
+ 20 21 22 23 24 25 26 27 28 29 30 31>;
+ };
+
+ uart@FF100000 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0xFF100000 0x100>;
+ clock-frequency = <166666666>;
+ interrupts = <25 8>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ interrupt-parent = <&tb10x_ictl>;
+ };
+ ethernet@FE100000 {
+ compatible = "snps,dwmac-3.70a","snps,dwmac";
+ reg = <0xFE100000 0x1058>;
+ interrupt-parent = <&tb10x_ictl>;
+ interrupts = <6 8>;
+ interrupt-names = "macirq";
+ clocks = <&ahb_clk>;
+ clock-names = "stmmaceth";
+ };
+ dma@FE000000 {
+ compatible = "snps,dma-spear1340";
+ reg = <0xFE000000 0x400>;
+ interrupt-parent = <&tb10x_ictl>;
+ interrupts = <14 8>;
+ dma-channels = <6>;
+ dma-requests = <0>;
+ dma-masters = <1>;
+ #dma-cells = <3>;
+ chan_allocation_order = <0>;
+ chan_priority = <1>;
+ block_size = <0x7ff>;
+ data_width = <2 0 0 0>;
+ clocks = <&ahb_clk>;
+ clock-names = "hclk";
+ };
+
+ i2c0: i2c@FF120000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "snps,designware-i2c";
+ reg = <0xFF120000 0x1000>;
+ interrupt-parent = <&tb10x_ictl>;
+ interrupts = <12 8>;
+ clocks = <&ahb_clk>;
+ };
+ i2c1: i2c@FF121000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "snps,designware-i2c";
+ reg = <0xFF121000 0x1000>;
+ interrupt-parent = <&tb10x_ictl>;
+ interrupts = <12 8>;
+ clocks = <&ahb_clk>;
+ };
+ i2c2: i2c@FF122000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "snps,designware-i2c";
+ reg = <0xFF122000 0x1000>;
+ interrupt-parent = <&tb10x_ictl>;
+ interrupts = <12 8>;
+ clocks = <&ahb_clk>;
+ };
+ i2c3: i2c@FF123000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "snps,designware-i2c";
+ reg = <0xFF123000 0x1000>;
+ interrupt-parent = <&tb10x_ictl>;
+ interrupts = <12 8>;
+ clocks = <&ahb_clk>;
+ };
+ i2c4: i2c@FF124000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "snps,designware-i2c";
+ reg = <0xFF124000 0x1000>;
+ interrupt-parent = <&tb10x_ictl>;
+ interrupts = <12 8>;
+ clocks = <&ahb_clk>;
+ };
+
+ spi0: spi@0xFE010000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cell-index = <0>;
+ compatible = "abilis,tb100-spi";
+ num-cs = <1>;
+ reg = <0xFE010000 0x20>;
+ interrupt-parent = <&tb10x_ictl>;
+ interrupts = <26 8>;
+ clocks = <&ahb_clk>;
+ };
+ spi1: spi@0xFE011000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cell-index = <1>;
+ compatible = "abilis,tb100-spi";
+ num-cs = <2>;
+ reg = <0xFE011000 0x20>;
+ interrupt-parent = <&tb10x_ictl>;
+ interrupts = <10 8>;
+ clocks = <&ahb_clk>;
+ };
+
+ tb10x_tsm: tb10x-tsm@ff316000 {
+ compatible = "abilis,tb100-tsm";
+ reg = <0xff316000 0x400>;
+ interrupt-parent = <&tb10x_ictl>;
+ interrupts = <17 8>;
+ output-clkdiv = <4>;
+ global-packet-delay = <0x21>;
+ port-packet-delay = <0>;
+ };
+ tb10x_stream_proc: tb10x-stream-proc {
+ compatible = "abilis,tb100-streamproc";
+ reg = <0xfff00000 0x200>,
+ <0x000f0000 0x10000>,
+ <0xfff00200 0x105>,
+ <0xff10600c 0x1>,
+ <0xfe001018 0x1>;
+ reg-names = "mbox",
+ "sp_iccm",
+ "mbox_irq",
+ "cpuctrl",
+ "a6it_int_force";
+ interrupt-parent = <&tb10x_ictl>;
+ interrupts = <20 2>, <19 2>;
+ interrupt-names = "cmd_irq", "event_irq";
+ };
+ tb10x_mdsc0: tb10x-mdscr@FF300000 {
+ compatible = "abilis,tb100-mdscr";
+ reg = <0xFF300000 0x7000>;
+ tb100-mdscr-manage-tsin;
+ };
+ tb10x_mscr0: tb10x-mdscr@FF307000 {
+ compatible = "abilis,tb100-mdscr";
+ reg = <0xFF307000 0x7000>;
+ };
+ tb10x_scr0: tb10x-mdscr@ff30e000 {
+ compatible = "abilis,tb100-mdscr";
+ reg = <0xFF30e000 0x4000>;
+ tb100-mdscr-manage-tsin;
+ };
+ tb10x_scr1: tb10x-mdscr@ff312000 {
+ compatible = "abilis,tb100-mdscr";
+ reg = <0xFF312000 0x4000>;
+ tb100-mdscr-manage-tsin;
+ };
+ tb10x_wfb: tb10x-wfb@ff319000 {
+ compatible = "abilis,tb100-wfb";
+ reg = <0xff319000 0x1000>;
+ interrupt-parent = <&tb10x_ictl>;
+ interrupts = <16 8>;
+ };
+ };
+};
diff --git a/arch/arc/boot/dts/angel4.dts b/arch/arc/boot/dts/angel4.dts
new file mode 100644
index 0000000..4fb2d6f
--- /dev/null
+++ b/arch/arc/boot/dts/angel4.dts
@@ -0,0 +1,71 @@
+/*
+ * Copyright (C) 2012 Synopsys, Inc. (www.synopsys.com)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/dts-v1/;
+
+/include/ "skeleton.dtsi"
+
+/ {
+ compatible = "snps,arc-angel4";
+ clock-frequency = <80000000>; /* 80 MHZ */
+ #address-cells = <1>;
+ #size-cells = <1>;
+ interrupt-parent = <&intc>;
+
+ chosen {
+ bootargs = "console=ttyARC0,115200n8";
+ };
+
+ aliases {
+ serial0 = &arcuart0;
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x00000000 0x10000000>; /* 256M */
+ };
+
+ fpga {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ /* child and parent address space 1:1 mapped */
+ ranges;
+
+ intc: interrupt-controller {
+ compatible = "snps,arc700-intc";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
+
+ arcuart0: serial@c0fc1000 {
+ compatible = "snps,arc-uart";
+ reg = <0xc0fc1000 0x100>;
+ interrupts = <5>;
+ clock-frequency = <80000000>;
+ current-speed = <115200>;
+ status = "okay";
+ };
+
+ ethernet@c0fc2000 {
+ compatible = "snps,arc-emac";
+ reg = <0xc0fc2000 0x3c>;
+ interrupts = <6>;
+ mac-address = [ 00 11 22 33 44 55 ];
+ clock-frequency = <80000000>;
+ max-speed = <100>;
+ phy = <&phy0>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+ phy0: ethernet-phy@0 {
+ reg = <1>;
+ };
+ };
+ };
+};
diff --git a/arch/arc/boot/dts/nsimosci.dts b/arch/arc/boot/dts/nsimosci.dts
new file mode 100644
index 0000000..ea16d78
--- /dev/null
+++ b/arch/arc/boot/dts/nsimosci.dts
@@ -0,0 +1,77 @@
+/*
+ * Copyright (C) 2013 Synopsys, Inc. (www.synopsys.com)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/dts-v1/;
+
+/include/ "skeleton.dtsi"
+
+/ {
+ compatible = "snps,nsimosci";
+ clock-frequency = <80000000>; /* 80 MHZ */
+ #address-cells = <1>;
+ #size-cells = <1>;
+ interrupt-parent = <&intc>;
+
+ chosen {
+ bootargs = "console=tty0 consoleblank=0";
+ };
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x80000000 0x10000000>; /* 256M */
+ };
+
+ fpga {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ /* child and parent address space 1:1 mapped */
+ ranges;
+
+ intc: interrupt-controller {
+ compatible = "snps,arc700-intc";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
+
+ uart0: serial@c0000000 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0xc0000000 0x2000>;
+ interrupts = <11>;
+ #clock-frequency = <80000000>;
+ clock-frequency = <3686400>;
+ baud = <115200>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ status = "okay";
+ };
+
+ pgu0: pgu@c9000000 {
+ compatible = "snps,arcpgufb";
+ reg = <0xc9000000 0x400>;
+ };
+
+ ps2: ps2@c9001000 {
+ compatible = "snps,arc_ps2";
+ reg = <0xc9000400 0x14>;
+ interrupts = <13>;
+ interrupt-names = "arc_ps2_irq";
+ };
+
+ eth0: ethernet@c0003000 {
+ compatible = "snps,oscilan";
+ reg = <0xc0003000 0x44>;
+ interrupts = <7>, <8>;
+ interrupt-names = "rx", "tx";
+ };
+ };
+};
diff --git a/arch/arc/boot/dts/skeleton.dts b/arch/arc/boot/dts/skeleton.dts
new file mode 100644
index 0000000..25a84fb
--- /dev/null
+++ b/arch/arc/boot/dts/skeleton.dts
@@ -0,0 +1,10 @@
+/*
+ * Copyright (C) 2012 Synopsys, Inc. (www.synopsys.com)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/dts-v1/;
+
+/include/ "skeleton.dtsi"
diff --git a/arch/arc/boot/dts/skeleton.dtsi b/arch/arc/boot/dts/skeleton.dtsi
new file mode 100644
index 0000000..a870bdd
--- /dev/null
+++ b/arch/arc/boot/dts/skeleton.dtsi
@@ -0,0 +1,37 @@
+/*
+ * Copyright (C) 2012 Synopsys, Inc. (www.synopsys.com)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/*
+ * Skeleton device tree; the bare minimum needed to boot; just include and
+ * add a compatible value.
+ */
+
+/ {
+ compatible = "snps,arc";
+ clock-frequency = <80000000>; /* 80 MHZ */
