diff options
| author | Dmitry Torokhov <dmitry.torokhov@gmail.com> | 2013-05-01 08:47:44 -0700 |
|---|---|---|
| committer | Dmitry Torokhov <dmitry.torokhov@gmail.com> | 2013-05-01 08:47:44 -0700 |
| commit | bf61c8840efe60fd8f91446860b63338fb424158 (patch) | |
| tree | 7a71832407a4f0d6346db773343f4c3ae2257b19 /Documentation | |
| parent | 5846115b30f3a881e542c8bfde59a699c1c13740 (diff) | |
| parent | 0c6a61657da78098472fd0eb71cc01f2387fa1bb (diff) | |
Merge branch 'next' into for-linus
Prepare first set of updates for 3.10 merge window.
Diffstat (limited to 'Documentation')
551 files changed, 17465 insertions, 5176 deletions
diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX index ceb1ff735469..45b3df936d2f 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 @@ BUG-HUNTING 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 @@ applying-patches.txt - 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 @@ block/ - 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 @@ cdrom/ - 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,40 +141,66 @@ dcdbas.txt - 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/ - directory with info on the frame buffer graphics abstraction layer. -feature-removal-schedule.txt - - list of files and features that are going to be removed. filesystems/ - 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 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 @@ -164,10 +217,14 @@ ia64/ - 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 @@ -184,6 +241,8 @@ isdn/ - 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/ @@ -194,6 +253,12 @@ kernel-docs.txt - 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 @@ -210,6 +275,8 @@ local_ops.txt - 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 @@ -222,16 +289,28 @@ magic-number.txt - 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 @@ -242,6 +321,8 @@ netlabel/ - 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 @@ -258,26 +339,46 @@ parport-lowlevel.txt - 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 @@ -302,10 +403,10 @@ sgi-visws.txt - 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/ @@ -316,6 +417,8 @@ stable_api_nonsense.txt - 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 @@ -324,27 +427,53 @@ sysctl/ - 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/README b/Documentation/ABI/README index 9feaf16f1617..10069828568b 100644 --- a/Documentation/ABI/README +++ b/Documentation/ABI/README @@ -36,9 +36,6 @@ The different levels of stability are: the kernel, but are marked to be removed at some later point in time. The description of the interface will document the reason why it is obsolete and when it can be expected to be removed. - The file Documentation/feature-removal-schedule.txt may describe - some of these interfaces, giving a schedule for when they will - be removed. removed/ This directory contains a list of the old interfaces that have diff --git a/Documentation/ABI/obsolete/sysfs-driver-hid-roccat-koneplus b/Documentation/ABI/obsolete/sysfs-driver-hid-roccat-koneplus index c2a270b45b03..833fd59926a7 100644 --- a/Documentation/ABI/obsolete/sysfs-driver-hid-roccat-koneplus +++ b/Documentation/ABI/obsolete/sysfs-driver-hid-roccat-koneplus @@ -8,3 +8,41 @@ Description: The integer value of this attribute ranges from 0-4. When written, this file sets the number of the startup profile and the mouse activates this profile immediately. Please use actual_profile, it does the same thing. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/firmware_version +Date: October 2010 +Contact: Stefan Achatz <erazor_de@users.sourceforge.net> +Description: When read, this file returns the raw integer version number of the + firmware reported by the mouse. Using the integer value eases + further usage in other programs. To receive the real version + number the decimal point has to be shifted 2 positions to the + left. E.g. a returned value of 121 means 1.21 + This file is readonly. + Please read binary attribute info which contains firmware version. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/profile[1-5]_buttons +Date: August 2010 +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 read, these files return the respective profile buttons. + The returned data is 77 bytes in size. + This file is readonly. + Write control to select profile and read profile_buttons instead. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/profile[1-5]_settings +Date: August 2010 +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 read, these files return the respective profile settings. + The returned data is 43 bytes in size. + This file is readonly. + Write control to select profile and read profile_settings instead. +Users: http://roccat.sourceforge.net
\ No newline at end of file diff --git a/Documentation/ABI/obsolete/sysfs-driver-hid-roccat-kovaplus b/Documentation/ABI/obsolete/sysfs-driver-hid-roccat-kovaplus new file mode 100644 index 000000000000..4a98e02b6c6a --- /dev/null +++ b/Documentation/ABI/obsolete/sysfs-driver-hid-roccat-kovaplus @@ -0,0 +1,66 @@ +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/actual_cpi +Date: January 2011 +Contact: Stefan Achatz <erazor_de@users.sourceforge.net> +Description: The integer value of this attribute ranges from 1-4. + When read, this attribute returns the number of the active + cpi level. + This file is readonly. + Has never been used. If bookkeeping is done, it's done in userland tools. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/actual_sensitivity_x +Date: January 2011 +Contact: Stefan Achatz <erazor_de@users.sourceforge.net> +Description: The integer value of this attribute ranges from 1-10. + When read, this attribute returns the number of the actual + sensitivity in x direction. + This file is readonly. + Has never been used. If bookkeeping is done, it's done in userland tools. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/actual_sensitivity_y +Date: January 2011 +Contact: Stefan Achatz <erazor_de@users.sourceforge.net> +Description: The integer value of this attribute ranges from 1-10. + When read, this attribute returns the number of the actual + sensitivity in y direction. + This file is readonly. + Has never been used. If bookkeeping is done, it's done in userland tools. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/firmware_version +Date: January 2011 +Contact: Stefan Achatz <erazor_de@users.sourceforge.net> +Description: When read, this file returns the raw integer version number of the + firmware reported by the mouse. Using the integer value eases + further usage in other programs. To receive the real version + number the decimal point has to be shifted 2 positions to the + left. E.g. a returned value of 121 means 1.21 + This file is readonly. + Obsoleted by binary sysfs attribute "info". +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/profile[1-5]_buttons +Date: January 2011 +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 read, these files return the respective profile buttons. + The returned data is 23 bytes in size. + This file is readonly. + Write control to select profile and read profile_buttons instead. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/profile[1-5]_settings +Date: January 2011 +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 read, these files return the respective profile settings. + The returned data is 16 bytes in size. + This file is readonly. + Write control to select profile and read profile_settings instead. +Users: http://roccat.sourceforge.net diff --git a/Documentation/ABI/obsolete/sysfs-driver-hid-roccat-pyra b/Documentation/ABI/obsolete/sysfs-driver-hid-roccat-pyra new file mode 100644 index 000000000000..87ac87e9556d --- /dev/null +++ b/Documentation/ABI/obsolete/sysfs-driver-hid-roccat-pyra @@ -0,0 +1,73 @@ +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/actual_cpi +Date: August 2010 +Contact: Stefan Achatz <erazor_de@users.sourceforge.net> +Description: It is possible to switch the cpi setting of the mouse with the + press of a button. + When read, this file returns the raw number of the actual cpi + setting reported by the mouse. This number has to be further + processed to receive the real dpi value. + + VALUE DPI + 1 400 + 2 800 + 4 1600 + + This file is readonly. + Has never been used. If bookkeeping is done, it's done in userland tools. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/actual_profile +Date: August 2010 +Contact: Stefan Achatz <erazor_de@users.sourceforge.net> +Description: When read, this file returns the number of the actual profile in + range 0-4. + This file is readonly. + Please use binary attribute "settings" which provides this information. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/firmware_version +Date: August 2010 +Contact: Stefan Achatz <erazor_de@users.sourceforge.net> +Description: When read, this file returns the raw integer version number of the + firmware reported by the mouse. Using the integer value eases + further usage in other programs. To receive the real version + number the decimal point has to be shifted 2 positions to the + left. E.g. a returned value of 138 means 1.38 + This file is readonly. + Please use binary attribute "info" which provides this information. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/profile[1-5]_buttons +Date: August 2010 +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 read, these files return the respective profile buttons. + The returned data is 19 bytes in size. + This file is readonly. + Write control to select profile and read profile_buttons instead. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/profile[1-5]_settings +Date: August 2010 +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 read, these files return the respective profile settings. + The returned data is 13 bytes in size. + This file is readonly. + Write control to select profile and read profile_settings instead. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/startup_profile +Date: August 2010 +Contact: Stefan Achatz <erazor_de@users.sourceforge.net> +Description: The integer value of this attribute ranges from 0-4. + When read, this attribute returns the number of the profile + that's active when the mouse is powered on. + This file is readonly. + Please use binary attribute "settings" which provides this information. +Users: http://roccat.sourceforge.net diff --git a/Documentation/ABI/stable/sysfs-class-tpm b/Documentation/ABI/stable/sysfs-class-tpm new file mode 100644 index 000000000000..a60b45e2493b --- /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-devices-node b/Documentation/ABI/stable/sysfs-devices-node index 49b82cad7003..ce259c13c36a 100644 --- a/Documentation/ABI/stable/sysfs-devices-node +++ b/Documentation/ABI/stable/sysfs-devices-node @@ -1,7 +1,101 @@ +What: /sys/devices/system/node/possible +Date: October 2002 +Contact: Linux Memory Management list <linux-mm@kvack.org> +Description: + Nodes that could be possibly become online at some point. + +What: /sys/devices/system/node/online +Date: October 2002 +Contact: Linux Memory Management list <linux-mm@kvack.org> +Description: + Nodes that are online. + +What: /sys/devices/system/node/has_normal_memory +Date: October 2002 +Contact: Linux Memory Management list <linux-mm@kvack.org> +Description: + Nodes that have regular memory. + +What: /sys/devices/system/node/has_cpu +Date: October 2002 +Contact: Linux Memory Management list <linux-mm@kvack.org> +Description: + Nodes that have one or more CPUs. + +What: /sys/devices/system/node/has_high_memory +Date: October 2002 +Contact: Linux Memory Management list <linux-mm@kvack.org> +Description: + Nodes that have regular or high memory. + Depends on CONFIG_HIGHMEM. + What: /sys/devices/system/node/nodeX Date: October 2002 Contact: Linux Memory Management list <linux-mm@kvack.org> Description: When CONFIG_NUMA is enabled, this is a directory containing information on node X such as what CPUs are local to the - node. + node. Each file is detailed next. + +What: /sys/devices/system/node/nodeX/cpumap +Date: October 2002 +Contact: Linux Memory Management list <linux-mm@kvack.org> +Description: + The node's cpumap. + +What: /sys/devices/system/node/nodeX/cpulist +Date: October 2002 +Contact: Linux Memory Management list <linux-mm@kvack.org> +Description: + The CPUs associated to the node. + +What: /sys/devices/system/node/nodeX/meminfo +Date: October 2002 +Contact: Linux Memory Management list <linux-mm@kvack.org> +Description: + Provides information about the node's distribution and memory + utilization. Similar to /proc/meminfo, see Documentation/filesystems/proc.txt + +What: /sys/devices/system/node/nodeX/numastat +Date: October 2002 +Contact: Linux Memory Management list <linux-mm@kvack.org> +Description: + The node's hit/miss statistics, in units of pages. + See Documentation/numastat.txt + +What: /sys/devices/system/node/nodeX/distance +Date: October 2002 +Contact: Linux Memory Management list <linux-mm@kvack.org> +Description: + Distance between the node and all the other nodes + in the system. + +What: /sys/devices/system/node/nodeX/vmstat +Date: October 2002 +Contact: Linux Memory Management list <linux-mm@kvack.org> +Description: + The node's zoned virtual memory statistics. + This is a superset of numastat. + +What: /sys/devices/system/node/nodeX/compact +Date: February 2010 +Contact: Mel Gorman <mel@csn.ul.ie> +Description: + When this file is written to, all memory within that node + will be compacted. When it completes, memory will be freed + into blocks which have as many contiguous pages as possible + +What: /sys/devices/system/node/nodeX/scan_unevictable_pages +Date: October 2008 +Contact: Lee Schermerhorn <lee.schermerhorn@hp.com> +Description: + When set, it triggers scanning the node's unevictable lists + and move any pages that have become evictable onto the respective + zone's inactive list. See mm/vmscan.c + +What: /sys/devices/system/node/nodeX/hugepages/hugepages-<size>/ +Date: December 2009 +Contact: Lee Schermerhorn <lee.schermerhorn@hp.com> +Description: + The node's huge page size control/query attributes. + See Documentation/vm/hugetlbpage.txt
\ No newline at end of file diff --git a/Documentation/ABI/stable/sysfs-driver-ib_srp b/Documentation/ABI/stable/sysfs-driver-ib_srp new file mode 100644 index 000000000000..481aae95c7d1 --- /dev/null +++ b/Documentation/ABI/stable/sysfs-driver-ib_srp @@ -0,0 +1,156 @@ +What: /sys/class/infiniband_srp/srp-<hca>-<port_number>/add_target +Date: January 2, 2006 +KernelVersion: 2.6.15 +Contact: linux-rdma@vger.kernel.org +Description: Interface for making ib_srp connect to a new target. + One can request ib_srp to connect to a new target by writing + a comma-separated list of login parameters to this sysfs + attribute. The supported parameters are: + * id_ext, a 16-digit hexadecimal number specifying the eight + byte identifier extension in the 16-byte SRP target port + identifier. The target port identifier is sent by ib_srp + to the target in the SRP_LOGIN_REQ request. + * ioc_guid, a 16-digit hexadecimal number specifying the eight + byte I/O controller GUID portion of the 16-byte target port + identifier. + * dgid, a 32-digit hexadecimal number specifying the + destination GID. + * pkey, a four-digit hexadecimal number specifying the + InfiniBand partition key. + * service_id, a 16-digit hexadecimal number specifying the + InfiniBand service ID used to establish communication with + the SRP target. How to find out the value of the service ID + is specified in the documentation of the SRP target. + * max_sect, a decimal number specifying the maximum number of + 512-byte sectors to be transferred via a single SCSI command. + * max_cmd_per_lun, a decimal number specifying the maximum + number of outstanding commands for a single LUN. + * io_class, a hexadecimal number specifying the SRP I/O class. + Must be either 0xff00 (rev 10) or 0x0100 (rev 16a). The I/O + class defines the format of the SRP initiator and target + port identifiers. + * initiator_ext, a 16-digit hexadecimal number specifying the + identifier extension portion of the SRP initiator port + identifier. This data is sent by the initiator to the target + in the SRP_LOGIN_REQ request. + * cmd_sg_entries, a number in the range 1..255 that specifies + the maximum number of data buffer descriptors stored in the + SRP_CMD information unit itself. With allow_ext_sg=0 the + parameter cmd_sg_entries defines the maximum S/G list length + for a single SRP_CMD, and commands whose S/G list length + exceeds this limit after S/G list collapsing will fail. + * allow_ext_sg, whether ib_srp is allowed to include a partial + memory descriptor list in an SRP_CMD instead of the entire + list. If a partial memory descriptor list has been included + in an SRP_CMD the remaining memory descriptors are + communicated from initiator to target via an additional RDMA + transfer. Setting allow_ext_sg to 1 increases the maximum + amount of data that can be transferred between initiator and + target via a single SCSI command. Since not all SRP target + implementations support partial memory descriptor lists the + default value for this option is 0. + * sg_tablesize, a number in the range 1..2048 specifying the + maximum S/G list length the SCSI layer is allowed to pass to + ib_srp. Specifying a value that exceeds cmd_sg_entries is + only safe with partial memory descriptor list support enabled + (allow_ext_sg=1). + +What: /sys/class/infiniband_srp/srp-<hca>-<port_number>/ibdev +Date: January 2, 2006 +KernelVersion: 2.6.15 +Contact: linux-rdma@vger.kernel.org +Description: HCA name (<hca>). + +What: /sys/class/infiniband_srp/srp-<hca>-<port_number>/port +Date: January 2, 2006 +KernelVersion: 2.6.15 +Contact: linux-rdma@vger.kernel.org +Description: HCA port number (<port_number>). + +What: /sys/class/scsi_host/host<n>/allow_ext_sg +Date: May 19, 2011 +KernelVersion: 2.6.39 +Contact: linux-rdma@vger.kernel.org +Description: Whether ib_srp is allowed to include a partial memory + descriptor list in an SRP_CMD when communicating with an SRP + target. + +What: /sys/class/scsi_host/host<n>/cmd_sg_entries +Date: May 19, 2011 +KernelVersion: 2.6.39 +Contact: linux-rdma@vger.kernel.org +Description: Maximum number of data buffer descriptors that may be sent to + the target in a single SRP_CMD request. + +What: /sys/class/scsi_host/host<n>/dgid +Date: June 17, 2006 +KernelVersion: 2.6.17 +Contact: linux-rdma@vger.kernel.org +Description: InfiniBand destination GID used for communication with the SRP + target. Differs from orig_dgid if port redirection has happened. + +What: /sys/class/scsi_host/host<n>/id_ext +Date: June 17, 2006 +KernelVersion: 2.6.17 +Contact: linux-rdma@vger.kernel.org +Description: Eight-byte identifier extension portion of the 16-byte target + port identifier. + +What: /sys/class/scsi_host/host<n>/ioc_guid +Date: June 17, 2006 +KernelVersion: 2.6.17 +Contact: linux-rdma@vger.kernel.org +Description: Eight-byte I/O controller GUID portion of the 16-byte target + port identifier. + +What: /sys/class/scsi_host/host<n>/local_ib_device +Date: November 29, 2006 +KernelVersion: 2.6.19 +Contact: linux-rdma@vger.kernel.org +Description: Name of the InfiniBand HCA used for communicating with the + SRP target. + +What: /sys/class/scsi_host/host<n>/local_ib_port +Date: November 29, 2006 +KernelVersion: 2.6.19 +Contact: linux-rdma@vger.kernel.org +Description: Number of the HCA port used for communicating with the + SRP target. + +What: /sys/class/scsi_host/host<n>/orig_dgid +Date: June 17, 2006 +KernelVersion: 2.6.17 +Contact: linux-rdma@vger.kernel.org +Description: InfiniBand destination GID specified in the parameters + written to the add_target sysfs attribute. + +What: /sys/class/scsi_host/host<n>/pkey +Date: June 17, 2006 +KernelVersion: 2.6.17 +Contact: linux-rdma@vger.kernel.org +Description: A 16-bit number representing the InfiniBand partition key used + for communication with the SRP target. + +What: /sys/class/scsi_host/host<n>/req_lim +Date: October 20, 2010 +KernelVersion: 2.6.36 +Contact: linux-rdma@vger.kernel.org +Description: Number of requests ib_srp can send to the target before it has + to wait for more credits. For more information see also the + SRP credit algorithm in the SRP specification. + +What: /sys/class/scsi_host/host<n>/service_id +Date: June 17, 2006 +KernelVersion: 2.6.17 +Contact: linux-rdma@vger.kernel.org +Description: InfiniBand service ID used for establishing communication with + the SRP target. + +What: /sys/class/scsi_host/host<n>/zero_req_lim +Date: September 20, 2006 +KernelVersion: 2.6.18 +Contact: linux-rdma@vger.kernel.org +Description: Number of times the initiator had to wait before sending a + request to the target because it ran out of credits. For more + information see also the SRP credit algorithm in the SRP + specification. diff --git a/Documentation/ABI/stable/sysfs-transport-srp b/Documentation/ABI/stable/sysfs-transport-srp new file mode 100644 index 000000000000..b36fb0dc13c8 --- /dev/null +++ b/Documentation/ABI/stable/sysfs-transport-srp @@ -0,0 +1,19 @@ +What: /sys/class/srp_remote_ports/port-<h>:<n>/delete +Date: June 1, 2012 +KernelVersion: 3.7 +Contact: linux-scsi@vger.kernel.org, linux-rdma@vger.kernel.org +Description: Instructs an SRP initiator to disconnect from a target and to + remove all LUNs imported from that target. + +What: /sys/class/srp_remote_ports/port-<h>:<n>/port_id +Date: June 27, 2007 +KernelVersion: 2.6.24 +Contact: linux-scsi@vger.kernel.org +Description: 16-byte local SRP port identifier in hexadecimal format. An + example: 4c:49:4e:55:58:20:56:49:4f:00:00:00:00:00:00:00. + +What: /sys/class/srp_remote_ports/port-<h>:<n>/roles +Date: June 27, 2007 +KernelVersion: 2.6.24 +Contact: linux-scsi@vger.kernel.org +Description: Role of the remote port. Either "SRP Initiator" or "SRP Target". diff --git a/Documentation/ABI/testing/dev-kmsg b/Documentation/ABI/testing/dev-kmsg index 7e7e07a82e0e..bb820be48179 100644 --- a/Documentation/ABI/testing/dev-kmsg +++ b/Documentation/ABI/testing/dev-kmsg @@ -92,7 +92,7 @@ Description: The /dev/kmsg character device node provides userspace access The flags field carries '-' by default. A 'c' indicates a fragment of a line. All following fragments are flagged with '+'. Note, that these hints about continuation lines are not - neccessarily correct, and the stream could be interleaved with + necessarily correct, and the stream could be interleaved with unrelated messages, but merging the lines in the output usually produces better human readable results. A similar logic is used internally when messages are printed to the diff --git a/Documentation/ABI/testing/ima_policy b/Documentation/ABI/testing/ima_policy index 986946613542..f1c5cc9d17a8 100644 --- a/Documentation/ABI/testing/ima_policy +++ b/Documentation/ABI/testing/ima_policy @@ -18,17 +18,21 @@ Description: 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] + 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 @@ -53,6 +57,7 @@ Description: measure func=BPRM_CHECK measure func=FILE_MMAP mask=MAY_EXEC measure func=FILE_CHECK mask=MAY_READ uid=0 + measure func=MODULE_CHECK uid=0 appraise fowner=0 The default policy measures all executables in bprm_check, diff --git a/Documentation/ABI/testing/pstore b/Documentation/ABI/testing/pstore index ff1df4e3b059..5fca9f5e10a3 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 @@ Description: Generic interface to platform dependent persistent storage. 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 @@ Description: Generic interface to platform dependent persistent storage. 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-bus-event_source-devices-events b/Documentation/ABI/testing/sysfs-bus-event_source-devices-events new file mode 100644 index 000000000000..0adeb524c0d4 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-events @@ -0,0 +1,62 @@ +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_LD_MISS_L1 + /sys/devices/cpu/events/PM_LD_REF_L1 + /sys/devices/cpu/events/PM_CYC + /sys/devices/cpu/events/PM_BRU_FIN + /sys/devices/cpu/events/PM_GCT_NOSLOT_CYC + /sys/devices/cpu/events/PM_BRU_MPRED + /sys/devices/cpu/events/PM_INST_CMPL + /sys/devices/cpu/events/PM_CMPLU_STALL + +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-fcoe b/Documentation/ABI/testing/sysfs-bus-fcoe index 50e2a80ea28f..21640eaad371 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 @@ Attributes: 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 2f06d40fe07d..2e33dc6b2346 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio +++ b/Documentation/ABI/testing/sysfs-bus-iio @@ -189,6 +189,14 @@ Description: A computed peak value based on the sum squared magnitude of the underlying value in the specified directions. +What: /sys/bus/iio/devices/iio:deviceX/in_pressureY_raw +What: /sys/bus/iio/devices/iio:deviceX/in_pressure_raw +KernelVersion: 3.8 +Contact: linux-iio@vger.kernel.org +Description: + Raw pressure measurement from channel Y. Units after + application of scale and offset are kilopascal. + What: /sys/bus/iio/devices/iio:deviceX/in_accel_offset What: /sys/bus/iio/devices/iio:deviceX/in_accel_x_offset What: /sys/bus/iio/devices/iio:deviceX/in_accel_y_offset @@ -197,6 +205,8 @@ What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_offset What: /sys/bus/iio/devices/iio:deviceX/in_voltage_offset What: /sys/bus/iio/devices/iio:deviceX/in_tempY_offset What: /sys/bus/iio/devices/iio:deviceX/in_temp_offset +What: /sys/bus/iio/devices/iio:deviceX/in_pressureY_offset +What: /sys/bus/iio/devices/iio:deviceX/in_pressure_offset KernelVersion: 2.6.35 Contact: linux-iio@vger.kernel.org Description: @@ -226,6 +236,8 @@ What: /sys/bus/iio/devices/iio:deviceX/in_magn_scale What: /sys/bus/iio/devices/iio:deviceX/in_magn_x_scale What: /sys/bus/iio/devices/iio:deviceX/in_magn_y_scale What: /sys/bus/iio/devices/iio:deviceX/in_magn_z_scale +What: /sys/bus/iio/devices/iio:deviceX/in_pressureY_scale +What: /sys/bus/iio/devices/iio:deviceX/in_pressure_scale KernelVersion: 2.6.35 Contact: linux-iio@vger.kernel.org Description: @@ -245,6 +257,8 @@ What: /sys/bus/iio/devices/iio:deviceX/in_anglvel_y_calibbias What: /sys/bus/iio/devices/iio:deviceX/in_anglvel_z_calibbias What: /sys/bus/iio/devices/iio:deviceX/in_illuminance0_calibbias What: /sys/bus/iio/devices/iio:deviceX/in_proximity0_calibbias +What: /sys/bus/iio/devices/iio:deviceX/in_pressureY_calibbias +What: /sys/bus/iio/devices/iio:deviceX/in_pressure_calibbias KernelVersion: 2.6.35 Contact: linux-iio@vger.kernel.org Description: @@ -262,6 +276,8 @@ What /sys/bus/iio/devices/iio:deviceX/in_anglvel_y_calibscale What /sys/bus/iio/devices/iio:deviceX/in_anglvel_z_calibscale what /sys/bus/iio/devices/iio:deviceX/in_illuminance0_calibscale what /sys/bus/iio/devices/iio:deviceX/in_proximity0_calibscale +What: /sys/bus/iio/devices/iio:deviceX/in_pressureY_calibscale +What: /sys/bus/iio/devices/iio:deviceX/in_pressure_calibscale KernelVersion: 2.6.35 Contact: linux-iio@vger.kernel.org Description: @@ -275,6 +291,8 @@ What: /sys/.../iio:deviceX/in_voltage-voltage_scale_available What: /sys/.../iio:deviceX/out_voltageX_scale_available What: /sys/.../iio:deviceX/out_altvoltageX_scale_available What: /sys/.../iio:deviceX/in_capacitance_scale_available +What: /sys/.../iio:deviceX/in_pressure_scale_available +What: /sys/.../iio:deviceX/in_pressureY_scale_available KernelVersion: 2.6.35 Contact: linux-iio@vger.kernel.org Description: @@ -694,6 +712,8 @@ 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 KernelVersion: 2.6.37 Contact: linux-iio@vger.kernel.org Description: @@ -707,6 +727,8 @@ 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 KernelVersion: 2.6.37 Contact: linux-iio@vger.kernel.org Description: @@ -751,6 +773,8 @@ 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 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 000000000000..cb53737aacbf --- /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-mdio b/Documentation/ABI/testing/sysfs-bus-mdio new file mode 100644 index 000000000000..6349749ebc29 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-mdio @@ -0,0 +1,9 @@ +What: /sys/bus/mdio_bus/devices/.../phy_id +Date: November 2012 +KernelVersion: 3.8 +Contact: netdev@vger.kernel.org +Description: + This attribute contains the 32-bit PHY Identifier as reported + by the device during bus enumeration, encoded in hexadecimal. + This ID is used to match the device with the appropriate + driver. diff --git a/Documentation/ABI/testing/sysfs-bus-pci b/Documentation/ABI/testing/sysfs-bus-pci index dff1f48d252d..1ce5ae329c04 100644 --- a/Documentation/ABI/testing/sysfs-bus-pci +++ b/Documentation/ABI/testing/sysfs-bus-pci @@ -222,3 +222,37 @@ Description: satisfied too. Reading this attribute will show the current value of d3cold_allowed bit. Writing this attribute will set the value of d3cold_allowed bit. + +What: /sys/bus/pci/devices/.../sriov_totalvfs +Date: November 2012 +Contact: Donald Dutile <ddutile@redhat.com> +Description: + This file appears when a physical PCIe device supports SR-IOV. + Userspace applications can read this file to determine the + maximum number of Virtual Functions (VFs) a PCIe physical + function (PF) can support. Typically, this is the value reported + in the PF's SR-IOV extended capability structure's TotalVFs + element. Drivers have the ability at probe time to reduce the + value read from this file via the pci_sriov_set_totalvfs() + function. + +What: /sys/bus/pci/devices/.../sriov_numvfs +Date: November 2012 +Contact: Donald Dutile <ddutile@redhat.com> +Description: + This file appears when a physical PCIe device supports SR-IOV. + Userspace applications can read and write to this file to + determine and control the enablement or disablement of Virtual + Functions (VFs) on the physical function (PF). A read of this + file will return the number of VFs that are enabled on this PF. + A number written to this file will enable the specified + number of VFs. A userspace application would typically read the + file and check that the value is zero, and then write the number + of VFs that should be enabled on the PF; the value written + should be less than or equal to the value in the sriov_totalvfs + file. A userspace application wanting to disable the VFs would + write a zero to this file. The core ensures that valid values + are written to this file, and returns errors when values are not + valid. For example, writing a 2 to this file when sriov_numvfs + is not 0 and not 2 already will return an error. Writing a 10 + when the value of sriov_totalvfs is 8 will return an error. diff --git a/Documentation/ABI/testing/sysfs-bus-rbd b/Documentation/ABI/testing/sysfs-bus-rbd index 1cf2adf46b11..cd9213ccf3dc 100644 --- a/Documentation/ABI/testing/sysfs-bus-rbd +++ b/Documentation/ABI/testing/sysfs-bus-rbd @@ -70,6 +70,10 @@ 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> ------------------------------------------------------------- diff --git a/Documentation/ABI/testing/sysfs-bus-usb b/Documentation/ABI/testing/sysfs-bus-usb index b6fbe514a869..c8baaf53594a 100644 --- a/Documentation/ABI/testing/sysfs-bus-usb +++ b/Documentation/ABI/testing/sysfs-bus-usb @@ -227,3 +227,12 @@ Contact: Lan Tianyu <tianyu.lan@intel.com> 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. diff --git a/Documentation/ABI/testing/sysfs-class-bdi b/Documentation/ABI/testing/sysfs-class-bdi index 5f500977b42f..d773d5697cf5 100644 --- a/Documentation/ABI/testing/sysfs-class-bdi +++ b/Documentation/ABI/testing/sysfs-class-bdi @@ -48,3 +48,8 @@ max_ratio (read-write) 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 23d78b5aab11..0ba6ea2f89d9 100644 --- a/Documentation/ABI/testing/sysfs-class-devfreq +++ b/Documentation/ABI/testing/sysfs-class-devfreq @@ -11,7 +11,7 @@ What: /sys/class/devfreq/.../governor Date: September 2011 Contact: MyungJoo Ham <myungjoo.ham@samsung.com> Description: - The /sys/class/devfreq/.../governor shows the name of the + The /sys/class/devfreq/.../governor show or set the name of the governor used by the corresponding devfreq object. What: /sys/class/devfreq/.../cur_freq @@ -19,15 +19,16 @@ Date: September 2011 Contact: MyungJoo Ham <myungjoo.ham@samsung.com> Description: The /sys/class/devfreq/.../cur_freq shows the current - frequency of the corresponding devfreq object. + frequency of the corresponding devfreq object. Same as + target_freq when get_cur_freq() is not implemented by + devfreq driver. -What: /sys/class/devfreq/.../central_polling -Date: September 2011 -Contact: MyungJoo Ham <myungjoo.ham@samsung.com> +What: /sys/class/devfreq/.../target_freq +Date: September 2012 +Contact: Rajagopal Venkat <rajagopal.venkat@linaro.org> Description: - The /sys/class/devfreq/.../central_polling shows whether - the devfreq ojbect is using devfreq-provided central - polling mechanism or not. + The /sys/class/devfreq/.../target_freq shows the next governor + predicted target frequency of the corresponding devfreq object. What: /sys/class/devfreq/.../polling_interval Date: September 2011 @@ -43,6 +44,17 @@ Description: (/sys/class/devfreq/.../central_polling is 0), this value may be useless. +What: /sys/class/devfreq/.../trans_stat +Date: October 2012 +Contact: MyungJoo Ham <myungjoo.ham@samsung.com> +Descrtiption: + This ABI shows the statistics of devfreq behavior on a + specific device. It shows the time spent in each state and + the number of transitions between states. + In order to activate this ABI, the devfreq target device + driver should provide the list of available frequencies + with its profile. + What: /sys/class/devfreq/.../userspace/set_freq Date: September 2011 Contact: MyungJoo Ham <myungjoo.ham@samsung.com> @@ -50,3 +62,19 @@ Description: The /sys/class/devfreq/.../userspace/set_freq shows and sets the requested frequency for the devfreq object if userspace governor is in effect. + +What: /sys/class/devfreq/.../available_frequencies +Date: October 2012 +Contact: Nishanth Menon <nm@ti.com> +Description: + The /sys/class/devfreq/.../available_frequencies shows + the available frequencies of the corresponding devfreq object. + This is a snapshot of available frequencies and not limited + by the min/max frequency restrictions. + +What: /sys/class/devfreq/.../available_governors +Date: October 2012 +Contact: Nishanth Menon <nm@ti.com> +Description: + The /sys/class/devfreq/.../available_governors shows + currently available governors in the system. diff --git a/Documentation/ABI/testing/sysfs-class-net-batman-adv b/Documentation/ABI/testing/sysfs-class-net-batman-adv index 38dd762def4b..bdc00707c751 100644 --- a/Documentation/ABI/testing/sysfs-class-net-batman-adv +++ b/Documentation/ABI/testing/sysfs-class-net-batman-adv @@ -1,4 +1,10 @@ +What: /sys/class/net/<iface>/batman-adv/iface_status +Date: May 2010 +Contact: Marek Lindner <lindner_marek@yahoo.de> +Description: + Indicates the status of <iface> as it is seen by batman. + What: /sys/class/net/<iface>/batman-adv/mesh_iface Date: May 2010 Contact: Marek Lindner <lindner_marek@yahoo.de> @@ -7,8 +13,3 @@ Description: displays the batman mesh interface this <iface> currently is associated with. -What: /sys/class/net/<iface>/batman-adv/iface_status -Date: May 2010 -Contact: Marek Lindner <lindner_marek@yahoo.de> -Description: - Indicates the status of <iface> as it is seen by batman. diff --git a/Documentation/ABI/testing/sysfs-class-net-grcan b/Documentation/ABI/testing/sysfs-class-net-grcan new file mode 100644 index 000000000000..f418c92ca555 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-net-grcan @@ -0,0 +1,35 @@ + +What: /sys/class/net/<iface>/grcan/enable0 +Date: October 2012 +KernelVersion: 3.8 +Contact: Andreas Larsson <andreas@gaisler.com> +Description: + Hardware configuration of physical interface 0. This file reads + and writes the "Enable 0" bit of the configuration register. + Possible values: 0 or 1. See the GRCAN chapter of the GRLIB IP + core library documentation for details. The default value is 0 + or set by the module parameter grcan.enable0 and can be read at + /sys/module/grcan/parameters/enable0. + +What: /sys/class/net/<iface>/grcan/enable1 +Date: October 2012 +KernelVersion: 3.8 +Contact: Andreas Larsson <andreas@gaisler.com> +Description: + Hardware configuration of physical interface 1. This file reads + and writes the "Enable 1" bit of the configuration register. + Possible values: 0 or 1. See the GRCAN chapter of the GRLIB IP + core library documentation for details. The default value is 0 + or set by the module parameter grcan.enable1 and can be read at + /sys/module/grcan/parameters/enable1. + +What: /sys/class/net/<iface>/grcan/select +Date: October 2012 +KernelVersion: 3.8 +Contact: Andreas Larsson <andreas@gaisler.com> +Description: + Configuration of which physical interface to be used. Possible + values: 0 or 1. See the GRCAN chapter of the GRLIB IP core + library documentation for details. The default value is 0 or is + set by the module parameter grcan.select and can be read at + /sys/module/grcan/parameters/select. diff --git a/Documentation/ABI/testing/sysfs-class-net-mesh b/Documentation/ABI/testing/sysfs-class-net-mesh index c81fe89c4c46..bc41da61608d 100644 --- a/Documentation/ABI/testing/sysfs-class-net-mesh +++ b/Documentation/ABI/testing/sysfs-class-net-mesh @@ -6,6 +6,14 @@ Description: Indicates whether the batman protocol messages of the mesh <mesh_iface> shall be aggregated or not. +What: /sys/class/net/<mesh_iface>/mesh/ap_isolation +Date: May 2011 +Contact: Antonio Quartulli <ordex@autistici.org> +Description: + Indicates whether the data traffic going from a + wireless client to another wireless client will be + silently dropped. + What: /sys/class/net/<mesh_iface>/mesh/bonding Date: June 2010 Contact: Simon Wunderlich <siwu@hrz.tu-chemnitz.de> @@ -31,14 +39,6 @@ Description: mesh will be fragmented or silently discarded if the packet size exceeds the outgoing interface MTU. -What: /sys/class/net/<mesh_iface>/mesh/ap_isolation -Date: May 2011 -Contact: Antonio Quartulli <ordex@autistici.org> -Description: - Indicates whether the data traffic going from a - wireless client to another wireless client will be - silently dropped. - What: /sys/class/net/<mesh_iface>/mesh/gw_bandwidth Date: October 2010 Contact: Marek Lindner <lindner_marek@yahoo.de> @@ -60,6 +60,13 @@ Description: Defines the selection criteria this node will use to choose a gateway if gw_mode was set to 'client'. +What: /sys/class/net/<mesh_iface>/mesh/hop_penalty +Date: Oct 2010 +Contact: Linus Lüssing <linus.luessing@web.de> +Description: + Defines the penalty which will be applied to an + originator message's tq-field on every hop. + What: /sys/class/net/<mesh_iface>/mesh/orig_interval Date: May 2010 Contact: Marek Lindner <lindner_marek@yahoo.de> @@ -67,19 +74,12 @@ Description: Defines the interval in milliseconds in which batman sends its protocol messages. -What: /sys/class/net/<mesh_iface>/mesh/hop_penalty -Date: Oct 2010 -Contact: Linus Lüssing <linus.luessing@web.de> -Description: - Defines the penalty which will be applied to an - originator message's tq-field on every hop. - -What: /sys/class/net/<mesh_iface>/mesh/routing_algo -Date: Dec 2011 -Contact: Marek Lindner <lindner_marek@yahoo.de> +What: /sys/class/net/<mesh_iface>/mesh/routing_algo +Date: Dec 2011 +Contact: Marek Lindner <lindner_marek@yahoo.de> Description: - Defines the routing procotol this mesh instance - uses to find the optimal paths through the mesh. + Defines the routing procotol this mesh instance + uses to find the optimal paths through the mesh. What: /sys/class/net/<mesh_iface>/mesh/vis_mode Date: May 2010 diff --git a/Documentation/ABI/testing/sysfs-devices-node b/Documentation/ABI/testing/sysfs-devices-node deleted file mode 100644 index 453a210c3ceb..000000000000 --- a/Documentation/ABI/testing/sysfs-devices-node +++ /dev/null @@ -1,7 +0,0 @@ -What: /sys/devices/system/node/nodeX/compact -Date: February 2010 -Contact: Mel Gorman <mel@csn.ul.ie> -Description: - When this file is written to, all memory within that node - will be compacted. When it completes, memory will be freed - into blocks which have as many contiguous pages as possible diff --git a/Documentation/ABI/testing/sysfs-devices-power b/Documentation/ABI/testing/sysfs-devices-power index 45000f0db4d4..9d43e7670841 100644 --- a/Documentation/ABI/testing/sysfs-devices-power +++ b/Documentation/ABI/testing/sysfs-devices-power @@ -164,7 +164,7 @@ Contact: Rafael J. Wysocki <rjw@sisk.pl> Description: The /sys/devices/.../wakeup_prevent_sleep_time_ms attribute contains the total time the device has been preventing - opportunistic transitions to sleep states from occuring. + opportunistic transitions to sleep states from occurring. This attribute is read-only. If the device is not enabled to wake up the system from sleep states, this attribute is not present. @@ -204,3 +204,34 @@ Description: This attribute has no effect on system-wide suspend/resume and hibernation. + +What: /sys/devices/.../power/pm_qos_no_power_off +Date: September 2012 +Contact: Rafael J. Wysocki <rjw@sisk.pl> +Description: + The /sys/devices/.../power/pm_qos_no_power_off attribute + is used for manipulating the PM QoS "no power off" flag. If + set, this flag indicates to the kernel that power should not + be removed entirely from the device. + + Not all drivers support this attribute. If it isn't supported, + it is not present. + + This attribute has no effect on system-wide suspend/resume and + hibernation. + +What: /sys/devices/.../power/pm_qos_remote_wakeup +Date: September 2012 +Contact: Rafael J. Wysocki <rjw@sisk.pl> +Description: + The /sys/devices/.../power/pm_qos_remote_wakeup attribute + is used for manipulating the PM QoS "remote wakeup required" + flag. If set, this flag indicates to the kernel that the + device is a source of user events that have to be signaled from + its low-power states. + + Not all drivers support this attribute. If it isn't supported, + it is not present. + + This attribute has no effect on system-wide suspend/resume and + hibernation. 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 000000000000..73b77a6be196 --- /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 000000000000..30c20703fb8c --- /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 000000000000..fd9d84b421e1 --- /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 000000000000..3df32c20addf --- /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_state b/Documentation/ABI/testing/sysfs-devices-power_state new file mode 100644 index 000000000000..7ad9546748f0 --- /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 000000000000..8b3527c82a7d --- /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 000000000000..b4a3bc5922a3 --- /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 new file mode 100644 index 000000000000..86be9848a77e --- /dev/null +++ b/Documentation/ABI/testing/sysfs-devices-sun @@ -0,0 +1,14 @@ +Whatt: /sys/devices/.../sun +Date: October 2012 +Contact: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com> +Description: + The file contains a Slot-unique ID which provided by the _SUN + method in the ACPI namespace. The value is written in Advanced + Configuration and Power Interface Specification as follows: + + "The _SUN value is required to be unique among the slots of + the same type. It is also recommended that this number match + the slot number printed on the physical slot whenever possible." + + So reading the sysfs file, we can identify a physical position + of the slot in the system. diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu index 6943133afcb8..9c978dcae07d 100644 --- a/Documentation/ABI/testing/sysfs-devices-system-cpu +++ b/Documentation/ABI/testing/sysfs-devices-system-cpu @@ -67,20 +67,6 @@ Description: Discover NUMA node a CPU belongs to /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 diff --git a/Documentation/ABI/testing/sysfs-driver-hid-roccat-isku b/Documentation/ABI/testing/sysfs-driver-hid-roccat-isku index 189dc43891bf..9eca5a182e64 100644 --- a/Documentation/ABI/testing/sysfs-driver-hid-roccat-isku +++ b/Documentation/ABI/testing/sysfs-driver-hid-roccat-isku @@ -117,6 +117,14 @@ Description: When written, this file lets one store macros with max 500 which profile and key 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>/isku/roccatisku<minor>/reset +Date: November 2012 +Contact: Stefan Achatz <erazor_de@users.sourceforge.net> +Description: When written, this file lets one reset the device. + 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>/isku/roccatisku<minor>/control Date: June 2011 Contact: Stefan Achatz <erazor_de@users.sourceforge.net> diff --git a/Documentation/ABI/testing/sysfs-driver-hid-roccat-koneplus b/Documentation/ABI/testing/sysfs-driver-hid-roccat-koneplus index 65e6e5dd67e8..7bd776f9c3c7 100644 --- a/Documentation/ABI/testing/sysfs-driver-hid-roccat-koneplus +++ b/Documentation/ABI/testing/sysfs-driver-hid-roccat-koneplus @@ -9,15 +9,12 @@ Description: The integer value of this attribute ranges from 0-4. and the mouse activates this profile immediately. Users: http://roccat.sourceforge.net -What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/firmware_version -Date: October 2010 +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/info +Date: November 2012 Contact: Stefan Achatz <erazor_de@users.sourceforge.net> -Description: When read, this file returns the raw integer version number of the - firmware reported by the mouse. Using the integer value eases - further usage in other programs. To receive the real version - number the decimal point has to be shifted 2 positions to the - left. E.g. a returned value of 121 means 1.21 - This file is readonly. +Description: When read, this file returns general data like firmware version. + When written, the device can be reset. + The data is 8 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>/koneplus/roccatkoneplus<minor>/macro @@ -42,18 +39,8 @@ Description: The mouse can store 5 profiles which can be switched by the The mouse will reject invalid data. Which profile to write is determined by the profile number contained in the data. - 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>/koneplus/roccatkoneplus<minor>/profile[1-5]_buttons -Date: August 2010 -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 read, these files return the respective profile buttons. - The returned data is 77 bytes in size. - This file is readonly. + 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>/koneplus/roccatkoneplus<minor>/profile_settings @@ -68,19 +55,8 @@ Description: The mouse can store 5 profiles which can be switched by the The mouse will reject invalid data. Which profile to write is determined by the profile number contained in the data. - 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>/koneplus/roccatkoneplus<minor>/profile[1-5]_settings -Date: August 2010 -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 read, these files return the respective profile settings. - The returned data is 43 bytes in size. - This file is readonly. + 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>/koneplus/roccatkoneplus<minor>/sensor @@ -104,9 +80,9 @@ What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid- Date: October 2010 Contact: Stefan Achatz <erazor_de@users.sourceforge.net> Description: When written a calibration process for the tracking control unit - can be initiated/cancelled. - The data has to be 3 bytes long. - This file is writeonly. + 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>/koneplus/roccatkoneplus<minor>/tcu_image diff --git a/Documentation/ABI/testing/sysfs-driver-hid-roccat-kovaplus b/Documentation/ABI/testing/sysfs-driver-hid-roccat-kovaplus index 20f937c9d84f..a10404f15a54 100644 --- a/Documentation/ABI/testing/sysfs-driver-hid-roccat-kovaplus +++ b/Documentation/ABI/testing/sysfs-driver-hid-roccat-kovaplus @@ -1,12 +1,3 @@ -What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/actual_cpi -Date: January 2011 -Contact: Stefan Achatz <erazor_de@users.sourceforge.net> -Description: The integer value of this attribute ranges from 1-4. - When read, this attribute returns the number of the active - cpi level. - This file is readonly. -Users: http://roccat.sourceforge.net - What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/actual_profile Date: January 2011 Contact: Stefan Achatz <erazor_de@users.sourceforge.net> @@ -18,33 +9,12 @@ Description: The integer value of this attribute ranges from 0-4. active when the mouse is powered on. Users: http://roccat.sourceforge.net -What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/actual_sensitivity_x -Date: January 2011 +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/info +Date: November 2012 Contact: Stefan Achatz <erazor_de@users.sourceforge.net> -Description: The integer value of this attribute ranges from 1-10. - When read, this attribute returns the number of the actual - sensitivity in x direction. - This file is readonly. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/actual_sensitivity_y -Date: January 2011 -Contact: Stefan Achatz <erazor_de@users.sourceforge.net> -Description: The integer value of this attribute ranges from 1-10. - When read, this attribute returns the number of the actual - sensitivity in y direction. - This file is readonly. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/firmware_version -Date: January 2011 -Contact: Stefan Achatz <erazor_de@users.sourceforge.net> -Description: When read, this file returns the raw integer version number of the - firmware reported by the mouse. Using the integer value eases - further usage in other programs. To receive the real version - number the decimal point has to be shifted 2 positions to the - left. E.g. a returned value of 121 means 1.21 - This file is readonly. +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>/kovaplus/roccatkovaplus<minor>/profile_buttons @@ -58,18 +28,8 @@ Description: The mouse can store 5 profiles which can be switched by the The mouse will reject invalid data. Which profile to write is determined by the profile number contained in the data. - 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>/kovaplus/roccatkovaplus<minor>/profile[1-5]_buttons -Date: January 2011 -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 read, these files return the respective profile buttons. - The returned data is 23 bytes in size. - This file is readonly. + 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>/kovaplus/roccatkovaplus<minor>/profile_settings @@ -84,17 +44,6 @@ Description: The mouse can store 5 profiles which can be switched by the The mouse will reject invalid data. Which profile to write is determined by the profile number contained in the data. - 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>/kovaplus/roccatkovaplus<minor>/profile[1-5]_settings -Date: January 2011 -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 read, these files return the respective profile settings. - The returned data is 16 bytes in size. - This file is readonly. + Before reading this file, control has to be written to select + which profile to read. Users: http://roccat.sourceforge.net diff --git a/Documentation/ABI/testing/sysfs-driver-hid-roccat-lua b/Documentation/ABI/testing/sysfs-driver-hid-roccat-lua new file mode 100644 index 000000000000..31c6c4c8ba2b --- /dev/null +++ b/Documentation/ABI/testing/sysfs-driver-hid-roccat-lua @@ -0,0 +1,7 @@ +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/control +Date: October 2012 +Contact: Stefan Achatz <erazor_de@users.sourceforge.net> +Description: When written, cpi, button and light settings can be configured. + When read, actual cpi setting and sensor data are returned. + The data has to be 8 bytes long. +Users: http://roccat.sourceforge.net diff --git a/Documentation/ABI/testing/sysfs-driver-hid-roccat-pyra b/Documentation/ABI/testing/sysfs-driver-hid-roccat-pyra index 3f8de50e4ff1..9fa9de30d14b 100644 --- a/Documentation/ABI/testing/sysfs-driver-hid-roccat-pyra +++ b/Documentation/ABI/testing/sysfs-driver-hid-roccat-pyra @@ -1,37 +1,9 @@ -What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/actual_cpi -Date: August 2010 -Contact: Stefan Achatz <erazor_de@users.sourceforge.net> -Description: It is possible to switch the cpi setting of the mouse with the - press of a button. - When read, this file returns the raw number of the actual cpi - setting reported by the mouse. This number has to be further - processed to receive the real dpi value. - - VALUE DPI - 1 400 - 2 800 - 4 1600 - - This file is readonly. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/actual_profile -Date: August 2010 +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/info +Date: November 2012 Contact: Stefan Achatz <erazor_de@users.sourceforge.net> -Description: When read, this file returns the number of the actual profile in - range 0-4. - This file is readonly. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/firmware_version -Date: August 2010 -Contact: Stefan Achatz <erazor_de@users.sourceforge.net> -Description: When read, this file returns the raw integer version number of the - firmware reported by the mouse. Using the integer value eases - further usage in other programs. To receive the real version - number the decimal point has to be shifted 2 positions to the - left. E.g. a returned value of 138 means 1.38 - This file is readonly. +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>/pyra/roccatpyra<minor>/profile_settings @@ -46,19 +18,8 @@ Description: The mouse can store 5 profiles which can be switched by the The mouse will reject invalid data. Which profile to write is determined by the profile number contained in the data. - 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>/pyra/roccatpyra<minor>/profile[1-5]_settings -Date: August 2010 -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 read, these files return the respective profile settings. - The returned data is 13 bytes in size. - This file is readonly. + 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>/pyra/roccatpyra<minor>/profile_buttons @@ -72,27 +33,8 @@ Description: The mouse can store 5 profiles which can be switched by the The mouse will reject invalid data. Which profile to write is determined by the profile number contained in the data. - 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>/pyra/roccatpyra<minor>/profile[1-5]_buttons -Date: August 2010 -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 read, these files return the respective profile buttons. - The returned data is 19 bytes in size. - This file is readonly. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/startup_profile -Date: August 2010 -Contact: Stefan Achatz <erazor_de@users.sourceforge.net> -Description: The integer value of this attribute ranges from 0-4. - When read, this attribute returns the number of the profile - that's active when the mouse is powered on. - This file is readonly. + 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>/pyra/roccatpyra<minor>/settings diff --git a/Documentation/ABI/testing/sysfs-driver-hid-roccat-savu b/Documentation/ABI/testing/sysfs-driver-hid-roccat-savu index b42922cf6b1f..f1e02a98bd9d 100644 --- a/Documentation/ABI/testing/sysfs-driver-hid-roccat-savu +++ b/Documentation/ABI/testing/sysfs-driver-hid-roccat-savu @@ -40,8 +40,8 @@ What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid- Date: Mai 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 8 bytes long. - This file is readonly. Users: http://roccat.sourceforge.net What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/savu/roccatsavu<minor>/macro @@ -74,4 +74,3 @@ Description: The mouse has a Avago ADNS-3090 sensor. This file allows reading and writing of the mouse sensors registers. The data has to be 4 bytes long. 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 000000000000..d0eba70c7d40 --- /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 000000000000..abcffeedd20a --- /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-ppi b/Documentation/ABI/testing/sysfs-driver-ppi index 97a003ee058b..7d1435bc976c 100644 --- a/Documentation/ABI/testing/sysfs-driver-ppi +++ b/Documentation/ABI/testing/sysfs-driver-ppi @@ -5,7 +5,7 @@ Contact: xiaoyan.zhang@intel.com Description: This folder includes the attributes related with PPI (Physical Presence Interface). Only if TPM is supported by BIOS, this - folder makes sence. The folder path can be got by command + folder makes sense. The folder path can be got by command 'find /sys/ -name 'pcrs''. For the detail information of PPI, please refer to the PPI specification from http://www.trustedcomputinggroup.org/ diff --git a/Documentation/ABI/testing/sysfs-kernel-mm-ksm b/Documentation/ABI/testing/sysfs-kernel-mm-ksm new file mode 100644 index 000000000000..73e653ee2481 --- /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 000000000000..307a247ba1ef --- /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 000000000000..c88375a537a1 --- /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/ABI/testing/sysfs-profiling b/Documentation/ABI/testing/sysfs-profiling index b02d8b8c173a..8a8e466eb2c0 100644 --- a/Documentation/ABI/testing/sysfs-profiling +++ b/Documentation/ABI/testing/sysfs-profiling @@ -1,13 +1,13 @@ -What: /sys/kernel/profile +What: /sys/kernel/profiling Date: September 2008 Contact: Dave Hansen <dave@linux.vnet.ibm.com> Description: - /sys/kernel/profile is the runtime equivalent + /sys/kernel/profiling is the runtime equivalent of the boot-time profile= option. You can get the same effect running: - echo 2 > /sys/kernel/profile + echo 2 > /sys/kernel/profiling as you would by issuing profile=2 on the boot command line. diff --git a/Documentation/ABI/testing/sysfs-tty b/Documentation/ABI/testing/sysfs-tty index 0c430150d929..ad22fb0ee765 100644 --- a/Documentation/ABI/testing/sysfs-tty +++ b/Documentation/ABI/testing/sysfs-tty @@ -26,3 +26,115 @@ Description: UART port in serial_core, that is bound to TTY like ttyS0. uartclk = 16 * baud_base + These sysfs values expose the TIOCGSERIAL interface via + sysfs rather than via ioctls. + +What: /sys/class/tty/ttyS0/type +Date: October 2012 +Contact: Alan Cox <alan@linux.intel.com> +Description: + Shows the current tty type for this port. + + These sysfs values expose the TIOCGSERIAL interface via + sysfs rather than via ioctls. + +What: /sys/class/tty/ttyS0/line +Date: October 2012 +Contact: Alan Cox <alan@linux.intel.com> +Description: + Shows the current tty line number for this port. + + These sysfs values expose the TIOCGSERIAL interface via + sysfs rather than via ioctls. + +What: /sys/class/tty/ttyS0/port +Date: October 2012 +Contact: Alan Cox <alan@linux.intel.com> +Description: + Shows the current tty port I/O address for this port. + + These sysfs values expose the TIOCGSERIAL interface via + sysfs rather than via ioctls. + +What: /sys/class/tty/ttyS0/irq +Date: October 2012 +Contact: Alan Cox <alan@linux.intel.com> +Description: + Shows the current primary interrupt for this port. + + These sysfs values expose the TIOCGSERIAL interface via + sysfs rather than via ioctls. + +What: /sys/class/tty/ttyS0/flags +Date: October 2012 +Contact: Alan Cox <alan@linux.intel.com> +Description: + Show the tty port status flags for this port. + + These sysfs values expose the TIOCGSERIAL interface via + sysfs rather than via ioctls. + +What: /sys/class/tty/ttyS0/xmit_fifo_size +Date: October 2012 +Contact: Alan Cox <alan@linux.intel.com> +Description: + Show the transmit FIFO size for this port. + + These sysfs values expose the TIOCGSERIAL interface via + sysfs rather than via ioctls. + +What: /sys/class/tty/ttyS0/close_delay +Date: October 2012 +Contact: Alan Cox <alan@linux.intel.com> +Description: + Show the closing delay time for this port in ms. + + These sysfs values expose the TIOCGSERIAL interface via + sysfs rather than via ioctls. + +What: /sys/class/tty/ttyS0/closing_wait +Date: October 2012 +Contact: Alan Cox <alan@linux.intel.com> +Description: + Show the close wait time for this port in ms. + + These sysfs values expose the TIOCGSERIAL interface via + sysfs rather than via ioctls. + +What: /sys/class/tty/ttyS0/custom_divisor +Date: October 2012 +Contact: Alan Cox <alan@linux.intel.com> +Description: + Show the custom divisor if any that is set on this port. + + These sysfs values expose the TIOCGSERIAL interface via + sysfs rather than via ioctls. + +What: /sys/class/tty/ttyS0/io_type +Date: October 2012 +Contact: Alan Cox <alan@linux.intel.com> +Description: + Show the I/O type that is to be used with the iomem base + address. + + These sysfs values expose the TIOCGSERIAL interface via + sysfs rather than via ioctls. + +What: /sys/class/tty/ttyS0/iomem_base +Date: October 2012 +Contact: Alan Cox <alan@linux.intel.com> +Description: + The I/O memory base for this port. + + These sysfs values expose the TIOCGSERIAL interface via + sysfs rather than via ioctls. + +What: /sys/class/tty/ttyS0/iomem_reg_shift +Date: October 2012 +Contact: Alan Cox <alan@linux.intel.com> +Description: + Show the register shift indicating the spacing to be used + for accesses on this iomem address. + + These sysfs values expose the TIOCGSERIAL interface via + sysfs rather than via ioctls. diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle index 495e5ba1634c..e00b8f0dde52 100644 --- a/Documentation/CodingStyle +++ b/Documentation/CodingStyle @@ -546,15 +546,7 @@ config AUDIT 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 a0b6250add79..14129f149a75 100644 --- a/Documentation/DMA-API-HOWTO.txt +++ b/Documentation/DMA-API-HOWTO.txt @@ -468,11 +468,47 @@ To map a single region, you do: size_t size = buffer->len; dma_handle = dma_map_single(dev, addr, size, direction); + if (dma_mapping_error(dma_handle)) { + /* + * reduce current DMA mapping usage, + * delay and try again later or + * reset driver. + */ + goto map_error_handling; + } and to unmap it: dma_unmap_single(dev, dma_handle, size, direction); +You should call dma_mapping_error() as dma_map_single() could fail and return +error. Not all dma implementations support dma_mapping_error() interface. +However, it is a good practice to call dma_mapping_error() interface, which +will invoke the generic mapping error check interface. Doing so will ensure +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. 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; + + dma_handle = dma_map_single(dev, addr, size, direction); + if ((dma_handle & 0xffff != 0) || (dma_handle >= 0x1000000)) { + goto map_error; + } + +Incorrect example 2: + dma_addr_t dma_handle; + + dma_handle = dma_map_single(dev, addr, size, direction); + if (dma_handle == DMA_ERROR_CODE) { + goto map_error; + } + You should call dma_unmap_single when the DMA activity is finished, e.g. from the interrupt which told you that the DMA transfer is done. @@ -489,6 +525,14 @@ Specifically: size_t size = buffer->len; dma_handle = dma_map_page(dev, page, offset, size, direction); + if (dma_mapping_error(dma_handle)) { + /* + * reduce current DMA mapping usage, + * delay and try again later or + * reset driver. + */ + goto map_error_handling; + } ... @@ -496,6 +540,12 @@ Specifically: Here, "offset" means byte offset within the given page. +You should call dma_mapping_error() as dma_map_page() could fail and return +error as outlined under the dma_map_single() discussion. + +You should call dma_unmap_page when the DMA activity is finished, e.g. +from the interrupt which told you that the DMA transfer is done. + With scatterlists, you map a region gathered from several regions by: int i, count = dma_map_sg(dev, sglist, nents, direction); @@ -578,6 +628,14 @@ to use the dma_sync_*() interfaces. dma_addr_t mapping; mapping = dma_map_single(cp->dev, buffer, len, DMA_FROM_DEVICE); + if (dma_mapping_error(dma_handle)) { + /* + * reduce current DMA mapping usage, + * delay and try again later or + * reset driver. + */ + goto map_error_handling; + } cp->rx_buf = buffer; cp->rx_len = len; @@ -658,6 +716,75 @@ failure can be determined by: * delay and try again later or * reset driver. */ + goto map_error_handling; + } + +- unmap pages that are already mapped, when mapping error occurs in the middle + of a multiple page mapping attempt. These example are applicable to + dma_map_page() as well. + +Example 1: + dma_addr_t dma_handle1; + dma_addr_t dma_handle2; + + dma_handle1 = dma_map_single(dev, addr, size, direction); + if (dma_mapping_error(dev, dma_handle1)) { + /* + * reduce current DMA mapping usage, + * delay and try again later or + * reset driver. + */ + goto map_error_handling1; + } + dma_handle2 = dma_map_single(dev, addr, size, direction); + if (dma_mapping_error(dev, dma_handle2)) { + /* + * reduce current DMA mapping usage, + * delay and try again later or + * reset driver. + */ + goto map_error_handling2; + } + + ... + + map_error_handling2: + dma_unmap_single(dma_handle1); + map_error_handling1: + +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; + dma_addr_t array[DMA_BUFFERS]; + int save_index = 0; + + for (i = 0; i < DMA_BUFFERS; i++) { + + ... + + dma_addr = dma_map_single(dev, addr, size, direction); + if (dma_mapping_error(dev, dma_addr)) { + /* + * reduce current DMA mapping usage, + * delay and try again later or + * reset driver. + */ + goto map_error_handling; + } + array[i].dma_addr = dma_addr; + save_index++; + } + + ... + + map_error_handling: + + for (i = 0; i < save_index; i++) { + + ... + + dma_unmap_single(array[i].dma_addr); } Networking drivers must call dev_kfree_skb to free the socket buffer diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt index 66bd97a95f10..78a6c569d204 100644 --- a/Documentation/DMA-API.txt +++ b/Documentation/DMA-API.txt @@ -678,3 +678,15 @@ out of dma_debug_entries. These entries are preallocated at boot. The number of preallocated entries is defined per architecture. If it is too low for you boot with 'dma_debug_entries=<your_desired_number>' to overwrite the architectural default. + +void debug_dmap_mapping_error(struct device *dev, dma_addr_t dma_addr); + +dma-debug interface debug_dma_mapping_error() to debug drivers that fail +to check dma mapping errors on addresses returned by dma_map_single() and +dma_map_page() interfaces. This interface clears a flag set by +debug_dma_map_page() to indicate that dma_mapping_error() has been called by +the driver. When driver does unmap, debug_dma_unmap() checks the flag and if +this flag is still set, prints warning message that includes call trace that +leads up to the unmap. This interface can be called from dma_mapping_error() +routines to enable dma mapping error check debugging. + diff --git a/Documentation/DMA-attributes.txt b/Documentation/DMA-attributes.txt index f50309081ac7..e59480db9ee0 100644 --- a/Documentation/DMA-attributes.txt +++ b/Documentation/DMA-attributes.txt @@ -91,3 +91,12 @@ transferred to 'device' domain. This attribute can be also used for dma_unmap_{single,page,sg} functions family to force buffer to stay in device domain after releasing a mapping for it. Use this attribute with care! + +DMA_ATTR_FORCE_CONTIGUOUS +------------------------- + +By default DMA-mapping subsystem is allowed to assemble the buffer +allocated by dma_alloc_attrs() function from individual pages if it can +be mapped as contiguous chunk into device dma address space. By +specifing this attribute the allocated buffer is forced to be contiguous +also in physical memory. diff --git a/Documentation/DocBook/80211.tmpl b/Documentation/DocBook/80211.tmpl index 42e7f030cb16..284ced7a228f 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 diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index b0300529ab13..f9df3b872c16 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -743,6 +743,10 @@ char *date;</synopsis> 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 +982,25 @@ int max_width, max_height;</synopsis> 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 +1041,16 @@ int max_width, max_height;</synopsis> </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 +1062,22 @@ int max_width, max_height;</synopsis> 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 --> @@ -1126,6 +1161,12 @@ int max_width, max_height;</synopsis> 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>. @@ -1141,23 +1182,13 @@ int max_width, max_height;</synopsis> the <methodname>page_flip</methodname> operation will be called with a non-NULL <parameter>event</parameter> argument pointing to a <structname>drm_pending_vblank_event</structname> instance. Upon page - flip completion the driver must fill the - <parameter>event</parameter>::<structfield>event</structfield> - <structfield>sequence</structfield>, <structfield>tv_sec</structfield> - and <structfield>tv_usec</structfield> fields with the associated - vertical blanking count and timestamp, add the event to the - <parameter>drm_file</parameter> list of events to be signaled, and wake - up any waiting process. This can be performed with + flip completion the driver must call <methodname>drm_send_vblank_event</methodname> + to fill in the event and send to wake up any waiting processes. + This can be performed with <programlisting><![CDATA[ - struct timeval now; - - event->event.sequence = drm_vblank_count_and_time(..., &now); - event->event.tv_sec = now.tv_sec; - event->event.tv_usec = now.tv_usec; - spin_lock_irqsave(&dev->event_lock, flags); - list_add_tail(&event->base.link, &event->base.file_priv->event_list); - wake_up_interruptible(&event->base.file_priv->event_wait); + ... + drm_send_vblank_event(dev, pipe, event); spin_unlock_irqrestore(&dev->event_lock, flags); ]]></programlisting> </para> @@ -1619,12 +1650,16 @@ void intel_crt_init(struct drm_device *dev) make its properties available to applications. </para> </sect2> + <sect2> + <title>KMS API Functions</title> +!Edrivers/gpu/drm/drm_crtc.c + </sect2> </sect1> - <!-- Internals: mid-layer helper functions --> + <!-- Internals: kms helper functions --> <sect1> - <title>Mid-layer Helper Functions</title> + <title>Mode Setting Helper Functions</title> <para> The CRTC, encoder and connector functions provided by the drivers implement the DRM API. They're called by the DRM core and ioctl handlers @@ -2106,6 +2141,26 @@ void intel_crt_init(struct drm_device *dev) </listitem> </itemizedlist> </sect2> + <sect2> + <title>Modeset Helper Functions Reference</title> +!Edrivers/gpu/drm/drm_crtc_helper.c + </sect2> + <sect2> + <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> +!Pdrivers/gpu/drm/drm_dp_helper.c dp helpers +!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> </sect1> <!-- Internals: vertical blanking --> diff --git a/Documentation/DocBook/gadget.tmpl b/Documentation/DocBook/gadget.tmpl index 6ef2f0073e5a..4017f147ba2f 100644 --- a/Documentation/DocBook/gadget.tmpl +++ b/Documentation/DocBook/gadget.tmpl @@ -671,7 +671,7 @@ than a kernel driver. <para>There's a USB Mass Storage class driver, which provides a different solution for interoperability with systems such as MS-Windows and MacOS. -That <emphasis>File-backed Storage</emphasis> driver uses a +That <emphasis>Mass Storage</emphasis> driver uses a file or block device as backing store for a drive, like the <filename>loop</filename> driver. The USB host uses the BBB, CB, or CBI versions of the mass diff --git a/Documentation/DocBook/kernel-api.tmpl b/Documentation/DocBook/kernel-api.tmpl index 00687ee9d363..f75ab4c1b281 100644 --- a/Documentation/DocBook/kernel-api.tmpl +++ b/Documentation/DocBook/kernel-api.tmpl @@ -58,6 +58,9 @@ <sect1><title>String Conversions</title> !Elib/vsprintf.c +!Finclude/linux/kernel.h kstrtol +!Finclude/linux/kernel.h kstrtoul +!Elib/kstrtox.c </sect1> <sect1><title>String Manipulation</title> <!-- All functions are exported at now diff --git a/Documentation/DocBook/kernel-hacking.tmpl b/Documentation/DocBook/kernel-hacking.tmpl index eee71426ecb8..d0758b241b23 100644 --- a/Documentation/DocBook/kernel-hacking.tmpl +++ b/Documentation/DocBook/kernel-hacking.tmpl @@ -945,7 +945,7 @@ printk(KERN_INFO "my ip: %pI4\n", &ipaddress); <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 @@ printk(KERN_INFO "my ip: %pI4\n", &ipaddress); <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 @@ static struct block_device_operations opt_fops = { </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/kgdb.tmpl b/Documentation/DocBook/kgdb.tmpl index 4ee4ba3509fc..f77358f96930 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 757488b24f4f..0197bcc7842d 100644 --- a/Documentation/DocBook/media/dvb/dvbapi.xml +++ b/Documentation/DocBook/media/dvb/dvbapi.xml @@ -84,7 +84,7 @@ Added ISDB-T test originally written by Patrick Boettcher <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 957e3acaae8e..4a5eaeed0b9e 100644 --- a/Documentation/DocBook/media/dvb/dvbproperty.xml +++ b/Documentation/DocBook/media/dvb/dvbproperty.xml @@ -7,14 +7,41 @@ 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 @@ typedef enum fe_delivery_system { <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,147 @@ enum fe_interleaving { <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> + <section id = "fecap-scale-params"> + <itemizedlist mark='bullet'> + <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> + </section> + </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><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem> + <listitem><constant>FE_SCALE_DECIBEL</constant> - signal strength is in 0.0001 dBm units, power measured in miliwatts. This value is generally negative.</listitem> + <listitem><constant>FE_SCALE_RELATIVE</constant> - The frontend provides a 0% to 100% measurement for power (actually, 0 to 65535).</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><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem> + <listitem><constant>FE_SCALE_DECIBEL</constant> - Signal/Noise ratio is in 0.0001 dB units.</listitem> + <listitem><constant>FE_SCALE_RELATIVE</constant> - The frontend provides a 0% to 100% measurement for Signal/Noise (actually, 0 to 65535).</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><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem> + <listitem><constant>FE_SCALE_COUNTER</constant> - Number of error bits counted before the inner coding.</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, loosing 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><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem> + <listitem><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>.</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><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem> + <listitem><constant>FE_SCALE_COUNTER</constant> - Number of error bits counted after the inner coding.</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, loosing 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><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem> + <listitem><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>.</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><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem> + <listitem><constant>FE_SCALE_COUNTER</constant> - Number of error blocks counted after the outer coding.</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><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem> + <listitem><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>.</listitem> + </itemizedlist> + </section> + </section> + <section id="frontend-property-terrestrial-systems"> <title>Properties used on terrestrial delivery systems</title> <section id="dvbt-params"> @@ -871,6 +1039,7 @@ enum fe_interleaving { <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 +1064,7 @@ enum fe_interleaving { <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 +1118,7 @@ enum fe_interleaving { <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 +1132,7 @@ enum fe_interleaving { <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 +1160,7 @@ enum fe_interleaving { <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 +1180,7 @@ enum fe_interleaving { <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 +1202,7 @@ enum fe_interleaving { <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 +1218,7 @@ enum fe_interleaving { <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 +1238,7 @@ enum fe_interleaving { <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 +1254,7 @@ enum fe_interleaving { <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 426c2526a454..df39ba395df0 100644 --- a/Documentation/DocBook/media/dvb/frontend.xml +++ b/Documentation/DocBook/media/dvb/frontend.xml @@ -230,7 +230,7 @@ typedef enum fe_status { <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> diff --git a/Documentation/DocBook/media/v4l/common.xml b/Documentation/DocBook/media/v4l/common.xml index 73c6847436c9..ae06afbbb3a9 100644 --- a/Documentation/DocBook/media/v4l/common.xml +++ b/Documentation/DocBook/media/v4l/common.xml @@ -609,7 +609,7 @@ to zero and the <constant>VIDIOC_G_STD</constant>, <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 diff --git a/Documentation/DocBook/media/v4l/compat.xml b/Documentation/DocBook/media/v4l/compat.xml index 4fdf6b562d1c..104a1a2b8849 100644 --- a/Documentation/DocBook/media/v4l/compat.xml +++ b/Documentation/DocBook/media/v4l/compat.xml @@ -2477,6 +2477,22 @@ that used it. It was originally scheduled for removal in 2.6.35. </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 id="other"> <title>Relation of V4L2 to other Linux multimedia APIs</title> @@ -2586,6 +2602,13 @@ ioctls.</para> <para>Vendor and device specific media bus pixel formats. <xref linkend="v4l2-mbus-vendor-spec-fmts" />.</para> </listitem> + <listitem> + <para>Importing DMABUF file descriptors as a new IO method described + in <xref linkend="dmabuf" />.</para> + </listitem> + <listitem> + <para>Exporting DMABUF files using &VIDIOC-EXPBUF; ioctl.</para> + </listitem> </itemizedlist> </section> diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml index 7fe5be1d3bbb..9e8f85498678 100644 --- a/Documentation/DocBook/media/v4l/controls.xml +++ b/Documentation/DocBook/media/v4l/controls.xml @@ -203,29 +203,6 @@ and should not be used in new drivers and applications.</entry> <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> diff --git a/Documentation/DocBook/media/v4l/driver.xml b/Documentation/DocBook/media/v4l/driver.xml index eacafe312cd2..7c6638bacedb 100644 --- a/Documentation/DocBook/media/v4l/driver.xml +++ b/Documentation/DocBook/media/v4l/driver.xml @@ -116,7 +116,7 @@ my_suspend (struct pci_dev * pci_dev, 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 @@ my_remove (struct pci_dev * pci_dev) /* 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 @@ my_pci_driver = { .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 b5d1cbdc558b..e6c58559ca6b 100644 --- a/Documentation/DocBook/media/v4l/io.xml +++ b/Documentation/DocBook/media/v4l/io.xml @@ -331,7 +331,7 @@ application until one or more buffers can be dequeued. By default outgoing queue. When the <constant>O_NONBLOCK</constant> flag was given to the &func-open; function, <constant>VIDIOC_DQBUF</constant> returns immediately with an &EAGAIN; when no buffer is available. The -&func-select; or &func-poll; function are always available.</para> +&func-select; or &func-poll; functions are always available.</para> <para>To start and stop capturing or output applications call the &VIDIOC-STREAMON; and &VIDIOC-STREAMOFF; ioctl. Note @@ -472,6 +472,165 @@ rest should be evident.</para> </footnote></para> </section> + <section id="dmabuf"> + <title>Streaming I/O (DMA buffer importing)</title> + + <note> + <title>Experimental</title> + <para>This is an <link linkend="experimental">experimental</link> + interface and may change in the future.</para> + </note> + +<para>The DMABUF framework provides a generic method for sharing buffers +between multiple devices. Device drivers that support DMABUF can export a DMA +buffer to userspace as a file descriptor (known as the exporter role), import a +DMA buffer from userspace using a file descriptor previously exported for a +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 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 +<constant>V4L2_CAP_STREAMING</constant> flag in the +<structfield>capabilities</structfield> field of &v4l2-capability; returned by +the &VIDIOC-QUERYCAP; ioctl is set. Whether importing DMA buffers through +DMABUF file descriptors is supported is determined by calling the +&VIDIOC-REQBUFS; ioctl with the memory type set to +<constant>V4L2_MEMORY_DMABUF</constant>.</para> + + <para>This I/O method is dedicated to sharing DMA buffers between different +devices, which may be V4L devices or other video-related devices (e.g. DRM). +Buffers (planes) are allocated by a driver on behalf of an application. Next, +these buffers are exported to the application as file descriptors using an API +which is specific for an allocator driver. Only such file descriptor are +exchanged. The descriptors and meta-information are passed in &v4l2-buffer; (or +in &v4l2-plane; in the multi-planar API case). The driver must be switched +into DMABUF I/O mode by calling the &VIDIOC-REQBUFS; with the desired buffer +type.</para> + + <example> + <title>Initiating streaming I/O with DMABUF file descriptors</title> + + <programlisting> +&v4l2-requestbuffers; reqbuf; + +memset(&reqbuf, 0, sizeof (reqbuf)); +reqbuf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; +reqbuf.memory = V4L2_MEMORY_DMABUF; +reqbuf.count = 1; + +if (ioctl(fd, &VIDIOC-REQBUFS;, &reqbuf) == -1) { + if (errno == EINVAL) + printf("Video capturing or DMABUF streaming is not supported\n"); + else + perror("VIDIOC_REQBUFS"); + + exit(EXIT_FAILURE); +} + </programlisting> + </example> + + <para>The buffer (plane) file descriptor is passed on the fly with the +&VIDIOC-QBUF; ioctl. In case of multiplanar buffers, every plane can be +associated with a different DMABUF descriptor. Although buffers are commonly +cycled, applications can pass a different DMABUF descriptor at each +<constant>VIDIOC_QBUF</constant> call.</para> + + <example> + <title>Queueing DMABUF using single plane API</title> + + <programlisting> +int buffer_queue(int v4lfd, int index, int dmafd) +{ + &v4l2-buffer; buf; + + memset(&buf, 0, sizeof buf); + buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + buf.memory = V4L2_MEMORY_DMABUF; + buf.index = index; + buf.m.fd = dmafd; + + if (ioctl(v4lfd, &VIDIOC-QBUF;, &buf) == -1) { + perror("VIDIOC_QBUF"); + return -1; + } + + return 0; +} + </programlisting> + </example> + + <example> + <title>Queueing DMABUF using multi plane API</title> + + <programlisting> +int buffer_queue_mp(int v4lfd, int index, int dmafd[], int n_planes) +{ + &v4l2-buffer; buf; + &v4l2-plane; planes[VIDEO_MAX_PLANES]; + int i; + + memset(&buf, 0, sizeof buf); + buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE; + buf.memory = V4L2_MEMORY_DMABUF; + buf.index = index; + buf.m.planes = planes; + buf.length = n_planes; + + memset(&planes, 0, sizeof planes); + + for (i = 0; i < n_planes; ++i) + buf.m.planes[i].m.fd = dmafd[i]; + + if (ioctl(v4lfd, &VIDIOC-QBUF;, &buf) == -1) { + perror("VIDIOC_QBUF"); + return -1; + } + + return 0; +} + </programlisting> + </example> + + <para>Captured or displayed buffers are dequeued with the +&VIDIOC-DQBUF; ioctl. The driver can unlock the buffer at any +time between the completion of the DMA and this ioctl. The memory is +also unlocked when &VIDIOC-STREAMOFF; is called, &VIDIOC-REQBUFS;, or +when the device is closed.</para> + + <para>For capturing applications it is customary to enqueue a +number of empty buffers, to start capturing and enter the read loop. +Here the application waits until a filled buffer can be dequeued, and +re-enqueues the buffer when the data is no longer needed. Output +applications fill and enqueue buffers, when enough buffers are stacked +up output is started. In the write loop, when the application +runs out of free buffers it must wait until an empty buffer can be +dequeued and reused. Two methods exist to suspend execution of the +application until one or more buffers can be dequeued. By default +<constant>VIDIOC_DQBUF</constant> blocks when no buffer is in the +outgoing queue. When the <constant>O_NONBLOCK</constant> flag was +given to the &func-open; function, <constant>VIDIOC_DQBUF</constant> +returns immediately with an &EAGAIN; when no buffer is available. The +&func-select; and &func-poll; functions are always available.</para> + + <para>To start and stop capturing or displaying applications call the +&VIDIOC-STREAMON; and &VIDIOC-STREAMOFF; ioctls. Note that +<constant>VIDIOC_STREAMOFF</constant> removes all buffers from both queues and +unlocks all buffers as a side effect. Since there is no notion of doing +anything "now" on a multitasking system, if an application needs to synchronize +with another event it should examine the &v4l2-buffer; +<structfield>timestamp</structfield> of captured buffers, or set the field +before enqueuing buffers for output.</para> + + <para>Drivers implementing DMABUF importing I/O must support the +<constant>VIDIOC_REQBUFS</constant>, <constant>VIDIOC_QBUF</constant>, +<constant>VIDIOC_DQBUF</constant>, <constant>VIDIOC_STREAMON</constant> and +<constant>VIDIOC_STREAMOFF</constant> ioctls, and the +<function>select()</function> and <function>poll()</function> functions.</para> + + </section> + <section id="async"> <title>Asynchronous I/O</title> @@ -582,17 +741,19 @@ applications when an output stream.</entry> <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> @@ -673,6 +834,14 @@ memory, set by the application. See <xref linkend="userp" /> for details. <structname>v4l2_buffer</structname> structure.</entry> </row> <row> + <entry></entry> + <entry>int</entry> + <entry><structfield>fd</structfield></entry> + <entry>For the single-plane API and when +<structfield>memory</structfield> is <constant>V4L2_MEMORY_DMABUF</constant> this +is the file descriptor associated with a DMABUF buffer.</entry> + </row> + <row> <entry>__u32</entry> <entry><structfield>length</structfield></entry> <entry></entry> @@ -736,7 +905,7 @@ should set this to 0.</entry> </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 @@ -744,6 +913,15 @@ should set this to 0.</entry> </entry> </row> <row> + <entry></entry> + <entry>int</entry> + <entry><structfield>fd</structfield></entry> + <entry>When the memory type in the containing &v4l2-buffer; is + <constant>V4L2_MEMORY_DMABUF</constant>, this is a file + descriptor associated with a DMABUF buffer, similar to the + <structfield>fd</structfield> field in &v4l2-buffer;.</entry> + </row> + <row> <entry>__u32</entry> <entry><structfield>data_offset</structfield></entry> <entry></entry> @@ -923,7 +1101,7 @@ application. Drivers set or clear this flag when the </row> <row> <entry><constant>V4L2_BUF_FLAG_NO_CACHE_INVALIDATE</constant></entry> - <entry>0x0400</entry> + <entry>0x0800</entry> <entry>Caches do not have to be invalidated for this buffer. Typically applications shall use this flag if the data captured in the buffer is not going to be touched by the CPU, instead the buffer will, probably, be @@ -932,12 +1110,41 @@ passed on to a DMA-capable hardware unit for further processing or output. </row> <row> <entry><constant>V4L2_BUF_FLAG_NO_CACHE_CLEAN</constant></entry> - <entry>0x0800</entry> + <entry>0x1000</entry> <entry>Caches do not have to be cleaned for this buffer. Typically applications shall use this flag for output buffers if the data 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> </tbody> </tgroup> </table> @@ -964,6 +1171,12 @@ pointer</link> I/O.</entry> <entry>3</entry> <entry>[to do]</entry> </row> + <row> + <entry><constant>V4L2_MEMORY_DMABUF</constant></entry> + <entry>4</entry> + <entry>The buffer is used for <link linkend="dmabuf">DMA shared +buffer</link> I/O.</entry> + </row> </tbody> </tgroup> </table> diff --git a/Documentation/DocBook/media/v4l/pixfmt-nv12m.xml b/Documentation/DocBook/media/v4l/pixfmt-nv12m.xml index a990b34d911a..f3a3d459fcdf 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-srggb10alaw8.xml b/Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml new file mode 100644 index 000000000000..29acc2098cc2 --- /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 000000000000..c507c1f73cd0 --- /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 bf94f417592c..99b8d2ad6e4f 100644 --- a/Documentation/DocBook/media/v4l/pixfmt.xml +++ b/Documentation/DocBook/media/v4l/pixfmt.xml @@ -673,6 +673,7 @@ access the palette, this must be done with ioctls of the Linux framebuffer API.< &sub-srggb8; &sub-sbggr16; &sub-srggb10; + &sub-srggb10alaw8; &sub-srggb10dpcm8; &sub-srggb12; </section> @@ -701,6 +702,7 @@ information.</para> &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 a0a936455fae..cc51372ed5e0 100644 --- a/Documentation/DocBook/media/v4l/subdev-formats.xml +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml @@ -353,9 +353,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 +504,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 +921,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 +951,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 +973,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 +1015,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 +1052,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 +1065,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,6 +1106,40 @@ <entry>-</entry> <entry>-</entry> <entry>-</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> + &dash-ent-10; + &dash-ent-10; + <entry>-</entry> + <entry>-</entry> <entry>y<subscript>7</subscript></entry> <entry>y<subscript>6</subscript></entry> <entry>y<subscript>5</subscript></entry> @@ -1019,16 +1153,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> @@ -1044,16 +1170,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> @@ -1069,16 +1187,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 +1204,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 +1221,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 +1238,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 +1255,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 +1272,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 +1289,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 +1306,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 +1323,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 +1340,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 +1357,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 +1374,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 +1391,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 +1408,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 +1425,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 +1442,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 +1459,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 +1476,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 +1493,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 +1510,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 +1527,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 +1544,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 +1561,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 +1578,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 +1595,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 +1612,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 +1629,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 +1646,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 +1663,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 +1680,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 +1697,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 +1714,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 +1731,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 +1748,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 +1765,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 +1782,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 +1799,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 +1816,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 +1833,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 +1850,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 +1867,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 +1884,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 +1901,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 +1918,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 +1935,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 +1952,7 @@ <entry>V4L2_MBUS_FMT_Y12_1X12</entry> <entry>0x2013</entry> <entry></entry> + &dash-ent-10; <entry>-</entry> <entry>-</entry> <entry>-</entry> @@ -2219,6 +1978,7 @@ <entry>V4L2_MBUS_FMT_UYVY8_1X16</entry> <entry>0x200f</entry> <entry></entry> + &dash-ent-10; <entry>-</entry> <entry>-</entry> <entry>-</entry> @@ -2244,6 +2004,7 @@ <entry></entry> <entry></entry> <entry></entry> + &dash-ent-10; <entry>-</entry> <entry>-</entry> <entry>-</entry> @@ -2269,6 +2030,7 @@ <entry>V4L2_MBUS_FMT_VYUY8_1X16</entry> <entry>0x2010</entry> <entry></entry> + &dash-ent-10; <entry>-</entry> <entry>-</entry> <entry>-</entry> @@ -2294,6 +2056,7 @@ <entry></entry> <entry></entry> <entry></entry> + &dash-ent-10; <entry>-</entry> <entry>-</entry> <entry>-</entry> @@ -2319,6 +2082,7 @@ <entry>V4L2_MBUS_FMT_YUYV8_1X16</entry> <entry>0x2011</entry> <entry></entry> + &dash-ent-10; <entry>-</entry> <entry>-</entry> <entry>-</entry> @@ -2344,6 +2108,7 @@ <entry></entry> <entry></entry> <entry></entry> + &dash-ent-10; <entry>-</entry> <entry>-</entry> <entry>-</entry> @@ -2369,6 +2134,7 @@ <entry>V4L2_MBUS_FMT_YVYU8_1X16</entry> <entry>0x2012</entry> <entry></entry> + &dash-ent-10; <entry>-</entry> <entry>-</entry> <entry>-</entry> @@ -2394,6 +2160,57 @@ <entry></entry> <entry></entry> <entry></entry> + &dash-ent-10; + <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 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> @@ -2415,10 +2232,61 @@ <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 +2312,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 +2338,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 +2364,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 +2386,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 10ccde9d16d0..a3cce18384e9 100644 --- a/Documentation/DocBook/media/v4l/v4l2.xml +++ b/Documentation/DocBook/media/v4l/v4l2.xml @@ -140,6 +140,16 @@ structs, ioctls) must be noted in more detail in the history chapter applications. --> <revision> + <revnumber>3.9</revnumber> + <date>2012-12-03</date> + <authorinitials>sa, sn</authorinitials> + <revremark>Added timestamp types to v4l2_buffer. + Added <constant>V4L2_EVENT_CTRL_CH_RANGE</constant> control + event changes flag, see <xref linkend="changes-flags"/>. + </revremark> + </revision> + + <revision> <revnumber>3.6</revnumber> <date>2012-07-02</date> <authorinitials>hv</authorinitials> @@ -472,7 +482,7 @@ and discussions on the V4L mailing list.</revremark> </partinfo> <title>Video for Linux Two API Specification</title> - <subtitle>Revision 3.6</subtitle> + <subtitle>Revision 3.9</subtitle> <chapter id="common"> &sub-common; @@ -543,6 +553,7 @@ and discussions on the V4L mailing list.</revremark> &sub-enuminput; &sub-enumoutput; &sub-enumstd; + &sub-expbuf; &sub-g-audio; &sub-g-audioout; &sub-g-crop; diff --git a/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml b/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml index a8cda1acacd9..cd9943672434 100644 --- a/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml +++ b/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml @@ -6,7 +6,8 @@ <refnamediv> <refname>VIDIOC_CREATE_BUFS</refname> - <refpurpose>Create buffers for Memory Mapped or User Pointer I/O</refpurpose> + <refpurpose>Create buffers for Memory Mapped or User Pointer or DMA Buffer + I/O</refpurpose> </refnamediv> <refsynopsisdiv> @@ -55,11 +56,11 @@ </note> <para>This ioctl is used to create buffers for <link linkend="mmap">memory -mapped</link> or <link linkend="userp">user pointer</link> -I/O. It can be used as an alternative or in addition to the -<constant>VIDIOC_REQBUFS</constant> ioctl, when a tighter control over buffers -is required. This ioctl can be called multiple times to create buffers of -different sizes.</para> +mapped</link> or <link linkend="userp">user pointer</link> or <link +linkend="dmabuf">DMA buffer</link> I/O. It can be used as an alternative or in +addition to the <constant>VIDIOC_REQBUFS</constant> ioctl, when a tighter +control over buffers is required. This ioctl can be called multiple times to +create buffers of different sizes.</para> <para>To allocate device buffers applications initialize relevant fields of the <structname>v4l2_create_buffers</structname> structure. They set the @@ -109,7 +110,8 @@ information.</para> <entry>__u32</entry> <entry><structfield>memory</structfield></entry> <entry>Applications set this field to -<constant>V4L2_MEMORY_MMAP</constant> or +<constant>V4L2_MEMORY_MMAP</constant>, +<constant>V4L2_MEMORY_DMABUF</constant> or <constant>V4L2_MEMORY_USERPTR</constant>. See <xref linkend="v4l2-memory" /></entry> </row> diff --git a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml index 98a856f9ec30..89891adb928a 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-expbuf.xml b/Documentation/DocBook/media/v4l/vidioc-expbuf.xml new file mode 100644 index 000000000000..e287c8fc803b --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-expbuf.xml @@ -0,0 +1,208 @@ +<refentry id="vidioc-expbuf"> + + <refmeta> + <refentrytitle>ioctl VIDIOC_EXPBUF</refentrytitle> + &manvol; + </refmeta> + + <refnamediv> + <refname>VIDIOC_EXPBUF</refname> + <refpurpose>Export a buffer as a DMABUF file descriptor.</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_exportbuffer *<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_EXPBUF</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>This ioctl is an extension to the <link linkend="mmap">memory +mapping</link> I/O method, therefore it is available only for +<constant>V4L2_MEMORY_MMAP</constant> buffers. It can be used to export a +buffer as a DMABUF file at any time after buffers have been allocated with the +&VIDIOC-REQBUFS; ioctl.</para> + +<para> To export a buffer, applications fill &v4l2-exportbuffer;. The +<structfield> type </structfield> field is set to the same buffer type as was +previously used with &v4l2-requestbuffers;<structfield> type </structfield>. +Applications must also set the <structfield> index </structfield> field. Valid +index numbers range from zero to the number of buffers allocated with +&VIDIOC-REQBUFS; (&v4l2-requestbuffers;<structfield> count </structfield>) +minus one. For the multi-planar API, applications set the <structfield> plane +</structfield> field to the index of the plane to be exported. Valid planes +range from zero to the maximal number of valid planes for the currently active +format. For the single-planar API, applications must set <structfield> plane +</structfield> to zero. Additional flags may be posted in the <structfield> +flags </structfield> field. Refer to a manual for open() for details. +Currently only O_CLOEXEC is supported. All other fields must be set to zero. +In the case of multi-planar API, every plane is exported separately using +multiple <constant> VIDIOC_EXPBUF </constant> calls. </para> + +<para> After calling <constant>VIDIOC_EXPBUF</constant> the <structfield> fd +</structfield> field will be set by a driver. This is a DMABUF file +descriptor. The application may pass it to other DMABUF-aware devices. Refer to +<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> + <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; + + memset(&expbuf, 0, sizeof(expbuf)); + expbuf.type = bt; + expbuf.index = index; + if (ioctl(v4lfd, &VIDIOC-EXPBUF;, &expbuf) == -1) { + perror("VIDIOC_EXPBUF"); + return -1; + } + + *dmafd = expbuf.fd; + + return 0; +} + </programlisting> + </example> + + <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) +{ + int i; + + for (i = 0; i < n_planes; ++i) { + &v4l2-exportbuffer; expbuf; + + memset(&expbuf, 0, sizeof(expbuf)); + expbuf.type = bt; + expbuf.index = index; + expbuf.plane = i; + if (ioctl(v4lfd, &VIDIOC-EXPBUF;, &expbuf) == -1) { + perror("VIDIOC_EXPBUF"); + while (i) + close(dmafd[--i]); + return -1; + } + dmafd[i] = expbuf.fd; + } + + return 0; +} + </programlisting> + </example> + + <table pgwide="1" frame="none" id="v4l2-exportbuffer"> + <title>struct <structname>v4l2_exportbuffer</structname></title> + <tgroup cols="3"> + &cs-str; + <tbody valign="top"> + <row> + <entry>__u32</entry> + <entry><structfield>type</structfield></entry> + <entry>Type of the buffer, same as &v4l2-format; +<structfield>type</structfield> or &v4l2-requestbuffers; +<structfield>type</structfield>, set by the application. See <xref +linkend="v4l2-buf-type" /></entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>index</structfield></entry> + <entry>Number of the buffer, set by the application. This field is +only used for <link linkend="mmap">memory mapping</link> I/O and can range from +zero to the number of buffers allocated with the &VIDIOC-REQBUFS; and/or +&VIDIOC-CREATE-BUFS; ioctls. </entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>plane</structfield></entry> + <entry>Index of the plane to be exported when using the +multi-planar API. Otherwise this value must be set to zero. </entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>flags</structfield></entry> + <entry>Flags for the newly created file, currently only <constant> +O_CLOEXEC </constant> is supported, refer to the manual of open() for more +details.</entry> + </row> + <row> + <entry>__s32</entry> + <entry><structfield>fd</structfield></entry> + <entry>The DMABUF file descriptor associated with a buffer. Set by + the driver.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>reserved[11]</structfield></entry> + <entry>Reserved field for future use. Must be set to zero.</entry> + </row> + </tbody> + </tgroup> + </table> + + </refsect1> + + <refsect1> + &return-value; + <variablelist> + <varlistentry> + <term><errorcode>EINVAL</errorcode></term> + <listitem> + <para>A queue is not in MMAP mode or DMABUF exporting is not +supported or <structfield> flags </structfield> or <structfield> type +</structfield> or <structfield> index </structfield> or <structfield> plane +</structfield> fields are invalid.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + +</refentry> diff --git a/Documentation/DocBook/media/v4l/vidioc-g-ctrl.xml b/Documentation/DocBook/media/v4l/vidioc-g-ctrl.xml index 12b1d0503e26..ee2820d6ca66 100644 --- a/Documentation/DocBook/media/v4l/vidioc-g-ctrl.xml +++ b/Documentation/DocBook/media/v4l/vidioc-g-ctrl.xml @@ -64,7 +64,9 @@ return an &EINVAL;. When the <structfield>value</structfield> is out 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 @@ application.</entry> <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-ext-ctrls.xml b/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml index 0a4b90fcf2da..4e16112df992 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 @@ value or if an error is returned.</para> &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 @@ also be zero.</entry> <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> @@ -298,8 +333,10 @@ These controls are described in <xref <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-qbuf.xml b/Documentation/DocBook/media/v4l/vidioc-qbuf.xml index 2d37abefce13..3504a7f2f382 100644 --- a/Documentation/DocBook/media/v4l/vidioc-qbuf.xml +++ b/Documentation/DocBook/media/v4l/vidioc-qbuf.xml @@ -109,6 +109,23 @@ they cannot be swapped out to disk. Buffers remain locked until dequeued, until the &VIDIOC-STREAMOFF; or &VIDIOC-REQBUFS; ioctl is called, or until the device is closed.</para> + <para>To enqueue a <link linkend="dmabuf">DMABUF</link> buffer applications +set the <structfield>memory</structfield> field to +<constant>V4L2_MEMORY_DMABUF</constant> and the <structfield>m.fd</structfield> +field to a file descriptor associated with a DMABUF buffer. When the +multi-planar API is used the <structfield>m.fd</structfield> fields of the +passed array of &v4l2-plane; have to be used instead. When +<constant>VIDIOC_QBUF</constant> is called with a pointer to this structure the +driver sets the <constant>V4L2_BUF_FLAG_QUEUED</constant> flag and clears the +<constant>V4L2_BUF_FLAG_MAPPED</constant> and +<constant>V4L2_BUF_FLAG_DONE</constant> flags in the +<structfield>flags</structfield> field, or it returns an error code. This +ioctl locks the buffer. Locking a buffer means passing it to a driver for a +hardware access (usually DMA). If an application accesses (reads/writes) a +locked buffer then the result is undefined. Buffers remain locked until +dequeued, until the &VIDIOC-STREAMOFF; or &VIDIOC-REQBUFS; ioctl is called, or +until the device is closed.</para> + <para>Applications call the <constant>VIDIOC_DQBUF</constant> ioctl to dequeue a filled (capturing) or displayed (output) buffer from the driver's outgoing queue. They just set the diff --git a/Documentation/DocBook/media/v4l/vidioc-querycap.xml b/Documentation/DocBook/media/v4l/vidioc-querycap.xml index 4c70215ae03f..d5a3c97b206a 100644 --- a/Documentation/DocBook/media/v4l/vidioc-querycap.xml +++ b/Documentation/DocBook/media/v4l/vidioc-querycap.xml @@ -76,7 +76,7 @@ make sure the strings are properly NUL-terminated.</para></entry> <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-reqbufs.xml b/Documentation/DocBook/media/v4l/vidioc-reqbufs.xml index 2b50ef2007f3..78a06a9a5ece 100644 --- a/Documentation/DocBook/media/v4l/vidioc-reqbufs.xml +++ b/Documentation/DocBook/media/v4l/vidioc-reqbufs.xml @@ -48,28 +48,30 @@ <refsect1> <title>Description</title> - <para>This ioctl is used to initiate <link linkend="mmap">memory -mapped</link> or <link linkend="userp">user pointer</link> -I/O. Memory mapped buffers are located in device memory and must be -allocated with this ioctl before they can be mapped into the -application's address space. User buffers are allocated by -applications themselves, and this ioctl is merely used to switch the -driver into user pointer I/O mode and to setup some internal structures.</para> +<para>This ioctl is used to initiate <link linkend="mmap">memory mapped</link>, +<link linkend="userp">user pointer</link> or <link +linkend="dmabuf">DMABUF</link> based I/O. Memory mapped buffers are located in +device memory and must be allocated with this ioctl before they can be mapped +into the application's address space. User buffers are allocated by +applications themselves, and this ioctl is merely used to switch the driver +into user pointer I/O mode and to setup some internal structures. +Similarly, DMABUF buffers are allocated by applications through a device +driver, and this ioctl only configures the driver into DMABUF I/O mode without +performing any direct allocation.</para> - <para>To allocate device buffers applications initialize all -fields of the <structname>v4l2_requestbuffers</structname> structure. -They set the <structfield>type</structfield> field to the respective -stream or buffer type, the <structfield>count</structfield> field to -the desired number of buffers, <structfield>memory</structfield> -must be set to the requested I/O method and the <structfield>reserved</structfield> array -must be zeroed. When the ioctl -is called with a pointer to this structure the driver will attempt to allocate -the requested number of buffers and it stores the actual number -allocated in the <structfield>count</structfield> field. It can be -smaller than the number requested, even zero, when the driver runs out -of free memory. A larger number is also possible when the driver requires -more buffers to function correctly. For example video output requires at least two buffers, -one displayed and one filled by the application.</para> + <para>To allocate device buffers applications initialize all fields of the +<structname>v4l2_requestbuffers</structname> structure. They set the +<structfield>type</structfield> field to the respective stream or buffer type, +the <structfield>count</structfield> field to the desired number of buffers, +<structfield>memory</structfield> must be set to the requested I/O method and +the <structfield>reserved</structfield> array must be zeroed. When the ioctl is +called with a pointer to this structure the driver will attempt to allocate the +requested number of buffers and it stores the actual number allocated in the +<structfield>count</structfield> field. It can be smaller than the number +requested, even zero, when the driver runs out of free memory. A larger number +is also possible when the driver requires more buffers to function correctly. +For example video output requires at least two buffers, one displayed and one +filled by the application.</para> <para>When the I/O method is not supported the ioctl returns an &EINVAL;.</para> @@ -102,7 +104,8 @@ as the &v4l2-format; <structfield>type</structfield> field. See <xref <entry>__u32</entry> <entry><structfield>memory</structfield></entry> <entry>Applications set this field to -<constant>V4L2_MEMORY_MMAP</constant> or +<constant>V4L2_MEMORY_MMAP</constant>, +<constant>V4L2_MEMORY_DMABUF</constant> or <constant>V4L2_MEMORY_USERPTR</constant>. See <xref linkend="v4l2-memory" />.</entry> </row> diff --git a/Documentation/DocBook/media_api.tmpl b/Documentation/DocBook/media_api.tmpl index f2413acfe241..1f6593deb995 100644 --- a/Documentation/DocBook/media_api.tmpl +++ b/Documentation/DocBook/media_api.tmpl @@ -22,6 +22,7 @@ <!-- 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>"> ]> <book id="media_api"> diff --git a/Documentation/DocBook/uio-howto.tmpl b/Documentation/DocBook/uio-howto.tmpl index ac3d0018140c..95618159e29b 100644 --- a/Documentation/DocBook/uio-howto.tmpl +++ b/Documentation/DocBook/uio-howto.tmpl @@ -719,6 +719,62 @@ framework to set up sysfs files for this region. Simply leave it alone. </para> </sect1> +<sect1 id="using uio_dmem_genirq"> +<title>Using uio_dmem_genirq for platform devices</title> + <para> + In addition to statically allocated memory ranges, they may also be + a desire to use dynamically allocated regions in a user space driver. + In particular, being able to access memory made available through the + dma-mapping API, may be particularly useful. The + <varname>uio_dmem_genirq</varname> driver provides a way to accomplish + this. + </para> + <para> + This driver is used in a similar manner to the + <varname>"uio_pdrv_genirq"</varname> driver with respect to interrupt + configuration and handling. + </para> + <para> + Set the <varname>.name</varname> element of + <varname>struct platform_device</varname> to + <varname>"uio_dmem_genirq"</varname> to use this driver. + </para> + <para> + When using this driver, fill in the <varname>.platform_data</varname> + element of <varname>struct platform_device</varname>, which is of type + <varname>struct uio_dmem_genirq_pdata</varname> and which contains the + following elements: + </para> + <itemizedlist> + <listitem><varname>struct uio_info uioinfo</varname>: The same + structure used as the <varname>uio_pdrv_genirq</varname> platform + data</listitem> + <listitem><varname>unsigned int *dynamic_region_sizes</varname>: + Pointer to list of sizes of dynamic memory regions to be mapped into + user space. + </listitem> + <listitem><varname>unsigned int num_dynamic_regions</varname>: + Number of elements in <varname>dynamic_region_sizes</varname> array. + </listitem> + </itemizedlist> + <para> + The dynamic regions defined in the platform data will be appended to + the <varname> mem[] </varname> array after the platform device + resources, which implies that the total number of static and dynamic + memory regions cannot exceed <varname>MAX_UIO_MAPS</varname>. + </para> + <para> + The dynamic memory regions will be allocated when the UIO device file, + <varname>/dev/uioX</varname> is opened. + Simiar to static memory resources, the memory region information for + dynamic regions is then visible via sysfs at + <varname>/sys/class/uio/uioX/maps/mapY/*</varname>. + The dynmaic memory regions will be freed when the UIO device file is + closed. When no processes are holding the device file open, the address + returned to userspace is ~0. + </para> +</sect1> + </chapter> <chapter id="userspace_driver" xreflabel="Writing a driver in user space"> @@ -928,7 +984,7 @@ int main() 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 cab4ec58e46e..bd6fee22c4dd 100644 --- a/Documentation/DocBook/writing-an-alsa-driver.tmpl +++ b/Documentation/DocBook/writing-an-alsa-driver.tmpl @@ -433,9 +433,9 @@ /* chip-specific constructor * (see "Management of Cards and Components") */ - static int __devinit snd_mychip_create(struct snd_card *card, - struct pci_dev *pci, - struct mychip **rchip) + static int snd_mychip_create(struct snd_card *card, + struct pci_dev *pci, + struct mychip **rchip) { struct mychip *chip; int err; @@ -475,8 +475,8 @@ } /* constructor -- see "Constructor" sub-section */ - static int __devinit snd_mychip_probe(struct pci_dev *pci, - const struct pci_device_id *pci_id) + static int snd_mychip_probe(struct pci_dev *pci, + const struct pci_device_id *pci_id) { static int dev; struct snd_card *card; @@ -526,7 +526,7 @@ } /* destructor -- see the "Destructor" sub-section */ - static void __devexit snd_mychip_remove(struct pci_dev *pci) + static void snd_mychip_remove(struct pci_dev *pci) { snd_card_free(pci_get_drvdata(pci)); pci_set_drvdata(pci, NULL); @@ -542,9 +542,8 @@ <para> The real constructor of PCI drivers is the <function>probe</function> callback. The <function>probe</function> callback and other component-constructors which are called - from the <function>probe</function> callback should be defined with - the <parameter>__devinit</parameter> prefix. You - cannot use the <parameter>__init</parameter> prefix for them, + from the <function>probe</function> callback cannot be used with + the <parameter>__init</parameter> prefix because any PCI device could be a hotplug device. </para> @@ -728,7 +727,7 @@ <informalexample> <programlisting> <![CDATA[ - static void __devexit snd_mychip_remove(struct pci_dev *pci) + static void snd_mychip_remove(struct pci_dev *pci) { snd_card_free(pci_get_drvdata(pci)); pci_set_drvdata(pci, NULL); @@ -872,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> @@ -1059,14 +1057,6 @@ </para> <para> - As further notes, the destructors (both - <function>snd_mychip_dev_free</function> and - <function>snd_mychip_free</function>) cannot be defined with - the <parameter>__devexit</parameter> prefix, because they may be - called from the constructor, too, at the false path. - </para> - - <para> For a device which allows hotplugging, you can use <function>snd_card_free_when_closed</function>. This one will postpone the destruction until all devices are closed. @@ -1120,9 +1110,9 @@ } /* chip-specific constructor */ - static int __devinit snd_mychip_create(struct snd_card *card, - struct pci_dev *pci, - struct mychip **rchip) + static int snd_mychip_create(struct snd_card *card, + struct pci_dev *pci, + struct mychip **rchip) { struct mychip *chip; int err; @@ -1200,7 +1190,7 @@ .name = KBUILD_MODNAME, .id_table = snd_mychip_ids, .probe = snd_mychip_probe, - .remove = __devexit_p(snd_mychip_remove), + .remove = snd_mychip_remove, }; /* module initialization */ @@ -1465,11 +1455,6 @@ </para> <para> - Again, remember that you cannot - use the <parameter>__devexit</parameter> prefix for this destructor. - </para> - - <para> We didn't implement the hardware disabling part in the above. If you need to do this, please note that the destructor may be called even before the initialization of the chip is completed. @@ -1619,7 +1604,7 @@ .name = KBUILD_MODNAME, .id_table = snd_mychip_ids, .probe = snd_mychip_probe, - .remove = __devexit_p(snd_mychip_remove), + .remove = snd_mychip_remove, }; ]]> </programlisting> @@ -1630,11 +1615,7 @@ The <structfield>probe</structfield> and <structfield>remove</structfield> functions have already been defined in the previous sections. - The <structfield>remove</structfield> function should - be defined with the - <function>__devexit_p()</function> macro, so that it's not - defined for built-in (and non-hot-pluggable) case. The - <structfield>name</structfield> + The <structfield>name</structfield> field is the name string of this device. Note that you must not use a slash <quote>/</quote> in this string. </para> @@ -1665,9 +1646,7 @@ <para> Note that these module entries are tagged with <parameter>__init</parameter> and - <parameter>__exit</parameter> prefixes, not - <parameter>__devinit</parameter> nor - <parameter>__devexit</parameter>. + <parameter>__exit</parameter> prefixes. </para> <para> @@ -1918,7 +1897,7 @@ */ /* create a pcm device */ - static int __devinit snd_mychip_new_pcm(struct mychip *chip) + static int snd_mychip_new_pcm(struct mychip *chip) { struct snd_pcm *pcm; int err; @@ -1957,7 +1936,7 @@ <informalexample> <programlisting> <![CDATA[ - static int __devinit snd_mychip_new_pcm(struct mychip *chip) + static int snd_mychip_new_pcm(struct mychip *chip) { struct snd_pcm *pcm; int err; @@ -2124,7 +2103,7 @@ .... } - static int __devinit snd_mychip_new_pcm(struct mychip *chip) + static int snd_mychip_new_pcm(struct mychip *chip) { struct snd_pcm *pcm; .... @@ -2324,7 +2303,7 @@ struct _snd_pcm_runtime { <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 @@ -2918,7 +2897,7 @@ struct _snd_pcm_runtime { <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. @@ -3105,7 +3084,7 @@ struct _snd_pcm_runtime { <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 @@ -3271,18 +3250,19 @@ struct _snd_pcm_runtime { <title>Example of Hardware Constraints for Channels</title> <programlisting> <![CDATA[ - static int hw_rule_format_by_channels(struct snd_pcm_hw_params *params, + static int hw_rule_channels_by_format(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); + SNDRV_PCM_HW_PARAM_CHANNELS); struct snd_mask *f = hw_param_mask(params, SNDRV_PCM_HW_PARAM_FORMAT); - struct snd_mask fmt; + struct snd_interval ch; - 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); + snd_interval_any(&ch); + if (f->bits[0] == SNDRV_PCM_FMTBIT_S16_LE) { + ch.min = ch.max = 1; + ch.integer = 1; + return snd_interval_refine(c, &ch); } return 0; } @@ -3298,35 +3278,35 @@ struct _snd_pcm_runtime { <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); + 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 number of - channels. But an application can set the format before the number of - channels. Thus you also need to define the inverse rule: + 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 Channels</title> + <title>Example of Hardware Constraints for Formats</title> <programlisting> <![CDATA[ - static int hw_rule_channels_by_format(struct snd_pcm_hw_params *params, + 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); + SNDRV_PCM_HW_PARAM_CHANNELS); struct snd_mask *f = hw_param_mask(params, SNDRV_PCM_HW_PARAM_FORMAT); - struct snd_interval ch; + struct snd_mask fmt; - snd_interval_any(&ch); - if (f->bits[0] == SNDRV_PCM_FMTBIT_S16_LE) { - ch.min = ch.max = 1; - ch.integer = 1; - return snd_interval_refine(c, &ch); + 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; } @@ -3341,8 +3321,8 @@ struct _snd_pcm_runtime { <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> @@ -3399,7 +3379,7 @@ struct _snd_pcm_runtime { <title>Definition of a Control</title> <programlisting> <![CDATA[ - static struct snd_kcontrol_new my_control __devinitdata = { + static struct snd_kcontrol_new my_control = { .iface = SNDRV_CTL_ELEM_IFACE_MIXER, .name = "PCM Playback Switch", .index = 0, @@ -3415,13 +3395,6 @@ struct _snd_pcm_runtime { </para> <para> - Most likely the control is created via - <function>snd_ctl_new1()</function>, and in such a case, you can - add the <parameter>__devinitdata</parameter> prefix to the - definition as above. - </para> - - <para> The <structfield>iface</structfield> field specifies the control type, <constant>SNDRV_CTL_ELEM_IFACE_XXX</constant>, which is usually <constant>MIXER</constant>. @@ -3847,10 +3820,8 @@ struct _snd_pcm_runtime { <para> <function>snd_ctl_new1()</function> allocates a new - <structname>snd_kcontrol</structname> instance (that's why the definition - of <parameter>my_control</parameter> can be with - the <parameter>__devinitdata</parameter> - prefix), and <function>snd_ctl_add</function> assigns the given + <structname>snd_kcontrol</structname> instance, + and <function>snd_ctl_add</function> assigns the given control component to the card. </para> </section> @@ -3896,7 +3867,7 @@ struct _snd_pcm_runtime { <![CDATA[ static DECLARE_TLV_DB_SCALE(db_scale_my_control, -4050, 150, 0); - static struct snd_kcontrol_new my_control __devinitdata = { + static struct snd_kcontrol_new my_control = { ... .access = SNDRV_CTL_ELEM_ACCESS_READWRITE | SNDRV_CTL_ELEM_ACCESS_TLV_READ, @@ -5761,8 +5732,8 @@ struct _snd_pcm_runtime { <informalexample> <programlisting> <![CDATA[ - static int __devinit snd_mychip_probe(struct pci_dev *pci, - const struct pci_device_id *pci_id) + static int snd_mychip_probe(struct pci_dev *pci, + const struct pci_device_id *pci_id) { .... struct snd_card *card; @@ -5787,8 +5758,8 @@ struct _snd_pcm_runtime { <informalexample> <programlisting> <![CDATA[ - static int __devinit snd_mychip_probe(struct pci_dev *pci, - const struct pci_device_id *pci_id) + static int snd_mychip_probe(struct pci_dev *pci, + const struct pci_device_id *pci_id) { .... struct snd_card *card; @@ -5825,7 +5796,7 @@ struct _snd_pcm_runtime { .name = KBUILD_MODNAME, .id_table = snd_my_ids, .probe = snd_my_probe, - .remove = __devexit_p(snd_my_remove), + .remove = snd_my_remove, #ifdef CONFIG_PM .suspend = snd_my_suspend, .resume = snd_my_resume, diff --git a/Documentation/EDID/HOWTO.txt b/Documentation/EDID/HOWTO.txt index 75a9f2a0c43d..2d0a8f09475d 100644 --- a/Documentation/EDID/HOWTO.txt +++ b/Documentation/EDID/HOWTO.txt @@ -28,11 +28,30 @@ 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 59c080f084ef..a9f288ff54f9 100644 --- a/Documentation/HOWTO +++ b/Documentation/HOWTO @@ -462,7 +462,7 @@ Differences between the kernel community and corporate structures The kernel community works differently than most traditional corporate development environments. Here are a list of things that you can try to -do to try to avoid problems: +do to avoid problems: Good things to say regarding your proposed changes: - "This solves multiple problems." - "This deletes 2000 lines of code." diff --git a/Documentation/IPMI.txt b/Documentation/IPMI.txt index 16eb4c9e9233..f13c9132e9f2 100644 --- a/Documentation/IPMI.txt +++ b/Documentation/IPMI.txt @@ -348,34 +348,40 @@ You can change this at module load time (for a module) with: 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/IRQ-domain.txt b/Documentation/IRQ-domain.txt index 1401cece745a..9bc95942ec22 100644 --- a/Documentation/IRQ-domain.txt +++ b/Documentation/IRQ-domain.txt @@ -7,6 +7,21 @@ systems with multiple interrupt controllers the kernel must ensure that each one gets assigned non-overlapping allocations of Linux IRQ numbers. +The number of interrupt controllers registered as unique irqchips +show a rising tendency: for example subdrivers of different kinds +such as GPIO controllers avoid reimplementing identical callback +mechanisms as the IRQ core system by modelling their interrupt +handlers as irqchips, i.e. in effect cascading interrupt controllers. + +Here the interrupt number loose all kind of correspondence to +hardware interrupt numbers: whereas in the past, IRQ numbers could +be chosen so they matched the hardware IRQ line into the root +interrupt controller (i.e. the component actually fireing the +interrupt line to the CPU) nowadays this number is just a number. + +For this reason we need a mechanism to separate controller-local +interrupt numbers, called hardware irq's, from Linux IRQ numbers. + The irq_alloc_desc*() and irq_free_desc*() APIs provide allocation of irq numbers, but they don't provide any support for reverse mapping of the controller-local IRQ (hwirq) number into the Linux IRQ number @@ -40,6 +55,10 @@ required hardware setup. When an interrupt is received, irq_find_mapping() function should be used to find the Linux IRQ number from the hwirq number. +The irq_create_mapping() function must be called *atleast once* +before any call to irq_find_mapping(), lest the descriptor will not +be allocated. + If the driver has the Linux IRQ number or the irq_data pointer, and needs to know the associated hwirq number (such as in the irq_chip callbacks) then it can be directly obtained from irq_data->hwirq. @@ -119,4 +138,17 @@ numbers. Most users of legacy mappings should use irq_domain_add_simple() which will use a legacy domain only if an IRQ range is supplied by the -system and will otherwise use a linear domain mapping. +system and will otherwise use a linear domain mapping. The semantics +of this call are such that if an IRQ range is specified then +descriptors will be allocated on-the-fly for it, and if no range is +specified it will fall through to irq_domain_add_linear() which meand +*no* irq descriptors will be allocated. + +A typical use case for simple domains is where an irqchip provider +is supporting both dynamic and static IRQ assignments. + +In order to avoid ending up in a situation where a linear domain is +used and no descriptor gets allocated it is very important to make sure +that the driver using the simple domain call irq_create_mapping() +before any irq_find_mapping() since the latter will actually work +for the static IRQ assignment case. diff --git a/Documentation/PCI/MSI-HOWTO.txt b/Documentation/PCI/MSI-HOWTO.txt index 53e6fca146d7..a09178086c30 100644 --- a/Documentation/PCI/MSI-HOWTO.txt +++ b/Documentation/PCI/MSI-HOWTO.txt @@ -127,15 +127,42 @@ on the number of vectors that can be allocated; pci_enable_msi_block() 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 fc73ef5d65b8..86551cc72e03 100644 --- a/Documentation/PCI/pci-iov-howto.txt +++ b/Documentation/PCI/pci-iov-howto.txt @@ -2,6 +2,9 @@ Copyright (C) 2009 Intel Corporation Yu Zhao <yu.zhao@intel.com> + Update: November 2012 + -- sysfs-based SRIOV enable-/disable-ment + Donald Dutile <ddutile@redhat.com> 1. Overview @@ -24,10 +27,21 @@ real existing PCI device. 2.1 How can I enable SR-IOV capability -The device driver (PF driver) will control the enabling and disabling -of the capability via API provided by SR-IOV core. If the hardware -has SR-IOV capability, loading its PF driver would enable it and all -VFs associated with the PF. +Multiple methods are available for SR-IOV enablement. +In the first method, the device driver (PF driver) will control the +enabling and disabling of the capability via API provided by SR-IOV core. +If the hardware has SR-IOV capability, loading its PF driver would +enable it and all VFs associated with the PF. Some PF drivers require +a module parameter to be set to determine the number of VFs to enable. +In the second method, a write to the sysfs file sriov_numvfs will +enable and disable the VFs associated with a PCIe PF. This method +enables per-PF, VF enable/disable values versus the first method, +which applies to all PFs of the same device. Additionally, the +PCI SRIOV core support ensures that enable/disable operations are +valid to reduce duplication in multiple drivers for the same +checks, e.g., check numvfs == 0 if enabling VFs, ensure +numvfs <= totalvfs. +The second method is the recommended method for new/future VF devices. 2.2 How can I use the Virtual Functions @@ -40,20 +54,29 @@ requires device driver that is same as a normal PCI device's. 3.1 SR-IOV API To enable SR-IOV capability: +(a) For the first method, in the driver: int pci_enable_sriov(struct pci_dev *dev, int nr_virtfn); 'nr_virtfn' is number of VFs to be enabled. +(b) For the second method, from sysfs: + echo 'nr_virtfn' > \ + /sys/bus/pci/devices/<DOMAIN:BUS:DEVICE.FUNCTION>/sriov_numvfs To disable SR-IOV capability: +(a) For the first method, in the driver: void pci_disable_sriov(struct pci_dev *dev); +(b) For the second method, from sysfs: + echo 0 > \ + /sys/bus/pci/devices/<DOMAIN:BUS:DEVICE.FUNCTION>/sriov_numvfs To notify SR-IOV core of Virtual Function Migration: +(a) In the driver: irqreturn_t pci_sriov_migration(struct pci_dev *dev); 3.2 Usage example 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); @@ -62,7 +85,7 @@ static int __devinit dev_probe(struct pci_dev *dev, const struct pci_device_id * return 0; } -static void __devexit dev_remove(struct pci_dev *dev) +static void dev_remove(struct pci_dev *dev) { pci_disable_sriov(dev); @@ -88,12 +111,29 @@ static void dev_shutdown(struct pci_dev *dev) ... } +static int dev_sriov_configure(struct pci_dev *dev, int numvfs) +{ + if (numvfs > 0) { + ... + pci_enable_sriov(dev, numvfs); + ... + return numvfs; + } + if (numvfs == 0) { + .... + pci_disable_sriov(dev); + ... + return 0; + } +} + static struct pci_driver dev_driver = { .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, + .sriov_configure = dev_sriov_configure, }; diff --git a/Documentation/PCI/pci.txt b/Documentation/PCI/pci.txt index aa09e5476bba..bccf602a87f5 100644 --- a/Documentation/PCI/pci.txt +++ b/Documentation/PCI/pci.txt @@ -183,12 +183,6 @@ Please mark the initialization and cleanup functions where appropriate 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 @@ Tips on when/where to use the above attributes: 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/RTFP.txt b/Documentation/RCU/RTFP.txt index 7c1dfb19fc40..7f40c72a9c51 100644 --- a/Documentation/RCU/RTFP.txt +++ b/Documentation/RCU/RTFP.txt @@ -186,7 +186,7 @@ Bibtex Entries @article{Kung80 ,author="H. T. Kung and Q. Lehman" -,title="Concurrent Maintenance of Binary Search Trees" +,title="Concurrent Manipulation of Binary Search Trees" ,Year="1980" ,Month="September" ,journal="ACM Transactions on Database Systems" diff --git a/Documentation/RCU/checklist.txt b/Documentation/RCU/checklist.txt index cdb20d41a44a..31ef8fe07f82 100644 --- a/Documentation/RCU/checklist.txt +++ b/Documentation/RCU/checklist.txt @@ -271,15 +271,14 @@ over a rather long period of time, but improvements are always welcome! The same cautions apply to call_rcu_bh() and call_rcu_sched(). 9. All RCU list-traversal primitives, which include - rcu_dereference(), list_for_each_entry_rcu(), - list_for_each_continue_rcu(), and list_for_each_safe_rcu(), - must be either within an RCU read-side critical section or - must be protected by appropriate update-side locks. RCU - read-side critical sections are delimited by rcu_read_lock() - and rcu_read_unlock(), or by similar primitives such as - rcu_read_lock_bh() and rcu_read_unlock_bh(), in which case - the matching rcu_dereference() primitive must be used in order - to keep lockdep happy, in this case, rcu_dereference_bh(). + rcu_dereference(), list_for_each_entry_rcu(), and + list_for_each_safe_rcu(), must be either within an RCU read-side + critical section or must be protected by appropriate update-side + locks. RCU read-side critical sections are delimited by + rcu_read_lock() and rcu_read_unlock(), or by similar primitives + such as rcu_read_lock_bh() and rcu_read_unlock_bh(), in which + case the matching rcu_dereference() primitive must be used in + order to keep lockdep happy, in this case, rcu_dereference_bh(). The reason that it is permissible to use RCU list-traversal primitives when the update-side lock is held is that doing so diff --git a/Documentation/RCU/listRCU.txt b/Documentation/RCU/listRCU.txt index 4349c1487e91..adb5a3782846 100644 --- a/Documentation/RCU/listRCU.txt +++ b/Documentation/RCU/listRCU.txt @@ -205,7 +205,7 @@ RCU ("read-copy update") its name. The RCU code is as follows: audit_copy_rule(&ne->rule, &e->rule); ne->rule.action = newaction; ne->rule.file_count = newfield_count; - list_replace_rcu(e, ne); + list_replace_rcu(&e->list, &ne->list); call_rcu(&e->rcu, audit_free_rule); return 0; } diff --git a/Documentation/RCU/rcuref.txt b/Documentation/RCU/rcuref.txt index 4202ad093130..141d531aa14b 100644 --- a/Documentation/RCU/rcuref.txt +++ b/Documentation/RCU/rcuref.txt @@ -20,7 +20,7 @@ release_referenced() delete() { { ... write_lock(&list_lock); atomic_dec(&el->rc, relfunc) ... - ... delete_element + ... remove_element } write_unlock(&list_lock); ... if (atomic_dec_and_test(&el->rc)) @@ -52,7 +52,7 @@ release_referenced() delete() { { ... spin_lock(&list_lock); if (atomic_dec_and_test(&el->rc)) ... - call_rcu(&el->head, el_free); delete_element + call_rcu(&el->head, el_free); remove_element ... spin_unlock(&list_lock); } ... if (atomic_dec_and_test(&el->rc)) @@ -64,3 +64,60 @@ Sometimes, a reference to the element needs to be obtained in the update (write) stream. In such cases, atomic_inc_not_zero() might be overkill, since we hold the update-side spinlock. One might instead use atomic_inc() in such cases. + +It is not always convenient to deal with "FAIL" in the +search_and_reference() code path. In such cases, the +atomic_dec_and_test() may be moved from delete() to el_free() +as follows: + +1. 2. +add() search_and_reference() +{ { + alloc_object rcu_read_lock(); + ... search_for_element + atomic_set(&el->rc, 1); atomic_inc(&el->rc); + spin_lock(&list_lock); ... + + add_element rcu_read_unlock(); + ... } + spin_unlock(&list_lock); 4. +} delete() +3. { +release_referenced() spin_lock(&list_lock); +{ ... + ... remove_element + if (atomic_dec_and_test(&el->rc)) spin_unlock(&list_lock); + kfree(el); ... + ... call_rcu(&el->head, el_free); +} ... +5. } +void el_free(struct rcu_head *rhp) +{ + release_referenced(); +} + +The key point is that the initial reference added by add() is not removed +until after a grace period has elapsed following removal. This means that +search_and_reference() cannot find this element, which means that the value +of el->rc cannot increase. Thus, once it reaches zero, there are no +readers that can or ever will be able to reference the element. The +element can therefore safely be freed. This in turn guarantees that if +any reader finds the element, that reader may safely acquire a reference +without checking the value of the reference counter. + +In cases where delete() can sleep, synchronize_rcu() can be called from +delete(), so that el_free() can be subsumed into delete as follows: + +4. +delete() +{ + spin_lock(&list_lock); + ... + remove_element + spin_unlock(&list_lock); + ... + synchronize_rcu(); + if (atomic_dec_and_test(&el->rc)) + kfree(el); + ... +} diff --git a/Documentation/RCU/trace.txt b/Documentation/RCU/trace.txt index 672d19083252..c776968f4463 100644 --- a/Documentation/RCU/trace.txt +++ b/Documentation/RCU/trace.txt @@ -10,51 +10,63 @@ for rcutree and next for rcutiny. CONFIG_TREE_RCU and CONFIG_TREE_PREEMPT_RCU debugfs Files and Formats -These implementations of RCU provides several debugfs files under the +These implementations of RCU provide several debugfs directories under the top-level directory "rcu": -rcu/rcudata: +rcu/rcu_bh +rcu/rcu_preempt +rcu/rcu_sched + +Each directory contains files for the corresponding flavor of RCU. +Note that rcu/rcu_preempt is only present for CONFIG_TREE_PREEMPT_RCU. +For CONFIG_TREE_RCU, the RCU flavor maps onto the RCU-sched flavor, +so that activity for both appears in rcu/rcu_sched. + +In addition, the following file appears in the top-level directory: +rcu/rcutorture. This file displays rcutorture test progress. The output +of "cat rcu/rcutorture" looks as follows: + +rcutorture test sequence: 0 (test in progress) +rcutorture update version number: 615 + +The first line shows the number of rcutorture tests that have completed +since boot. If a test is currently running, the "(test in progress)" +string will appear as shown above. The second line shows the number of +update cycles that the current test has started, or zero if there is +no test in progress. + + +Within each flavor directory (rcu/rcu_bh, rcu/rcu_sched, and possibly +also rcu/rcu_preempt) the following files will be present: + +rcudata: Displays fields in struct rcu_data. -rcu/rcudata.csv: - Comma-separated values spreadsheet version of rcudata. -rcu/rcugp: +rcuexp: + Displays statistics for expedited grace periods. +rcugp: Displays grace-period counters. -rcu/rcuhier: +rcuhier: Displays the struct rcu_node hierarchy. -rcu/rcu_pending: +rcu_pending: Displays counts of the reasons rcu_pending() decided that RCU had work to do. -rcu/rcutorture: - Displays rcutorture test progress. -rcu/rcuboost: +rcuboost: Displays RCU boosting statistics. Only present if CONFIG_RCU_BOOST=y. -The output of "cat rcu/rcudata" looks as follows: - -rcu_sched: - 0 c=20972 g=20973 pq=1 pgp=20973 qp=0 dt=545/1/0 df=50 of=0 ql=163 qs=NRW. kt=0/W/0 ktl=ebc3 b=10 ci=153737 co=0 ca=0 - 1 c=20972 g=20973 pq=1 pgp=20973 qp=0 dt=967/1/0 df=58 of=0 ql=634 qs=NRW. kt=0/W/1 ktl=58c b=10 ci=191037 co=0 ca=0 - 2 c=20972 g=20973 pq=1 pgp=20973 qp=0 dt=1081/1/0 df=175 of=0 ql=74 qs=N.W. kt=0/W/2 ktl=da94 b=10 ci=75991 co=0 ca=0 - 3 c=20942 g=20943 pq=1 pgp=20942 qp=1 dt=1846/0/0 df=404 of=0 ql=0 qs=.... kt=0/W/3 ktl=d1cd b=10 ci=72261 co=0 ca=0 - 4 c=20972 g=20973 pq=1 pgp=20973 qp=0 dt=369/1/0 df=83 of=0 ql=48 qs=N.W. kt=0/W/4 ktl=e0e7 b=10 ci=128365 co=0 ca=0 - 5 c=20972 g=20973 pq=1 pgp=20973 qp=0 dt=381/1/0 df=64 of=0 ql=169 qs=NRW. kt=0/W/5 ktl=fb2f b=10 ci=164360 co=0 ca=0 - 6 c=20972 g=20973 pq=1 pgp=20973 qp=0 dt=1037/1/0 df=183 of=0 ql=62 qs=N.W. kt=0/W/6 ktl=d2ad b=10 ci=65663 co=0 ca=0 - 7 c=20897 g=20897 pq=1 pgp=20896 qp=0 dt=1572/0/0 df=382 of=0 ql=0 qs=.... kt=0/W/7 ktl=cf15 b=10 ci=75006 co=0 ca=0 -rcu_bh: - 0 c=1480 g=1480 pq=1 pgp=1480 qp=0 dt=545/1/0 df=6 of=0 ql=0 qs=.... kt=0/W/0 ktl=ebc3 b=10 ci=0 co=0 ca=0 - 1 c=1480 g=1480 pq=1 pgp=1480 qp=0 dt=967/1/0 df=3 of=0 ql=0 qs=.... kt=0/W/1 ktl=58c b=10 ci=151 co=0 ca=0 - 2 c=1480 g=1480 pq=1 pgp=1480 qp=0 dt=1081/1/0 df=6 of=0 ql=0 qs=.... kt=0/W/2 ktl=da94 b=10 ci=0 co=0 ca=0 - 3 c=1480 g=1480 pq=1 pgp=1480 qp=0 dt=1846/0/0 df=8 of=0 ql=0 qs=.... kt=0/W/3 ktl=d1cd b=10 ci=0 co=0 ca=0 - 4 c=1480 g=1480 pq=1 pgp=1480 qp=0 dt=369/1/0 df=6 of=0 ql=0 qs=.... kt=0/W/4 ktl=e0e7 b=10 ci=0 co=0 ca=0 - 5 c=1480 g=1480 pq=1 pgp=1480 qp=0 dt=381/1/0 df=4 of=0 ql=0 qs=.... kt=0/W/5 ktl=fb2f b=10 ci=0 co=0 ca=0 - 6 c=1480 g=1480 pq=1 pgp=1480 qp=0 dt=1037/1/0 df=6 of=0 ql=0 qs=.... kt=0/W/6 ktl=d2ad b=10 ci=0 co=0 ca=0 - 7 c=1474 g=1474 pq=1 pgp=1473 qp=0 dt=1572/0/0 df=8 of=0 ql=0 qs=.... kt=0/W/7 ktl=cf15 b=10 ci=0 co=0 ca=0 - -The first section lists the rcu_data structures for rcu_sched, the second -for rcu_bh. Note that CONFIG_TREE_PREEMPT_RCU kernels will have an -additional section for rcu_preempt. Each section has one line per CPU, -or eight for this 8-CPU system. The fields are as follows: +The output of "cat rcu/rcu_preempt/rcudata" looks as follows: + + 0!c=30455 g=30456 pq=1 qp=1 dt=126535/140000000000000/0 df=2002 of=4 ql=0/0 qs=N... b=10 ci=74572 nci=0 co=1131 ca=716 + 1!c=30719 g=30720 pq=1 qp=0 dt=132007/140000000000000/0 df=1874 of=10 ql=0/0 qs=N... b=10 ci=123209 nci=0 co=685 ca=982 + 2!c=30150 g=30151 pq=1 qp=1 dt=138537/140000000000000/0 df=1707 of=8 ql=0/0 qs=N... b=10 ci=80132 nci=0 co=1328 ca=1458 + 3 c=31249 g=31250 pq=1 qp=0 dt=107255/140000000000000/0 df=1749 of=6 ql=0/450 qs=NRW. b=10 ci=151700 nci=0 co=509 ca=622 + 4!c=29502 g=29503 pq=1 qp=1 dt=83647/140000000000000/0 df=965 of=5 ql=0/0 qs=N... b=10 ci=65643 nci=0 co=1373 ca=1521 + 5 c=31201 g=31202 pq=1 qp=1 dt=70422/0/0 df=535 of=7 ql=0/0 qs=.... b=10 ci=58500 nci=0 co=764 ca=698 + 6!c=30253 g=30254 pq=1 qp=1 dt=95363/140000000000000/0 df=780 of=5 ql=0/0 qs=N... b=10 ci=100607 nci=0 co=1414 ca=1353 + 7 c=31178 g=31178 pq=1 qp=0 dt=91536/0/0 df=547 of=4 ql=0/0 qs=.... b=10 ci=109819 nci=0 co=1115 ca=969 + +This file has one line per CPU, or eight for this 8-CPU system. +The fields are as follows: o The number at the beginning of each line is the CPU number. CPUs numbers followed by an exclamation mark are offline, @@ -64,11 +76,13 @@ o The number at the beginning of each line is the CPU number. substantially larger than the number of actual CPUs. o "c" is the count of grace periods that this CPU believes have - completed. Offlined CPUs and CPUs in dynticks idle mode may - lag quite a ways behind, for example, CPU 6 under "rcu_sched" - above, which has been offline through not quite 40,000 RCU grace - periods. It is not unusual to see CPUs lagging by thousands of - grace periods. + completed. Offlined CPUs and CPUs in dynticks idle mode may lag + quite a ways behind, for example, CPU 4 under "rcu_sched" above, + which has been offline through 16 RCU grace periods. It is not + unusual to see offline CPUs lagging by thousands of grace periods. + Note that although the grace-period number is an unsigned long, + it is printed out as a signed long to allow more human-friendly + representation near boot time. o "g" is the count of grace periods that this CPU believes have started. Again, offlined CPUs and CPUs in dynticks idle mode @@ -84,30 +98,25 @@ o "pq" indicates that this CPU has passed through a quiescent state CPU has not yet reported that fact, (2) some other CPU has not yet reported for this grace period, or (3) both. -o "pgp" indicates which grace period the last-observed quiescent - state for this CPU corresponds to. This is important for handling - the race between CPU 0 reporting an extended dynticks-idle - quiescent state for CPU 1 and CPU 1 suddenly waking up and - reporting its own quiescent state. If CPU 1 was the last CPU - for the current grace period, then the CPU that loses this race - will attempt to incorrectly mark CPU 1 as having checked in for - the next grace period! - o "qp" indicates that RCU still expects a quiescent state from this CPU. Offlined CPUs and CPUs in dyntick idle mode might well have qp=1, which is OK: RCU is still ignoring them. o "dt" is the current value of the dyntick counter that is incremented - when entering or leaving dynticks idle state, either by the - scheduler or by irq. This number is even if the CPU is in - dyntick idle mode and odd otherwise. The number after the first - "/" is the interrupt nesting depth when in dyntick-idle state, - or one greater than the interrupt-nesting depth otherwise. - The number after the second "/" is the NMI nesting depth. + when entering or leaving idle, either due to a context switch or + due to an interrupt. This number is even if the CPU is in idle + from RCU's viewpoint and odd otherwise. The number after the + first "/" is the interrupt nesting depth when in idle state, + or a large number added to the interrupt-nesting depth when + running a non-idle task. Some architectures do not accurately + count interrupt nesting when running in non-idle kernel context, + which can result in interesting anomalies such as negative + interrupt-nesting levels. The number after the second "/" + is the NMI nesting depth. o "df" is the number of times that some other CPU has forced a quiescent state on behalf of this CPU due to this CPU being in - dynticks-idle state. + idle state. o "of" is the number of times that some other CPU has forced a quiescent state on behalf of this CPU due to this CPU being @@ -120,9 +129,13 @@ o "of" is the number of times that some other CPU has forced a error, so it makes sense to err conservatively. o "ql" is the number of RCU callbacks currently residing on - this CPU. This is the total number of callbacks, regardless - of what state they are in (new, waiting for grace period to - start, waiting for grace period to end, ready to invoke). + this CPU. The first number is the number of "lazy" callbacks + that are known to RCU to only be freeing memory, and the number + after the "/" is the total number of callbacks, lazy or not. + These counters count callbacks regardless of what phase of + grace-period processing that they are in (new, waiting for + grace period to start, waiting for grace period to end, ready + to invoke). o "qs" gives an indication of the state of the callback queue with four characters: @@ -150,6 +163,43 @@ o "qs" gives an indication of the state of the callback queue If there are no callbacks in a given one of the above states, the corresponding character is replaced by ".". +o "b" is the batch limit for this CPU. If more than this number + of RCU callbacks is ready to invoke, then the remainder will + be deferred. + +o "ci" is the number of RCU callbacks that have been invoked for + this CPU. Note that ci+nci+ql is the number of callbacks that have + been registered in absence of CPU-hotplug activity. + +o "nci" is the number of RCU callbacks that have been offloaded from + this CPU. This will always be zero unless the kernel was built + with CONFIG_RCU_NOCB_CPU=y and the "rcu_nocbs=" kernel boot + parameter was specified. + +o "co" is the number of RCU callbacks that have been orphaned due to + this CPU going offline. These orphaned callbacks have been moved + to an arbitrarily chosen online CPU. + +o "ca" is the number of RCU callbacks that have been adopted by this + CPU due to other CPUs going offline. Note that ci+co-ca+ql is + the number of RCU callbacks registered on this CPU. + + +Kernels compiled with CONFIG_RCU_BOOST=y display the following from +/debug/rcu/rcu_preempt/rcudata: + + 0!c=12865 g=12866 pq=1 qp=1 dt=83113/140000000000000/0 df=288 of=11 ql=0/0 qs=N... kt=0/O ktl=944 b=10 ci=60709 nci=0 co=748 ca=871 + 1 c=14407 g=14408 pq=1 qp=0 dt=100679/140000000000000/0 df=378 of=7 ql=0/119 qs=NRW. kt=0/W ktl=9b6 b=10 ci=109740 nci=0 co=589 ca=485 + 2 c=14407 g=14408 pq=1 qp=0 dt=105486/0/0 df=90 of=9 ql=0/89 qs=NRW. kt=0/W ktl=c0c b=10 ci=83113 nci=0 co=533 ca=490 + 3 c=14407 g=14408 pq=1 qp=0 dt=107138/0/0 df=142 of=8 ql=0/188 qs=NRW. kt=0/W ktl=b96 b=10 ci=121114 nci=0 co=426 ca=290 + 4 c=14405 g=14406 pq=1 qp=1 dt=50238/0/0 df=706 of=7 ql=0/0 qs=.... kt=0/W ktl=812 b=10 ci=34929 nci=0 co=643 ca=114 + 5!c=14168 g=14169 pq=1 qp=0 dt=45465/140000000000000/0 df=161 of=11 ql=0/0 qs=N... kt=0/O ktl=b4d b=10 ci=47712 nci=0 co=677 ca=722 + 6 c=14404 g=14405 pq=1 qp=0 dt=59454/0/0 df=94 of=6 ql=0/0 qs=.... kt=0/W ktl=e57 b=10 ci=55597 nci=0 co=701 ca=811 + 7 c=14407 g=14408 pq=1 qp=1 dt=68850/0/0 df=31 of=8 ql=0/0 qs=.... kt=0/W ktl=14bd b=10 ci=77475 nci=0 co=508 ca=1042 + +This is similar to the output discussed above, but contains the following +additional fields: + o "kt" is the per-CPU kernel-thread state. The digit preceding the first slash is zero if there is no work pending and 1 otherwise. The character between the first pair of slashes is @@ -184,35 +234,51 @@ o "ktl" is the low-order 16 bits (in hexadecimal) of the count of This field is displayed only for CONFIG_RCU_BOOST kernels. -o "b" is the batch limit for this CPU. If more than this number - of RCU callbacks is ready to invoke, then the remainder will - be deferred. -o "ci" is the number of RCU callbacks that have been invoked for - this CPU. Note that ci+ql is the number of callbacks that have - been registered in absence of CPU-hotplug activity. +The output of "cat rcu/rcu_preempt/rcuexp" looks as follows: -o "co" is the number of RCU callbacks that have been orphaned due to - this CPU going offline. These orphaned callbacks have been moved - to an arbitrarily chosen online CPU. +s=21872 d=21872 w=0 tf=0 wd1=0 wd2=0 n=0 sc=21872 dt=21872 dl=0 dx=21872 + +These fields are as follows: + +o "s" is the starting sequence number. -o "ca" is the number of RCU callbacks that have been adopted due to - other CPUs going offline. Note that ci+co-ca+ql is the number of - RCU callbacks registered on this CPU. +o "d" is the ending sequence number. When the starting and ending + numbers differ, there is an expedited grace period in progress. -There is also an rcu/rcudata.csv file with the same information in -comma-separated-variable spreadsheet format. +o "w" is the number of times that the sequence numbers have been + in danger of wrapping. +o "tf" is the number of times that contention has resulted in a + failure to begin an expedited grace period. -The output of "cat rcu/rcugp" looks as follows: +o "wd1" and "wd2" are the number of times that an attempt to + start an expedited grace period found that someone else had + completed an expedited grace period that satisfies the + attempted request. "Our work is done." -rcu_sched: completed=33062 gpnum=33063 -rcu_bh: completed=464 gpnum=464 +o "n" is number of times that contention was so great that + the request was demoted from an expedited grace period to + a normal grace period. + +o "sc" is the number of times that the attempt to start a + new expedited grace period succeeded. + +o "dt" is the number of times that we attempted to update + the "d" counter. + +o "dl" is the number of times that we failed to update the "d" + counter. + +o "dx" is the number of times that we succeeded in updating + the "d" counter. -Again, this output is for both "rcu_sched" and "rcu_bh". Note that -kernels built with CONFIG_TREE_PREEMPT_RCU will have an additional -"rcu_preempt" line. The fields are taken from the rcu_state structure, -and are as follows: + +The output of "cat rcu/rcu_preempt/rcugp" looks as follows: + +completed=31249 gpnum=31250 age=1 max=18 + +These fields are taken from the rcu_state structure, and are as follows: o "completed" is the number of grace periods that have completed. It is comparable to the "c" field from rcu/rcudata in that a @@ -220,44 +286,42 @@ o "completed" is the number of grace periods that have completed. that the corresponding RCU grace period has completed. o "gpnum" is the number of grace periods that have started. It is - comparable to the "g" field from rcu/rcudata in that a CPU - whose "g" field matches the value of "gpnum" is aware that the - corresponding RCU grace period has started. + similarly comparable to the "g" field from rcu/rcudata in that + a CPU whose "g" field matches the value of "gpnum" is aware that + the corresponding RCU grace period has started. + + If these two fields are equal, then there is no grace period + in progress, in other words, RCU is idle. On the other hand, + if the two fields differ (as they are above), then an RCU grace + period is in progress. - If these two fields are equal (as they are for "rcu_bh" above), - then there is no grace period in progress, in other words, RCU - is idle. On the other hand, if the two fields differ (as they - do for "rcu_sched" above), then an RCU grace period is in progress. +o "age" is the number of jiffies that the current grace period + has extended for, or zero if there is no grace period currently + in effect. +o "max" is the age in jiffies of the longest-duration grace period + thus far. -The output of "cat rcu/rcuhier" looks as follows, with very long lines: +The output of "cat rcu/rcu_preempt/rcuhier" looks as follows: -c=6902 g=6903 s=2 jfq=3 j=72c7 nfqs=13142/nfqsng=0(13142) fqlh=6 -1/1 ..>. 0:127 ^0 -3/3 ..>. 0:35 ^0 0/0 ..>. 36:71 ^1 0/0 ..>. 72:107 ^2 0/0 ..>. 108:127 ^3 -3/3f ..>. 0:5 ^0 2/3 ..>. 6:11 ^1 0/0 ..>. 12:17 ^2 0/0 ..>. 18:23 ^3 0/0 ..>. 24:29 ^4 0/0 ..>. 30:35 ^5 0/0 ..>. 36:41 ^0 0/0 ..>. 42:47 ^1 0/0 ..>. 48:53 ^2 0/0 ..>. 54:59 ^3 0/0 ..>. 60:65 ^4 0/0 ..>. 66:71 ^5 0/0 ..>. 72:77 ^0 0/0 ..>. 78:83 ^1 0/0 ..>. 84:89 ^2 0/0 ..>. 90:95 ^3 0/0 ..>. 96:101 ^4 0/0 ..>. 102:107 ^5 0/0 ..>. 108:113 ^0 0/0 ..>. 114:119 ^1 0/0 ..>. 120:125 ^2 0/0 ..>. 126:127 ^3 -rcu_bh: -c=-226 g=-226 s=1 jfq=-5701 j=72c7 nfqs=88/nfqsng=0(88) fqlh=0 -0/1 ..>. 0:127 ^0 -0/3 ..>. 0:35 ^0 0/0 ..>. 36:71 ^1 0/0 ..>. 72:107 ^2 0/0 ..>. 108:127 ^3 -0/3f ..>. 0:5 ^0 0/3 ..>. 6:11 ^1 0/0 ..>. 12:17 ^2 0/0 ..>. 18:23 ^3 0/0 ..>. 24:29 ^4 0/0 ..>. 30:35 ^5 0/0 ..>. 36:41 ^0 0/0 ..>. 42:47 ^1 0/0 ..>. 48:53 ^2 0/0 ..>. 54:59 ^3 0/0 ..>. 60:65 ^4 0/0 ..>. 66:71 ^5 0/0 ..>. 72:77 ^0 0/0 ..>. 78:83 ^1 0/0 ..>. 84:89 ^2 0/0 ..>. 90:95 ^3 0/0 ..>. 96:101 ^4 0/0 ..>. 102:107 ^5 0/0 ..>. 108:113 ^0 0/0 ..>. 114:119 ^1 0/0 ..>. 120:125 ^2 0/0 ..>. 126:127 ^3 +c=14407 g=14408 s=0 jfq=2 j=c863 nfqs=12040/nfqsng=0(12040) fqlh=1051 oqlen=0/0 +3/3 ..>. 0:7 ^0 +e/e ..>. 0:3 ^0 d/d ..>. 4:7 ^1 -This is once again split into "rcu_sched" and "rcu_bh" portions, -and CONFIG_TREE_PREEMPT_RCU kernels will again have an additional -"rcu_preempt" section. The fields are as follows: +The fields are as follows: -o "c" is exactly the same as "completed" under rcu/rcugp. +o "c" is exactly the same as "completed" under rcu/rcu_preempt/rcugp. -o "g" is exactly the same as "gpnum" under rcu/rcugp. +o "g" is exactly the same as "gpnum" under rcu/rcu_preempt/rcugp. -o "s" is the "signaled" state that drives force_quiescent_state()'s +o "s" is the current state of the force_quiescent_state() state machine. o "jfq" is the number of jiffies remaining for this grace period before force_quiescent_state() is invoked to help push things - along. Note that CPUs in dyntick-idle mode throughout the grace - period will not report on their own, but rather must be check by - some other CPU via force_quiescent_state(). + along. Note that CPUs in idle mode throughout the grace period + will not report on their own, but rather must be check by some + other CPU via force_quiescent_state(). o "j" is the low-order four hex digits of the jiffies counter. Yes, Paul did run into a number of problems that turned out to @@ -268,7 +332,8 @@ o "nfqs" is the number of calls to force_quiescent_state() since o "nfqsng" is the number of useless calls to force_quiescent_state(), where there wasn't actually a grace period active. This can - happen due to races. The number in parentheses is the difference + no longer happen due to grace-period processing being pushed + into a kthread. The number in parentheses is the difference between "nfqs" and "nfqsng", or the number of times that force_quiescent_state() actually did some real work. @@ -276,28 +341,27 @@ o "fqlh" is the number of calls to force_quiescent_state() that exited immediately (without even being counted in nfqs above) due to contention on ->fqslock. -o Each element of the form "1/1 0:127 ^0" represents one struct - rcu_node. Each line represents one level of the hierarchy, from - root to leaves. It is best to think of the rcu_data structures - as forming yet another level after the leaves. Note that there - might be either one, two, or three levels of rcu_node structures, - depending on the relationship between CONFIG_RCU_FANOUT and - CONFIG_NR_CPUS. +o Each element of the form "3/3 ..>. 0:7 ^0" represents one rcu_node + structure. Each line represents one level of the hierarchy, + from root to leaves. It is best to think of the rcu_data + structures as forming yet another level after the leaves. + Note that there might be either one, two, three, or even four + levels of rcu_node structures, depending on the relationship + between CONFIG_RCU_FANOUT, CONFIG_RCU_FANOUT_LEAF (possibly + adjusted using the rcu_fanout_leaf kernel boot parameter), and + CONFIG_NR_CPUS (possibly adjusted using the nr_cpu_ids count of + possible CPUs for the booting hardware). o The numbers separated by the "/" are the qsmask followed by the qsmaskinit. The qsmask will have one bit - set for each entity in the next lower level that - has not yet checked in for the current grace period. + set for each entity in the next lower level that has + not yet checked in for the current grace period ("e" + indicating CPUs 5, 6, and 7 in the example above). The qsmaskinit will have one bit for each entity that is currently expected to check in during each grace period. The value of qsmaskinit is assigned to that of qsmask at the beginning of each grace period. - For example, for "rcu_sched", the qsmask of the first - entry of the lowest level is 0x14, meaning that we - are still waiting for CPUs 2 and 4 to check in for the - current grace period. - o The characters separated by the ">" indicate the state of the blocked-tasks lists. A "G" preceding the ">" indicates that at least one task blocked in an RCU @@ -312,48 +376,39 @@ o Each element of the form "1/1 0:127 ^0" represents one struct A "." character appears if the corresponding condition does not hold, so that "..>." indicates that no tasks are blocked. In contrast, "GE>T" indicates maximal - inconvenience from blocked tasks. + inconvenience from blocked tasks. CONFIG_TREE_RCU + builds of the kernel will always show "..>.". o The numbers separated by the ":" are the range of CPUs served by this struct rcu_node. This can be helpful in working out how the hierarchy is wired together. - For example, the first entry at the lowest level shows - "0:5", indicating that it covers CPUs 0 through 5. + For example, the example rcu_node structure shown above + has "0:7", indicating that it covers CPUs 0 through 7. o The number after the "^" indicates the bit in the - next higher level rcu_node structure that this - rcu_node structure corresponds to. - - For example, the first entry at the lowest level shows - "^0", indicating that it corresponds to bit zero in - the first entry at the middle level. - - -The output of "cat rcu/rcu_pending" looks as follows: - -rcu_sched: - 0 np=255892 qsp=53936 rpq=85 cbr=0 cng=14417 gpc=10033 gps=24320 nn=146741 - 1 np=261224 qsp=54638 rpq=33 cbr=0 cng=25723 gpc=16310 gps=2849 nn=155792 - 2 np=237496 qsp=49664 rpq=23 cbr=0 cng=2762 gpc=45478 gps=1762 nn=136629 - 3 np=236249 qsp=48766 rpq=98 cbr=0 cng=286 gpc=48049 gps=1218 nn=137723 - 4 np=221310 qsp=46850 rpq=7 cbr=0 cng=26 gpc=43161 gps=4634 nn=123110 - 5 np=237332 qsp=48449 rpq=9 cbr=0 cng=54 gpc=47920 gps=3252 nn=137456 - 6 np=219995 qsp=46718 rpq=12 cbr=0 cng=50 gpc=42098 gps=6093 nn=120834 - 7 np=249893 qsp=49390 rpq=42 cbr=0 cng=72 gpc=38400 gps=17102 nn=144888 -rcu_bh: - 0 np=146741 qsp=1419 rpq=6 cbr=0 cng=6 gpc=0 gps=0 nn=145314 - 1 np=155792 qsp=12597 rpq=3 cbr=0 cng=0 gpc=4 gps=8 nn=143180 - 2 np=136629 qsp=18680 rpq=1 cbr=0 cng=0 gpc=7 gps=6 nn=117936 - 3 np=137723 qsp=2843 rpq=0 cbr=0 cng=0 gpc=10 gps=7 nn=134863 - 4 np=123110 qsp=12433 rpq=0 cbr=0 cng=0 gpc=4 gps=2 nn=110671 - 5 np=137456 qsp=4210 rpq=1 cbr=0 cng=0 gpc=6 gps=5 nn=133235 - 6 np=120834 qsp=9902 rpq=2 cbr=0 cng=0 gpc=6 gps=3 nn=110921 - 7 np=144888 qsp=26336 rpq=0 cbr=0 cng=0 gpc=8 gps=2 nn=118542 - -As always, this is once again split into "rcu_sched" and "rcu_bh" -portions, with CONFIG_TREE_PREEMPT_RCU kernels having an additional -"rcu_preempt" section. The fields are as follows: + next higher level rcu_node structure that this rcu_node + structure corresponds to. For example, the "d/d ..>. 4:7 + ^1" has a "1" in this position, indicating that it + corresponds to the "1" bit in the "3" shown in the + "3/3 ..>. 0:7 ^0" entry on the next level up. + + +The output of "cat rcu/rcu_sched/rcu_pending" looks as follows: + + 0!np=26111 qsp=29 rpq=5386 cbr=1 cng=570 gpc=3674 gps=577 nn=15903 + 1!np=28913 qsp=35 rpq=6097 cbr=1 cng=448 gpc=3700 gps=554 nn=18113 + 2!np=32740 qsp=37 rpq=6202 cbr=0 cng=476 gpc=4627 gps=546 nn=20889 + 3 np=23679 qsp=22 rpq=5044 cbr=1 cng=415 gpc=3403 gps=347 nn=14469 + 4!np=30714 qsp=4 rpq=5574 cbr=0 cng=528 gpc=3931 gps=639 nn=20042 + 5 np=28910 qsp=2 rpq=5246 cbr=0 cng=428 gpc=4105 gps=709 nn=18422 + 6!np=38648 qsp=5 rpq=7076 cbr=0 cng=840 gpc=4072 gps=961 nn=25699 + 7 np=37275 qsp=2 rpq=6873 cbr=0 cng=868 gpc=3416 gps=971 nn=25147 + +The fields are as follows: + +o The leading number is the CPU number, with "!" indicating + an offline CPU. o "np" is the number of times that __rcu_pending() has been invoked for the corresponding flavor of RCU. @@ -377,38 +432,23 @@ o "gpc" is the number of times that an old grace period had o "gps" is the number of times that a new grace period had started, but this CPU was not yet aware of it. -o "nn" is the number of times that this CPU needed nothing. Alert - readers will note that the rcu "nn" number for a given CPU very - closely matches the rcu_bh "np" number for that same CPU. This - is due to short-circuit evaluation in rcu_pending(). - - -The output of "cat rcu/rcutorture" looks as follows: - -rcutorture test sequence: 0 (test in progress) -rcutorture update version number: 615 - -The first line shows the number of rcutorture tests that have completed -since boot. If a test is currently running, the "(test in progress)" -string will appear as shown above. The second line shows the number of -update cycles that the current test has started, or zero if there is -no test in progress. +o "nn" is the number of times that this CPU needed nothing. The output of "cat rcu/rcuboost" looks as follows: -0:5 tasks=.... kt=W ntb=0 neb=0 nnb=0 j=2f95 bt=300f - balk: nt=0 egt=989 bt=0 nb=0 ny=0 nos=16 -6:7 tasks=.... kt=W ntb=0 neb=0 nnb=0 j=2f95 bt=300f - balk: nt=0 egt=225 bt=0 nb=0 ny=0 nos=6 +0:3 tasks=.... kt=W ntb=0 neb=0 nnb=0 j=c864 bt=c894 + balk: nt=0 egt=4695 bt=0 nb=0 ny=56 nos=0 +4:7 tasks=.... kt=W ntb=0 neb=0 nnb=0 j=c864 bt=c894 + balk: nt=0 egt=6541 bt=0 nb=0 ny=126 nos=0 This information is output only for rcu_preempt. Each two-line entry corresponds to a leaf rcu_node strcuture. The fields are as follows: o "n:m" is the CPU-number range for the corresponding two-line entry. In the sample output above, the first entry covers - CPUs zero through five and the second entry covers CPUs 6 - and 7. + CPUs zero through three and the second entry covers CPUs four + through seven. o "tasks=TNEB" gives the state of the various segments of the rnp->blocked_tasks list: diff --git a/Documentation/RCU/whatisRCU.txt b/Documentation/RCU/whatisRCU.txt index bf0f6de2aa00..0cc7820967f4 100644 --- a/Documentation/RCU/whatisRCU.txt +++ b/Documentation/RCU/whatisRCU.txt @@ -499,6 +499,8 @@ The foo_reclaim() function might appear as follows: { struct foo *fp = container_of(rp, struct foo, rcu); + foo_cleanup(fp->a); + kfree(fp); } @@ -521,6 +523,12 @@ o Use call_rcu() -after- removing a data element from an read-side critical sections that might be referencing that data item. +If the callback for call_rcu() is not doing anything more than calling +kfree() on the structure, you can use kfree_rcu() instead of call_rcu() +to avoid having to write your own callback: + + kfree_rcu(old_fp, rcu); + Again, see checklist.txt for additional rules governing the use of RCU. @@ -773,8 +781,8 @@ a single atomic update, converting to RCU will require special care. Also, the presence of synchronize_rcu() means that the RCU version of delete() can now block. If this is a problem, there is a callback-based -mechanism that never blocks, namely call_rcu(), that can be used in -place of synchronize_rcu(). +mechanism that never blocks, namely call_rcu() or kfree_rcu(), that can +be used in place of synchronize_rcu(). 7. FULL LIST OF RCU APIs @@ -789,9 +797,7 @@ RCU list traversal: list_for_each_entry_rcu hlist_for_each_entry_rcu hlist_nulls_for_each_entry_rcu - - list_for_each_continue_rcu (to be deprecated in favor of new - list_for_each_entry_continue_rcu) + list_for_each_entry_continue_rcu RCU pointer/list update: @@ -813,6 +819,7 @@ RCU: Critical sections Grace period Barrier rcu_read_unlock synchronize_rcu rcu_dereference synchronize_rcu_expedited call_rcu + kfree_rcu bh: Critical sections Grace period Barrier diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index c379a2a6949f..aa0c1e63f050 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -60,8 +60,7 @@ own source tree. For example: "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- diff --git a/Documentation/accounting/getdelays.c b/Documentation/accounting/getdelays.c index 6f706aca2049..f8ebcde43b17 100644 --- a/Documentation/accounting/getdelays.c +++ b/Documentation/accounting/getdelays.c @@ -51,7 +51,6 @@ int dbg; int print_delays; int print_io_accounting; int print_task_context_switch_counts; -__u64 stime, utime; #define PRINTF(fmt, arg...) { \ if (dbg) { \ diff --git a/Documentation/acpi/enumeration.txt b/Documentation/acpi/enumeration.txt new file mode 100644 index 000000000000..94a656131885 --- /dev/null +++ b/Documentation/acpi/enumeration.txt @@ -0,0 +1,227 @@ +ACPI based device enumeration +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +ACPI 5 introduced a set of new resources (UartTSerialBus, I2cSerialBus, +SpiSerialBus, GpioIo and GpioInt) which can be used in enumerating slave +devices behind serial bus controllers. + +In addition we are starting to see peripherals integrated in the +SoC/Chipset to appear only in ACPI namespace. These are typically devices +that are accessed through memory-mapped registers. + +In order to support this and re-use the existing drivers as much as +possible we decided to do following: + + o Devices that have no bus connector resource are represented as + platform devices. + + o Devices behind real busses where there is a connector resource + are represented as struct spi_device or struct i2c_device + (standard UARTs are not busses so there is no struct uart_device). + +As both ACPI and Device Tree represent a tree of devices (and their +resources) this implementation follows the Device Tree way as much as +possible. + +The ACPI implementation enumerates devices behind busses (platform, SPI and +I2C), creates the physical devices and binds them to their ACPI handle in +the ACPI namespace. + +This means that when ACPI_HANDLE(dev) returns non-NULL the device was +enumerated from ACPI namespace. This handle can be used to extract other +device-specific configuration. There is an example of this below. + +Platform bus support +~~~~~~~~~~~~~~~~~~~~ +Since we are using platform devices to represent devices that are not +connected to any physical bus we only need to implement a platform driver +for the device and add supported ACPI IDs. If this same IP-block is used on +some other non-ACPI platform, the driver might work out of the box or needs +some minor changes. + +Adding ACPI support for an existing driver should be pretty +straightforward. Here is the simplest example: + + #ifdef CONFIG_ACPI + static struct acpi_device_id mydrv_acpi_match[] = { + /* ACPI IDs here */ + { } + }; + MODULE_DEVICE_TABLE(acpi, mydrv_acpi_match); + #endif + + static struct platform_driver my_driver = { + ... + .driver = { + .acpi_match_table = ACPI_PTR(mydrv_acpi_match), + }, + }; + +If the driver needs to perform more complex initialization like getting and +configuring GPIOs it can get its ACPI handle and extract this information +from ACPI tables. + +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/acpi_platform.c. This limitation is only for the platform +devices, SPI and I2C devices are created automatically as described below. + +SPI serial bus support +~~~~~~~~~~~~~~~~~~~~~~ +Slave devices behind SPI bus have SpiSerialBus resource attached to them. +This is extracted automatically by the SPI core and the slave devices are +enumerated once spi_register_master() is called by the bus driver. + +Here is what the ACPI namespace for a SPI slave might look like: + + Device (EEP0) + { + Name (_ADR, 1) + Name (_CID, Package() { + "ATML0025", + "AT25", + }) + ... + Method (_CRS, 0, NotSerialized) + { + SPISerialBus(1, PolarityLow, FourWireMode, 8, + ControllerInitiated, 1000000, ClockPolarityLow, + ClockPhaseFirst, "\\_SB.PCI0.SPI1",) + } + ... + +The SPI device drivers only need to add ACPI IDs in a similar way than with +the platform device drivers. Below is an example where we add ACPI support +to at25 SPI eeprom driver (this is meant for the above ACPI snippet): + + #ifdef CONFIG_ACPI + static struct acpi_device_id at25_acpi_match[] = { + { "AT25", 0 }, + { }, + }; + MODULE_DEVICE_TABLE(acpi, at25_acpi_match); + #endif + + static struct spi_driver at25_driver = { + .driver = { + ... + .acpi_match_table = ACPI_PTR(at25_acpi_match), + }, + }; + +Note that this driver actually needs more information like page size of the +eeprom etc. but at the time writing this there is no standard way of +passing those. One idea is to return this in _DSM method like: + + Device (EEP0) + { + ... + Method (_DSM, 4, NotSerialized) + { + Store (Package (6) + { + "byte-len", 1024, + "addr-mode", 2, + "page-size, 32 + }, Local0) + + // Check UUIDs etc. + + Return (Local0) + } + +Then the at25 SPI driver can get this configation by calling _DSM on its +ACPI handle like: + + struct acpi_buffer output = { ACPI_ALLOCATE_BUFFER, NULL }; + struct acpi_object_list input; + acpi_status status; + + /* Fill in the input buffer */ + + status = acpi_evaluate_object(ACPI_HANDLE(&spi->dev), "_DSM", + &input, &output); + if (ACPI_FAILURE(status)) + /* Handle the error */ + + /* Extract the data here */ + + kfree(output.pointer); + +I2C serial bus support +~~~~~~~~~~~~~~~~~~~~~~ +The slaves behind I2C bus controller only need to add the ACPI IDs like +with the platform and SPI drivers. However the I2C bus controller driver +needs to call acpi_i2c_register_devices() after it has added the adapter. + +An I2C bus (controller) driver does: + + ... + ret = i2c_add_numbered_adapter(adapter); + if (ret) + /* handle error */ + + of_i2c_register_devices(adapter); + /* Enumerate the slave devices behind this bus via ACPI */ + acpi_i2c_register_devices(adapter); + +Below is an example of how to add ACPI support to the existing mpu3050 +input driver: + + #ifdef CONFIG_ACPI + static struct acpi_device_id mpu3050_acpi_match[] = { + { "MPU3050", 0 }, + { }, + }; + MODULE_DEVICE_TABLE(acpi, mpu3050_acpi_match); + #endif + + static struct i2c_driver mpu3050_i2c_driver = { + .driver = { + .name = "mpu3050", + .owner = THIS_MODULE, + .pm = &mpu3050_pm, + .of_match_table = mpu3050_of_match, + .acpi_match_table ACPI_PTR(mpu3050_acpi_match), + }, + .probe = mpu3050_probe, + .remove = mpu3050_remove, + .id_table = mpu3050_ids, + }; + +GPIO support +~~~~~~~~~~~~ +ACPI 5 introduced two new resources to describe GPIO connections: GpioIo +and GpioInt. These resources are used be used to pass GPIO numbers used by +the device to the driver. For example: + + Method (_CRS, 0, NotSerialized) + { + Name (SBUF, ResourceTemplate() + { + GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, + IoRestrictionOutputOnly, "\\_SB.PCI0.GPI0", + 0x00, ResourceConsumer,,) + { + // Pin List + 0x0055 + } + ... + + Return (SBUF) + } + } + +These GPIO numbers are controller relative and path "\\_SB.PCI0.GPI0" +specifies the path to the controller. In order to use these GPIOs in Linux +we need to translate them to the Linux GPIO numbers. + +The driver can do this by including <linux/acpi_gpio.h> and then calling +acpi_get_gpio(path, gpio). This will return the Linux GPIO number or +negative errno if there was no translation found. + +Other GpioIo parameters must be converted first by the driver to be +suitable to the gpiolib before passing them. + +In case of GpioInt resource an additional call to gpio_to_irq() must be +done before calling request_irq(). diff --git a/Documentation/acpi/initrd_table_override.txt b/Documentation/acpi/initrd_table_override.txt new file mode 100644 index 000000000000..35c3f5415476 --- /dev/null +++ b/Documentation/acpi/initrd_table_override.txt @@ -0,0 +1,94 @@ +Overriding ACPI tables via initrd +================================= + +1) Introduction (What is this about) +2) What is this for +3) How does it work +4) References (Where to retrieve userspace tools) + +1) What is this about +--------------------- + +If the ACPI_INITRD_TABLE_OVERRIDE compile option is true, it is possible to +override nearly any ACPI table provided by the BIOS with an instrumented, +modified one. + +For a full list of ACPI tables that can be overridden, take a look at +the char *table_sigs[MAX_ACPI_SIGNATURE]; definition in drivers/acpi/osl.c +All ACPI tables iasl (Intel's ACPI compiler and disassembler) knows should +be overridable, except: + - ACPI_SIG_RSDP (has a signature of 6 bytes) + - ACPI_SIG_FACS (does not have an ordinary ACPI table header) +Both could get implemented as well. + + +2) What is this for +------------------- + +Please keep in mind that this is a debug option. +ACPI tables should not get overridden for productive use. +If BIOS ACPI tables are overridden the kernel will get tainted with the +TAINT_OVERRIDDEN_ACPI_TABLE flag. +Complain to your platform/BIOS vendor if you find a bug which is so sever +that a workaround is not accepted in the Linux kernel. + +Still, it can and should be enabled in any kernel, because: + - There is no functional change with not instrumented initrds + - It provides a powerful feature to easily debug and test ACPI BIOS table + compatibility with the Linux kernel. + + +3) How does it work +------------------- + +# Extract the machine's ACPI tables: +cd /tmp +acpidump >acpidump +acpixtract -a acpidump +# Disassemble, modify and recompile them: +iasl -d *.dat +# For example add this statement into a _PRT (PCI Routing Table) function +# of the DSDT: +Store("HELLO WORLD", debug) +iasl -sa dsdt.dsl +# Add the raw ACPI tables to an uncompressed cpio archive. +# They must be put into a /kernel/firmware/acpi directory inside the +# cpio archive. +# The uncompressed cpio archive must be the first. +# Other, typically compressed cpio archives, must be +# concatenated on top of the uncompressed one. +mkdir -p kernel/firmware/acpi +cp dsdt.aml kernel/firmware/acpi +# A maximum of: #define ACPI_OVERRIDE_TABLES 10 +# tables are currently allowed (see osl.c): +iasl -sa facp.dsl +iasl -sa ssdt1.dsl +cp facp.aml kernel/firmware/acpi +cp ssdt1.aml kernel/firmware/acpi +# Create the uncompressed cpio archive and concatenate the original initrd +# on top: +find kernel | cpio -H newc --create > /boot/instrumented_initrd +cat /boot/initrd >>/boot/instrumented_initrd +# reboot with increased acpi debug level, e.g. boot params: +acpi.debug_level=0x2 acpi.debug_layer=0xFFFFFFFF +# and check your syslog: +[ 1.268089] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] +[ 1.272091] [ACPI Debug] String [0x0B] "HELLO WORLD" + +iasl is able to disassemble and recompile quite a lot different, +also static ACPI tables. + + +4) Where to retrieve userspace tools +------------------------------------ + +iasl and acpixtract are part of Intel's ACPICA project: +http://acpica.org/ +and should be packaged by distributions (for example in the acpica package +on SUSE). + +acpidump can be found in Len Browns pmtools: +ftp://kernel.org/pub/linux/kernel/people/lenb/acpi/utils/pmtools/acpidump +This tool is also part of the acpica package on SUSE. +Alternatively, used ACPI tables can be retrieved via sysfs in latest kernels: +/sys/firmware/acpi/tables diff --git a/Documentation/acpi/scan_handlers.txt b/Documentation/acpi/scan_handlers.txt new file mode 100644 index 000000000000..3246ccf15992 --- /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/aoe/aoe.txt b/Documentation/aoe/aoe.txt index bfc9cb19abcd..c71487d399d1 100644 --- a/Documentation/aoe/aoe.txt +++ b/Documentation/aoe/aoe.txt @@ -125,7 +125,9 @@ DRIVER OPTIONS The aoe_deadsecs module parameter determines the maximum number of seconds that the driver will wait for an AoE device to provide a response to an AoE command. After aoe_deadsecs seconds have - elapsed, the AoE device will be marked as "down". + elapsed, the AoE device will be marked as "down". A value of zero + is supported for testing purposes and makes the aoe driver keep + trying AoE commands forever. The aoe_maxout module parameter has a default of 128. This is the maximum number of unresponded packets that will be sent to an AoE diff --git a/Documentation/arm/OMAP/DSS b/Documentation/arm/OMAP/DSS index a564ceea9e98..4484e021290e 100644 --- a/Documentation/arm/OMAP/DSS +++ b/Documentation/arm/OMAP/DSS @@ -285,7 +285,10 @@ FB0 +-- GFX ---- LCD ---- LCD Misc notes ---------- -OMAP FB allocates the framebuffer memory using the OMAP VRAM allocator. +OMAP FB allocates the framebuffer memory using the standard dma allocator. You +can enable Contiguous Memory Allocator (CONFIG_CMA) to improve the dma +allocator, and if CMA is enabled, you use "cma=" kernel parameter to increase +the global memory area for CMA. Using DSI DPLL to generate pixel clock it is possible produce the pixel clock of 86.5MHz (max possible), and with that you get 1280x1024@57 output from DVI. @@ -301,11 +304,6 @@ framebuffer parameters. Kernel boot arguments --------------------- -vram=<size>[,<physaddr>] - - Amount of total VRAM to preallocate and optionally a physical start - memory address. For example, "10M". omapfb allocates memory for - framebuffers from VRAM. - omapfb.mode=<display>:<mode>[,...] - Default video mode for specified displays. For example, "dvi:800x400MR-24@60". See drivers/video/modedb.c. diff --git a/Documentation/arm/sunxi/README b/Documentation/arm/sunxi/README new file mode 100644 index 000000000000..87a1e8fb6242 --- /dev/null +++ b/Documentation/arm/sunxi/README @@ -0,0 +1,19 @@ +ARM Allwinner SoCs +================== + +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. + +SunXi family +------------ + + Flavors: + Allwinner A10 (sun4i) + Datasheet : http://dl.linux-sunxi.org/A10/A10%20Datasheet%20-%20v1.21%20%282012-04-06%29.pdf + + Allwinner A13 (sun5i) + Datasheet : http://dl.linux-sunxi.org/A13/A13%20Datasheet%20-%20v1.12%20%282012-03-29%29.pdf + + Core: Cortex A8 + Linux kernel mach directory: arch/arm/mach-sunxi
\ No newline at end of file diff --git a/Documentation/arm64/memory.txt b/Documentation/arm64/memory.txt index dbbdcbba75a3..5f583af0a6e1 100644 --- a/Documentation/arm64/memory.txt +++ b/Documentation/arm64/memory.txt @@ -27,21 +27,23 @@ Start End Size Use ----------------------------------------------------------------------- 0000000000000000 0000007fffffffff 512GB user -ffffff8000000000 ffffffbbfffcffff ~240GB vmalloc +ffffff8000000000 ffffffbbfffeffff ~240GB vmalloc -ffffffbbfffd0000 ffffffbcfffdffff 64KB [guard page] +ffffffbbffff0000 ffffffbbffffffff 64KB [guard page] -ffffffbbfffe0000 ffffffbcfffeffff 64KB PCI I/O space +ffffffbc00000000 ffffffbdffffffff 8GB vmemmap -ffffffbbffff0000 ffffffbcffffffff 64KB [guard page] +ffffffbe00000000 ffffffbffbbfffff ~8GB [guard, future vmmemap] -ffffffbc00000000 ffffffbdffffffff 8GB vmemmap +ffffffbffbc00000 ffffffbffbdfffff 2MB earlyprintk device + +ffffffbffbe00000 ffffffbffbe0ffff 64KB PCI I/O space -ffffffbe00000000 ffffffbffbffffff ~8GB [guard, future vmmemap] +ffffffbbffff0000 ffffffbcffffffff ~2MB [guard] ffffffbffc000000 ffffffbfffffffff 64MB modules -ffffffc000000000 ffffffffffffffff 256GB memory +ffffffc000000000 ffffffffffffffff 256GB kernel logical memory map Translation table lookup with 4KB pages: diff --git a/Documentation/atomic_ops.txt b/Documentation/atomic_ops.txt index 27f2b21a9d5c..d9ca5be9b471 100644 --- a/Documentation/atomic_ops.txt +++ b/Documentation/atomic_ops.txt @@ -253,6 +253,8 @@ This performs an atomic exchange operation on the atomic variable v, setting 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 f5e4caafab7d..18b06ca038ea 100644 --- a/Documentation/backlight/lp855x-driver.txt +++ b/Documentation/backlight/lp855x-driver.txt @@ -4,7 +4,7 @@ Kernel driver lp855x 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 @@ Value : pwm based or register based 2) chip_id The lp855x chip id. -Value : lp8550/lp8551/lp8552/lp8553/lp8556 +Value : lp8550/lp8551/lp8552/lp8553/lp8556/lp8557 Platform data for lp855x ------------------------ @@ -35,11 +35,8 @@ For supporting platform specific data, the lp855x platform data can be used. * mode : Brightness control mode. PWM or register based. * device_control : Value of DEVICE CONTROL register. * initial_brightness : Initial value of backlight brightness. -* pwm_data : Platform specific pwm generation functions. +* period_ns : Platform specific PWM period value. unit is nano. Only valid when brightness is pwm input mode. - Functions should be implemented by PWM driver. - - pwm_set_intensity() : set duty of PWM - - pwm_get_intensity() : get current duty of PWM * load_new_rom_data : 0 : use default configuration data 1 : update values of eeprom or eprom registers on loading driver @@ -71,8 +68,5 @@ static struct lp855x_platform_data lp8556_pdata = { .mode = PWM_BASED, .device_control = PWM_CONFIG(LP8556), .initial_brightness = INITIAL_BRT, - .pwm_data = { - .pwm_set_intensity = platform_pwm_set_intensity, - .pwm_get_intensity = platform_pwm_get_intensity, - }, + .period_ns = 1000000, }; diff --git a/Documentation/block/cfq-iosched.txt b/Documentation/block/cfq-iosched.txt index d89b4fe724d7..a5eb7d19a65d 100644 --- a/Documentation/block/cfq-iosched.txt +++ b/Documentation/block/cfq-iosched.txt @@ -102,6 +102,64 @@ processing of request. Therefore, increasing the value can imporve the performace 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/blockdev/nbd.txt b/Documentation/blockdev/nbd.txt index aeb93ffe6416..271e607304da 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/bus-devices/ti-gpmc.txt b/Documentation/bus-devices/ti-gpmc.txt new file mode 100644 index 000000000000..cc9ce57e0a26 --- /dev/null +++ b/Documentation/bus-devices/ti-gpmc.txt @@ -0,0 +1,122 @@ +GPMC (General Purpose Memory Controller): +========================================= + +GPMC is an unified memory controller dedicated to interfacing external +memory devices like + * Asynchronous SRAM like memories and application specific integrated + circuit devices. + * Asynchronous, synchronous, and page mode burst NOR flash devices + NAND flash + * Pseudo-SRAM devices + +GPMC is found on Texas Instruments SoC's (OMAP based) +IP details: http://www.ti.com/lit/pdf/spruh73 section 7.1 + + +GPMC generic timing calculation: +================================ + +GPMC has certain timings that has to be programmed for proper +functioning of the peripheral, while peripheral has another set of +timings. To have peripheral work with gpmc, peripheral timings has to +be translated to the form gpmc can understand. The way it has to be +translated depends on the connected peripheral. Also there is a +dependency for certain gpmc timings on gpmc clock frequency. Hence a +generic timing routine was developed to achieve above requirements. + +Generic routine provides a generic method to calculate gpmc timings +from gpmc peripheral timings. struct gpmc_device_timings fields has to +be updated with timings from the datasheet of the peripheral that is +connected to gpmc. A few of the peripheral timings can be fed either +in time or in cycles, provision to handle this scenario has been +provided (refer struct gpmc_device_timings definition). It may so +happen that timing as specified by peripheral datasheet is not present +in timing structure, in this scenario, try to correlate peripheral +timing to the one available. If that doesn't work, try to add a new +field as required by peripheral, educate generic timing routine to +handle it, make sure that it does not break any of the existing. +Then there may be cases where peripheral datasheet doesn't mention +certain fields of struct gpmc_device_timings, zero those entries. + +Generic timing routine has been verified to work properly on +multiple onenand's and tusb6010 peripherals. + +A word of caution: generic timing routine has been developed based +on understanding of gpmc timings, peripheral timings, available +custom timing routines, a kind of reverse engineering without +most of the datasheets & hardware (to be exact none of those supported +in mainline having custom timing routine) and by simulation. + +gpmc timing dependency on peripheral timings: +[<gpmc_timing>: <peripheral timing1>, <peripheral timing2> ...] + +1. common +cs_on: t_ceasu +adv_on: t_avdasu, t_ceavd + +2. sync common +sync_clk: clk +page_burst_access: t_bacc +clk_activation: t_ces, t_avds + +3. read async muxed +adv_rd_off: t_avdp_r +oe_on: t_oeasu, t_aavdh +access: t_iaa, t_oe, t_ce, t_aa +rd_cycle: t_rd_cycle, t_cez_r, t_oez + +4. read async non-muxed +adv_rd_off: t_avdp_r +oe_on: t_oeasu +access: t_iaa, t_oe, t_ce, t_aa +rd_cycle: t_rd_cycle, t_cez_r, t_oez + +5. read sync muxed +adv_rd_off: t_avdp_r, t_avdh +oe_on: t_oeasu, t_ach, cyc_aavdh_oe +access: t_iaa, cyc_iaa, cyc_oe +rd_cycle: t_cez_r, t_oez, t_ce_rdyz + +6. read sync non-muxed +adv_rd_off: t_avdp_r +oe_on: t_oeasu +access: t_iaa, cyc_iaa, cyc_oe +rd_cycle: t_cez_r, t_oez, t_ce_rdyz + +7. write async muxed +adv_wr_off: t_avdp_w +we_on, wr_data_mux_bus: t_weasu, t_aavdh, cyc_aavhd_we +we_off: t_wpl +cs_wr_off: t_wph +wr_cycle: t_cez_w, t_wr_cycle + +8. write async non-muxed +adv_wr_off: t_avdp_w +we_on, wr_data_mux_bus: t_weasu +we_off: t_wpl +cs_wr_off: t_wph +wr_cycle: t_cez_w, t_wr_cycle + +9. write sync muxed +adv_wr_off: t_avdp_w, t_avdh +we_on, wr_data_mux_bus: t_weasu, t_rdyo, t_aavdh, cyc_aavhd_we +we_off: t_wpl, cyc_wpl +cs_wr_off: t_wph +wr_cycle: t_cez_w, t_ce_rdyz + +10. write sync non-muxed +adv_wr_off: t_avdp_w +we_on, wr_data_mux_bus: t_weasu, t_rdyo +we_off: t_wpl, cyc_wpl +cs_wr_off: t_wph +wr_cycle: t_cez_w, t_ce_rdyz + + +Note: Many of gpmc timings are dependent on other gpmc timings (a few +gpmc timings purely dependent on other gpmc timings, a reason that +some of the gpmc timings are missing above), and it will result in +indirect dependency of peripheral timings to gpmc timings other than +mentioned above, refer timing routine for more details. To know what +these peripheral timings correspond to, please see explanations in +struct gpmc_device_timings definition. And for gpmc timings refer +IP details (link above). diff --git a/Documentation/cgroups/00-INDEX b/Documentation/cgroups/00-INDEX index 3f58fa3d6d00..f5635a09c3f6 100644 --- a/Documentation/cgroups/00-INDEX +++ b/Documentation/cgroups/00-INDEX @@ -1,5 +1,7 @@ 00-INDEX - this file +blkio-controller.txt + - Description for Block IO Controller, implementation and usage details. cgroups.txt - Control Groups definition, implementation details, examples and API. cpuacct.txt @@ -10,9 +12,13 @@ devices.txt - Device Whitelist Controller; description, interface and security. freezer-subsystem.txt - checkpointing; rationale to not use signals, interface. +hugetlb.txt + - HugeTLB Controller implementation and usage details. memcg_test.txt - Memory Resource Controller; implementation details. memory.txt - Memory Resource Controller; design, accounting, interface, testing. +net_prio.txt + - Network priority cgroups details and usages. resource_counter.txt - Resource Counter API. diff --git a/Documentation/cgroups/blkio-controller.txt b/Documentation/cgroups/blkio-controller.txt index b4b1fb3a83f0..da272c8f44e7 100644 --- a/Documentation/cgroups/blkio-controller.txt +++ b/Documentation/cgroups/blkio-controller.txt @@ -75,7 +75,7 @@ Throttling/Upper Limit policy 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,11 @@ Throttling/Upper Limit policy 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. +- Currently only CFQ supports hierarchical groups. For throttling, + cgroup interface does allow creation of hierarchical cgroups and + internally it treats 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. + If somebody created a hierarchy like as follows. root / \ @@ -108,16 +106,20 @@ Hierarchical Cgroups | test3 - CFQ and throttling will practically treat all groups at same level. + CFQ will handle the hierarchy correctly but and throttling will + practically treat all groups at same level. For details on CFQ + hierarchy support, refer to Documentation/block/cfq-iosched.txt. + Throttling will treat the hierarchy 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. + Nesting cgroups, while allowed, isn't officially supported and blkio + genereates warning when cgroups nest. Once throttling implements + hierarchy support, hierarchy will be supported and the warning will + be removed. Various user visible config options =================================== @@ -172,6 +174,12 @@ Proportional weight policy files 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 +287,11 @@ Proportional weight policy files 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 3e082f96dc12..000000000000 --- 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 9e04196c4d78..bcf1a00b06a1 100644 --- a/Documentation/cgroups/cgroups.txt +++ b/Documentation/cgroups/cgroups.txt @@ -299,11 +299,9 @@ a cgroup hierarchy's release_agent path is empty. 1.5 What does clone_children do ? --------------------------------- -If the clone_children flag is enabled (1) in a cgroup, then all -cgroups created beneath will call the post_clone callbacks for each -subsystem of the newly created cgroup. Usually when this callback is -implemented for a subsystem, it copies the values of the parent -subsystem, this is the case for the cpuset. +This flag only affects the cpuset controller. If the clone_children +flag is enabled (1) in a cgroup, a new cpuset cgroup will copy its +configuration from the parent during initialization. 1.6 How do I use cgroups ? -------------------------- @@ -553,16 +551,16 @@ call to cgroup_unload_subsys(). It should also set its_subsys.module = THIS_MODULE in its .c file. Each subsystem may export the following methods. The only mandatory -methods are create/destroy. Any others that are null are presumed to +methods are css_alloc/free. Any others that are null are presumed to be successful no-ops. -struct cgroup_subsys_state *create(struct cgroup *cgrp) +struct cgroup_subsys_state *css_alloc(struct cgroup *cgrp) (cgroup_mutex held by caller) -Called to create a subsystem state object for a cgroup. The +Called to allocate a subsystem state object for a cgroup. The subsystem should allocate its subsystem state object for the passed cgroup, returning a pointer to the new object on success or a -negative error code. On success, the subsystem pointer should point to +ERR_PTR() value. On success, the subsystem pointer should point to a structure of type cgroup_subsys_state (typically embedded in a larger subsystem-specific object), which will be initialized by the cgroup system. Note that this will be called at initialization to @@ -571,24 +569,33 @@ identified by the passed cgroup object having a NULL parent (since it's the root of the hierarchy) and may be an appropriate place for initialization code. -void destroy(struct cgroup *cgrp) +int css_online(struct cgroup *cgrp) (cgroup_mutex held by caller) -The cgroup system is about to destroy the passed cgroup; the subsystem -should do any necessary cleanup and free its subsystem state -object. By the time this method is called, the cgroup has already been -unlinked from the file system and from the child list of its parent; -cgroup->parent is still valid. (Note - can also be called for a -newly-created cgroup if an error occurs after this subsystem's -create() method has been called for the new cgroup). +Called after @cgrp successfully completed all allocations and made +visible to cgroup_for_each_child/descendant_*() iterators. The +subsystem may choose to fail creation by returning -errno. This +callback can be used to implement reliable state sharing and +propagation along the hierarchy. See the comment on +cgroup_for_each_descendant_pre() for details. -int pre_destroy(struct cgroup *cgrp); +void css_offline(struct cgroup *cgrp); -Called before checking the reference count on each subsystem. This may -be useful for subsystems which have some extra references even if -there are not tasks in the cgroup. If pre_destroy() returns error code, -rmdir() will fail with it. From this behavior, pre_destroy() can be -called multiple times against a cgroup. +This is the counterpart of css_online() and called iff css_online() +has succeeded on @cgrp. This signifies the beginning of the end of +@cgrp. @cgrp is being removed and the subsystem should start dropping +all references it's holding on @cgrp. When all references are dropped, +cgroup removal will proceed to the next step - css_free(). After this +callback, @cgrp should be considered dead to the subsystem. + +void css_free(struct cgroup *cgrp) +(cgroup_mutex held by caller) + +The cgroup system is about to free @cgrp; the subsystem should free +its subsystem state object. By the time this method is called, @cgrp +is completely unused; @cgrp->parent is still valid. (Note - can also +be called for a newly-created cgroup if an error occurs after this +subsystem's create() method has been called for the new cgroup). int can_attach(struct cgroup *cgrp, struct cgroup_taskset *tset) (cgroup_mutex held by caller) @@ -635,14 +642,6 @@ void exit(struct task_struct *task) Called during task exit. -void post_clone(struct cgroup *cgrp) -(cgroup_mutex held by caller) - -Called during cgroup_create() to do any parameter -initialization which might be required before a task could attach. For -example, in cpusets, no task may attach before 'cpus' and 'mems' are set -up. - void bind(struct cgroup *root) (cgroup_mutex held by caller) diff --git a/Documentation/cgroups/cpusets.txt b/Documentation/cgroups/cpusets.txt index cefd3d8bbd11..12e01d432bfe 100644 --- a/Documentation/cgroups/cpusets.txt +++ b/Documentation/cgroups/cpusets.txt @@ -218,7 +218,7 @@ and name space for cpusets, with a minimum of additional kernel code. The cpus and mems files in the root (top_cpuset) cpuset are read-only. The cpus file automatically tracks the value of cpu_online_mask using a CPU hotplug notifier, and the mems file -automatically tracks the value of node_states[N_HIGH_MEMORY]--i.e., +automatically tracks the value of node_states[N_MEMORY]--i.e., nodes with memory--using the cpuset_track_online_nodes() hook. diff --git a/Documentation/cgroups/freezer-subsystem.txt b/Documentation/cgroups/freezer-subsystem.txt index 7e62de1e59ff..c96a72cbb30a 100644 --- a/Documentation/cgroups/freezer-subsystem.txt +++ b/Documentation/cgroups/freezer-subsystem.txt @@ -49,13 +49,49 @@ prevent the freeze/unfreeze cycle from becoming visible to the tasks being frozen. This allows the bash example above and gdb to run as expected. -The freezer subsystem in the container filesystem defines a file named -freezer.state. Writing "FROZEN" to the state file will freeze all tasks in the -cgroup. Subsequently writing "THAWED" will unfreeze the tasks in the cgroup. -Reading will return the current state. +The cgroup freezer is hierarchical. Freezing a cgroup freezes all +tasks beloning to the cgroup and all its descendant cgroups. Each +cgroup has its own state (self-state) and the state inherited from the +parent (parent-state). Iff both states are THAWED, the cgroup is +THAWED. -Note freezer.state doesn't exist in root cgroup, which means root cgroup -is non-freezable. +The following cgroupfs files are created by cgroup freezer. + +* freezer.state: Read-write. + + When read, returns the effective state of the cgroup - "THAWED", + "FREEZING" or "FROZEN". This is the combined self and parent-states. + If any is freezing, the cgroup is freezing (FREEZING or FROZEN). + + FREEZING cgroup transitions into FROZEN state when all tasks + belonging to the cgroup and its descendants become frozen. Note that + a cgroup reverts to FREEZING from FROZEN after a new task is added + to the cgroup or one of its descendant cgroups until the new task is + frozen. + + When written, sets the self-state of the cgroup. Two values are + allowed - "FROZEN" and "THAWED". If FROZEN is written, the cgroup, + if not already freezing, enters FREEZING state along with all its + descendant cgroups. + + If THAWED is written, the self-state of the cgroup is changed to + THAWED. Note that the effective state may not change to THAWED if + the parent-state is still freezing. If a cgroup's effective state + becomes THAWED, all its descendants which are freezing because of + the cgroup also leave the freezing state. + +* freezer.self_freezing: Read only. + + Shows the self-state. 0 if the self-state is THAWED; otherwise, 1. + This value is 1 iff the last write to freezer.state was "FROZEN". + +* freezer.parent_freezing: Read only. + + Shows the parent-state. 0 if none of the cgroup's ancestors is + frozen; otherwise, 1. + +The root cgroup is non-freezable and the above interface files don't +exist. * Examples of usage : @@ -85,18 +121,3 @@ to unfreeze all tasks in the container : This is the basic mechanism which should do the right thing for user space task in a simple scenario. - -It's important to note that freezing can be incomplete. In that case we return -EBUSY. This means that some tasks in the cgroup are busy doing something that -prevents us from completely freezing the cgroup at this time. After EBUSY, -the cgroup will remain partially frozen -- reflected by freezer.state reporting -"FREEZING" when read. The state will remain "FREEZING" until one of these -things happens: - - 1) Userspace cancels the freezing operation by writing "THAWED" to - the freezer.state file - 2) Userspace retries the freezing operation by writing "FROZEN" to - the freezer.state file (writing "FREEZING" is not legal - and returns EINVAL) - 3) The tasks that blocked the cgroup from entering the "FROZEN" - state disappear from the cgroup's set of tasks. diff --git a/Documentation/cgroups/memcg_test.txt b/Documentation/cgroups/memcg_test.txt index fc8fa97a09ac..ce94a83a7d9a 100644 --- a/Documentation/cgroups/memcg_test.txt +++ b/Documentation/cgroups/memcg_test.txt @@ -399,8 +399,7 @@ Under below explanation, we assume CONFIG_MEM_RES_CTRL_SWAP=y. 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 c07f7b4fb88d..8b8c28b9864c 100644 --- a/Documentation/cgroups/memory.txt +++ b/Documentation/cgroups/memory.txt @@ -71,6 +71,11 @@ Brief summary of control files. memory.oom_control # set/show oom controls. memory.numa_stat # show the number of memory usage per numa node + memory.kmem.limit_in_bytes # set/show hard limit for kernel memory + memory.kmem.usage_in_bytes # show current kernel memory allocation + memory.kmem.failcnt # show the number of kernel memory usage hits limits + memory.kmem.max_usage_in_bytes # show max kernel memory usage recorded + memory.kmem.tcp.limit_in_bytes # set/show hard limit for tcp buf memory memory.kmem.tcp.usage_in_bytes # show current tcp buf memory allocation memory.kmem.tcp.failcnt # show the number of tcp buf memory usage hits limits @@ -144,9 +149,9 @@ Figure 1 shows the important aspects of the controller 3. Each page has a pointer to the page_cgroup, which in turn knows the cgroup it belongs to -The accounting is done as follows: mem_cgroup_charge() is invoked to set up -the necessary data structures and check if the cgroup that is being charged -is over its limit. If it is, then reclaim is invoked on the cgroup. +The accounting is done as follows: mem_cgroup_charge_common() is invoked to +set up the necessary data structures and check if the cgroup that is being +charged is over its limit. If it is, then reclaim is invoked on the cgroup. More details can be found in the reclaim section of this document. If everything goes well, a page meta-data-structure called page_cgroup is updated. page_cgroup has its own LRU on cgroup. @@ -268,20 +273,73 @@ the amount of kernel memory used by the system. Kernel memory is fundamentally different than user memory, since it can't be swapped out, which makes it possible to DoS the system by consuming too much of this precious resource. +Kernel memory won't be accounted at all until limit on a group is set. This +allows for existing setups to continue working without disruption. The limit +cannot be set if the cgroup have children, or if there are already tasks in the +cgroup. Attempting to set the limit under those conditions will return -EBUSY. +When use_hierarchy == 1 and a group is accounted, its children will +automatically be accounted regardless of their limit value. + +After a group is first limited, it will be kept being accounted until it +is removed. The memory limitation itself, can of course be removed by writing +-1 to memory.kmem.limit_in_bytes. In this case, kmem will be accounted, but not +limited. + Kernel memory limits are not imposed for the root cgroup. Usage for the root -cgroup may or may not be accounted. +cgroup may or may not be accounted. The memory used is accumulated into +memory.kmem.usage_in_bytes, or in a separate counter when it makes sense. +(currently only for tcp). +The main "kmem" counter is fed into the main counter, so kmem charges will +also be visible from the user counter. Currently no soft limit is implemented for kernel memory. It is future work to trigger slab reclaim when those limits are reached. 2.7.1 Current Kernel Memory resources accounted +* stack pages: every process consumes some stack pages. By accounting into +kernel memory, we prevent new processes from being created when the kernel +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 +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 +different memcg during the page allocation by the cache. + * sockets memory pressure: some sockets protocols have memory pressure thresholds. The Memory Controller allows them to be controlled individually per cgroup, instead of globally. * tcp memory pressure: sockets memory pressure for the tcp protocol. +2.7.3 Common use cases + +Because the "kmem" counter is fed to the main user counter, kernel memory can +never be limited completely independently of user memory. Say "U" is the user +limit, and "K" the kernel limit. There are three possible ways limits can be +set: + + U != 0, K = unlimited: + This is the standard memcg limitation mechanism already present before kmem + accounting. Kernel memory is completely ignored. + + U != 0, K < U: + Kernel memory is a subset of the user memory. This setup is useful in + deployments where the total amount of memory per-cgroup is overcommited. + Overcommiting kernel memory limits is definitely not recommended, since the + box can still run out of non-reclaimable memory. + In this case, the admin could set up K so that the sum of all groups is + never greater than the total memory, and freely set U at the cost of his + QoS. + + U != 0, K >= U: + Since kmem charges will also be fed to the user counter and reclaim will be + triggered for the cgroup for both kinds of memory. This setup gives the + admin a unified view of memory, and it is also useful for people who just + want to track kernel memory usage. + 3. User Interface 0. Configuration @@ -290,6 +348,7 @@ a. Enable CONFIG_CGROUPS b. Enable CONFIG_RESOURCE_COUNTERS c. Enable CONFIG_MEMCG d. Enable CONFIG_MEMCG_SWAP (to use swap extension) +d. Enable CONFIG_MEMCG_KMEM (to use kmem extension) 1. Prepare the cgroups (see cgroups.txt, Why are cgroups needed?) # mount -t tmpfs none /sys/fs/cgroup @@ -406,6 +465,11 @@ About use_hierarchy, see Section 6. Because rmdir() moves all pages to parent, some out-of-use page caches can be moved to the parent. If you want to avoid that, force_empty will be useful. + Also, note that when memory.kmem.limit_in_bytes is set the charges due to + kernel pages will still be seen. This is not considered a failure and the + write will still return success. In this case, it is expected that + memory.kmem.usage_in_bytes == memory.usage_in_bytes. + About use_hierarchy, see Section 6. 5.2 stat file @@ -466,6 +530,10 @@ Note: 5.3 swappiness Similar to /proc/sys/vm/swappiness, but affecting a hierarchy of groups only. +Please note that unlike the global swappiness, memcg knob set to 0 +really prevents from any swapping even if there is a swap storage +available. This might lead to memcg OOM killer if there are no file +pages to reclaim. Following cgroups' swappiness can't be changed. - root cgroup (uses /proc/sys/vm/swappiness). diff --git a/Documentation/cgroups/net_prio.txt b/Documentation/cgroups/net_prio.txt index 01b322635591..a82cbd28ea8a 100644 --- a/Documentation/cgroups/net_prio.txt +++ b/Documentation/cgroups/net_prio.txt @@ -51,3 +51,5 @@ One usage for the net_prio cgroup is with mqprio qdisc allowing application traffic to be steered to hardware/driver based traffic classes. These mappings can then be managed by administrators or other networking protocols such as DCBX. + +A new net_prio cgroup inherits the parent's configuration. diff --git a/Documentation/cgroups/resource_counter.txt b/Documentation/cgroups/resource_counter.txt index 0c4a344e78fa..c4d99ed0b418 100644 --- a/Documentation/cgroups/resource_counter.txt +++ b/Documentation/cgroups/resource_counter.txt @@ -83,16 +83,17 @@ to work with it. res_counter->lock internally (it must be called with res_counter->lock held). The force parameter indicates whether we can bypass the limit. - e. void res_counter_uncharge[_locked] + e. u64 res_counter_uncharge[_locked] (struct res_counter *rc, unsigned long val) When a resource is released (freed) it should be de-accounted from the resource counter it was accounted to. This is called - "uncharging". + "uncharging". The return value of this function indicate the amount + of charges still present in the counter. The _locked routines imply that the res_counter->lock is taken. - f. void res_counter_uncharge_until + f. u64 res_counter_uncharge_until (struct res_counter *rc, struct res_counter *top, unsinged long val) diff --git a/Documentation/coccinelle.txt b/Documentation/coccinelle.txt index cf44eb6499b4..dffa2d620d6d 100644 --- a/Documentation/coccinelle.txt +++ b/Documentation/coccinelle.txt @@ -87,6 +87,10 @@ As any static code analyzer, Coccinelle produces false 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 + Using Coccinelle with a single semantic patch ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/Documentation/cpu-freq/cpu-drivers.txt b/Documentation/cpu-freq/cpu-drivers.txt index c436096351f8..72f70b16d299 100644 --- a/Documentation/cpu-freq/cpu-drivers.txt +++ b/Documentation/cpu-freq/cpu-drivers.txt @@ -111,6 +111,12 @@ policy->governor must contain the "default policy" for For setting some of these values, 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 ------------ diff --git a/Documentation/cpu-freq/user-guide.txt b/Documentation/cpu-freq/user-guide.txt index 04f6b32993e6..ff2f28332cc4 100644 --- a/Documentation/cpu-freq/user-guide.txt +++ b/Documentation/cpu-freq/user-guide.txt @@ -190,11 +190,11 @@ scaling_max_freq show the current "policy limits" (in 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 66ef8f35613d..9f401350f502 100644 --- a/Documentation/cpu-hotplug.txt +++ b/Documentation/cpu-hotplug.txt @@ -207,6 +207,30 @@ by making it not-removable. In such cases you will also notice that the online file is missing under cpu0. +Q: Is CPU0 removable on X86? +A: Yes. If kernel is compiled with CONFIG_BOOTPARAM_HOTPLUG_CPU0=y, CPU0 is +removable by default. Otherwise, CPU0 is also removable by kernel option +cpu0_hotplug. + +But some features depend on CPU0. Two known dependencies are: + +1. Resume from hibernate/suspend depends on CPU0. Hibernate/suspend will fail if +CPU0 is offline and you need to online CPU0 before hibernate/suspend can +continue. +2. PIC interrupts also depend on CPU0. CPU0 can't be removed if a PIC interrupt +is detected. + +It's said poweroff/reboot may depend on CPU0 on some machines although I haven't +seen any poweroff/reboot failure so far after CPU0 is offline on a few tested +machines. + +Please let me know if you know or see any other dependencies of CPU0. + +If the dependencies are under your control, you can turn on CPU0 hotplug feature +either by CONFIG_BOOTPARAM_HOTPLUG_CPU0 or by kernel parameter cpu0_hotplug. + +--Fenghua Yu <fenghua.yu@intel.com> + Q: How do i find out if a particular CPU is not removable? A: Depending on the implementation, some architectures may show this by the absence of the "online" file. This is done if it can be determined ahead of diff --git a/Documentation/device-mapper/cache-policies.txt b/Documentation/device-mapper/cache-policies.txt new file mode 100644 index 000000000000..d7c440b444cc --- /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 000000000000..f50470abe241 --- /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 occuring 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 728c38c242d6..b428556197c9 100644 --- a/Documentation/device-mapper/dm-raid.txt +++ b/Documentation/device-mapper/dm-raid.txt @@ -30,6 +30,7 @@ The target is named "raid" and it accepts the following parameters: 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 @@ -64,15 +65,15 @@ The target is named "raid" and it accepts the following parameters: 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 +86,33 @@ The target is named "raid" and it accepts the following parameters: 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 @@ -141,3 +169,6 @@ Version History 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 Add RAID10 "far" and "offset" algorithm support. diff --git a/Documentation/devices.txt b/Documentation/devices.txt index b6251cca9263..08f01e79c41a 100644 --- a/Documentation/devices.txt +++ b/Documentation/devices.txt @@ -2561,9 +2561,6 @@ Your cooperation is appreciated. 192 = /dev/usb/yurex1 First USB Yurex device ... 209 = /dev/usb/yurex16 16th USB Yurex device - 240 = /dev/usb/dabusb0 First daubusb device - ... - 243 = /dev/usb/dabusb3 Fourth dabusb device 180 block USB block devices 0 = /dev/uba First USB block device diff --git a/Documentation/devicetree/bindings/arc/interrupts.txt b/Documentation/devicetree/bindings/arc/interrupts.txt new file mode 100644 index 000000000000..9a5d562435ea --- /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-reset.txt b/Documentation/devicetree/bindings/arm/altera/socfpga-reset.txt new file mode 100644 index 000000000000..ecdb57d69dbf --- /dev/null +++ b/Documentation/devicetree/bindings/arm/altera/socfpga-reset.txt @@ -0,0 +1,11 @@ +Altera SOCFPGA Reset Manager + +Required properties: +- compatible : "altr,rst-mgr" +- reg : Should contain 1 register ranges(address and length) + +Example: + rstmgr@ffd05000 { + compatible = "altr,rst-mgr"; + reg = <0xffd05000 0x1000>; + }; diff --git a/Documentation/devicetree/bindings/arm/altera/socfpga-system.txt b/Documentation/devicetree/bindings/arm/altera/socfpga-system.txt new file mode 100644 index 000000000000..f4d04a067282 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/altera/socfpga-system.txt @@ -0,0 +1,13 @@ +Altera SOCFPGA System Manager + +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 52478c83d0cc..20746e5abe6f 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/arm-boards b/Documentation/devicetree/bindings/arm/arm-boards index fc81a7d6b0f1..db5858e32d3f 100644 --- a/Documentation/devicetree/bindings/arm/arm-boards +++ b/Documentation/devicetree/bindings/arm/arm-boards @@ -9,6 +9,10 @@ Required properties (in root node): FPGA type interrupt controllers, see the versatile-fpga-irq binding doc. +In the root node the Integrator/CP must have a /cpcon node pointing +to the CP control registers, and the Integrator/AP must have a +/syscon node pointing to the Integrator/AP system controller. + ARM Versatile Application and Platform Baseboards ------------------------------------------------- diff --git a/Documentation/devicetree/bindings/arm/armada-370-xp-mpic.txt b/Documentation/devicetree/bindings/arm/armada-370-xp-mpic.txt index 70c0dc5f00ed..61df564c0d23 100644 --- a/Documentation/devicetree/bindings/arm/armada-370-xp-mpic.txt +++ b/Documentation/devicetree/bindings/arm/armada-370-xp-mpic.txt @@ -6,9 +6,15 @@ Required properties: - interrupt-controller: Identifies the node as an interrupt controller. - #interrupt-cells: The number of cells to define the interrupts. Should be 1. The cell is the IRQ number + - reg: Should contain PMIC registers location and length. First pair for the main interrupt registers, second pair for the per-CPU - interrupt registers + interrupt registers. For this last pair, to be compliant with SMP + support, the "virtual" must be use (For the record, these registers + automatically map to the interrupt controller registers of the + current CPU) + + Example: @@ -18,6 +24,6 @@ Example: #address-cells = <1>; #size-cells = <1>; interrupt-controller; - reg = <0xd0020000 0x1000>, - <0xd0021000 0x1000>; + reg = <0xd0020a00 0x1d0>, + <0xd0021070 0x58>; }; diff --git a/Documentation/devicetree/bindings/arm/armada-370-xp-pmsu.txt b/Documentation/devicetree/bindings/arm/armada-370-xp-pmsu.txt new file mode 100644 index 000000000000..926b4d6aae7e --- /dev/null +++ b/Documentation/devicetree/bindings/arm/armada-370-xp-pmsu.txt @@ -0,0 +1,20 @@ +Power Management Service Unit(PMSU) +----------------------------------- +Available on Marvell SOCs: Armada 370 and Armada XP + +Required properties: + +- compatible: "marvell,armada-370-xp-pmsu" + +- reg: Should contain PMSU registers location and length. First pair + for the per-CPU SW Reset Control registers, second pair for the + Power Management Service Unit. + +Example: + +armada-370-xp-pmsu@d0022000 { + compatible = "marvell,armada-370-xp-pmsu"; + reg = <0xd0022100 0x430>, + <0xd0020800 0x20>; +}; + 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 8b6ea2267c94..000000000000 --- a/Documentation/devicetree/bindings/arm/armada-370-xp-timer.txt +++ /dev/null @@ -1,11 +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 - -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 000000000000..9821283ff516 --- /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-aic.txt b/Documentation/devicetree/bindings/arm/atmel-aic.txt index 19078bf5cca8..ad031211b5b8 100644 --- a/Documentation/devicetree/bindings/arm/atmel-aic.txt +++ b/Documentation/devicetree/bindings/arm/atmel-aic.txt @@ -4,7 +4,7 @@ Required properties: - 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/atmel-at91.txt b/Documentation/devicetree/bindings/arm/atmel-at91.txt index d187e9f7cf1c..1196290082d1 100644 --- a/Documentation/devicetree/bindings/arm/atmel-at91.txt +++ b/Documentation/devicetree/bindings/arm/atmel-at91.txt @@ -7,6 +7,12 @@ PIT Timer required properties: - interrupts: Should contain interrupt for the PIT which is the IRQ line shared across all System Controller members. +System Timer (ST) required properties: +- compatible: Should be "atmel,at91rm9200-st" +- reg: Should contain registers location and length +- interrupts: Should contain interrupt for the ST which is the IRQ line + shared across all System Controller members. + TC/TCLIB Timer required properties: - compatible: Should be "atmel,<chip>-tcb". <chip> can be "at91rm9200" or "at91sam9x5" diff --git a/Documentation/devicetree/bindings/arm/bcm/bcm11351.txt b/Documentation/devicetree/bindings/arm/bcm/bcm11351.txt new file mode 100644 index 000000000000..fb7b5cd2652f --- /dev/null +++ b/Documentation/devicetree/bindings/arm/bcm/bcm11351.txt @@ -0,0 +1,9 @@ +Broadcom BCM11351 device tree bindings +------------------------------------------- + +Boards with the bcm281xx SoC family (which includes bcm11130, bcm11140, +bcm11351, bcm28145, bcm28155 SoCs) shall have the following properties: + +Required root node property: + +compatible = "bcm,bcm11351"; diff --git a/Documentation/devicetree/bindings/arm/calxeda.txt b/Documentation/devicetree/bindings/arm/calxeda.txt index 4755caaccba6..25fcf96795ca 100644 --- a/Documentation/devicetree/bindings/arm/calxeda.txt +++ b/Documentation/devicetree/bindings/arm/calxeda.txt @@ -1,8 +1,15 @@ -Calxeda Highbank Platforms Device Tree Bindings +Calxeda Platforms Device Tree Bindings ----------------------------------------------- -Boards with Calxeda Cortex-A9 based Highbank SOC shall have the following -properties. +Boards with Calxeda Cortex-A9 based ECX-1000 (Highbank) SOC shall have the +following properties. Required root node properties: - compatible = "calxeda,highbank"; + + +Boards with Calxeda Cortex-A15 based ECX-2000 SOC shall have the following +properties. + +Required root node properties: + - compatible = "calxeda,ecx-2000"; diff --git a/Documentation/devicetree/bindings/arm/coherency-fabric.txt b/Documentation/devicetree/bindings/arm/coherency-fabric.txt new file mode 100644 index 000000000000..17d8cd107559 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/coherency-fabric.txt @@ -0,0 +1,21 @@ +Coherency fabric +---------------- +Available on Marvell SOCs: Armada 370 and Armada XP + +Required properties: + +- compatible: "marvell,coherency-fabric" + +- reg: Should contain coherency fabric registers location and + length. First pair for the coherency fabric registers, second pair + for the per-CPU fabric registers registers. + +Example: + +coherency-fabric@d0020200 { + compatible = "marvell,coherency-fabric"; + reg = <0xd0020200 0xb0>, + <0xd0021810 0x1c>; + +}; + diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt new file mode 100644 index 000000000000..f32494dbfe19 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/cpus.txt @@ -0,0 +1,77 @@ +* ARM CPUs binding description + +The device tree allows to describe the layout of CPUs in a system through +the "cpus" node, which in turn contains a number of subnodes (ie "cpu") +defining properties for every cpu. + +Bindings for CPU nodes follow the ePAPR standard, available from: + +http://devicetree.org + +For the ARM architecture every CPU node must contain the following properties: + +- device_type: must be "cpu" +- reg: property matching the CPU MPIDR[23:0] register bits + reg[31:24] bits must be set to 0 +- compatible: should be one of: + "arm,arm1020" + "arm,arm1020e" + "arm,arm1022" + "arm,arm1026" + "arm,arm720" + "arm,arm740" + "arm,arm7tdmi" + "arm,arm920" + "arm,arm922" + "arm,arm925" + "arm,arm926" + "arm,arm940" + "arm,arm946" + "arm,arm9tdmi" + "arm,cortex-a5" + "arm,cortex-a7" + "arm,cortex-a8" + "arm,cortex-a9" + "arm,cortex-a15" + "arm,arm1136" + "arm,arm1156" + "arm,arm1176" + "arm,arm11mpcore" + "faraday,fa526" + "intel,sa110" + "intel,sa1100" + "marvell,feroceon" + "marvell,mohawk" + "marvell,xsc3" + "marvell,xscale" + +Example: + + cpus { + #size-cells = <0>; + #address-cells = <1>; + + CPU0: cpu@0 { + device_type = "cpu"; + compatible = "arm,cortex-a15"; + reg = <0x0>; + }; + + CPU1: cpu@1 { + device_type = "cpu"; + compatible = "arm,cortex-a15"; + reg = <0x1>; + }; + + CPU2: cpu@100 { + device_type = "cpu"; + compatible = "arm,cortex-a7"; + reg = <0x100>; + }; + + CPU3: cpu@101 { + device_type = "cpu"; + compatible = "arm,cortex-a7"; + reg = <0x101>; + }; + }; diff --git a/Documentation/devicetree/bindings/arm/davinci.txt b/Documentation/devicetree/bindings/arm/davinci.txt new file mode 100644 index 000000000000..cfaeda4274e6 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/davinci.txt @@ -0,0 +1,17 @@ +Texas Instruments DaVinci Platforms Device Tree Bindings +-------------------------------------------------------- + +DA850/OMAP-L138/AM18x Evaluation Module (EVM) board +Required root node properties: + - compatible = "ti,da850-evm", "ti,da850"; + +EnBW AM1808 based CMC board +Required root node properties: + - compatible = "enbw,cmc", "ti,da850; + +Generic DaVinci Boards +---------------------- + +DA850/OMAP-L138/AM18x generic board +Required root node properties: + - compatible = "ti,da850"; diff --git a/Documentation/devicetree/bindings/arm/davinci/nand.txt b/Documentation/devicetree/bindings/arm/davinci/nand.txt index e37241f1fdd8..3545ea704b50 100644 --- a/Documentation/devicetree/bindings/arm/davinci/nand.txt +++ b/Documentation/devicetree/bindings/arm/davinci/nand.txt @@ -23,29 +23,24 @@ Recommended properties : - ti,davinci-nand-buswidth: buswidth 8 or 16 - ti,davinci-nand-use-bbt: use flash based bad block table support. -Example (enbw_cmc board): -aemif@60000000 { - compatible = "ti,davinci-aemif"; - #address-cells = <2>; - #size-cells = <1>; - reg = <0x68000000 0x80000>; - ranges = <2 0 0x60000000 0x02000000 - 3 0 0x62000000 0x02000000 - 4 0 0x64000000 0x02000000 - 5 0 0x66000000 0x02000000 - 6 0 0x68000000 0x02000000>; - nand@3,0 { - compatible = "ti,davinci-nand"; - reg = <3 0x0 0x807ff - 6 0x0 0x8000>; - #address-cells = <1>; - #size-cells = <1>; - ti,davinci-chipselect = <1>; - ti,davinci-mask-ale = <0>; - ti,davinci-mask-cle = <0>; - ti,davinci-mask-chipsel = <0>; - ti,davinci-ecc-mode = "hw"; - ti,davinci-ecc-bits = <4>; - ti,davinci-nand-use-bbt; +nand device bindings may contain additional sub-nodes describing +partitions of the address space. See partition.txt for more detail. + +Example(da850 EVM ): +nand_cs3@62000000 { + compatible = "ti,davinci-nand"; + reg = <0x62000000 0x807ff + 0x68000000 0x8000>; + ti,davinci-chipselect = <1>; + ti,davinci-mask-ale = <0>; + ti,davinci-mask-cle = <0>; + ti,davinci-mask-chipsel = <0>; + ti,davinci-ecc-mode = "hw"; + ti,davinci-ecc-bits = <4>; + ti,davinci-nand-use-bbt; + + partition@180000 { + label = "ubifs"; + reg = <0x180000 0x7e80000>; }; }; diff --git a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt index 6528e215c5fe..5216b419016a 100644 --- a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt +++ b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt @@ -4,14 +4,13 @@ Exynos processors include support for multiple power domains which are used to gate power to one or more peripherals on the processor. Required Properties: -- compatiable: should be one of the following. +- compatible: should be one of the following. * samsung,exynos4210-pd - for exynos4210 type power domain. - reg: physical base address of the controller and length of memory mapped region. -Optional Properties: -- samsung,exynos4210-pd-off: Specifies that the power domain is in turned-off - state during boot and remains to be turned-off until explicitly turned-on. +Node of a device using power domains must have a samsung,power-domain property +defined with a phandle to respective power domain. Example: @@ -19,3 +18,11 @@ Example: compatible = "samsung,exynos4210-pd"; reg = <0x10023C00 0x10>; }; + +Example of the node using power domain: + + node { + /* ... */ + samsung,power-domain = <&lcd0>; + /* ... */ + }; diff --git a/Documentation/devicetree/bindings/arm/fsl.txt b/Documentation/devicetree/bindings/arm/fsl.txt index ac9e7516756e..e935d7d4ac43 100644 --- a/Documentation/devicetree/bindings/arm/fsl.txt +++ b/Documentation/devicetree/bindings/arm/fsl.txt @@ -5,6 +5,14 @@ i.MX23 Evaluation Kit 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"; @@ -41,6 +49,10 @@ i.MX6 Quad SABRE Smart Device Board Required root node properties: - compatible = "fsl,imx6q-sabresd", "fsl,imx6q"; +i.MX6 Quad SABRE Automotive Board +Required root node properties: + - compatible = "fsl,imx6q-sabreauto", "fsl,imx6q"; + Generic i.MX boards ------------------- diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt index 62eb8df1e08d..3dfb0c0384f5 100644 --- a/Documentation/devicetree/bindings/arm/gic.txt +++ b/Documentation/devicetree/bindings/arm/gic.txt @@ -42,7 +42,7 @@ Main node required properties: 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 @@ Required properties: 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/kirkwood.txt b/Documentation/devicetree/bindings/arm/kirkwood.txt new file mode 100644 index 000000000000..98cce9a653eb --- /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 7ca52161e7ab..cbef09b5c8a7 100644 --- a/Documentation/devicetree/bindings/arm/l2cc.txt +++ b/Documentation/devicetree/bindings/arm/l2cc.txt @@ -10,6 +10,12 @@ Required properties: "arm,pl310-cache" "arm,l220-cache" "arm,l210-cache" + "marvell,aurora-system-cache": Marvell Controller designed to be + compatible with the ARM one, with system cache mode (meaning + maintenance operations on L1 are broadcasted to the L2 and L2 + performs the same operation). + "marvell,"aurora-outer-cache: Marvell Controller designed to be + compatible with the ARM one with outer cache mode. - 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 @@ -29,6 +35,9 @@ Optional properties: filter. Addresses in the filter window are directed to the M1 port. Other addresses will go to the M0 port. - interrupts : 1 combined interrupt. +- cache-id-part: cache id part number to be used if it is not present + on hardware +- wt-override: If present then L2 is forced to Write through mode Example: @@ -37,7 +46,7 @@ L2: cache-controller { reg = <0xfff12000 0x1000>; arm,data-latency = <1 1 1>; arm,tag-latency = <2 2 2>; - arm,filter-latency = <0x80000000 0x8000000>; + arm,filter-ranges = <0x80000000 0x8000000>; cache-unified; cache-level = <2>; interrupts = <45>; diff --git a/Documentation/devicetree/bindings/arm/omap/counter.txt b/Documentation/devicetree/bindings/arm/omap/counter.txt new file mode 100644 index 000000000000..5bd8aa091315 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/omap/counter.txt @@ -0,0 +1,15 @@ +OMAP Counter-32K bindings + +Required properties: +- compatible: Must be "ti,omap-counter32k" for OMAP controllers +- reg: Contains timer register address range (base address and length) +- ti,hwmods: Name of the hwmod associated to the counter, which is typically + "counter_32k" + +Example: + +counter32k: counter@4a304000 { + compatible = "ti,omap-counter32k"; + reg = <0x4a304000 0x20>; + ti,hwmods = "counter_32k"; +}; diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt b/Documentation/devicetree/bindings/arm/omap/omap.txt index d0051a750587..f8288ea1b530 100644 --- a/Documentation/devicetree/bindings/arm/omap/omap.txt +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt @@ -39,16 +39,16 @@ Boards: - 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 diff --git a/Documentation/devicetree/bindings/arm/omap/timer.txt b/Documentation/devicetree/bindings/arm/omap/timer.txt new file mode 100644 index 000000000000..8732d4d41f8b --- /dev/null +++ b/Documentation/devicetree/bindings/arm/omap/timer.txt @@ -0,0 +1,31 @@ +OMAP Timer bindings + +Required properties: +- compatible: Must be "ti,omap2-timer" for OMAP2+ controllers. +- reg: Contains timer register address range (base address and + length). +- interrupts: Contains the interrupt information for the timer. The + format is being dependent on which interrupt controller + the OMAP device uses. +- ti,hwmods: Name of the hwmod associated to the timer, "timer<X>", + where <X> is the instance number of the timer from the + HW spec. + +Optional properties: +- ti,timer-alwon: Indicates the timer is in an alway-on power domain. +- ti,timer-dsp: Indicates the timer can interrupt the on-chip DSP in + addition to the ARM CPU. +- ti,timer-pwm: Indicates the timer can generate a PWM output. +- ti,timer-secure: Indicates the timer is reserved on a secure OMAP device + and therefore cannot be used by the kernel. + +Example: + +timer12: timer@48304000 { + compatible = "ti,omap2-timer"; + reg = <0x48304000 0x400>; + interrupts = <95>; + ti,hwmods = "timer12" + ti,timer-alwon; + ti,timer-secure; +}; diff --git a/Documentation/devicetree/bindings/arm/psci.txt b/Documentation/devicetree/bindings/arm/psci.txt new file mode 100644 index 000000000000..433afe9cb590 --- /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/sirf.txt b/Documentation/devicetree/bindings/arm/sirf.txt index 1881e1c6dda5..c6ba6d3c747f 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 new file mode 100644 index 000000000000..13fbb8866bd6 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/spear/shirq.txt @@ -0,0 +1,48 @@ +* SPEAr Shared IRQ layer (shirq) + +SPEAr3xx architecture includes shared/multiplexed irqs for certain set +of devices. The multiplexor provides a single interrupt to parent +interrupt controller (VIC) on behalf of a group of devices. + +There can be multiple groups available on SPEAr3xx variants but not +exceeding 4. The number of devices in a group can differ, further they +may share same set of status/mask registers spanning across different +bit masks. Also in some cases the group may not have enable or other +registers. This makes software little complex. + +A single node in the device tree is used to describe the shared +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. + +Required properties: + - compatible: should be, either of + - "st,spear300-shirq" + - "st,spear310-shirq" + - "st,spear320-shirq" + - interrupt-controller: Identifies the node as an interrupt controller. + - #interrupt-cells: should be <1> which basically contains the offset + (starting from 0) of interrupts for all the groups. + - reg: Base address and size of shirq registers. + - interrupts: The list of interrupts generated by the groups which are + then connected to a parent interrupt controller. Each group is + associated with one of the interrupts, hence number of interrupts (to + parent) is equal to number of groups. The format of the interrupt + specifier depends in the interrupt parent controller. + + Optional properties: + - interrupt-parent: pHandle of the parent interrupt controller, if not + inherited from the parent node. + +Example: + +The following is an example from the SPEAr320 SoC dtsi file. + +shirq: interrupt-controller@0xb3000000 { + compatible = "st,spear320-shirq"; + reg = <0xb3000000 0x1000>; + interrupts = <28 29 30 1>; + #interrupt-cells = <1>; + interrupt-controller; +}; diff --git a/Documentation/devicetree/bindings/arm/ste-nomadik.txt b/Documentation/devicetree/bindings/arm/ste-nomadik.txt new file mode 100644 index 000000000000..19bca04b81c9 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/ste-nomadik.txt @@ -0,0 +1,27 @@ +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. + +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/tegra.txt b/Documentation/devicetree/bindings/arm/tegra.txt index 6e69d2e5e766..ed9c85334436 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/vexpress-sysreg.txt b/Documentation/devicetree/bindings/arm/vexpress-sysreg.txt new file mode 100644 index 000000000000..9cf3f25544c7 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/vexpress-sysreg.txt @@ -0,0 +1,50 @@ +ARM Versatile Express system registers +-------------------------------------- + +This is a system control registers block, providing multiple low level +platform functions like board detection and identification, software +interrupt generation, MMC and NOR Flash control etc. + +Required node properties: +- compatible value : = "arm,vexpress,sysreg"; +- reg : physical base address and the size of the registers window +- gpio-controller : specifies that the node is a GPIO controller +- #gpio-cells : size of the GPIO specifier, should be 2: + - first cell is the pseudo-GPIO line number: + 0 - MMC CARDIN + 1 - MMC WPROT + 2 - NOR FLASH WPn + - second cell can take standard GPIO flags (currently ignored). + +Example: + v2m_sysreg: sysreg@10000000 { + compatible = "arm,vexpress-sysreg"; + reg = <0x10000000 0x1000>; + gpio-controller; + #gpio-cells = <2>; + }; + +This block also can also act a bridge to the platform's configuration +bus via "system control" interface, addressing devices with site number, +position in the board stack, config controller, function and device +numbers - see motherboard's TRM for more details. + +The node describing a config device must refer to the sysreg node via +"arm,vexpress,config-bridge" phandle (can be also defined in the node's +parent) and relies on the board topology properties - see main vexpress +node documentation for more details. It must must also define the +following property: +- arm,vexpress-sysreg,func : must contain two cells: + - first cell defines function number (eg. 1 for clock generator, + 2 for voltage regulators etc.) + - device number (eg. osc 0, osc 1 etc.) + +Example: + mcc { + arm,vexpress,config-bridge = <&v2m_sysreg>; + + osc@0 { + compatible = "arm,vexpress-osc"; + arm,vexpress-sysreg,func = <1 0>; + }; + }; diff --git a/Documentation/devicetree/bindings/arm/vexpress.txt b/Documentation/devicetree/bindings/arm/vexpress.txt index ec8b50cbb2e8..ae49161e478a 100644 --- a/Documentation/devicetree/bindings/arm/vexpress.txt +++ b/Documentation/devicetree/bindings/arm/vexpress.txt @@ -11,6 +11,10 @@ the motherboard file using a /include/ directive. As the motherboard can be initialized in one of two different configurations ("memory maps"), care must be taken to include the correct one. + +Root node +--------- + Required properties in the root node: - compatible value: compatible = "arm,vexpress,<model>", "arm,vexpress"; @@ -45,6 +49,10 @@ Optional properties in the root node: - Coretile Express A9x4 (V2P-CA9) HBI-0225: arm,hbi = <0x225>; + +CPU nodes +--------- + Top-level standard "cpus" node is required. It must contain a node with device_type = "cpu" property for every available core, eg.: @@ -59,6 +67,52 @@ with device_type = "cpu" property for every available core, eg.: }; }; + +Configuration infrastructure +---------------------------- + +The platform has an elaborated configuration system, consisting of +microcontrollers residing on the mother- and daughterboards known +as Motherboard/Daughterboard Configuration Controller (MCC and DCC). +The controllers are responsible for the platform initialization +(reset generation, flash programming, FPGA bitfiles loading etc.) +but also control clock generators, voltage regulators, gather +environmental data like temperature, power consumption etc. Even +the video output switch (FPGA) is controlled that way. + +Nodes describing devices controlled by this infrastructure should +point at the bridge device node: +- bridge phandle: + arm,vexpress,config-bridge = <phandle>; +This property can be also defined in a parent node (eg. for a DCC) +and is effective for all children. + + +Platform topology +----------------- + +As Versatile Express can be configured in number of physically +different setups, the device tree should describe platform topology. +Root node and main motherboard node must define the following +property, describing physical location of the children nodes: +- site number: + arm,vexpress,site = <number>; + where 0 means motherboard, 1 or 2 are daugtherboard sites, + 0xf means "master" site (site containing main CPU tile) +- when daughterboards are stacked on one site, their position + in the stack be be described with: + arm,vexpress,position = <number>; +- when describing tiles consisting more than one DCC, its number + can be described with: + arm,vexpress,dcc = <number>; + +Any of the numbers above defaults to zero if not defined in +the node or any of its parent. + + +Motherboard +----------- + The motherboard description file provides a single "motherboard" node using 2 address cells corresponding to the Static Memory Bus used between the motherboard and the tile. The first cell defines the Chip @@ -87,22 +141,30 @@ can be used to obtain required phandle in the tile's "aliases" node: - SP804 timers: v2m_timer01 and v2m_timer23 -Current Linux implementation requires a "arm,v2m_timer" alias -pointing at one of the motherboard's SP804 timers, if it is to be -used as the system timer. This alias should be defined in the -motherboard files. +The tile description should define a "smb" node, describing the +Static Memory Bus between the tile and motherboard. It must define +the following properties: +- "simple-bus" compatible value (to ensure creation of the children) + compatible = "simple-bus"; +- mapping of the SMB CS/offset addresses into main address space: + #address-cells = <2>; + #size-cells = <1>; + ranges = <...>; +- interrupts mapping: + #interrupt-cells = <1>; + interrupt-map-mask = <0 0 63>; + interrupt-map = <...>; -The tile description must define "ranges", "interrupt-map-mask" and -"interrupt-map" properties to translate the motherboard's address -and interrupt space into one used by the tile's processor. -Abbreviated example: +Example of a VE tile description (simplified) +--------------------------------------------- /dts-v1/; / { model = "V2P-CA5s"; arm,hbi = <0x225>; + arm,vexpress,site = <0xf>; compatible = "arm,vexpress-v2p-ca5s", "arm,vexpress"; interrupt-parent = <&gic>; #address-cells = <1>; @@ -134,13 +196,29 @@ Abbreviated example: <0x2c000100 0x100>; }; - motherboard { + dcc { + compatible = "simple-bus"; + arm,vexpress,config-bridge = <&v2m_sysreg>; + + osc@0 { + compatible = "arm,vexpress-osc"; + }; + }; + + smb { + compatible = "simple-bus"; + + #address-cells = <2>; + #size-cells = <1>; /* CS0 is visible at 0x08000000 */ ranges = <0 0 0x08000000 0x04000000>; + + #interrupt-cells = <1>; interrupt-map-mask = <0 0 63>; /* Active high IRQ 0 is connected to GIC's SPI0 */ interrupt-map = <0 0 0 &gic 0 0 4>; + + /include/ "vexpress-v2m-rs1.dtsi" }; }; -/include/ "vexpress-v2m-rs1.dtsi" diff --git a/Documentation/devicetree/bindings/arm/vt8500.txt b/Documentation/devicetree/bindings/arm/vt8500.txt index d657832c6819..87dc1ddf4770 100644 --- a/Documentation/devicetree/bindings/arm/vt8500.txt +++ b/Documentation/devicetree/bindings/arm/vt8500.txt @@ -12,3 +12,11 @@ compatible = "wm,wm8505"; 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/exynos-sata-phy.txt b/Documentation/devicetree/bindings/ata/exynos-sata-phy.txt new file mode 100644 index 000000000000..37824fac688e --- /dev/null +++ b/Documentation/devicetree/bindings/ata/exynos-sata-phy.txt @@ -0,0 +1,14 @@ +* Samsung SATA PHY Controller + +SATA PHY nodes are defined to describe on-chip SATA Physical layer controllers. +Each SATA PHY controller should have its own node. + +Required properties: +- compatible : compatible list, contains "samsung,exynos5-sata-phy" +- reg : <registers mapping> + +Example: + sata@ffe07000 { + compatible = "samsung,exynos5-sata-phy"; + reg = <0xffe07000 0x1000>; + }; diff --git a/Documentation/devicetree/bindings/ata/exynos-sata.txt b/Documentation/devicetree/bindings/ata/exynos-sata.txt new file mode 100644 index 000000000000..0849f1025e34 --- /dev/null +++ b/Documentation/devicetree/bindings/ata/exynos-sata.txt @@ -0,0 +1,17 @@ +* Samsung AHCI SATA Controller + +SATA nodes are defined to describe on-chip Serial ATA controllers. +Each SATA controller should have its own node. + +Required properties: +- compatible : compatible list, contains "samsung,exynos5-sata" +- interrupts : <interrupt mapping for SATA IRQ> +- reg : <registers mapping> +- samsung,sata-freq : <frequency in MHz> + +Example: + sata@ffe08000 { + compatible = "samsung,exynos5-sata"; + reg = <0xffe08000 0x1000>; + interrupts = <115>; + }; diff --git a/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt b/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt index d2fe064a828b..63dd8051521c 100644 --- a/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt +++ b/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt @@ -2,9 +2,27 @@ properties: - compatible : Should be "ti,omap-ocp2scp" +- reg : Address and length of the register set for the device - #address-cells, #size-cells : Must be present if the device has sub-nodes - ranges : the child address space are mapped 1:1 onto the parent address space - ti,hwmods : must be "ocp2scp_usb_phy" Sub-nodes: All the devices connected to ocp2scp are described using sub-node to ocp2scp + +ocp2scp@4a0ad000 { + compatible = "ti,omap-ocp2scp"; + reg = <0x4a0ad000 0x1f>; + #address-cells = <1>; + #size-cells = <1>; + ranges; + ti,hwmods = "ocp2scp_usb_phy"; + + subnode1 { + ... + }; + + subnode2 { + ... + }; +}; diff --git a/Documentation/devicetree/bindings/bus/ti-gpmc.txt b/Documentation/devicetree/bindings/bus/ti-gpmc.txt new file mode 100644 index 000000000000..5ddb2e9efaaa --- /dev/null +++ b/Documentation/devicetree/bindings/bus/ti-gpmc.txt @@ -0,0 +1,84 @@ +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: Minimum clock period for synchronous mode, in picoseconds + + Chip-select signal timings corresponding to GPMC_CONFIG2: + - gpmc,cs-on: Assertion time + - gpmc,cs-rd-off: Read deassertion time + - gpmc,cs-wr-off: Write deassertion time + + ADV signal timings corresponding to GPMC_CONFIG3: + - gpmc,adv-on: Assertion time + - gpmc,adv-rd-off: Read deassertion time + - gpmc,adv-wr-off: Write deassertion time + + WE signals timings corresponding to GPMC_CONFIG4: + - gpmc,we-on: Assertion time + - gpmc,we-off: Deassertion time + + OE signals timings corresponding to GPMC_CONFIG4: + - gpmc,oe-on: Assertion time + - gpmc,oe-off: Deassertion time + + Access time and cycle time timings corresponding to GPMC_CONFIG5: + - gpmc,page-burst-access: Multiple access word delay + - gpmc,access: Start-cycle to first data valid delay + - gpmc,rd-cycle: Total read cycle time + - gpmc,wr-cycle: Total write cycle time + +The following are only applicable to OMAP3+ and AM335x: + - gpmc,wr-access + - gpmc,wr-data-mux-bus + + +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/imx23-clock.txt b/Documentation/devicetree/bindings/clock/imx23-clock.txt index a0b867ef8d96..5083c0b834b2 100644 --- a/Documentation/devicetree/bindings/clock/imx23-clock.txt +++ b/Documentation/devicetree/bindings/clock/imx23-clock.txt @@ -52,7 +52,7 @@ clocks and IDs. lcdif 38 etm 39 usb 40 - usb_pwr 41 + usb_phy 41 Examples: @@ -60,11 +60,6 @@ clks: clkctrl@80040000 { 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 new file mode 100644 index 000000000000..db4f2f05c4d0 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/imx25-clock.txt @@ -0,0 +1,158 @@ +* Clock bindings for Freescale i.MX25 + +Required properties: +- compatible: Should be "fsl,imx25-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.MX25 +clocks and IDs. + + Clock ID + --------------------------- + dummy 0 + osc 1 + mpll 2 + upll 3 + mpll_cpu_3_4 4 + cpu_sel 5 + cpu 6 + ahb 7 + usb_div 8 + ipg 9 + per0_sel 10 + per1_sel 11 + per2_sel 12 + per3_sel 13 + per4_sel 14 + per5_sel 15 + per6_sel 16 + per7_sel 17 + per8_sel 18 + per9_sel 19 + per10_sel 20 + per11_sel 21 + per12_sel 22 + per13_sel 23 + per14_sel 24 + per15_sel 25 + per0 26 + per1 27 + per2 28 + per3 29 + per4 30 + per5 31 + per6 32 + per7 33 + per8 34 + per9 35 + per10 36 + per11 37 + per12 38 + per13 39 + per14 40 + per15 41 + csi_ipg_per 42 + epit_ipg_per 43 + esai_ipg_per 44 + esdhc1_ipg_per 45 + esdhc2_ipg_per 46 + gpt_ipg_per 47 + i2c_ipg_per 48 + lcdc_ipg_per 49 + nfc_ipg_per 50 + owire_ipg_per 51 + pwm_ipg_per 52 + sim1_ipg_per 53 + sim2_ipg_per 54 + ssi1_ipg_per 55 + ssi2_ipg_per 56 + uart_ipg_per 57 + ata_ahb 58 + reserved 59 + csi_ahb 60 + emi_ahb 61 + esai_ahb 62 + esdhc1_ahb 63 + esdhc2_ahb 64 + fec_ahb 65 + lcdc_ahb 66 + rtic_ahb 67 + sdma_ahb 68 + slcdc_ahb 69 + usbotg_ahb 70 + reserved 71 + reserved 72 + reserved 73 + reserved 74 + can1_ipg 75 + can2_ipg 76 + csi_ipg 77 + cspi1_ipg 78 + cspi2_ipg 79 + cspi3_ipg 80 + dryice_ipg 81 + ect_ipg 82 + epit1_ipg 83 + epit2_ipg 84 + reserved 85 + esdhc1_ipg 86 + esdhc2_ipg 87 + fec_ipg 88 + reserved 89 + reserved 90 + reserved 91 + gpt1_ipg 92 + gpt2_ipg 93 + gpt3_ipg 94 + gpt4_ipg 95 + reserved 96 + reserved 97 + reserved 98 + iim_ipg 99 + reserved 100 + reserved 101 + kpp_ipg 102 + lcdc_ipg 103 + reserved 104 + pwm1_ipg 105 + pwm2_ipg 106 + pwm3_ipg 107 + pwm4_ipg 108 + rngb_ipg 109 + reserved 110 + scc_ipg 111 + sdma_ipg 112 + sim1_ipg 113 + sim2_ipg 114 + slcdc_ipg 115 + spba_ipg 116 + ssi1_ipg 117 + ssi2_ipg 118 + tsc_ipg 119 + uart1_ipg 120 + uart2_ipg 121 + uart3_ipg 122 + uart4_ipg 123 + uart5_ipg 124 + reserved 125 + wdt_ipg 126 + +Examples: + +clks: ccm@53f80000 { + compatible = "fsl,imx25-ccm"; + reg = <0x53f80000 0x4000>; + interrupts = <31>; +}; + +uart1: serial@43f90000 { + compatible = "fsl,imx25-uart", "fsl,imx21-uart"; + reg = <0x43f90000 0x4000>; + interrupts = <45>; + clocks = <&clks 79>, <&clks 50>; + 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 aa2af2866fe8..e6587af62ff0 100644 --- a/Documentation/devicetree/bindings/clock/imx28-clock.txt +++ b/Documentation/devicetree/bindings/clock/imx28-clock.txt @@ -73,8 +73,8 @@ clocks and IDs. can1 59 usb0 60 usb1 61 - usb0_pwr 62 - usb1_pwr 63 + usb0_phy 62 + usb1_phy 63 enet_out 64 Examples: @@ -83,11 +83,6 @@ clks: clkctrl@80040000 { 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 000000000000..19df842c694f --- /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 new file mode 100644 index 000000000000..2a0c904c46ae --- /dev/null +++ b/Documentation/devicetree/bindings/clock/imx5-clock.txt @@ -0,0 +1,192 @@ +* Clock bindings for Freescale i.MX5 + +Required properties: +- compatible: Should be "fsl,<soc>-ccm" , where <soc> can be imx51 or imx53 +- 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.MX5 +clocks and IDs. + + Clock ID + --------------------------- + dummy 0 + ckil 1 + osc 2 + ckih1 3 + ckih2 4 + ahb 5 + ipg 6 + axi_a 7 + axi_b 8 + uart_pred 9 + uart_root 10 + esdhc_a_pred 11 + esdhc_b_pred 12 + esdhc_c_s 13 + esdhc_d_s 14 + emi_sel 15 + emi_slow_podf 16 + nfc_podf 17 + ecspi_pred 18 + ecspi_podf 19 + usboh3_pred 20 + usboh3_podf 21 + usb_phy_pred 22 + usb_phy_podf 23 + cpu_podf 24 + di_pred 25 + tve_di 26 + tve_s 27 + uart1_ipg_gate 28 + uart1_per_gate 29 + uart2_ipg_gate 30 + uart2_per_gate 31 + uart3_ipg_gate 32 + uart3_per_gate 33 + i2c1_gate 34 + i2c2_gate 35 + gpt_ipg_gate 36 + pwm1_ipg_gate 37 + pwm1_hf_gate 38 + pwm2_ipg_gate 39 + pwm2_hf_gate 40 + gpt_hf_gate 41 + fec_gate 42 + usboh3_per_gate 43 + esdhc1_ipg_gate 44 + esdhc2_ipg_gate 45 + esdhc3_ipg_gate 46 + esdhc4_ipg_gate 47 + ssi1_ipg_gate 48 + ssi2_ipg_gate 49 + ssi3_ipg_gate 50 + ecspi1_ipg_gate 51 + ecspi1_per_gate 52 + ecspi2_ipg_gate 53 + ecspi2_per_gate 54 + cspi_ipg_gate 55 + sdma_gate 56 + emi_slow_gate 57 + ipu_s 58 + ipu_gate 59 + nfc_gate 60 + ipu_di1_gate 61 + vpu_s 62 + vpu_gate 63 + vpu_reference_gate 64 + uart4_ipg_gate 65 + uart4_per_gate 66 + uart5_ipg_gate 67 + uart5_per_gate 68 + tve_gate 69 + tve_pred 70 + esdhc1_per_gate 71 + esdhc2_per_gate 72 + esdhc3_per_gate 73 + esdhc4_per_gate 74 + usb_phy_gate 75 + hsi2c_gate 76 + mipi_hsc1_gate 77 + mipi_hsc2_gate 78 + mipi_esc_gate 79 + mipi_hsp_gate 80 + ldb_di1_div_3_5 81 + ldb_di1_div 82 + ldb_di0_div_3_5 83 + ldb_di0_div 84 + ldb_di1_gate 85 + can2_serial_gate 86 + can2_ipg_gate 87 + i2c3_gate 88 + lp_apm 89 + periph_apm 90 + main_bus 91 + ahb_max 92 + aips_tz1 93 + aips_tz2 94 + tmax1 95 + tmax2 96 + tmax3 97 + spba 98 + uart_sel 99 + esdhc_a_sel 100 + esdhc_b_sel 101 + esdhc_a_podf 102 + esdhc_b_podf 103 + ecspi_sel 104 + usboh3_sel 105 + usb_phy_sel 106 + iim_gate 107 + usboh3_gate 108 + emi_fast_gate 109 + ipu_di0_gate 110 + gpc_dvfs 111 + pll1_sw 112 + pll2_sw 113 + pll3_sw 114 + ipu_di0_sel 115 + ipu_di1_sel 116 + tve_ext_sel 117 + mx51_mipi 118 + pll4_sw 119 + ldb_di1_sel 120 + di_pll4_podf 121 + ldb_di0_sel 122 + ldb_di0_gate 123 + usb_phy1_gate 124 + usb_phy2_gate 125 + per_lp_apm 126 + per_pred1 127 + per_pred2 128 + per_podf 129 + per_root 130 + ssi_apm 131 + ssi1_root_sel 132 + ssi2_root_sel 133 + ssi3_root_sel 134 + ssi_ext1_sel 135 + ssi_ext2_sel 136 + ssi_ext1_com_sel 137 + ssi_ext2_com_sel 138 + ssi1_root_pred 139 + ssi1_root_podf 140 + ssi2_root_pred 141 + ssi2_root_podf 142 + ssi_ext1_pred 143 + ssi_ext1_podf 144 + ssi_ext2_pred 145 + ssi_ext2_podf 146 + ssi1_root_gate 147 + ssi2_root_gate 148 + ssi3_root_gate 149 + ssi_ext1_gate 150 + ssi_ext2_gate 151 + epit1_ipg_gate 152 + epit1_hf_gate 153 + epit2_ipg_gate 154 + epit2_hf_gate 155 + can_sel 156 + can1_serial_gate 157 + can1_ipg_gate 158 + owire_gate 159 + +Examples (for mx53): + +clks: ccm@53fd4000{ + compatible = "fsl,imx53-ccm"; + reg = <0x53fd4000 0x4000>; + interrupts = <0 71 0x04 0 72 0x04>; + #clock-cells = <1>; +}; + +can1: can@53fc8000 { + compatible = "fsl,imx53-flexcan", "fsl,p1010-flexcan"; + reg = <0x53fc8000 0x4000>; + interrupts = <82>; + clocks = <&clks 158>, <&clks 157>; + clock-names = "ipg", "per"; + status = "disabled"; +}; diff --git a/Documentation/devicetree/bindings/clock/imx6q-clock.txt b/Documentation/devicetree/bindings/clock/imx6q-clock.txt index 492bd991d52a..969b38e06ad3 100644 --- a/Documentation/devicetree/bindings/clock/imx6q-clock.txt +++ b/Documentation/devicetree/bindings/clock/imx6q-clock.txt @@ -187,9 +187,9 @@ clocks and IDs. pll3_usb_otg 172 pll4_audio 173 pll5_video 174 - pll6_mlb 175 + pll8_mlb 175 pll7_usb_host 176 - pll8_enet 177 + pll6_enet 177 ssi1_ipg 178 ssi2_ipg 179 ssi3_ipg 180 @@ -198,6 +198,13 @@ clocks and IDs. usbphy2 183 ldb_di0_div_3_5 184 ldb_di1_div_3_5 185 + sata_ref 186 + sata_ref_100m 187 + pcie_ref 188 + pcie_ref_125m 189 + enet_ref 190 + usbphy1_gate 191 + usbphy2_gate 192 Examples: @@ -206,10 +213,6 @@ clks: ccm@020c4000 { 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/mvebu-core-clock.txt b/Documentation/devicetree/bindings/clock/mvebu-core-clock.txt new file mode 100644 index 000000000000..1e662948661e --- /dev/null +++ b/Documentation/devicetree/bindings/clock/mvebu-core-clock.txt @@ -0,0 +1,47 @@ +* Core Clock bindings for Marvell MVEBU SoCs + +Marvell MVEBU SoCs usually allow to determine core clock frequencies by +reading the Sample-At-Reset (SAR) register. The core clock consumer should +specify the desired clock by having the clock ID in its "clocks" phandle cell. + +The following is a list of provided IDs and clock names on Armada 370/XP: + 0 = tclk (Internal Bus clock) + 1 = cpuclk (CPU clock) + 2 = nbclk (L2 Cache clock) + 3 = hclk (DRAM control clock) + 4 = dramclk (DDR clock) + +The following is a list of provided IDs and clock names on Kirkwood and Dove: + 0 = tclk (Internal Bus clock) + 1 = cpuclk (CPU0 clock) + 2 = l2clk (L2 Cache clock derived from CPU0 clock) + 3 = ddrclk (DDR controller clock derived from CPU0 clock) + +Required properties: +- compatible : shall be one of the following: + "marvell,armada-370-core-clock" - For Armada 370 SoC core clocks + "marvell,armada-xp-core-clock" - For Armada XP SoC core clocks + "marvell,dove-core-clock" - for Dove SoC core clocks + "marvell,kirkwood-core-clock" - for Kirkwood SoC (except mv88f6180) + "marvell,mv88f6180-core-clock" - for Kirkwood MV88f6180 SoC +- reg : shall be the register address of the Sample-At-Reset (SAR) register +- #clock-cells : from common clock binding; shall be set to 1 + +Optional properties: +- clock-output-names : from common clock binding; allows overwrite default clock + output names ("tclk", "cpuclk", "l2clk", "ddrclk") + +Example: + +core_clk: core-clocks@d0214 { + compatible = "marvell,dove-core-clock"; + reg = <0xd0214 0x4>; + #clock-cells = <1>; +}; + +spi0: spi@10600 { + compatible = "marvell,orion-spi"; + /* ... */ + /* get tclk from core clock provider */ + clocks = <&core_clk 0>; +}; diff --git a/Documentation/devicetree/bindings/clock/mvebu-cpu-clock.txt b/Documentation/devicetree/bindings/clock/mvebu-cpu-clock.txt new file mode 100644 index 000000000000..feb830130714 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/mvebu-cpu-clock.txt @@ -0,0 +1,21 @@ +Device Tree Clock bindings for cpu clock of Marvell EBU platforms + +Required properties: +- compatible : shall be one of the following: + "marvell,armada-xp-cpu-clock" - cpu clocks for Armada XP +- reg : Address and length of the clock complex register set +- #clock-cells : should be set to 1. +- clocks : shall be the input parent clock phandle for the clock. + +cpuclk: clock-complex@d0018700 { + #clock-cells = <1>; + compatible = "marvell,armada-xp-cpu-clock"; + reg = <0xd0018700 0xA0>; + clocks = <&coreclk 1>; +} + +cpu@0 { + compatible = "marvell,sheeva-v7"; + reg = <0>; + clocks = <&cpuclk 0>; +}; diff --git a/Documentation/devicetree/bindings/clock/mvebu-gated-clock.txt b/Documentation/devicetree/bindings/clock/mvebu-gated-clock.txt new file mode 100644 index 000000000000..cffc93d97f54 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/mvebu-gated-clock.txt @@ -0,0 +1,119 @@ +* Gated Clock bindings for Marvell Orion SoCs + +Marvell Dove and Kirkwood allow some peripheral clocks to be gated to save +some power. The clock consumer should specify the desired clock by having +the clock ID in its "clocks" phandle cell. The clock ID is directly mapped to +the corresponding clock gating control bit in HW to ease manual clock lookup +in datasheet. + +The following is a list of provided IDs for Armada 370: +ID Clock Peripheral +----------------------------------- +0 Audio AC97 Cntrl +1 pex0_en PCIe 0 Clock out +2 pex1_en PCIe 1 Clock out +3 ge1 Gigabit Ethernet 1 +4 ge0 Gigabit Ethernet 0 +5 pex0 PCIe Cntrl 0 +9 pex1 PCIe Cntrl 1 +15 sata0 SATA Host 0 +17 sdio SDHCI Host +25 tdm Time Division Mplx +28 ddr DDR Cntrl +30 sata1 SATA Host 0 + +The following is a list of provided IDs for Armada XP: +ID Clock Peripheral +----------------------------------- +0 audio Audio Cntrl +1 ge3 Gigabit Ethernet 3 +2 ge2 Gigabit Ethernet 2 +3 ge1 Gigabit Ethernet 1 +4 ge0 Gigabit Ethernet 0 +5 pex0 PCIe Cntrl 0 +6 pex1 PCIe Cntrl 1 +7 pex2 PCIe Cntrl 2 +8 pex3 PCIe Cntrl 3 +13 bp +14 sata0lnk +15 sata0 SATA Host 0 +16 lcd LCD Cntrl +17 sdio SDHCI Host +18 usb0 USB Host 0 +19 usb1 USB Host 1 +20 usb2 USB Host 2 +22 xor0 XOR DMA 0 +23 crypto CESA engine +25 tdm Time Division Mplx +28 xor1 XOR DMA 1 +29 sata1lnk +30 sata1 SATA Host 0 + +The following is a list of provided IDs for Dove: +ID Clock Peripheral +----------------------------------- +0 usb0 USB Host 0 +1 usb1 USB Host 1 +2 ge Gigabit Ethernet +3 sata SATA Host +4 pex0 PCIe Cntrl 0 +5 pex1 PCIe Cntrl 1 +8 sdio0 SDHCI Host 0 +9 sdio1 SDHCI Host 1 +10 nand NAND Cntrl +11 camera Camera Cntrl +12 i2s0 I2S Cntrl 0 +13 i2s1 I2S Cntrl 1 +15 crypto CESA engine +21 ac97 AC97 Cntrl +22 pdma Peripheral DMA +23 xor0 XOR DMA 0 +24 xor1 XOR DMA 1 +30 gephy Gigabit Ethernel PHY +Note: gephy(30) is implemented as a parent clock of ge(2) + +The following is a list of provided IDs for Kirkwood: +ID Clock Peripheral +----------------------------------- +0 ge0 Gigabit Ethernet 0 +2 pex0 PCIe Cntrl 0 +3 usb0 USB Host 0 +4 sdio SDIO Cntrl +5 tsu Transp. Stream Unit +6 dunit SDRAM Cntrl +7 runit Runit +8 xor0 XOR DMA 0 +9 audio I2S Cntrl 0 +14 sata0 SATA Host 0 +15 sata1 SATA Host 1 +16 xor1 XOR DMA 1 +17 crypto CESA engine +18 pex1 PCIe Cntrl 1 +19 ge1 Gigabit Ethernet 1 +20 tdm Time Division Mplx + +Required properties: +- compatible : shall be one of the following: + "marvell,dove-gating-clock" - for Dove SoC clock gating + "marvell,kirkwood-gating-clock" - for Kirkwood SoC clock gating +- reg : shall be the register address of the Clock Gating Control register +- #clock-cells : from common clock binding; shall be set to 1 + +Optional properties: +- clocks : default parent clock phandle (e.g. tclk) + +Example: + +gate_clk: clock-gating-control@d0038 { + compatible = "marvell,dove-gating-clock"; + reg = <0xd0038 0x4>; + /* default parent clock is tclk */ + clocks = <&core_clk 0>; + #clock-cells = <1>; +}; + +sdio0: sdio@92000 { + compatible = "marvell,dove-sdhci"; + /* get clk gate bit 8 (sdio0) */ + clocks = <&gate_clk 8>; +}; 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 000000000000..0921fac73528 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt @@ -0,0 +1,205 @@ +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 first 96 clocks are numbered to match the bits in the CAR's CLK_OUT_ENB + registers. These IDs often match those in the CAR's RST_DEVICES registers, + but not in all cases. Some bits in CLK_OUT_ENB affect multiple clocks. In + this case, those clocks are assigned IDs above 95 in order to highlight + this issue. Implementations that interpret these clock IDs as bit values + within the CLK_OUT_ENB or RST_DEVICES registers should be careful to + explicitly handle these special cases. + + The balance of the clocks controlled by the CAR are assigned IDs of 96 and + above. + + 0 cpu + 1 unassigned + 2 unassigned + 3 ac97 + 4 rtc + 5 tmr + 6 uart1 + 7 unassigned (register bit affects uart2 and vfir) + 8 gpio + 9 sdmmc2 + 10 unassigned (register bit affects spdif_in and spdif_out) + 11 i2s1 + 12 i2c1 + 13 ndflash + 14 sdmmc1 + 15 sdmmc4 + 16 twc + 17 pwm + 18 i2s2 + 19 epp + 20 unassigned (register bit affects vi and vi_sensor) + 21 2d + 22 usbd + 23 isp + 24 3d + 25 ide + 26 disp2 + 27 disp1 + 28 host1x + 29 vcp + 30 unassigned + 31 cache2 + + 32 mem + 33 ahbdma + 34 apbdma + 35 unassigned + 36 kbc + 37 stat_mon + 38 pmc + 39 fuse + 40 kfuse + 41 sbc1 + 42 snor + 43 spi1 + 44 sbc2 + 45 xio + 46 sbc3 + 47 dvc + 48 dsi + 49 unassigned (register bit affects tvo and cve) + 50 mipi + 51 hdmi + 52 csi + 53 tvdac + 54 i2c2 + 55 uart3 + 56 unassigned + 57 emc + 58 usb2 + 59 usb3 + 60 mpe + 61 vde + 62 bsea + 63 bsev + + 64 speedo + 65 uart4 + 66 uart5 + 67 i2c3 + 68 sbc4 + 69 sdmmc3 + 70 pcie + 71 owr + 72 afi + 73 csite + 74 unassigned + 75 avpucq + 76 la + 77 unassigned + 78 unassigned + 79 unassigned + 80 unassigned + 81 unassigned + 82 unassigned + 83 unassigned + 84 irama + 85 iramb + 86 iramc + 87 iramd + 88 cram2 + 89 audio_2x a/k/a audio_2x_sync_clk + 90 clk_d + 91 unassigned + 92 sus + 93 cdev1 + 94 cdev2 + 95 unassigned + + 96 uart2 + 97 vfir + 98 spdif_in + 99 spdif_out + 100 vi + 101 vi_sensor + 102 tvo + 103 cve + 104 osc + 105 clk_32k a/k/a clk_s + 106 clk_m + 107 sclk + 108 cclk + 109 hclk + 110 pclk + 111 blink + 112 pll_a + 113 pll_a_out0 + 114 pll_c + 115 pll_c_out1 + 116 pll_d + 117 pll_d_out0 + 118 pll_e + 119 pll_m + 120 pll_m_out1 + 121 pll_p + 122 pll_p_out1 + 123 pll_p_out2 + 124 pll_p_out3 + 125 pll_p_out4 + 126 pll_s + 127 pll_u + 128 pll_x + 129 cop a/k/a avp + 130 audio a/k/a audio_sync_clk + 131 pll_ref + 132 twd + +Example SoC include file: + +/ { + tegra_car: clock { + compatible = "nvidia,tegra20-car"; + reg = <0x60006000 0x1000>; + #clock-cells = <1>; + }; + + usb@c5004000 { + clocks = <&tegra_car 58>; /* 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 000000000000..f3da3be5fcad --- /dev/null +++ b/Documentation/devicetree/bindings/clock/nvidia,tegra30-car.txt @@ -0,0 +1,262 @@ +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 first 130 clocks are numbered to match the bits in the CAR's CLK_OUT_ENB + registers. These IDs often match those in the CAR's RST_DEVICES registers, + but not in all cases. Some bits in CLK_OUT_ENB affect multiple clocks. In + this case, those clocks are assigned IDs above 160 in order to highlight + this issue. Implementations that interpret these clock IDs as bit values + within the CLK_OUT_ENB or RST_DEVICES registers should be careful to + explicitly handle these special cases. + + The balance of the clocks controlled by the CAR are assigned IDs of 160 and + above. + + 0 cpu + 1 unassigned + 2 unassigned + 3 unassigned + 4 rtc + 5 timer + 6 uarta + 7 unassigned (register bit affects uartb and vfir) + 8 gpio + 9 sdmmc2 + 10 unassigned (register bit affects spdif_in and spdif_out) + 11 i2s1 + 12 i2c1 + 13 ndflash + 14 sdmmc1 + 15 sdmmc4 + 16 unassigned + 17 pwm + 18 i2s2 + 19 epp + 20 unassigned (register bit affects vi and vi_sensor) + 21 2d + 22 usbd + 23 isp + 24 3d + 25 unassigned + 26 disp2 + 27 disp1 + 28 host1x + 29 vcp + 30 i2s0 + 31 cop_cache + + 32 mc + 33 ahbdma + 34 apbdma + 35 unassigned + 36 kbc + 37 statmon + 38 pmc + 39 unassigned (register bit affects fuse and fuse_burn) + 40 kfuse + 41 sbc1 + 42 nor + 43 unassigned + 44 sbc2 + 45 unassigned + 46 sbc3 + 47 i2c5 + 48 dsia + 49 unassigned (register bit affects cve and tvo) + 50 mipi + 51 hdmi + 52 csi + 53 tvdac + 54 i2c2 + 55 uartc + 56 unassigned + 57 emc + 58 usb2 + 59 usb3 + 60 mpe + 61 vde + 62 bsea + 63 bsev + + 64 speedo + 65 uartd + 66 uarte + 67 i2c3 + 68 sbc4 + 69 sdmmc3 + 70 pcie + 71 owr + 72 afi + 73 csite + 74 pciex + 75 avpucq + 76 la + 77 unassigned + 78 unassigned + 79 dtv + 80 ndspeed + 81 i2cslow + 82 dsib + 83 unassigned + 84 irama + 85 iramb + 86 iramc + 87 iramd + 88 cram2 + 89 unassigned + 90 audio_2x a/k/a audio_2x_sync_clk + 91 unassigned + 92 csus + 93 cdev2 + 94 cdev1 + 95 unassigned + + 96 cpu_g + 97 cpu_lp + 98 3d2 + 99 mselect + 100 tsensor + 101 i2s3 + 102 i2s4 + 103 i2c4 + 104 sbc5 + 105 sbc6 + 106 d_audio + 107 apbif + 108 dam0 + 109 dam1 + 110 dam2 + 111 hda2codec_2x + 112 atomics + 113 audio0_2x + 114 audio1_2x + 115 audio2_2x + 116 audio3_2x + 117 audio4_2x + 118 audio5_2x + 119 actmon + 120 extern1 + 121 extern2 + 122 extern3 + 123 sata_oob + 124 sata + 125 hda + 127 se + 128 hda2hdmi + 129 sata_cold + + 160 uartb + 161 vfir + 162 spdif_in + 163 spdif_out + 164 vi + 165 vi_sensor + 166 fuse + 167 fuse_burn + 168 cve + 169 tvo + + 170 clk_32k + 171 clk_m + 172 clk_m_div2 + 173 clk_m_div4 + 174 pll_ref + 175 pll_c + 176 pll_c_out1 + 177 pll_m + 178 pll_m_out1 + 179 pll_p + 180 pll_p_out1 + 181 pll_p_out2 + 182 pll_p_out3 + 183 pll_p_out4 + 184 pll_a + 185 pll_a_out0 + 186 pll_d + 187 pll_d_out0 + 188 pll_d2 + 189 pll_d2_out0 + 190 pll_u + 191 pll_x + 192 pll_x_out0 + 193 pll_e + 194 spdif_in_sync + 195 i2s0_sync + 196 i2s1_sync + 197 i2s2_sync + 198 i2s3_sync + 199 i2s4_sync + 200 vimclk + 201 audio0 + 202 audio1 + 203 audio2 + 204 audio3 + 205 audio4 + 206 audio5 + 207 clk_out_1 (extern1) + 208 clk_out_2 (extern2) + 209 clk_out_3 (extern3) + 210 sclk + 211 blink + 212 cclk_g + 213 cclk_lp + 214 twd + 215 cml0 + 216 cml1 + 217 hclk + 218 pclk + +Example SoC include file: + +/ { + tegra_car: clock { + compatible = "nvidia,tegra30-car"; + reg = <0x60006000 0x1000>; + #clock-cells = <1>; + }; + + usb@c5004000 { + clocks = <&tegra_car 58>; /* 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 000000000000..5016979c0f78 --- /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/zynq-7000.txt b/Documentation/devicetree/bindings/clock/zynq-7000.txt new file mode 100644 index 000000000000..23ae1db1bc13 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/zynq-7000.txt @@ -0,0 +1,55 @@ +Device Tree Clock bindings for the Zynq 7000 EPP + +The Zynq EPP has several different clk providers, each with there own bindings. +The purpose of this document is to document their usage. + +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. + +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 + +Optional properties: +- clock-output-names : name of the output clock + +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 { + #clock-cells = <1>; + compatible = "xlnx,zynq-periph-clock"; + clocks = <&iopll &armpll &ddrpll>; + reg = <0x154>; + clock-output-names = "uart0_ref_clk", + "uart1_ref_clk"; + }; diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-spear.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-spear.txt new file mode 100644 index 000000000000..f3d44984d91c --- /dev/null +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-spear.txt @@ -0,0 +1,42 @@ +SPEAr cpufreq driver +------------------- + +SPEAr SoC cpufreq driver for CPU frequency scaling. +It supports both uniprocessor (UP) and symmetric multiprocessor (SMP) systems +which share clock across all CPUs. + +Required properties: +- cpufreq_tbl: Table of frequencies CPU could be transitioned into, in the + increasing order. + +Optional properties: +- clock-latency: Specify the possible maximum transition latency for clock, in + unit of nanoseconds. + +Both required and optional properties listed above must be defined under node +/cpus/cpu@0. + +Examples: +-------- +cpus { + + <...> + + cpu@0 { + compatible = "arm,cortex-a9"; + reg = <0>; + + <...> + + cpufreq_tbl = < 166000 + 200000 + 250000 + 300000 + 400000 + 500000 + 600000 >; + }; + + <...> + +}; diff --git a/Documentation/devicetree/bindings/crypto/fsl-sec4.txt b/Documentation/devicetree/bindings/crypto/fsl-sec4.txt index bd7ce120bc13..e4022776ac6e 100644 --- a/Documentation/devicetree/bindings/crypto/fsl-sec4.txt +++ b/Documentation/devicetree/bindings/crypto/fsl-sec4.txt @@ -56,6 +56,12 @@ PROPERTIES Value type: <string> 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 Value type: <u32> @@ -107,6 +113,7 @@ PROPERTIES EXAMPLE crypto@300000 { 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 36e27d54260b..267565894db9 100644 --- a/Documentation/devicetree/bindings/dma/arm-pl330.txt +++ b/Documentation/devicetree/bindings/dma/arm-pl330.txt @@ -10,7 +10,11 @@ Required properties: - 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 @@ Example: 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/dma.txt b/Documentation/devicetree/bindings/dma/dma.txt new file mode 100644 index 000000000000..8f504e6bae14 --- /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/mv-xor.txt b/Documentation/devicetree/bindings/dma/mv-xor.txt new file mode 100644 index 000000000000..7c6cb7fcecd2 --- /dev/null +++ b/Documentation/devicetree/bindings/dma/mv-xor.txt @@ -0,0 +1,40 @@ +* Marvell XOR engines + +Required properties: +- compatible: Should be "marvell,orion-xor" +- reg: Should contain registers location and length (two sets) + the first set is the low registers, the second set the high + registers for the XOR engine. +- clocks: pointer to the reference clock + +The DT node must also contains sub-nodes for each XOR channel that the +XOR engine has. Those sub-nodes have the following required +properties: +- interrupts: interrupt of the XOR channel + +And the following optional properties: +- dmacap,memcpy to indicate that the XOR channel is capable of memcpy operations +- dmacap,memset to indicate that the XOR channel is capable of memset operations +- dmacap,xor to indicate that the XOR channel is capable of xor operations + +Example: + +xor@d0060900 { + compatible = "marvell,orion-xor"; + reg = <0xd0060900 0x100 + 0xd0060b00 0x100>; + clocks = <&coreclk 0>; + status = "okay"; + + xor00 { + interrupts = <51>; + dmacap,memcpy; + dmacap,xor; + }; + xor01 { + interrupts = <52>; + dmacap,memcpy; + dmacap,xor; + dmacap,memset; + }; +}; diff --git a/Documentation/devicetree/bindings/dma/snps-dma.txt b/Documentation/devicetree/bindings/dma/snps-dma.txt index c0d85dbcada5..d58675ea1abf 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/drm/exynos/g2d.txt b/Documentation/devicetree/bindings/drm/exynos/g2d.txt new file mode 100644 index 000000000000..1eb124d35a99 --- /dev/null +++ b/Documentation/devicetree/bindings/drm/exynos/g2d.txt @@ -0,0 +1,22 @@ +Samsung 2D Graphic Accelerator using DRM frame work + +Samsung FIMG2D is a graphics 2D accelerator which supports Bit Block Transfer. +We set the drawing-context registers for configuring rendering parameters and +then start rendering. +This driver is for SOCs which contain G2D IPs with version 4.1. + +Required properties: + -compatible: + should be "samsung,exynos-g2d-41". + -reg: + physical base address of the controller and length + of memory mapped region. + -interrupts: + interrupt combiner values. + +Example: + g2d { + compatible = "samsung,exynos-g2d-41"; + reg = <0x10850000 0x1000>; + interrupts = <0 91 0>; + }; diff --git a/Documentation/devicetree/bindings/drm/exynos/hdmi.txt b/Documentation/devicetree/bindings/drm/exynos/hdmi.txt new file mode 100644 index 000000000000..589edee37394 --- /dev/null +++ b/Documentation/devicetree/bindings/drm/exynos/hdmi.txt @@ -0,0 +1,22 @@ +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 new file mode 100644 index 000000000000..fa166d945809 --- /dev/null +++ b/Documentation/devicetree/bindings/drm/exynos/hdmiddc.txt @@ -0,0 +1,12 @@ +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 new file mode 100644 index 000000000000..858f4f9b902f --- /dev/null +++ b/Documentation/devicetree/bindings/drm/exynos/hdmiphy.txt @@ -0,0 +1,12 @@ +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 new file mode 100644 index 000000000000..9b2ea0343566 --- /dev/null +++ b/Documentation/devicetree/bindings/drm/exynos/mixer.txt @@ -0,0 +1,15 @@ +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 000000000000..9301c330d1a6 --- /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 000000000000..3d2c52460dca --- /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 000000000000..a58ae7756fc6 --- /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 000000000000..e5f130159ae1 --- /dev/null +++ b/Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt @@ -0,0 +1,21 @@ +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 + +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/gpio/gpio-poweroff.txt b/Documentation/devicetree/bindings/gpio/gpio-poweroff.txt new file mode 100644 index 000000000000..d4eab9227ea4 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio-poweroff.txt @@ -0,0 +1,36 @@ +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". +- gpios : The GPIO to set high/low, see "gpios property" in + Documentation/devicetree/bindings/gpio/gpio.txt. If the pin should be + low to power down the board set it to "Active Low", otherwise set + gpio to "Active High". + +Optional properties: +- input : Initially configure the GPIO line as an input. Only reconfigure + it to an output when the pm_power_off function is called. If this optional + 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>; +}; diff --git a/Documentation/devicetree/bindings/gpio/gpio-stmpe.txt b/Documentation/devicetree/bindings/gpio/gpio-stmpe.txt new file mode 100644 index 000000000000..a0e4cf885213 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio-stmpe.txt @@ -0,0 +1,18 @@ +STMPE gpio +---------- + +Required properties: + - compatible: "st,stmpe-gpio" + +Optional properties: + - st,norequest-mask: bitmask specifying which GPIOs should _not_ be requestable + due to different usage (e.g. touch, keypad) + +Node name must be stmpe_gpio and should be child node of stmpe node to which it +belongs. + +Example: + stmpe_gpio { + compatible = "st,stmpe-gpio"; + st,norequest-mask = <0x20>; //gpio 5 can't be used + }; diff --git a/Documentation/devicetree/bindings/gpio/gpio.txt b/Documentation/devicetree/bindings/gpio/gpio.txt index 4e16ba4feab0..a33628759d36 100644 --- a/Documentation/devicetree/bindings/gpio/gpio.txt +++ b/Documentation/devicetree/bindings/gpio/gpio.txt @@ -75,4 +75,40 @@ Example of two SOC GPIO banks defined as gpio-controller nodes: gpio-controller; }; +2.1) gpio-controller and pinctrl subsystem +------------------------------------------ +gpio-controller on a SOC might be tightly coupled with the pinctrl +subsystem, in the sense that the pins can be used by other functions +together with optional gpio feature. + +While the pin allocation is totally managed by the pin ctrl subsystem, +gpio (under gpiolib) is still maintained by gpio drivers. It may happen +that different pin ranges in a SoC is managed by different gpio drivers. + +This makes it logical to let gpio drivers announce their pin ranges to +the pin ctrl subsystem and call 'pinctrl_request_gpio' in order to +request the corresponding pin before any gpio usage. + +For this, the gpio controller can use a pinctrl phandle and pins to +announce the pinrange to the pin ctrl subsystem. For example, + + qe_pio_e: gpio-controller@1460 { + #gpio-cells = <2>; + compatible = "fsl,qe-pario-bank-e", "fsl,qe-pario-bank"; + reg = <0x1460 0x18>; + gpio-controller; + gpio-ranges = <&pinctrl1 20 10>, <&pinctrl2 50 20>; + + } + +where, + &pinctrl1 and &pinctrl2 is the phandle to the pinctrl DT node. + + 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. + +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/gpio_atmel.txt b/Documentation/devicetree/bindings/gpio/gpio_atmel.txt index 66efc804806a..85f8c0d084fa 100644 --- a/Documentation/devicetree/bindings/gpio/gpio_atmel.txt +++ b/Documentation/devicetree/bindings/gpio/gpio_atmel.txt @@ -9,6 +9,10 @@ Required properties: unused). - gpio-controller: Marks the device node as a GPIO controller. +optional properties: +- #gpio-lines: Number of gpio if absent 32. + + Example: pioA: gpio@fffff200 { compatible = "atmel,at91rm9200-gpio"; @@ -16,5 +20,6 @@ Example: interrupts = <2 4>; #gpio-cells = <2>; gpio-controller; + #gpio-lines = <19>; }; diff --git a/Documentation/devicetree/bindings/gpio/spear_spics.txt b/Documentation/devicetree/bindings/gpio/spear_spics.txt new file mode 100644 index 000000000000..96c37eb15075 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/spear_spics.txt @@ -0,0 +1,50 @@ +=== ST Microelectronics SPEAr SPI CS Driver === + +SPEAr platform provides a provision to control chipselects of ARM PL022 Prime +Cell spi controller through its system registers, which otherwise remains under +PL022 control. If chipselect remain under PL022 control then they would be +released as soon as transfer is over and TxFIFO becomes empty. This is not +desired by some of the device protocols above spi which expect (multiple) +transfers without releasing their chipselects. + +Chipselects can be controlled by software by turning them as GPIOs. SPEAr +provides another interface through system registers through which software can +directly control each PL022 chipselect. Hence, it is natural for SPEAr to export +the control of this interface as gpio. + +Required properties: + + * compatible: should be defined as "st,spear-spics-gpio" + * reg: mentioning address range of spics controller + * st-spics,peripcfg-reg: peripheral configuration register offset + * st-spics,sw-enable-bit: bit offset to enable sw control + * st-spics,cs-value-bit: bit offset to drive chipselect low or high + * st-spics,cs-enable-mask: chip select number bit mask + * st-spics,cs-enable-shift: chip select number program offset + * gpio-controller: Marks the device node as gpio controller + * #gpio-cells: should be 1 and will mention chip select number + +All the above bit offsets are within peripcfg register. + +Example: +------- +spics: spics@e0700000{ + compatible = "st,spear-spics-gpio"; + reg = <0xe0700000 0x1000>; + st-spics,peripcfg-reg = <0x3b0>; + st-spics,sw-enable-bit = <12>; + st-spics,cs-value-bit = <11>; + st-spics,cs-enable-mask = <3>; + st-spics,cs-enable-shift = <8>; + gpio-controller; + #gpio-cells = <2>; +}; + + +spi0: spi@e0100000 { + status = "okay"; + num-cs = <3>; + cs-gpios = <&gpio1 7 0>, <&spics 0>, + <&spics 1>; + ... +} diff --git a/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt b/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt new file mode 100644 index 000000000000..b4fa934ae3a2 --- /dev/null +++ b/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt @@ -0,0 +1,191 @@ +NVIDIA Tegra host1x + +Required properties: +- compatible: "nvidia,tegra<chip>-host1x" +- reg: Physical base address and length of the controller's registers. +- interrupts: The interrupt outputs from the controller. +- #address-cells: The number of cells used to represent physical base addresses + in the host1x address space. Should be 1. +- #size-cells: The number of cells used to represent the size of an address + range in the host1x address space. Should be 1. +- ranges: The mapping of the host1x address space to the CPU address space. + +The host1x top-level node defines a number of children, each representing one +of the following host1x client modules: + +- mpe: video encoder + + Required properties: + - compatible: "nvidia,tegra<chip>-mpe" + - reg: Physical base address and length of the controller's registers. + - interrupts: The interrupt outputs from the controller. + +- vi: video input + + Required properties: + - compatible: "nvidia,tegra<chip>-vi" + - reg: Physical base address and length of the controller's registers. + - interrupts: The interrupt outputs from the controller. + +- epp: encoder pre-processor + + Required properties: + - compatible: "nvidia,tegra<chip>-epp" + - reg: Physical base address and length of the controller's registers. + - interrupts: The interrupt outputs from the controller. + +- isp: image signal processor + + Required properties: + - compatible: "nvidia,tegra<chip>-isp" + - reg: Physical base address and length of the controller's registers. + - interrupts: The interrupt outputs from the controller. + +- gr2d: 2D graphics engine + + Required properties: + - compatible: "nvidia,tegra<chip>-gr2d" + - reg: Physical base address and length of the controller's registers. + - interrupts: The interrupt outputs from the controller. + +- gr3d: 3D graphics engine + + Required properties: + - compatible: "nvidia,tegra<chip>-gr3d" + - reg: Physical base address and length of the controller's registers. + +- dc: display controller + + Required properties: + - compatible: "nvidia,tegra<chip>-dc" + - reg: Physical base address and length of the controller's registers. + - interrupts: The interrupt outputs from the controller. + + Each display controller node has a child node, named "rgb", that represents + the RGB output associated with the controller. It can take the following + optional properties: + - nvidia,ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing + - nvidia,hpd-gpio: specifies a GPIO used for hotplug detection + - nvidia,edid: supplies a binary EDID blob + +- hdmi: High Definition Multimedia Interface + + Required properties: + - compatible: "nvidia,tegra<chip>-hdmi" + - reg: Physical base address and length of the controller's registers. + - interrupts: The interrupt outputs from the controller. + - vdd-supply: regulator for supply voltage + - pll-supply: regulator for PLL + + Optional properties: + - nvidia,ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing + - nvidia,hpd-gpio: specifies a GPIO used for hotplug detection + - nvidia,edid: supplies a binary EDID blob + +- tvo: TV encoder output + + Required properties: + - compatible: "nvidia,tegra<chip>-tvo" + - reg: Physical base address and length of the controller's registers. + - interrupts: The interrupt outputs from the controller. + +- dsi: display serial interface + + Required properties: + - compatible: "nvidia,tegra<chip>-dsi" + - reg: Physical base address and length of the controller's registers. + +Example: + +/ { + ... + + host1x { + compatible = "nvidia,tegra20-host1x", "simple-bus"; + reg = <0x50000000 0x00024000>; + interrupts = <0 65 0x04 /* mpcore syncpt */ + 0 67 0x04>; /* mpcore general */ + + #address-cells = <1>; + #size-cells = <1>; + + ranges = <0x54000000 0x54000000 0x04000000>; + + mpe { + compatible = "nvidia,tegra20-mpe"; + reg = <0x54040000 0x00040000>; + interrupts = <0 68 0x04>; + }; + + vi { + compatible = "nvidia,tegra20-vi"; + reg = <0x54080000 0x00040000>; + interrupts = <0 69 0x04>; + }; + + epp { + compatible = "nvidia,tegra20-epp"; + reg = <0x540c0000 0x00040000>; + interrupts = <0 70 0x04>; + }; + + isp { + compatible = "nvidia,tegra20-isp"; + reg = <0x54100000 0x00040000>; + interrupts = <0 71 0x04>; + }; + + gr2d { + compatible = "nvidia,tegra20-gr2d"; + reg = <0x54140000 0x00040000>; + interrupts = <0 72 0x04>; + }; + + gr3d { + compatible = "nvidia,tegra20-gr3d"; + reg = <0x54180000 0x00040000>; + }; + + dc@54200000 { + compatible = "nvidia,tegra20-dc"; + reg = <0x54200000 0x00040000>; + interrupts = <0 73 0x04>; + + rgb { + status = "disabled"; + }; + }; + + dc@54240000 { + compatible = "nvidia,tegra20-dc"; + reg = <0x54240000 0x00040000>; + interrupts = <0 74 0x04>; + + rgb { + status = "disabled"; + }; + }; + + hdmi { + compatible = "nvidia,tegra20-hdmi"; + reg = <0x54280000 0x00040000>; + interrupts = <0 75 0x04>; + status = "disabled"; + }; + + tvo { + compatible = "nvidia,tegra20-tvo"; + reg = <0x542c0000 0x00040000>; + interrupts = <0 76 0x04>; + status = "disabled"; + }; + + dsi { + compatible = "nvidia,tegra20-dsi"; + reg = <0x54300000 0x00040000>; + status = "disabled"; + }; + }; + + ... +}; diff --git a/Documentation/devicetree/bindings/hwmon/vexpress.txt b/Documentation/devicetree/bindings/hwmon/vexpress.txt new file mode 100644 index 000000000000..9c27ed694bbb --- /dev/null +++ b/Documentation/devicetree/bindings/hwmon/vexpress.txt @@ -0,0 +1,23 @@ +Versatile Express hwmon sensors +------------------------------- + +Requires node properties: +- "compatible" value : one of + "arm,vexpress-volt" + "arm,vexpress-amp" + "arm,vexpress-temp" + "arm,vexpress-power" + "arm,vexpress-energy" +- "arm,vexpress-sysreg,func" when controlled via vexpress-sysreg + (see Documentation/devicetree/bindings/arm/vexpress-sysreg.txt + for more details) + +Optional node properties: +- label : string describing the monitored value + +Example: + energy@0 { + compatible = "arm,vexpress-energy"; + arm,vexpress-sysreg,func = <13 0>; + label = "A15 Jcore"; + }; 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 000000000000..e9de3756752b --- /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/atmel-i2c.txt b/Documentation/devicetree/bindings/i2c/i2c-at91.txt index b689a0d9441c..b689a0d9441c 100644 --- a/Documentation/devicetree/bindings/i2c/atmel-i2c.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-at91.txt diff --git a/Documentation/devicetree/bindings/i2c/i2c-cbus-gpio.txt b/Documentation/devicetree/bindings/i2c/i2c-cbus-gpio.txt new file mode 100644 index 000000000000..8ce9cd2855b5 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/i2c-cbus-gpio.txt @@ -0,0 +1,27 @@ +Device tree bindings for i2c-cbus-gpio driver + +Required properties: + - compatible = "i2c-cbus-gpio"; + - gpios: clk, dat, sel + - #address-cells = <1>; + - #size-cells = <0>; + +Optional properties: + - child nodes conforming to i2c bus binding + +Example: + +i2c@0 { + compatible = "i2c-cbus-gpio"; + gpios = <&gpio 66 0 /* clk */ + &gpio 65 0 /* dat */ + &gpio 64 0 /* sel */ + >; + #address-cells = <1>; + #size-cells = <0>; + + retu-mfd: retu@1 { + compatible = "retu-mfd"; + reg = <0x1>; + }; +}; diff --git a/Documentation/devicetree/bindings/i2c/davinci.txt b/Documentation/devicetree/bindings/i2c/i2c-davinci.txt index 2dc935b4113d..2dc935b4113d 100644 --- a/Documentation/devicetree/bindings/i2c/davinci.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-davinci.txt diff --git a/Documentation/devicetree/bindings/i2c/gpio-i2c.txt b/Documentation/devicetree/bindings/i2c/i2c-gpio.txt index 4f8ec947c6bd..4f8ec947c6bd 100644 --- a/Documentation/devicetree/bindings/i2c/gpio-i2c.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-gpio.txt diff --git a/Documentation/devicetree/bindings/i2c/fsl-imx-i2c.txt b/Documentation/devicetree/bindings/i2c/i2c-imx.txt index f3cf43b66f7e..3614242e7732 100644 --- a/Documentation/devicetree/bindings/i2c/fsl-imx-i2c.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-imx.txt @@ -12,13 +12,13 @@ Optional properties: Examples: i2c@83fc4000 { /* I2C2 on i.MX51 */ - compatible = "fsl,imx51-i2c", "fsl,imx1-i2c"; + compatible = "fsl,imx51-i2c", "fsl,imx21-i2c"; reg = <0x83fc4000 0x4000>; interrupts = <63>; }; i2c@70038000 { /* HS-I2C on i.MX51 */ - compatible = "fsl,imx51-i2c", "fsl,imx1-i2c"; + compatible = "fsl,imx51-i2c", "fsl,imx21-i2c"; reg = <0x70038000 0x4000>; interrupts = <64>; clock-frequency = <400000>; diff --git a/Documentation/devicetree/bindings/i2c/fsl-i2c.txt b/Documentation/devicetree/bindings/i2c/i2c-mpc.txt index 1eacd6b20ed5..1eacd6b20ed5 100644 --- a/Documentation/devicetree/bindings/i2c/fsl-i2c.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-mpc.txt diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-gpio.txt b/Documentation/devicetree/bindings/i2c/i2c-mux-gpio.txt new file mode 100644 index 000000000000..66709a825541 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/i2c-mux-gpio.txt @@ -0,0 +1,81 @@ +GPIO-based I2C Bus Mux + +This binding describes an I2C bus multiplexer that uses GPIOs to +route the I2C signals. + + +-----+ +-----+ + | dev | | dev | + +------------+ +-----+ +-----+ + | SoC | | | + | | /--------+--------+ + | +------+ | +------+ child bus A, on GPIO value set to 0 + | | I2C |-|--| Mux | + | +------+ | +--+---+ child bus B, on GPIO value set to 1 + | | | \----------+--------+--------+ + | +------+ | | | | | + | | GPIO |-|-----+ +-----+ +-----+ +-----+ + | +------+ | | dev | | dev | | dev | + +------------+ +-----+ +-----+ +-----+ + +Required properties: +- compatible: i2c-mux-gpio +- i2c-parent: The phandle of the I2C bus that this multiplexer's master-side + port is connected to. +- mux-gpios: list of gpios used to control the muxer +* Standard I2C mux properties. See mux.txt in this directory. +* I2C child bus nodes. See mux.txt in this directory. + +Optional properties: +- idle-state: value to set the muxer to when idle. When no value is + given, it defaults to the last value used. + +For each i2c child node, an I2C child bus will be created. They will +be numbered based on their order in the device tree. + +Whenever an access is made to a device on a child bus, the value set +in the revelant node's reg property will be output using the list of +GPIOs, the first in the list holding the least-significant value. + +If an idle state is defined, using the idle-state (optional) property, +whenever an access is not being made to a device on a child bus, the +GPIOs will be set according to the idle value. + +If an idle state is not defined, the most recently used value will be +left programmed into hardware whenever no access is being made to a +device on a child bus. + +Example: + i2cmux { + compatible = "i2c-mux-gpio"; + #address-cells = <1>; + #size-cells = <0>; + mux-gpios = <&gpio1 22 0 &gpio1 23 0>; + i2c-parent = <&i2c1>; + + i2c@1 { + reg = <1>; + #address-cells = <1>; + #size-cells = <0>; + + ssd1307: oled@3c { + compatible = "solomon,ssd1307fb-i2c"; + reg = <0x3c>; + pwms = <&pwm 4 3000>; + reset-gpios = <&gpio2 7 1>; + reset-active-low; + }; + }; + + i2c@3 { + reg = <3>; + #address-cells = <1>; + #size-cells = <0>; + + pca9555: pca9555@20 { + compatible = "nxp,pca9555"; + gpio-controller; + #gpio-cells = <2>; + reg = <0x20>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/i2c/mux.txt b/Documentation/devicetree/bindings/i2c/i2c-mux.txt index af84cce5cd7b..af84cce5cd7b 100644 --- a/Documentation/devicetree/bindings/i2c/mux.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-mux.txt diff --git a/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt b/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt new file mode 100644 index 000000000000..f46d928aa73d --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt @@ -0,0 +1,18 @@ + +* Marvell MV64XXX I2C controller + +Required properties : + + - 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. + +Examples: + + i2c@11000 { + compatible = "marvell,mv64xxx-i2c"; + reg = <0x11000 0x20>; + interrupts = <29>; + clock-frequency = <100000>; + }; diff --git a/Documentation/devicetree/bindings/i2c/nomadik.txt b/Documentation/devicetree/bindings/i2c/i2c-nomadik.txt index 72065b0ff680..72065b0ff680 100644 --- a/Documentation/devicetree/bindings/i2c/nomadik.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-nomadik.txt diff --git a/Documentation/devicetree/bindings/i2c/i2c-ocores.txt b/Documentation/devicetree/bindings/i2c/i2c-ocores.txt index c15781f4dc8c..1637c298a1b3 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-ocores.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-ocores.txt @@ -1,7 +1,7 @@ Device tree configuration for i2c-ocores Required properties: -- compatible : "opencores,i2c-ocores" +- compatible : "opencores,i2c-ocores" or "aeroflexgaisler,i2cmst" - reg : bus address start and address range size of device - interrupts : interrupt number - clock-frequency : frequency of bus clock in Hz diff --git a/Documentation/devicetree/bindings/i2c/cavium-i2c.txt b/Documentation/devicetree/bindings/i2c/i2c-octeon.txt index dced82ebe31d..dced82ebe31d 100644 --- a/Documentation/devicetree/bindings/i2c/cavium-i2c.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-octeon.txt diff --git a/Documentation/devicetree/bindings/i2c/omap-i2c.txt b/Documentation/devicetree/bindings/i2c/i2c-omap.txt index 56564aa4b444..56564aa4b444 100644 --- a/Documentation/devicetree/bindings/i2c/omap-i2c.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-omap.txt diff --git a/Documentation/devicetree/bindings/i2c/pnx.txt b/Documentation/devicetree/bindings/i2c/i2c-pnx.txt index fe98ada33ee4..fe98ada33ee4 100644 --- a/Documentation/devicetree/bindings/i2c/pnx.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-pnx.txt diff --git a/Documentation/devicetree/bindings/i2c/ce4100-i2c.txt b/Documentation/devicetree/bindings/i2c/i2c-pxa-pci-ce4100.txt index 569b16248514..569b16248514 100644 --- a/Documentation/devicetree/bindings/i2c/ce4100-i2c.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-pxa-pci-ce4100.txt diff --git a/Documentation/devicetree/bindings/i2c/mrvl-i2c.txt b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt index 0f7945019f6f..12b78ac507e9 100644 --- a/Documentation/devicetree/bindings/i2c/mrvl-i2c.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt @@ -31,21 +31,3 @@ Examples: reg = <0xd4025000 0x1000>; interrupts = <58>; }; - -* Marvell MV64XXX I2C controller - -Required properties : - - - 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. - -Examples: - - i2c@11000 { - compatible = "marvell,mv64xxx-i2c"; - reg = <0x11000 0x20>; - interrupts = <29>; - clock-frequency = <100000>; - }; diff --git a/Documentation/devicetree/bindings/i2c/samsung-i2c.txt b/Documentation/devicetree/bindings/i2c/i2c-s3c2410.txt index b6cb5a12c672..f98d4c5b5cca 100644 --- a/Documentation/devicetree/bindings/i2c/samsung-i2c.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-s3c2410.txt @@ -8,16 +8,24 @@ Required properties: (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. - samsung,i2c-sda-delay: Delay (in ns) applied to data line (SDA) edges. +Required for all cases except "samsung,s3c2440-hdmiphy-i2c": + - Samsung GPIO variant (deprecated): + - gpios: The order of the gpios should be the following: <SDA, SCL>. + The gpio specifier depends on the gpio controller. Required in all + cases except for "samsung,s3c2440-hdmiphy-i2c" whose input/output + lines are permanently wired to the respective clienta + - Pinctrl variant (preferred, if available): + - pinctrl-0: Pin control group to be used for this controller. + - pinctrl-names: Should contain only one value - "default". + Optional properties: - - gpios: The order of the gpios should be the following: <SDA, SCL>. - The gpio specifier depends on the gpio controller. Required in all - cases except for "samsung,s3c2440-hdmiphy-i2c" whose input/output - lines are permanently wired to the respective client - samsung,i2c-slave-addr: Slave address in multi-master enviroment. If not specified, default value is 0. - samsung,i2c-max-bus-freq: Desired frequency in Hz of the bus. If not @@ -31,8 +39,14 @@ Example: interrupts = <345>; samsung,i2c-sda-delay = <100>; samsung,i2c-max-bus-freq = <100000>; + /* Samsung GPIO variant begins here */ gpios = <&gpd1 2 0 /* SDA */ &gpd1 3 0 /* SCL */>; + /* Samsung GPIO variant ends here */ + /* Pinctrl variant begins here */ + pinctrl-0 = <&i2c3_bus>; + pinctrl-names = "default"; + /* Pinctrl variant ends here */ #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/i2c/sirf-i2c.txt b/Documentation/devicetree/bindings/i2c/i2c-sirf.txt index 7baf9e133fa8..7baf9e133fa8 100644 --- a/Documentation/devicetree/bindings/i2c/sirf-i2c.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-sirf.txt diff --git a/Documentation/devicetree/bindings/i2c/arm-versatile.txt b/Documentation/devicetree/bindings/i2c/i2c-versatile.txt index 361d31c51b6f..361d31c51b6f 100644 --- a/Documentation/devicetree/bindings/i2c/arm-versatile.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-versatile.txt diff --git a/Documentation/devicetree/bindings/i2c/xiic.txt b/Documentation/devicetree/bindings/i2c/i2c-xiic.txt index ceabbe91ae44..ceabbe91ae44 100644 --- a/Documentation/devicetree/bindings/i2c/xiic.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-xiic.txt diff --git a/Documentation/devicetree/bindings/i2c/ina209.txt b/Documentation/devicetree/bindings/i2c/ina209.txt new file mode 100644 index 000000000000..9dd2bee80840 --- /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/max6697.txt b/Documentation/devicetree/bindings/i2c/max6697.txt new file mode 100644 index 000000000000..5f793998e4a4 --- /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/trivial-devices.txt b/Documentation/devicetree/bindings/i2c/trivial-devices.txt index 2f5322b119eb..446859fcdca4 100644 --- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt +++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt @@ -55,5 +55,7 @@ st-micro,24c256 i2c serial eeprom (24cxx) stm,m41t00 Serial Access TIMEKEEPER stm,m41t62 Serial real-time clock (RTC) with alarm stm,m41t80 M41T80 - SERIAL ACCESS RTC WITH ALARMS +taos,tsl2550 Ambient Light Sensor with SMBUS/Two Wire Serial Interface ti,tsc2003 I2C Touch-Screen Controller ti,tmp102 Low Power Digital Temperature Sensor with SMBUS/Two Wire Serial Interface +ti,tmp275 Digital Temperature Sensor diff --git a/Documentation/devicetree/bindings/input/lpc32xx-key.txt b/Documentation/devicetree/bindings/input/lpc32xx-key.txt index 31afd5014c48..bcf62f856358 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 3cd8b98ccd2d..c54919fad17e 100644 --- a/Documentation/devicetree/bindings/input/matrix-keymap.txt +++ b/Documentation/devicetree/bindings/input/matrix-keymap.txt @@ -9,6 +9,12 @@ Required properties: 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 @@ word for the modifier other from "Fn". Example: linux,keymap = < 0x00030012 0x0102003a >; + keypad,num-rows = <2>; + keypad,num-columns = <8>; diff --git a/Documentation/devicetree/bindings/input/omap-keypad.txt b/Documentation/devicetree/bindings/input/omap-keypad.txt index f2fa5e10493d..34ed1c60ff95 100644 --- a/Documentation/devicetree/bindings/input/omap-keypad.txt +++ b/Documentation/devicetree/bindings/input/omap-keypad.txt @@ -6,19 +6,16 @@ A key can be placed at each intersection of a unique row and a unique column. 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 000000000000..3029c5694cf6 --- /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/tca8418_keypad.txt b/Documentation/devicetree/bindings/input/tca8418_keypad.txt index 2a1538f0053f..255185009167 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/touchscreen/auo_pixcir_ts.txt b/Documentation/devicetree/bindings/input/touchscreen/auo_pixcir_ts.txt new file mode 100644 index 000000000000..f40f21c642b9 --- /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/bu21013.txt b/Documentation/devicetree/bindings/input/touchscreen/bu21013.txt new file mode 100644 index 000000000000..ca5a2c86480c --- /dev/null +++ b/Documentation/devicetree/bindings/input/touchscreen/bu21013.txt @@ -0,0 +1,28 @@ +* Rohm BU21013 Touch Screen + +Required properties: + - compatible : "rohm,bu21013_tp" + - reg : I2C device address + +Optional properties: + - touch-gpio : GPIO pin registering a touch event + - <supply_name>-supply : Phandle to a regulator supply + - rohm,touch-max-x : Maximum outward permitted limit in the X axis + - rohm,touch-max-y : Maximum outward permitted limit in the Y axis + - rohm,flip-x : Flip touch coordinates on the X axis + - rohm,flip-y : Flip touch coordinates on the Y axis + +Example: + + i2c@80110000 { + bu21013_tp@0x5c { + compatible = "rohm,bu21013_tp"; + reg = <0x5c>; + touch-gpio = <&gpio2 20 0x4>; + avdd-supply = <&ab8500_ldo_aux1_reg>; + + rohm,touch-max-x = <384>; + rohm,touch-max-y = <704>; + rohm,flip-y; + }; + }; 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 000000000000..64ad48b824a2 --- /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/interrupt-controller/allwinner,sunxi-ic.txt b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sunxi-ic.txt new file mode 100644 index 000000000000..7f9fb85f5456 --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sunxi-ic.txt @@ -0,0 +1,104 @@ +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/leds/common.txt b/Documentation/devicetree/bindings/leds/common.txt new file mode 100644 index 000000000000..2d88816dd550 --- /dev/null +++ b/Documentation/devicetree/bindings/leds/common.txt @@ -0,0 +1,23 @@ +Common leds properties. + +Optional properties for child nodes: +- label : The label for this LED. If omitted, the label is + taken from the node name (excluding the unit address). + +- linux,default-trigger : This parameter, if present, is a + string defining the trigger assigned to the LED. Current triggers are: + "backlight" - LED will act as a back-light, controlled by the framebuffer + system + "default-on" - LED will turn on (but for leds-gpio see "default-state" + property in Documentation/devicetree/bindings/gpio/led.txt) + "heartbeat" - LED "double" flashes at a load average based rate + "ide-disk" - LED indicates disk activity + "timer" - LED flashes at a fixed, configurable rate + +Examples: + +system-status { + label = "Status"; + linux,default-trigger = "heartbeat"; + ... +}; diff --git a/Documentation/devicetree/bindings/gpio/led.txt b/Documentation/devicetree/bindings/leds/leds-gpio.txt index edc83c1c0d54..df1b3080f6b8 100644 --- a/Documentation/devicetree/bindings/gpio/led.txt +++ b/Documentation/devicetree/bindings/leds/leds-gpio.txt @@ -10,16 +10,10 @@ LED sub-node properties: - gpios : Should specify the LED's GPIO, see "gpios property" in Documentation/devicetree/bindings/gpio/gpio.txt. Active low LEDs should be indicated using flags in the GPIO specifier. -- label : (optional) The label for this LED. If omitted, the label is - taken from the node name (excluding the unit address). -- linux,default-trigger : (optional) This parameter, if present, is a - string defining the trigger assigned to the LED. Current triggers are: - "backlight" - LED will act as a back-light, controlled by the framebuffer - system - "default-on" - LED will turn on, but see "default-state" below - "heartbeat" - LED "double" flashes at a load average based rate - "ide-disk" - LED indicates disk activity - "timer" - LED flashes at a fixed, configurable rate +- label : (optional) + see Documentation/devicetree/bindings/leds/common.txt +- linux,default-trigger : (optional) + see Documentation/devicetree/bindings/leds/common.txt - default-state: (optional) The initial state of the LED. Valid values are "on", "off", and "keep". If the LED is already on or off and the default-state property is set the to same value, then no diff --git a/Documentation/devicetree/bindings/leds/leds-ns2.txt b/Documentation/devicetree/bindings/leds/leds-ns2.txt new file mode 100644 index 000000000000..aef3aca34d2d --- /dev/null +++ b/Documentation/devicetree/bindings/leds/leds-ns2.txt @@ -0,0 +1,26 @@ +Binding for dual-GPIO LED found on Network Space v2 (and parents). + +Required properties: +- compatible: "lacie,ns2-leds". + +Each LED is represented as a sub-node of the ns2-leds device. + +Required sub-node properties: +- cmd-gpio: Command LED GPIO. See OF device-tree GPIO specification. +- slow-gpio: Slow LED GPIO. See OF device-tree GPIO specification. + +Optional sub-node properties: +- label: Name for this LED. If omitted, the label is taken from the node name. +- linux,default-trigger: Trigger assigned to the LED. + +Example: + +ns2-leds { + compatible = "lacie,ns2-leds"; + + blue-sata { + label = "ns2:blue:sata"; + slow-gpio = <&gpio0 29 0>; + cmd-gpio = <&gpio0 30 0>; + }; +}; diff --git a/Documentation/devicetree/bindings/leds/leds-pwm.txt b/Documentation/devicetree/bindings/leds/leds-pwm.txt new file mode 100644 index 000000000000..7297107cf832 --- /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 000000000000..2b6693b972fb --- /dev/null +++ b/Documentation/devicetree/bindings/leds/tca6507.txt @@ -0,0 +1,33 @@ +LEDs conected 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/media/gpio-ir-receiver.txt b/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt new file mode 100644 index 000000000000..56e726ef4bf2 --- /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/s5p-mfc.txt b/Documentation/devicetree/bindings/media/s5p-mfc.txt new file mode 100644 index 000000000000..67ec3d4ccc7f --- /dev/null +++ b/Documentation/devicetree/bindings/media/s5p-mfc.txt @@ -0,0 +1,23 @@ +* Samsung Multi Format Codec (MFC) + +Multi Format Codec (MFC) is the IP present in Samsung SoCs which +supports high resolution decoding and encoding functionalities. +The MFC device driver is a v4l2 driver which can encode/decode +video raw/elementary streams and has support for all popular +video codecs. + +Required properties: + - compatible : value should be either one among the following + (a) "samsung,mfc-v5" for MFC v5 present in Exynos4 SoCs + (b) "samsung,mfc-v6" for MFC v6 present in Exynos5 SoCs + + - reg : Physical base address of the IP registers and length of memory + mapped region. + + - interrupts : MFC interrupt number to the CPU. + + - 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. diff --git a/Documentation/devicetree/bindings/metag/meta-intc.txt b/Documentation/devicetree/bindings/metag/meta-intc.txt new file mode 100644 index 000000000000..8c47dcbfabc6 --- /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 interupt 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/mfd/ab8500.txt b/Documentation/devicetree/bindings/mfd/ab8500.txt index ce83c8d3c00e..c3a14e0ad0ad 100644 --- a/Documentation/devicetree/bindings/mfd/ab8500.txt +++ b/Documentation/devicetree/bindings/mfd/ab8500.txt @@ -13,9 +13,6 @@ Required parent device properties: 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 @@ -24,7 +21,32 @@ ab8500-bm : : : Battery Manager ab8500-btemp : : : Battery Temperature ab8500-charger : : : Battery Charger ab8500-codec : : : Audio Codec -ab8500-fg : : : Fuel Gauge +ab8500-fg : : vddadc : Fuel Gauge + : NCONV_ACCU : : Accumulate N Sample Conversion + : BATT_OVV : : Battery Over Voltage + : LOW_BAT_F : : LOW threshold battery voltage + : CC_INT_CALIB : : Coulomb Counter Internal Calibration + : CCEOC : : Coulomb Counter End of Conversion +ab8500-btemp : : vtvout : Battery Temperature + : BAT_CTRL_INDB : : Battery Removal Indicator + : BTEMP_LOW : : Btemp < BtempLow, if battery temperature is lower than -10°C + : BTEMP_LOW_MEDIUM : : BtempLow < Btemp < BtempMedium,if battery temperature is between -10 and 0°C + : BTEMP_MEDIUM_HIGH : : BtempMedium < Btemp < BtempHigh,if battery temperature is between 0°C and“MaxTemp + : BTEMP_HIGH : : Btemp > BtempHigh, if battery temperature is higher than “MaxTemp +ab8500-charger : : vddadc : Charger interface + : MAIN_CH_UNPLUG_DET : : main charger unplug detection management (not in 8505) + : MAIN_CHARGE_PLUG_DET : : main charger plug detection management (not in 8505) + : MAIN_EXT_CH_NOT_OK : : main charger not OK + : MAIN_CH_TH_PROT_R : : Die temp is above main charger + : MAIN_CH_TH_PROT_F : : Die temp is below main charger + : VBUS_DET_F : : VBUS falling detected + : VBUS_DET_R : : VBUS rising detected + : USB_LINK_STATUS : : USB link status has changed + : USB_CH_TH_PROT_R : : Die temp is above usb charger + : USB_CH_TH_PROT_F : : Die temp is below usb charger + : USB_CHARGER_NOT_OKR : : allowed USB charger not ok detection + : VBUS_OVV : : Overvoltage on Vbus ball detected (USB charge is stopped) + : CH_WD_EXP : : Charger watchdog detected ab8500-gpadc : HW_CONV_END : vddadc : Analogue to Digital Converter SW_CONV_END : : ab8500-gpio : : : GPIO Controller @@ -61,9 +83,8 @@ Non-standard child device properties: - 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>; diff --git a/Documentation/devicetree/bindings/mfd/max8925.txt b/Documentation/devicetree/bindings/mfd/max8925.txt new file mode 100644 index 000000000000..4f0dc6638e5e --- /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/stmpe.txt b/Documentation/devicetree/bindings/mfd/stmpe.txt new file mode 100644 index 000000000000..56edb5520685 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/stmpe.txt @@ -0,0 +1,28 @@ +* ST Microelectronics STMPE Multi-Functional Device + +STMPE is an MFD device which may expose the following inbuilt devices: gpio, +keypad, touchscreen, adc, pwm, rotator. + +Required properties: + - compatible : "st,stmpe[610|801|811|1601|2401|2403]" + - reg : I2C/SPI address of the device + +Optional properties: + - interrupts : The interrupt outputs from the controller + - interrupt-controller : Marks the device node as an interrupt controller + - interrupt-parent : Specifies which IRQ controller we're connected to + - wakeup-source : Marks the input device as wakable + - st,autosleep-timeout : Valid entries (ms); 4, 16, 32, 64, 128, 256, 512 and 1024 + +Example: + + stmpe1601: stmpe1601@40 { + compatible = "st,stmpe1601"; + reg = <0x40>; + interrupts = <26 0x4>; + interrupt-parent = <&gpio6>; + interrupt-controller; + + wakeup-source; + st,autosleep-timeout = <1024>; + }; diff --git a/Documentation/devicetree/bindings/mfd/tps6507x.txt b/Documentation/devicetree/bindings/mfd/tps6507x.txt new file mode 100755 index 000000000000..8fffa3c5ed40 --- /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/mips/cavium/dma-engine.txt b/Documentation/devicetree/bindings/mips/cavium/dma-engine.txt index cb4291e3b1d1..a5bdff400002 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 000000000000..13aa4b62c62a --- /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/misc/atmel-ssc.txt b/Documentation/devicetree/bindings/misc/atmel-ssc.txt new file mode 100644 index 000000000000..38e51ad2e07e --- /dev/null +++ b/Documentation/devicetree/bindings/misc/atmel-ssc.txt @@ -0,0 +1,15 @@ +* Atmel SSC driver. + +Required properties: +- compatible: "atmel,at91rm9200-ssc" or "atmel,at91sam9g45-ssc" + - atmel,at91rm9200-ssc: support pdc transfer + - atmel,at91sam9g45-ssc: support dma transfer +- reg: Should contain SSC registers location and length +- interrupts: Should contain SSC interrupt + +Example: +ssc0: ssc@fffbc000 { + compatible = "atmel,at91rm9200-ssc"; + reg = <0xfffbc000 0x4000>; + interrupts = <14 4 5>; +}; 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 000000000000..59476fbdbfa1 --- /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/exynos-dw-mshc.txt b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt index 792768953330..6d1c0988cfc7 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/mmc.txt b/Documentation/devicetree/bindings/mmc/mmc.txt index 8e2e0ba2f486..85aada2263d5 100644 --- a/Documentation/devicetree/bindings/mmc/mmc.txt +++ b/Documentation/devicetree/bindings/mmc/mmc.txt @@ -6,21 +6,49 @@ Interpreted by the OF core: - 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 + +*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 +- enable-sdio-wakeup: Enables wake up of host system on SDIO IRQ assertion Example: @@ -33,4 +61,6 @@ sdhci@ab000000 { cd-inverted; wp-gpios = <&gpio 70 0>; max-frequency = <50000000>; + keep-power-in-suspend; + enable-sdio-wakeup; } diff --git a/Documentation/devicetree/bindings/mmc/orion-sdio.txt b/Documentation/devicetree/bindings/mmc/orion-sdio.txt new file mode 100644 index 000000000000..84f0ebd67a13 --- /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/samsung-sdhci.txt b/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt index 630a7d7f4718..3b3a1ee055ff 100644 --- a/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt +++ b/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt @@ -12,10 +12,6 @@ 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. -[B] If core card-detect bindings and "samsung,cd-pinmux-gpio" property - is not specified, it is assumed that there is no card detection - mechanism used. - Required SoC Specific Properties: - compatible: should be one of the following - "samsung,s3c6410-sdhci": For controllers compatible with s3c6410 sdhci @@ -24,14 +20,18 @@ Required SoC Specific Properties: controller. Required Board Specific Properties: -- gpios: Should specify the gpios used for clock, command and data lines. The - gpio specifier format depends on the gpio controller. +- 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. + used. Only for Samsung GPIO variant. Example: sdhci@12530000 { @@ -40,14 +40,20 @@ Example: 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>; + pinctrl-names = "default"; }; 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/synposis-dw-mshc.txt b/Documentation/devicetree/bindings/mmc/synopsis-dw-mshc.txt index 06cd32d08052..726fd2122a13 100644 --- a/Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt +++ b/Documentation/devicetree/bindings/mmc/synopsis-dw-mshc.txt @@ -26,8 +26,16 @@ Required Properties: * 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: diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt index be76a23b34c4..ed271fc255b2 100644 --- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt @@ -19,6 +19,7 @@ ti,dual-volt: boolean, supports dual voltage cards "supply-name" examples are "vmmc", "vmmc_aux" etc ti,non-removable: non-removable slot (like eMMC) ti,needs-special-reset: Requires a special softreset sequence +ti,needs-special-hs-handling: HSMMC IP needs special setting for handling High Speed Example: mmc1: mmc@0x4809c000 { diff --git a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt new file mode 100644 index 000000000000..df204e18e030 --- /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/mmc/vt8500-sdmmc.txt b/Documentation/devicetree/bindings/mmc/vt8500-sdmmc.txt new file mode 100644 index 000000000000..d7fb6abb3eb8 --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/vt8500-sdmmc.txt @@ -0,0 +1,23 @@ +* Wondermedia WM8505/WM8650 SD/MMC Host Controller + +This file documents differences between the core properties described +by mmc.txt and the properties used by the wmt-sdmmc driver. + +Required properties: +- compatible: Should be "wm,wm8505-sdhc". +- interrupts: Two interrupts are required - regular irq and dma irq. + +Optional properties: +- sdon-inverted: SD_ON bit is inverted on the controller + +Examples: + +sdhc@d800a000 { + compatible = "wm,wm8505-sdhc"; + reg = <0xd800a000 0x1000>; + interrupts = <20 21>; + clocks = <&sdhc>; + bus-width = <4>; + sdon-inverted; +}; + diff --git a/Documentation/devicetree/bindings/mtd/denali-nand.txt b/Documentation/devicetree/bindings/mtd/denali-nand.txt new file mode 100644 index 000000000000..b04d03a1d499 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/denali-nand.txt @@ -0,0 +1,23 @@ +* Denali NAND controller + +Required properties: + - compatible : should be "denali,denali-nand-dt" + - reg : should contain registers location and length for data and reg. + - reg-names: Should contain the reg names "nand_data" and "denali_reg" + - interrupts : The interrupt number. + - dm-mask : DMA bit mask + +The device tree may optionally contain sub-nodes describing partitions of the +address space. See partition.txt for more detail. + +Examples: + +nand: nand@ff900000 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "denali,denali-nand-dt"; + reg = <0xff900000 0x100000>, <0xffb80000 0x10000>; + reg-names = "nand_data", "denali_reg"; + interrupts = <0 144 4>; + dma-mask = <0xffffffff>; +}; diff --git a/Documentation/devicetree/bindings/mtd/elm.txt b/Documentation/devicetree/bindings/mtd/elm.txt new file mode 100644 index 000000000000..8c1528c421d4 --- /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/flctl-nand.txt b/Documentation/devicetree/bindings/mtd/flctl-nand.txt new file mode 100644 index 000000000000..427f46dc60ad --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/flctl-nand.txt @@ -0,0 +1,49 @@ +FLCTL NAND controller + +Required properties: +- compatible : "renesas,shmobile-flctl-sh7372" +- reg : Address range of the FLCTL +- interrupts : flste IRQ number +- nand-bus-width : bus width to NAND chip + +Optional properties: +- dmas: DMA specifier(s) +- dma-names: name for each DMA specifier. Valid names are + "data_tx", "data_rx", "ecc_tx", "ecc_rx" + +The DMA fields are not used yet in the driver but are listed here for +completing the bindings. + +The device tree may optionally contain sub-nodes describing partitions of the +address space. See partition.txt for more detail. + +Example: + + flctl@e6a30000 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "renesas,shmobile-flctl-sh7372"; + reg = <0xe6a30000 0x100>; + interrupts = <0x0d80>; + + nand-bus-width = <16>; + + dmas = <&dmac 1 /* data_tx */ + &dmac 2;> /* data_rx */ + dma-names = "data_tx", "data_rx"; + + system@0 { + label = "system"; + reg = <0x0 0x8000000>; + }; + + userdata@8000000 { + label = "userdata"; + reg = <0x8000000 0x10000000>; + }; + + cache@18000000 { + label = "cache"; + reg = <0x18000000 0x8000000>; + }; + }; diff --git a/Documentation/devicetree/bindings/mtd/fsmc-nand.txt b/Documentation/devicetree/bindings/mtd/fsmc-nand.txt index e2c663b354d2..2240ac09f6ba 100644 --- a/Documentation/devicetree/bindings/mtd/fsmc-nand.txt +++ b/Documentation/devicetree/bindings/mtd/fsmc-nand.txt @@ -1,11 +1,9 @@ * 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" and "nand_data" -- st,ale-off : Chip specific offset to ALE -- st,cle-off : Chip specific offset to CLE +- reg-names: Should contain the reg names "fsmc_regs", "nand_data", "nand_addr" and "nand_cmd" Optional properties: - bank-width : Width (in bytes) of the device. If not present, the width @@ -19,10 +17,10 @@ Example: #address-cells = <1>; #size-cells = <1>; reg = <0xd1800000 0x1000 /* FSMC Register */ - 0xd2000000 0x4000>; /* NAND Base */ - reg-names = "fsmc_regs", "nand_data"; - st,ale-off = <0x20000>; - st,cle-off = <0x10000>; + 0xd2000000 0x0010 /* NAND Base DATA */ + 0xd2020000 0x0010 /* NAND Base ADDR */ + 0xd2010000 0x0010>; /* NAND Base CMD */ + reg-names = "fsmc_regs", "nand_data", "nand_addr", "nand_cmd"; bank-width = <1>; nand-skip-bbtscan; diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt new file mode 100644 index 000000000000..e7f8d7ed47eb --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt @@ -0,0 +1,80 @@ +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 + + - 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"; + + gpmc,sync-clk = <0>; + gpmc,cs-on = <0>; + gpmc,cs-rd-off = <44>; + gpmc,cs-wr-off = <44>; + gpmc,adv-on = <6>; + gpmc,adv-rd-off = <34>; + gpmc,adv-wr-off = <44>; + gpmc,we-off = <40>; + gpmc,oe-off = <54>; + gpmc,access = <64>; + gpmc,rd-cycle = <82>; + gpmc,wr-cycle = <82>; + gpmc,wr-access = <40>; + gpmc,wr-data-mux-bus = <0>; + + #address-cells = <1>; + #size-cells = <1>; + + /* partitions go here */ + }; + }; + diff --git a/Documentation/devicetree/bindings/mtd/gpmc-onenand.txt b/Documentation/devicetree/bindings/mtd/gpmc-onenand.txt new file mode 100644 index 000000000000..deec9da224a2 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/gpmc-onenand.txt @@ -0,0 +1,43 @@ +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 + +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 */ + + #address-cells = <1>; + #size-cells = <1>; + + /* partitions go here */ + }; + }; diff --git a/Documentation/devicetree/bindings/mtd/m25p80.txt b/Documentation/devicetree/bindings/mtd/m25p80.txt new file mode 100644 index 000000000000..6d3d57609470 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/m25p80.txt @@ -0,0 +1,29 @@ +* MTD SPI driver for ST M25Pxx (and similar) serial flash chips + +Required properties: +- #address-cells, #size-cells : Must be present if the device has sub-nodes + representing partitions. +- compatible : Should be the manufacturer and the name of the chip. Bear in mind + the DT binding is not Linux-only, but in case of Linux, see the + "m25p_ids" table in drivers/mtd/devices/m25p80.c for the list of + supported chips. +- reg : Chip-Select number +- spi-max-frequency : Maximum frequency of the SPI bus the chip can operate at + +Optional properties: +- m25p,fast-read : Use the "fast read" opcode to read data from the chip instead + of the usual "read" opcode. This opcode is not supported by + all chips and support for it can not be detected at runtime. + Refer to your chips' datasheet to check if this is supported + by your chip. + +Example: + + flash: m25p80@0 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "spansion,m25p80"; + reg = <0>; + spi-max-frequency = <40000000>; + m25p,fast-read; + }; diff --git a/Documentation/devicetree/bindings/mtd/mtd-physmap.txt b/Documentation/devicetree/bindings/mtd/mtd-physmap.txt index 94de19b8f16b..61c5ec850f2f 100644 --- a/Documentation/devicetree/bindings/mtd/mtd-physmap.txt +++ b/Documentation/devicetree/bindings/mtd/mtd-physmap.txt @@ -23,6 +23,12 @@ file systems on embedded devices. unaligned accesses as implemented in the JFFS2 code via memcpy(). By defining "no-unaligned-direct-access", the flash will not be exposed directly to the MTD users (e.g. JFFS2) any more. + - 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/net/can/grcan.txt b/Documentation/devicetree/bindings/net/can/grcan.txt new file mode 100644 index 000000000000..34ef3498f887 --- /dev/null +++ b/Documentation/devicetree/bindings/net/can/grcan.txt @@ -0,0 +1,28 @@ +Aeroflex Gaisler GRCAN and GRHCAN CAN controllers. + +The GRCAN and CRHCAN CAN controllers are available in the GRLIB VHDL IP core +library. + +Note: These properties are built from the AMBA plug&play in a Leon SPARC system +(the ordinary environment for GRCAN and GRHCAN). There are no dts files for +sparc. + +Required properties: + +- name : Should be "GAISLER_GRCAN", "01_03d", "GAISLER_GRHCAN" or "01_034" + +- reg : Address and length of the register set for the device + +- freq : Frequency of the external oscillator clock in Hz (the frequency of + the amba bus in the ordinary case) + +- interrupts : Interrupt number for this device + +Optional properties: + +- systemid : If not present or if the value of the least significant 16 bits + of this 32-bit property is smaller than GRCAN_TXBUG_SAFE_GRLIB_VERSION + a bug workaround is activated. + +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/net/cdns-emac.txt b/Documentation/devicetree/bindings/net/cdns-emac.txt new file mode 100644 index 000000000000..09055c2495f0 --- /dev/null +++ b/Documentation/devicetree/bindings/net/cdns-emac.txt @@ -0,0 +1,23 @@ +* Cadence EMAC Ethernet controller + +Required properties: +- compatible: Should be "cdns,[<chip>-]{emac}" + Use "cdns,at91rm9200-emac" Atmel at91rm9200 SoC. + or the generic form: "cdns,emac". +- reg: Address and length of the register set for the device +- interrupts: Should contain macb interrupt +- phy-mode: String, operation mode of the PHY interface. + Supported values are: "mii", "rmii". + +Optional properties: +- local-mac-address: 6 bytes, mac address + +Examples: + + macb0: ethernet@fffc4000 { + compatible = "cdns,at91rm9200-emac"; + reg = <0xfffc4000 0x4000>; + interrupts = <21>; + phy-mode = "rmii"; + local-mac-address = [3a 0e 03 04 05 06]; + }; diff --git a/Documentation/devicetree/bindings/net/cpsw.txt b/Documentation/devicetree/bindings/net/cpsw.txt index dcaabe9fe869..ecfdf756d10f 100644 --- a/Documentation/devicetree/bindings/net/cpsw.txt +++ b/Documentation/devicetree/bindings/net/cpsw.txt @@ -9,27 +9,23 @@ Required properties: number - interrupt-parent : The parent interrupt controller - cpdma_channels : Specifies number of channels in CPDMA -- host_port_no : Specifies host port shift -- cpdma_reg_ofs : Specifies CPDMA submodule register offset -- cpdma_sram_ofs : Specifies CPDMA SRAM offset -- ale_reg_ofs : Specifies ALE submodule register offset - ale_entries : Specifies No of entries ALE can hold -- host_port_reg_ofs : Specifies host port register offset -- hw_stats_reg_ofs : Specifies hardware statistics register offset -- bd_ram_ofs : Specifies internal desciptor RAM offset - bd_ram_size : Specifies internal descriptor RAM size - rx_descs : Specifies number of Rx descriptors - mac_control : Specifies Default MAC control register content for the specific platform - slaves : Specifies number for slaves -- slave_reg_ofs : Specifies slave register offset -- sliver_reg_ofs : Specifies slave sliver register offset +- cpts_active_slave : Specifies the slave to use for time stamping +- 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 +- 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,30 +41,22 @@ Examples: interrupts = <55 0x4>; interrupt-parent = <&intc>; cpdma_channels = <8>; - host_port_no = <0>; - cpdma_reg_ofs = <0x800>; - cpdma_sram_ofs = <0xa00>; - ale_reg_ofs = <0xd00>; ale_entries = <1024>; - host_port_reg_ofs = <0x108>; - hw_stats_reg_ofs = <0x900>; - bd_ram_ofs = <0x2000>; bd_ram_size = <0x2000>; no_bd_ram = <0>; rx_descs = <64>; mac_control = <0x20>; slaves = <2>; + cpts_active_slave = <0>; + cpts_clock_mult = <0x80000000>; + cpts_clock_shift = <29>; cpsw_emac0: slave@0 { - slave_reg_ofs = <0x208>; - sliver_reg_ofs = <0xd80>; - phy_id = "davinci_mdio.16:00"; + phy_id = <&davinci_mdio>, <0>; /* Filled in by U-Boot */ mac-address = [ 00 00 00 00 00 00 ]; }; cpsw_emac1: slave@1 { - slave_reg_ofs = <0x308>; - sliver_reg_ofs = <0xdc0>; - phy_id = "davinci_mdio.16:01"; + phy_id = <&davinci_mdio>, <1>; /* Filled in by U-Boot */ mac-address = [ 00 00 00 00 00 00 ]; }; @@ -79,30 +67,22 @@ Examples: compatible = "ti,cpsw"; ti,hwmods = "cpgmac0"; cpdma_channels = <8>; - host_port_no = <0>; - cpdma_reg_ofs = <0x800>; - cpdma_sram_ofs = <0xa00>; - ale_reg_ofs = <0xd00>; ale_entries = <1024>; - host_port_reg_ofs = <0x108>; - hw_stats_reg_ofs = <0x900>; - bd_ram_ofs = <0x2000>; bd_ram_size = <0x2000>; no_bd_ram = <0>; rx_descs = <64>; mac_control = <0x20>; slaves = <2>; + cpts_active_slave = <0>; + cpts_clock_mult = <0x80000000>; + cpts_clock_shift = <29>; cpsw_emac0: slave@0 { - slave_reg_ofs = <0x208>; - sliver_reg_ofs = <0xd80>; - phy_id = "davinci_mdio.16:00"; + phy_id = <&davinci_mdio>, <0>; /* Filled in by U-Boot */ mac-address = [ 00 00 00 00 00 00 ]; }; cpsw_emac1: slave@1 { - slave_reg_ofs = <0x308>; - sliver_reg_ofs = <0xdc0>; - phy_id = "davinci_mdio.16:01"; + phy_id = <&davinci_mdio>, <1>; /* Filled in by U-Boot */ mac-address = [ 00 00 00 00 00 00 ]; }; diff --git a/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt b/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt new file mode 100644 index 000000000000..859a6fa7569c --- /dev/null +++ b/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt @@ -0,0 +1,23 @@ +* Marvell Armada 370 / Armada XP Ethernet Controller (NETA) + +Required properties: +- compatible: should be "marvell,armada-370-neta". +- 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). +- phy-mode: The interface between the SoC and the PHY (a string that + of_get_phy_mode() can understand) +- clocks: a pointer to the reference clock for this device. + +Example: + +ethernet@d0070000 { + compatible = "marvell,armada-370-neta"; + reg = <0xd0070000 0x2500>; + interrupts = <8>; + clocks = <&gate_clk 4>; + status = "okay"; + phy = <&phy0>; + phy-mode = "rgmii-id"; +}; diff --git a/Documentation/devicetree/bindings/net/marvell-orion-mdio.txt b/Documentation/devicetree/bindings/net/marvell-orion-mdio.txt new file mode 100644 index 000000000000..34e7aafa321c --- /dev/null +++ b/Documentation/devicetree/bindings/net/marvell-orion-mdio.txt @@ -0,0 +1,35 @@ +* Marvell MDIO Ethernet Controller interface + +The Ethernet controllers of the Marvel Kirkwood, Dove, Orion5x, +MV78xx0, Armada 370 and Armada XP have an identical unit that provides +an interface with the MDIO bus. This driver handles this MDIO +interface. + +Required properties: +- compatible: "marvell,orion-mdio" +- reg: address and length of the SMI register + +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. + +Example at the SoC level: + +mdio { + #address-cells = <1>; + #size-cells = <0>; + compatible = "marvell,orion-mdio"; + reg = <0xd0072004 0x4>; +}; + +And at the board level: + +mdio { + phy0: ethernet-phy@0 { + reg = <0>; + }; + + phy1: ethernet-phy@1 { + reg = <1>; + }; +} diff --git a/Documentation/devicetree/bindings/net/mdio-gpio.txt b/Documentation/devicetree/bindings/net/mdio-gpio.txt index bc9549529014..c79bab025369 100644 --- a/Documentation/devicetree/bindings/net/mdio-gpio.txt +++ b/Documentation/devicetree/bindings/net/mdio-gpio.txt @@ -8,9 +8,16 @@ gpios property as described in section VIII.1 in the following order: MDC, MDIO. +Note: Each gpio-mdio bus should have an alias correctly numbered in "aliases" +node. + Example: -mdio { +aliases { + mdio-gpio0 = <&mdio0>; +}; + +mdio0: mdio { compatible = "virtual,mdio-gpio"; #address-cells = <1>; #size-cells = <0>; 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 000000000000..dff0e5f995e2 --- /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 new file mode 100644 index 000000000000..bc50899e0c81 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt @@ -0,0 +1,142 @@ +* Atmel AT91 Pinmux Controller + +The AT91 Pinmux Controler, 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 +different PAD settings (like pull up, keeper, etc) the contoller controls +also the PAD settings parameters. + +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". + +Atmel AT91 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, multi drive, etc. + +Required properties for iomux controller: +- compatible: "atmel,at91rm9200-pinctrl" +- atmel,mux-mask: array of mask (periph per bank) to describe if a pin can be + configured in this periph mode. All the periph and bank need to be describe. + +How to create such array: + +Each column will represent the possible peripheral of the pinctrl +Each line will represent a pio bank + +Take an example on the 9260 +Peripheral: 2 ( A and B) +Bank: 3 (A, B and C) +=> + + /* A B */ + 0xffffffff 0xffc00c3b /* pioA */ + 0xffffffff 0x7fff3ccf /* pioB */ + 0xffffffff 0x007fffff /* pioC */ + +For each peripheral/bank we will descibe in a u32 if a pin can can be +configured in it by putting 1 to the pin bit (1 << pin) + +Let's take the pioA on peripheral B +From the datasheet Table 10-2. +Peripheral B +PA0 MCDB0 +PA1 MCCDB +PA2 +PA3 MCDB3 +PA4 MCDB2 +PA5 MCDB1 +PA6 +PA7 +PA8 +PA9 +PA10 ETX2 +PA11 ETX3 +PA12 +PA13 +PA14 +PA15 +PA16 +PA17 +PA18 +PA19 +PA20 +PA21 +PA22 ETXER +PA23 ETX2 +PA24 ETX3 +PA25 ERX2 +PA26 ERX3 +PA27 ERXCK +PA28 ECRS +PA29 ECOL +PA30 RXD4 +PA31 TXD4 + +=> 0xffc00c3b + +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, 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. +MULTIDRIVE (1 << 1): indicate this pin need to be configured as multidrive. +DEGLITCH (1 << 2): indicate this pin need deglitch. +PULL_DOWN (1 << 3): indicate this pin need a pull down. +DIS_SCHMIT (1 << 4): indicate this pin need to disable schmit trigger. +DEBOUNCE (1 << 16): indicate this pin need debounce. +DEBOUNCE_VAL (0x3fff << 17): debounce val. + +NOTE: +Some requirements for using atmel,at91rm9200-pinctrl binding: +1. We have pin function node defined under at91 controller node to represent + what pinmux functions this SoC supports. +2. The driver can use the function node's name and pin configuration node's + name describe the pin function and group hierarchy. + For example, Linux at91 pinctrl driver takes the function node's name + as the function name and pin configuration node's name as group name to + create the map table. +3. Each pin configuration node should have a phandle, devices can set pins + configurations by referring to the phandle of that pin configuration node. +4. The gpio controller must be describe in the pinctrl simple-bus. + +Examples: + +pinctrl@fffff400 { + #address-cells = <1>; + #size-cells = <1>; + ranges; + compatible = "atmel,at91rm9200-pinctrl", "simple-bus"; + reg = <0xfffff400 0x600>; + + atmel,mux-mask = < + /* A B */ + 0xffffffff 0xffc00c3b /* pioA */ + 0xffffffff 0x7fff3ccf /* pioB */ + 0xffffffff 0x007fffff /* pioC */ + >; + + /* shared pinctrl settings */ + dbgu { + pinctrl_dbgu: dbgu-0 { + atmel,pins = + <1 14 0x1 0x0 /* PB14 periph A */ + 1 15 0x1 0x1>; /* PB15 periph A with pullup */ + }; + }; +}; + +dbgu: serial@fffff200 { + compatible = "atmel,at91sam9260-usart"; + reg = <0xfffff200 0x200>; + interrupts = <1 4 7>; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_dbgu>; + status = "disabled"; +}; diff --git a/Documentation/devicetree/bindings/pinctrl/marvell,kirkwood-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/marvell,kirkwood-pinctrl.txt index 361bccb7ec89..95daf6335c37 100644 --- a/Documentation/devicetree/bindings/pinctrl/marvell,kirkwood-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/marvell,kirkwood-pinctrl.txt @@ -7,8 +7,10 @@ Required properties: - compatible: "marvell,88f6180-pinctrl", "marvell,88f6190-pinctrl", "marvell,88f6192-pinctrl", "marvell,88f6281-pinctrl", "marvell,88f6282-pinctrl" + "marvell,98dx4122-pinctrl" This driver supports all kirkwood variants, i.e. 88f6180, 88f619x, and 88f628x. +It also support the 88f6281-based variant in the 98dx412x Bobcat SoCs. Available mpp pins/groups and functions: Note: brackets (x) are not part of the mpp name for marvell,function and given @@ -277,3 +279,40 @@ mpp46 46 gpio, ts(mp10), tdm(fs), lcd(hsync) mpp47 47 gpio, ts(mp11), tdm(drx), lcd(vsync) mpp48 48 gpio, ts(mp12), tdm(dtx), lcd(d16) mpp49 49 gpo, tdm(rx0ql), pex(clkreq), lcd(d17) + +* Marvell Bobcat 98dx4122 + +name pins functions +================================================================================ +mpp0 0 gpio, nand(io2), spi(cs) +mpp1 1 gpo, nand(io3), spi(mosi) +mpp2 2 gpo, nand(io4), spi(sck) +mpp3 3 gpo, nand(io5), spi(miso) +mpp4 4 gpio, nand(io6), uart0(rxd) +mpp5 5 gpo, nand(io7), uart0(txd) +mpp6 6 sysrst(out), spi(mosi) +mpp7 7 gpo, pex(rsto), spi(cs) +mpp8 8 gpio, twsi0(sda), uart0(rts), uart1(rts) +mpp9 9 gpio, twsi(sck), uart0(cts), uart1(cts) +mpp10 10 gpo, spi(sck), uart0(txd) +mpp11 11 gpio, spi(miso), uart0(rxd) +mpp13 13 gpio, uart1(txd) +mpp14 14 gpio, uart1(rxd) +mpp15 15 gpio, uart0(rts) +mpp16 16 gpio, uart0(cts) +mpp18 18 gpo, nand(io0) +mpp19 19 gpo, nand(io1) +mpp34 34 gpio +mpp35 35 gpio +mpp36 36 gpio +mpp37 37 gpio +mpp38 38 gpio +mpp39 39 gpio +mpp40 40 gpio +mpp41 41 gpio +mpp42 42 gpio +mpp43 43 gpio +mpp44 44 gpio +mpp45 45 gpio +mpp49 49 gpio + 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 000000000000..e204d009f16c --- /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-sirf.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-sirf.txt new file mode 100644 index 000000000000..c596a6ad3285 --- /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/samsung-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt index 03dee50532f5..4598a47aa0cd 100644 --- a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt @@ -7,14 +7,21 @@ on-chip controllers onto these pads. Required Properties: - compatible: should be one of the following. - - "samsung,pinctrl-exynos4210": for Exynos4210 compatible pin-controller. - - "samsung,pinctrl-exynos5250": for Exynos5250 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. - reg: Base address of the pin controller hardware module and length of the address space it occupies. -- interrupts: interrupt specifier for the controller. The format and value of - the interrupt specifier depends on the interrupt parent for the controller. +- Pin banks as child nodes: Pin banks of the controller are represented by child + nodes of the controller node. Bank name is taken from name of the node. Each + bank node must contain following properties: + + - 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. - 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 @@ -72,16 +79,24 @@ used as system wakeup events. A. External GPIO Interrupts: For supporting external gpio interrupts, the following properties should be specified in the pin-controller device node. -- interrupt-controller: identifies the controller node as interrupt-parent. -- #interrupt-cells: the value of this property should be 2. - - First Cell: represents the external gpio interrupt number local to the - external gpio interrupt space of the controller. - - Second Cell: flags to identify the type of the interrupt - - 1 = rising edge triggered - - 2 = falling edge triggered - - 3 = rising and falling edge triggered - - 4 = high level triggered - - 8 = low level triggered + - interrupt-parent: phandle of the interrupt parent to which the external + GPIO interrupts are forwarded to. + - interrupts: interrupt specifier for the controller. The format and value of + the interrupt specifier depends on the interrupt parent for the controller. + + In addition, following properties must be present in node of every bank + of pins supporting GPIO interrupts: + + - interrupt-controller: identifies the controller node as interrupt-parent. + - #interrupt-cells: the value of this property should be 2. + - First Cell: represents the external gpio interrupt number local to the + external gpio interrupt space of the controller. + - Second Cell: flags to identify the type of the interrupt + - 1 = rising edge triggered + - 2 = falling edge triggered + - 3 = rising and falling edge triggered + - 4 = high level triggered + - 8 = low level triggered B. External Wakeup Interrupts: For supporting external wakeup interrupts, a child node representing the external wakeup interrupt controller should be @@ -94,6 +109,11 @@ B. External Wakeup Interrupts: For supporting external wakeup interrupts, a found on Samsung Exynos4210 SoC. - interrupt-parent: phandle of the interrupt parent to which the external wakeup interrupts are forwarded to. + - interrupts: interrupt used by multiplexed wakeup interrupts. + + In addition, following properties must be present in node of every bank + of pins supporting wake-up interrupts: + - interrupt-controller: identifies the node as interrupt-parent. - #interrupt-cells: the value of this property should be 2 - First Cell: represents the external wakeup interrupt number local to @@ -105,18 +125,72 @@ B. External Wakeup Interrupts: For supporting external wakeup interrupts, a - 4 = high level triggered - 8 = low level triggered + Node of every bank of pins supporting direct wake-up interrupts (without + multiplexing) must contain following properties: + + - interrupt-parent: phandle of the interrupt parent to which the external + wakeup interrupts are forwarded to. + - interrupts: interrupts of the interrupt parent which are used for external + wakeup interrupts from pins of the bank, must contain interrupts for all + pins of the bank. + Aliases: All the pin controller nodes should be represented in the aliases node using the following format 'pinctrl{n}' where n is a unique number for the alias. +Example: A pin-controller node with pin banks: + + pinctrl_0: pinctrl@11400000 { + compatible = "samsung,exynos4210-pinctrl"; + reg = <0x11400000 0x1000>; + interrupts = <0 47 0>; + + /* ... */ + + /* Pin bank without external interrupts */ + gpy0: gpy0 { + gpio-controller; + #gpio-cells = <2>; + }; + + /* ... */ + + /* Pin bank with external GPIO or muxed wake-up interrupts */ + gpj0: gpj0 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + /* ... */ + + /* Pin bank with external direct wake-up interrupts */ + gpx0: gpx0 { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + interrupt-parent = <&gic>; + interrupts = <0 16 0>, <0 17 0>, <0 18 0>, <0 19 0>, + <0 20 0>, <0 21 0>, <0 22 0>, <0 23 0>; + #interrupt-cells = <2>; + }; + + /* ... */ + }; + 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>; + /* ... */ + uart0_data: uart0-data { samsung,pins = "gpa0-0", "gpa0-1"; samsung,pin-function = <2>; @@ -156,22 +230,16 @@ Example 1: A pin-controller node with pin groups. 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>; - interrupt-controller; - #interrupt-cells = <2>; + interrupts = <0 46 0> + + /* ... */ - wakup_eint: wakeup-interrupt-controller { + wakeup-interrupt-controller { compatible = "samsung,exynos4210-wakeup-eint"; interrupt-parent = <&gic>; - interrupt-controller; - #interrupt-cells = <2>; - interrupts = <0 16 0>, <0 17 0>, <0 18 0>, <0 19 0>, - <0 20 0>, <0 21 0>, <0 22 0>, <0 23 0>, - <0 24 0>, <0 25 0>, <0 26 0>, <0 27 0>, - <0 28 0>, <0 29 0>, <0 30 0>, <0 31 0>, - <0 32 0>; + interrupts = <0 32 0>; }; }; @@ -190,7 +258,8 @@ Example 4: Set up the default pin state for uart controller. static int s3c24xx_serial_probe(struct platform_device *pdev) { struct pinctrl *pinctrl; - ... - ... + + /* ... */ + pinctrl = devm_pinctrl_get_select_default(&pdev->dev); } diff --git a/Documentation/devicetree/bindings/pinctrl/ste,nomadik.txt b/Documentation/devicetree/bindings/pinctrl/ste,nomadik.txt new file mode 100644 index 000000000000..9a2f3f420526 --- /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/ab8500/btemp.txt b/Documentation/devicetree/bindings/power_supply/ab8500/btemp.txt new file mode 100644 index 000000000000..0ba1bcc7f33a --- /dev/null +++ b/Documentation/devicetree/bindings/power_supply/ab8500/btemp.txt @@ -0,0 +1,16 @@ +=== AB8500 Battery Temperature Monitor Driver === + +The properties below describes the node for btemp driver. + +Required Properties: +- compatible = Shall be: "stericsson,ab8500-btemp" +- battery = Shall be battery specific information + + Example: + ab8500_btemp { + compatible = "stericsson,ab8500-btemp"; + battery = <&ab8500_battery>; + }; + +For information on battery specific node, Ref: +Documentation/devicetree/bindings/power_supply/ab8500/fg.txt diff --git a/Documentation/devicetree/bindings/power_supply/ab8500/chargalg.txt b/Documentation/devicetree/bindings/power_supply/ab8500/chargalg.txt new file mode 100644 index 000000000000..ef5328371122 --- /dev/null +++ b/Documentation/devicetree/bindings/power_supply/ab8500/chargalg.txt @@ -0,0 +1,16 @@ +=== AB8500 Charging Algorithm Driver === + +The properties below describes the node for chargalg driver. + +Required Properties: +- compatible = Shall be: "stericsson,ab8500-chargalg" +- battery = Shall be battery specific information + +Example: +ab8500_chargalg { + compatible = "stericsson,ab8500-chargalg"; + battery = <&ab8500_battery>; +}; + +For information on battery specific node, Ref: +Documentation/devicetree/bindings/power_supply/ab8500/fg.txt diff --git a/Documentation/devicetree/bindings/power_supply/ab8500/charger.txt b/Documentation/devicetree/bindings/power_supply/ab8500/charger.txt new file mode 100644 index 000000000000..6bdbb08ea9e0 --- /dev/null +++ b/Documentation/devicetree/bindings/power_supply/ab8500/charger.txt @@ -0,0 +1,25 @@ +=== AB8500 Charger Driver === + +Required Properties: +- compatible = Shall be "stericsson,ab8500-charger" +- battery = Shall be battery specific information + Example: + ab8500_charger { + compatible = "stericsson,ab8500-charger"; + battery = <&ab8500_battery>; + }; + +- vddadc-supply: Supply for USB and Main charger + Example: + ab8500-charger { + vddadc-supply = <&ab8500_ldo_tvout_reg>; + } +- autopower_cfg: + Boolean value depicting the presence of 'automatic poweron after powerloss' + Example: + ab8500-charger { + autopower_cfg; + }; + +For information on battery specific node, Ref: +Documentation/devicetree/bindings/power_supply/ab8500/fg.txt diff --git a/Documentation/devicetree/bindings/power_supply/ab8500/fg.txt b/Documentation/devicetree/bindings/power_supply/ab8500/fg.txt new file mode 100644 index 000000000000..ccafcb9112fb --- /dev/null +++ b/Documentation/devicetree/bindings/power_supply/ab8500/fg.txt @@ -0,0 +1,58 @@ +=== AB8500 Fuel Gauge Driver === + +AB8500 is a mixed signal multimedia and power management +device comprising: power and energy-management-module, +wall-charger, usb-charger, audio codec, general purpose adc, +tvout, clock management and sim card interface. + +Fuelgauge support is part of energy-management-modules, other +components of this module are: +main-charger, usb-combo-charger and battery-temperature-monitoring. + +The properties below describes the node for fuelgauge driver. + +Required Properties: +- compatible = This shall be: "stericsson,ab8500-fg" +- battery = Shall be battery specific information + Example: + ab8500_fg { + compatible = "stericsson,ab8500-fg"; + battery = <&ab8500_battery>; + }; + +dependent node: + ab8500_battery: ab8500_battery { + }; + This node will provide information on 'thermistor interface' and + 'battery technology type' used. + +Properties of this node are: +thermistor-on-batctrl: + A boolean value indicating thermistor interface to battery + + Note: + 'btemp' and 'batctrl' are the pins interfaced for battery temperature + measurement, 'btemp' signal is used when NTC(negative temperature + coefficient) resister is interfaced external to battery whereas + 'batctrl' pin is used when NTC resister is internal to battery. + + Example: + ab8500_battery: ab8500_battery { + thermistor-on-batctrl; + }; + indicates: NTC resister is internal to battery, 'batctrl' is used + for thermal measurement. + + The absence of property 'thermal-on-batctrl' indicates + NTC resister is external to battery and 'btemp' signal is used + for thermal measurement. + +battery-type: + This shall be the battery manufacturing technology type, + allowed types are: + "UNKNOWN" "NiMH" "LION" "LIPO" "LiFe" "NiCd" "LiMn" + Example: + ab8500_battery: ab8500_battery { + stericsson,battery-type = "LIPO"; + } + 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 000000000000..d7e3e0c0f71d --- /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/qnap-poweroff.txt b/Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt new file mode 100644 index 000000000000..9a599d27bd75 --- /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 charactor '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 000000000000..5776e684afda --- /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/powerpc/fsl/guts.txt b/Documentation/devicetree/bindings/powerpc/fsl/guts.txt index 9e7a2417dac5..7f150b5012cc 100644 --- a/Documentation/devicetree/bindings/powerpc/fsl/guts.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/guts.txt @@ -17,9 +17,20 @@ Recommended properties: 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/pamu.txt b/Documentation/devicetree/bindings/powerpc/fsl/pamu.txt new file mode 100644 index 000000000000..1f5e329f756c --- /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/raideng.txt b/Documentation/devicetree/bindings/powerpc/fsl/raideng.txt new file mode 100644 index 000000000000..4ad29b9ac2ac --- /dev/null +++ b/Documentation/devicetree/bindings/powerpc/fsl/raideng.txt @@ -0,0 +1,81 @@ +* Freescale 85xx RAID Engine nodes + +RAID Engine nodes are defined to describe on-chip RAID accelerators. Each RAID +Engine should have a separate node. + +Supported chips: +P5020, P5040 + +Required properties: + +- compatible: Should contain "fsl,raideng-v1.0" as the value + This identifies RAID Engine block. 1 in 1.0 represents + major number whereas 0 represents minor number. The + version matches the hardware IP version. +- reg: offset and length of the register set for the device +- ranges: standard ranges property specifying the translation + between child address space and parent address space + +Example: + /* P5020 */ + raideng: raideng@320000 { + compatible = "fsl,raideng-v1.0"; + #address-cells = <1>; + #size-cells = <1>; + reg = <0x320000 0x10000>; + ranges = <0 0x320000 0x10000>; + }; + + +There must be a sub-node for each job queue present in RAID Engine +This node must be a sub-node of the main RAID Engine node + +- compatible: Should contain "fsl,raideng-v1.0-job-queue" as the value + This identifies the job queue interface +- reg: offset and length of the register set for job queue +- ranges: standard ranges property specifying the translation + between child address space and parent address space + +Example: + /* P5020 */ + raideng_jq0@1000 { + compatible = "fsl,raideng-v1.0-job-queue"; + reg = <0x1000 0x1000>; + ranges = <0x0 0x1000 0x1000>; + }; + + +There must be a sub-node for each job ring present in RAID Engine +This node must be a sub-node of job queue node + +- compatible: Must contain "fsl,raideng-v1.0-job-ring" as the value + This identifies job ring. Should contain either + "fsl,raideng-v1.0-hp-ring" or "fsl,raideng-v1.0-lp-ring" + depending upon whether ring has high or low priority +- reg: offset and length of the register set for job ring +- interrupts: interrupt mapping for job ring IRQ + +Optional property: + +- fsl,liodn: Specifies the LIODN to be used for Job Ring. This + property is normally set by firmware. Value + is of 12-bits which is the LIODN number for this JR. + This property is used by the IOMMU (PAMU) to distinquish + transactions from this JR and than be able to do address + translation & protection accordingly. + +Example: + /* P5020 */ + raideng_jq0@1000 { + compatible = "fsl,raideng-v1.0-job-queue"; + reg = <0x1000 0x1000>; + ranges = <0x0 0x1000 0x1000>; + + raideng_jr0: jr@0 { + compatible = "fsl,raideng-v1.0-job-ring", "fsl,raideng-v1.0-hp-ring"; + reg = <0x0 0x400>; + interrupts = <139 2 0 0>; + interrupt-parent = <&mpic>; + fsl,liodn = <0x41>; + }; + }; diff --git a/Documentation/devicetree/bindings/powerpc/fsl/srio.txt b/Documentation/devicetree/bindings/powerpc/fsl/srio.txt index b039bcbee134..07abf0f2f440 100644 --- a/Documentation/devicetree/bindings/powerpc/fsl/srio.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/srio.txt @@ -8,9 +8,9 @@ Properties: 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/pwm/atmel-tcb-pwm.txt b/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt new file mode 100644 index 000000000000..de0eaed86651 --- /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/pwm-tiecap.txt b/Documentation/devicetree/bindings/pwm/pwm-tiecap.txt new file mode 100644 index 000000000000..131e8c11d26f --- /dev/null +++ b/Documentation/devicetree/bindings/pwm/pwm-tiecap.txt @@ -0,0 +1,23 @@ +TI SOC ECAP based APWM controller + +Required properties: +- compatible: Must be "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 + 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. +- reg: physical base address and size of the registers map. + +Optional properties: +- ti,hwmods: Name of the hwmod associated to the ECAP: + "ecap<x>", <x> being the 0-based instance number from the HW spec + +Example: + +ecap0: ecap@0 { + compatible = "ti,am33xx-ecap"; + #pwm-cells = <3>; + reg = <0x48300100 0x80>; + ti,hwmods = "ecap0"; +}; diff --git a/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt b/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt new file mode 100644 index 000000000000..4fc7079d822e --- /dev/null +++ b/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt @@ -0,0 +1,23 @@ +TI SOC EHRPWM based PWM controller + +Required properties: +- compatible : Must be "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 + 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. +- reg: physical base address and size of the registers map. + +Optional properties: +- ti,hwmods: Name of the hwmod associated to the EHRPWM: + "ehrpwm<x>", <x> being the 0-based instance number from the HW spec + +Example: + +ehrpwm0: ehrpwm@0 { + compatible = "ti,am33xx-ehrpwm"; + #pwm-cells = <3>; + reg = <0x48300200 0x100>; + ti,hwmods = "ehrpwm0"; +}; diff --git a/Documentation/devicetree/bindings/pwm/pwm-tipwmss.txt b/Documentation/devicetree/bindings/pwm/pwm-tipwmss.txt new file mode 100644 index 000000000000..f7eae77f8354 --- /dev/null +++ b/Documentation/devicetree/bindings/pwm/pwm-tipwmss.txt @@ -0,0 +1,31 @@ +TI SOC based PWM Subsystem + +Required properties: +- compatible: Must be "ti,am33xx-pwmss"; +- reg: physical base address and size of the registers map. +- address-cells: Specify the number of u32 entries needed in child nodes. + Should set to 1. +- size-cells: specify number of u32 entries needed to specify child nodes size + in reg property. Should set to 1. +- ranges: describes the address mapping of a memory-mapped bus. Should set to + physical address map of child's base address, physical address within + parent's address space and length of the address map. For am33xx, + 3 set of child register maps present, ECAP register space, EQEP + register space, EHRPWM register space. + +Also child nodes should also populated under PWMSS DT node. + +Example: +pwmss0: pwmss@48300000 { + compatible = "ti,am33xx-pwmss"; + reg = <0x48300000 0x10>; + ti,hwmods = "epwmss0"; + #address-cells = <1>; + #size-cells = <1>; + status = "disabled"; + ranges = <0x48300100 0x48300100 0x80 /* ECAP */ + 0x48300180 0x48300180 0x80 /* EQEP */ + 0x48300200 0x48300200 0x80>; /* EHRPWM */ + + /* child nodes go here */ +}; diff --git a/Documentation/devicetree/bindings/pwm/pwm.txt b/Documentation/devicetree/bindings/pwm/pwm.txt index 73ec962bfe8c..06e67247859a 100644 --- a/Documentation/devicetree/bindings/pwm/pwm.txt +++ b/Documentation/devicetree/bindings/pwm/pwm.txt @@ -37,10 +37,21 @@ device: pwm-names = "backlight"; }; +Note that in the example above, specifying the "pwm-names" is redundant +because the name "backlight" would be used as fallback anyway. + pwm-specifier typically encodes the chip-relative PWM number and the PWM -period in nanoseconds. Note that in the example above, specifying the -"pwm-names" is redundant because the name "backlight" would be used as -fallback anyway. +period in nanoseconds. + +Optionally, the pwm-specifier can encode a number of flags in a third cell: +- bit 0: PWM signal polarity (0: normal polarity, 1: inverse polarity) + +Example with optional PWM specifier for inverse polarity + + bl: backlight { + pwms = <&pwm 0 5000000 1>; + pwm-names = "backlight"; + }; 2) PWM controller nodes ----------------------- diff --git a/Documentation/devicetree/bindings/pwm/spear-pwm.txt b/Documentation/devicetree/bindings/pwm/spear-pwm.txt new file mode 100644 index 000000000000..3ac779d83386 --- /dev/null +++ b/Documentation/devicetree/bindings/pwm/spear-pwm.txt @@ -0,0 +1,18 @@ +== ST SPEAr SoC PWM controller == + +Required properties: +- compatible: should be one of: + - "st,spear320-pwm" + - "st,spear1340-pwm" +- reg: physical base address and length of the controller's registers +- #pwm-cells: number of cells used to specify PWM which is fixed to 2 on + SPEAr. The first cell specifies the per-chip index of the PWM to use and + the second cell is the period in nanoseconds. + +Example: + + pwm: pwm@a8000000 { + compatible ="st,spear320-pwm"; + reg = <0xa8000000 0x1000>; + #pwm-cells = <2>; + }; diff --git a/Documentation/devicetree/bindings/pwm/ti,twl-pwm.txt b/Documentation/devicetree/bindings/pwm/ti,twl-pwm.txt new file mode 100644 index 000000000000..2943ee5fce00 --- /dev/null +++ b/Documentation/devicetree/bindings/pwm/ti,twl-pwm.txt @@ -0,0 +1,17 @@ +Texas Instruments TWL series PWM drivers + +Supported PWMs: +On TWL4030 series: PWM1 and PWM2 +On TWL6030 series: PWM0 and PWM1 + +Required properties: +- compatible: "ti,twl4030-pwm" or "ti,twl6030-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. + +Example: + +twl_pwm: pwm { + compatible = "ti,twl6030-pwm"; + #pwm-cells = <2>; +}; diff --git a/Documentation/devicetree/bindings/pwm/ti,twl-pwmled.txt b/Documentation/devicetree/bindings/pwm/ti,twl-pwmled.txt new file mode 100644 index 000000000000..cb64f3acc10f --- /dev/null +++ b/Documentation/devicetree/bindings/pwm/ti,twl-pwmled.txt @@ -0,0 +1,17 @@ +Texas Instruments TWL series PWM drivers connected to LED terminals + +Supported PWMs: +On TWL4030 series: PWMA and PWMB (connected to LEDA and LEDB terminals) +On TWL6030 series: LED PWM (mainly used as charging indicator LED) + +Required properties: +- compatible: "ti,twl4030-pwmled" or "ti,twl6030-pwmled" +- #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. + +Example: + +twl_pwmled: pwmled { + compatible = "ti,twl6030-pwmled"; + #pwm-cells = <2>; +}; diff --git a/Documentation/devicetree/bindings/pwm/vt8500-pwm.txt b/Documentation/devicetree/bindings/pwm/vt8500-pwm.txt new file mode 100644 index 000000000000..d21d82d29855 --- /dev/null +++ b/Documentation/devicetree/bindings/pwm/vt8500-pwm.txt @@ -0,0 +1,20 @@ +VIA/Wondermedia VT8500/WM8xxx series SoC PWM controller + +Required properties: +- compatible: should be "via,vt8500-pwm" +- reg: physical base address and length of the controller's registers +- #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 = <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 357758cb6e92..758eae24082a 100644 --- a/Documentation/devicetree/bindings/regulator/anatop-regulator.txt +++ b/Documentation/devicetree/bindings/regulator/anatop-regulator.txt @@ -9,6 +9,11 @@ Required properties: - 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 @@ Example: 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/gpio-regulator.txt b/Documentation/devicetree/bindings/regulator/gpio-regulator.txt new file mode 100644 index 000000000000..63c659800c03 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/gpio-regulator.txt @@ -0,0 +1,37 @@ +GPIO controlled regulators + +Required properties: +- compatible : Must be "regulator-gpio". +- states : Selection of available voltages and GPIO configs. + if there are no states, then use a fixed regulator + +Optional properties: +- enable-gpio : GPIO to use to enable/disable the regulator. +- gpios : GPIO group used to control voltage. +- startup-delay-us : Startup time in microseconds. +- enable-active-high : Polarity of GPIO is active high (default is low). + +Any property defined as part of the core regulator binding defined in +regulator.txt can also be used. + +Example: + + mmciv: gpio-regulator { + compatible = "regulator-gpio"; + + regulator-name = "mmci-gpio-supply"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <2600000>; + regulator-boot-on; + + enable-gpio = <&gpio0 23 0x4>; + gpios = <&gpio0 24 0x4 + &gpio0 25 0x4>; + states = <1800000 0x3 + 2200000 0x2 + 2600000 0x1 + 2900000 0x0>; + + startup-delay-us = <100000>; + enable-active-high; + }; diff --git a/Documentation/devicetree/bindings/regulator/max8925-regulator.txt b/Documentation/devicetree/bindings/regulator/max8925-regulator.txt new file mode 100644 index 000000000000..0057695aae8f --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/max8925-regulator.txt @@ -0,0 +1,40 @@ +Max8925 Voltage regulators + +Required nodes: +-nodes: + - SDV1 for SDV SDV1 + - SDV2 for SDV SDV2 + - SDV3 for SDV SDV3 + - LDO1 for LDO LDO1 + - LDO2 for LDO LDO2 + - LDO3 for LDO LDO3 + - LDO4 for LDO LDO4 + - LDO5 for LDO LDO5 + - LDO6 for LDO LDO6 + - LDO7 for LDO LDO7 + - LDO8 for LDO LDO8 + - LDO9 for LDO LDO9 + - LDO10 for LDO LDO10 + - LDO11 for LDO LDO11 + - LDO12 for LDO LDO12 + - LDO13 for LDO LDO13 + - LDO14 for LDO LDO14 + - LDO15 for LDO LDO15 + - LDO16 for LDO LDO16 + - LDO17 for LDO LDO17 + - LDO18 for LDO LDO18 + - LDO19 for LDO LDO19 + - LDO20 for LDO LDO20 + +Optional properties: +- Any optional property defined in bindings/regulator/regulator.txt + +Example: + + SDV1 { + regulator-min-microvolt = <637500>; + regulator-max-microvolt = <1425000>; + regulator-boot-on; + regulator-always-on; + }; + diff --git a/Documentation/devicetree/bindings/regulator/max8997-regulator.txt b/Documentation/devicetree/bindings/regulator/max8997-regulator.txt new file mode 100644 index 000000000000..9fd69a18b0ba --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/max8997-regulator.txt @@ -0,0 +1,146 @@ +* Maxim MAX8997 Voltage and Current Regulator + +The Maxim MAX8997 is a multi-function device which includes volatage 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 max8997. + +Required properties: +- compatible: Should be "maxim,max8997-pmic". +- reg: Specifies the i2c slave address of the pmic block. It should be 0x66. + +- max8997,pmic-buck1-dvs-voltage: A set of 8 voltage values in micro-volt (uV) + units for buck1 when changing voltage using gpio dvs. Refer to [1] below + for additional information. + +- max8997,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. + +- max8997,pmic-buck5-dvs-voltage: A set of 8 voltage values in micro-volt (uV) + units for buck5 when changing voltage using gpio dvs. Refer to [1] below + for additional information. + +[1] If none of the 'max8997,pmic-buck[1/2/5]-uses-gpio-dvs' optional + property is specified, the 'max8997,pmic-buck[1/2/5]-dvs-voltage' + property should specify atleast one voltage level (which would be a + 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 + 'max8997,pmic-buck[1/2/5]-dvs-voltage' should be specified. + +Optional properties: +- interrupt-parent: Specifies the phandle of the interrupt controller to which + the interrupts from max8997 are delivered to. +- interrupts: Interrupt specifiers for two interrupt sources. + - First interrupt specifier is for 'irq1' interrupt. + - Second interrupt specifier is for 'alert' interrupt. +- max8997,pmic-buck1-uses-gpio-dvs: 'buck1' can be controlled by gpio dvs. +- max8997,pmic-buck2-uses-gpio-dvs: 'buck2' can be controlled by gpio dvs. +- max8997,pmic-buck5-uses-gpio-dvs: 'buck5' can be controlled by gpio dvs. + +Additional properties required if either of the optional properties are used: +- max8997,pmic-ignore-gpiodvs-side-effect: When GPIO-DVS mode is used for + multiple bucks, changing the voltage value of one of the bucks may affect + that of another buck, which is the side effect of the change (set_voltage). + Use this property to ignore such side effects and change the voltage. + +- max8997,pmic-buck125-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. + +- max8997,pmic-buck125-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 max8997 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 { + standard regulator bindings here + }; + +The following are the names of the regulators that the max8997 pmic block +supports. Note: The 'n' in LDOn and BUCKn represents the LDO or BUCK number +as per the datasheet of max8997. + + - LDOn + - valid values for n are 1 to 18 and 21 + - Example: LDO0, LD01, LDO2, LDO21 + - BUCKn + - valid values for n are 1 to 7. + - Example: BUCK1, BUCK2, BUCK3, BUCK7 + + - ENVICHG: Battery Charging Current Monitor Output. This is a fixed + voltage type regulator + + - ESAFEOUT1: (ldo19) + - ESAFEOUT2: (ld020) + + - CHARGER_CV: main battery charger voltage control + - CHARGER: main battery charger current control + - CHARGER_TOPOFF: end of charge current threshold level + +The bindings inside the regulator nodes use the standard regulator bindings +which are documented elsewhere. + +Example: + + max8997_pmic@66 { + compatible = "maxim,max8997-pmic"; + interrupt-parent = <&wakeup_eint>; + reg = <0x66>; + interrupts = <4 0>, <3 0>; + + max8997,pmic-buck1-uses-gpio-dvs; + max8997,pmic-buck2-uses-gpio-dvs; + max8997,pmic-buck5-uses-gpio-dvs; + + max8997,pmic-ignore-gpiodvs-side-effect; + max8997,pmic-buck125-default-dvs-idx = <0>; + + max8997,pmic-buck125-dvs-gpios = <&gpx0 0 1 0 0>, /* SET1 */ + <&gpx0 1 1 0 0>, /* SET2 */ + <&gpx0 2 1 0 0>; /* SET3 */ + + max8997,pmic-buck1-dvs-voltage = <1350000>, <1300000>, + <1250000>, <1200000>, + <1150000>, <1100000>, + <1000000>, <950000>; + + max8997,pmic-buck2-dvs-voltage = <1100000>, <1100000>, + <1100000>, <1100000>, + <1000000>, <1000000>, + <1000000>, <1000000>; + + max8997,pmic-buck5-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>; + }; + + 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/regulator/s5m8767-regulator.txt b/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt new file mode 100644 index 000000000000..a35ff99003a5 --- /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 volatage 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 1 0 0>, /* DVS1 */ + <&gpx0 1 1 0 0>, /* DVS2 */ + <&gpx0 2 1 0 0>; /* DVS3 */ + + s5m8767,pmic-buck-ds-gpios = <&gpx2 3 1 0 0>, /* SET1 */ + <&gpx2 4 1 0 0>, /* SET2 */ + <&gpx2 5 1 0 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/tps51632-regulator.txt b/Documentation/devicetree/bindings/regulator/tps51632-regulator.txt new file mode 100644 index 000000000000..2f7e44a96414 --- /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 c8ca6b8f6582..1b20c3dbcdb8 100644 --- a/Documentation/devicetree/bindings/regulator/tps62360-regulator.txt +++ b/Documentation/devicetree/bindings/regulator/tps62360-regulator.txt @@ -17,9 +17,9 @@ Optional properties: - 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 000000000000..313a60ba61d8 --- /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/tps65217.txt b/Documentation/devicetree/bindings/regulator/tps65217.txt index d316fb895daf..4f05d208c95c 100644 --- a/Documentation/devicetree/bindings/regulator/tps65217.txt +++ b/Documentation/devicetree/bindings/regulator/tps65217.txt @@ -11,6 +11,9 @@ Required properties: using the standard binding for regulators found at Documentation/devicetree/bindings/regulator/regulator.txt. +Optional properties: +- ti,pmic-shutdown-controller: Telling the PMIC to shutdown on PWR_EN toggle. + The valid names for regulators are: tps65217: dcdc1, dcdc2, dcdc3, ldo1, ldo2, ldo3 and ldo4 @@ -20,6 +23,7 @@ Example: tps: tps@24 { compatible = "ti,tps65217"; + ti,pmic-shutdown-controller; regulators { dcdc1_reg: dcdc1 { diff --git a/Documentation/devicetree/bindings/regulator/vexpress.txt b/Documentation/devicetree/bindings/regulator/vexpress.txt new file mode 100644 index 000000000000..d775f72487aa --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/vexpress.txt @@ -0,0 +1,32 @@ +Versatile Express voltage regulators +------------------------------------ + +Requires node properties: +- "compatible" value: "arm,vexpress-volt" +- "arm,vexpress-sysreg,func" when controlled via vexpress-sysreg + (see Documentation/devicetree/bindings/arm/vexpress-sysreg.txt + for more details) + +Required regulator properties: +- "regulator-name" +- "regulator-always-on" + +Optional regulator properties: +- "regulator-min-microvolt" +- "regulator-max-microvolt" + +See Documentation/devicetree/bindings/regulator/regulator.txt +for more details about the regulator properties. + +When no "regulator-[min|max]-microvolt" properties are defined, +the device is treated as fixed (or rather "read-only") regulator. + +Example: + volt@0 { + compatible = "arm,vexpress-volt"; + arm,vexpress-sysreg,func = <2 0>; + regulator-name = "Cores"; + regulator-min-microvolt = <800000>; + regulator-max-microvolt = <1050000>; + regulator-always-on; + }; diff --git a/Documentation/devicetree/bindings/rtc/imxdi-rtc.txt b/Documentation/devicetree/bindings/rtc/imxdi-rtc.txt new file mode 100644 index 000000000000..c9d80d7da141 --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/imxdi-rtc.txt @@ -0,0 +1,17 @@ +* i.MX25 Real Time Clock controller + +This binding supports the following chips: i.MX25, i.MX53 + +Required properties: +- compatible: should be: "fsl,imx25-rtc" +- reg: physical base address of the controller and length of memory mapped + region. +- interrupts: rtc alarm interrupt + +Example: + +rtc@80056000 { + compatible = "fsl,imx53-rtc", "fsl,imx25-rtc"; + reg = <0x80056000 2000>; + interrupts = <29>; +}; diff --git a/Documentation/devicetree/bindings/rtc/nvidia,tegra20-rtc.txt b/Documentation/devicetree/bindings/rtc/nvidia,tegra20-rtc.txt new file mode 100644 index 000000000000..93f45e9dce7c --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/nvidia,tegra20-rtc.txt @@ -0,0 +1,19 @@ +NVIDIA Tegra20 real-time clock + +The Tegra RTC maintains seconds and milliseconds counters, and five alarm +registers. The alarms and other interrupts may wake the system from low-power +state. + +Required properties: + +- compatible : should be "nvidia,tegra20-rtc". +- reg : Specifies base physical address and size of the registers. +- interrupts : A single interrupt specifier. + +Example: + +timer { + compatible = "nvidia,tegra20-rtc"; + reg = <0x7000e000 0x100>; + interrupts = <0 2 0x04>; +}; diff --git a/Documentation/devicetree/bindings/rtc/orion-rtc.txt b/Documentation/devicetree/bindings/rtc/orion-rtc.txt new file mode 100644 index 000000000000..3bf63ffa5160 --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/orion-rtc.txt @@ -0,0 +1,18 @@ +* Mvebu Real Time Clock + +RTC controller for the Kirkwood, the Dove, the Armada 370 and the +Armada XP SoCs + +Required properties: +- compatible : Should be "marvell,orion-rtc" +- reg: physical base address of the controller and length of memory mapped + region. +- interrupts: IRQ line for the RTC. + +Example: + +rtc@10300 { + compatible = "marvell,orion-rtc"; + reg = <0xd0010300 0x20>; + interrupts = <50>; +}; diff --git a/Documentation/devicetree/bindings/rtc/rtc-omap.txt b/Documentation/devicetree/bindings/rtc/rtc-omap.txt new file mode 100644 index 000000000000..b47aa415c820 --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/rtc-omap.txt @@ -0,0 +1,17 @@ +TI Real Time Clock + +Required properties: +- compatible: "ti,da830-rtc" +- reg: Address range of rtc register set +- interrupts: rtc timer, alarm interrupts in order +- interrupt-parent: phandle for the interrupt controller + +Example: + +rtc@1c23000 { + compatible = "ti,da830-rtc"; + reg = <0x23000 0x1000>; + interrupts = <19 + 19>; + interrupt-parent = <&intc>; +}; diff --git a/Documentation/devicetree/bindings/rtc/s3c-rtc.txt b/Documentation/devicetree/bindings/rtc/s3c-rtc.txt index 90ec45fd33ec..7ac7259fe9ea 100644 --- a/Documentation/devicetree/bindings/rtc/s3c-rtc.txt +++ b/Documentation/devicetree/bindings/rtc/s3c-rtc.txt @@ -7,7 +7,7 @@ Required properties: - 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 000000000000..5b78591aaa46 --- /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 000000000000..392a4493eebd --- /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/serio/snps-arc_ps2.txt b/Documentation/devicetree/bindings/serio/snps-arc_ps2.txt new file mode 100644 index 000000000000..38c2f21e8044 --- /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/ak4104.txt b/Documentation/devicetree/bindings/sound/ak4104.txt new file mode 100644 index 000000000000..b902ee39cf89 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/ak4104.txt @@ -0,0 +1,22 @@ +AK4104 S/PDIF transmitter + +This device supports SPI mode only. + +Required properties: + + - compatible : "asahi-kasei,ak4104" + + - reg : The chip select number on the SPI bus + +Optional properties: + + - reset-gpio : a GPIO spec for the reset pin. If specified, it will be + deasserted before communication to the device starts. + +Example: + +spdif: ak4104@0 { + compatible = "asahi-kasei,ak4104"; + reg = <0>; + spi-max-frequency = <5000000>; +}; diff --git a/Documentation/devicetree/bindings/sound/ak4642.txt b/Documentation/devicetree/bindings/sound/ak4642.txt new file mode 100644 index 000000000000..623d4e70ae11 --- /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/atmel-at91sam9g20ek-wm8731-audio.txt b/Documentation/devicetree/bindings/sound/atmel-at91sam9g20ek-wm8731-audio.txt new file mode 100644 index 000000000000..9c5a9947b64d --- /dev/null +++ b/Documentation/devicetree/bindings/sound/atmel-at91sam9g20ek-wm8731-audio.txt @@ -0,0 +1,26 @@ +* Atmel at91sam9g20ek wm8731 audio complex + +Required properties: + - compatible: "atmel,at91sam9g20ek-wm8731-audio" + - atmel,model: The user-visible name of this sound complex. + - atmel,audio-routing: A list of the connections between audio components. + - atmel,ssc-controller: The phandle of the SSC controller + - atmel,audio-codec: The phandle of the WM8731 audio codec +Optional properties: + - pinctrl-names, pinctrl-0: Please refer to pinctrl-bindings.txt + +Example: +sound { + compatible = "atmel,at91sam9g20ek-wm8731-audio"; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_pck0_as_mck>; + + atmel,model = "wm8731 @ AT91SAMG20EK"; + + atmel,audio-routing = + "Ext Spk", "LHPOUT", + "Int MIC", "MICIN"; + + atmel,ssc-controller = <&ssc0>; + atmel,audio-codec = <&wm8731>; +}; diff --git a/Documentation/devicetree/bindings/sound/cs4271.txt b/Documentation/devicetree/bindings/sound/cs4271.txt index c81b5fd5a5bc..e2cd1d7539e5 100644 --- a/Documentation/devicetree/bindings/sound/cs4271.txt +++ b/Documentation/devicetree/bindings/sound/cs4271.txt @@ -18,6 +18,20 @@ Optional properties: - reset-gpio: a GPIO spec to define which pin is connected to the chip's !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/nvidia,tegra-audio-wm9712.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm9712.txt new file mode 100644 index 000000000000..be35d34e8b26 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm9712.txt @@ -0,0 +1,51 @@ +NVIDIA Tegra audio complex + +Required properties: +- compatible : "nvidia,tegra-audio-wm9712" +- 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>; +}; 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 000000000000..c1454979c1ef --- /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/omap-abe-twl6040.txt b/Documentation/devicetree/bindings/sound/omap-abe-twl6040.txt index 65dec876cb2d..fd40c852d7c7 100644 --- a/Documentation/devicetree/bindings/sound/omap-abe-twl6040.txt +++ b/Documentation/devicetree/bindings/sound/omap-abe-twl6040.txt @@ -12,7 +12,7 @@ Required properties: Optional properties: - ti,dmic: phandle for the OMAP dmic node if the machine have it connected -- ti,jack_detection: Need to be set to <1> if the board capable to detect jack +- ti,jack_detection: Need to be present if the board capable to detect jack insertion, removal. Available audio endpoints for the audio-routing table: @@ -59,7 +59,7 @@ sound { compatible = "ti,abe-twl6040"; ti,model = "SDP4430"; - ti,jack-detection = <1>; + ti,jack-detection; ti,mclk-freq = <38400000>; ti,mcpdm = <&mcpdm>; diff --git a/Documentation/devicetree/bindings/sound/omap-twl4030.txt b/Documentation/devicetree/bindings/sound/omap-twl4030.txt index 6fae51c7f766..1ab6bc8404d5 100644 --- a/Documentation/devicetree/bindings/sound/omap-twl4030.txt +++ b/Documentation/devicetree/bindings/sound/omap-twl4030.txt @@ -6,6 +6,52 @@ Required properties: - 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 000000000000..c5be003f413e --- /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/samsung,smdk-wm8994.txt b/Documentation/devicetree/bindings/sound/samsung,smdk-wm8994.txt new file mode 100644 index 000000000000..4686646fb122 --- /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 000000000000..3070046da2e5 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/samsung-i2s.txt @@ -0,0 +1,63 @@ +* 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. + +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). + +Required Board Specific Properties: + +- gpios: The gpio specifier for data out,data in, LRCLK, CDCLK and SCLK + interface lines. The format of the gpio specifier depends on the gpio + controller. + The syntax of samsung gpio specifier is + <[phandle of the gpio controller node] + [pin number within the gpio controller] + [mux function] + [flags and pull up/down] + [drive strength]> + +Example: + +- SoC Specific Portion: + +i2s@03830000 { + compatible = "samsung,i2s-v5"; + reg = <0x03830000 0x100>; + dmas = <&pdma0 10 + &pdma0 9 + &pdma0 8>; + dma-names = "tx", "rx", "tx-sec"; + samsung,supports-6ch; + samsung,supports-rstclr; + samsung,supports-secdai; + samsung,idma-addr = <0x03000000>; +}; + +- Board Specific Portion: + +i2s@03830000 { + gpios = <&gpz 0 2 0 0>, /* I2S_0_SCLK */ + <&gpz 1 2 0 0>, /* I2S_0_CDCLK */ + <&gpz 2 2 0 0>, /* I2S_0_LRCK */ + <&gpz 3 2 0 0>, /* I2S_0_SDI */ + <&gpz 4 2 0 0>, /* I2S_0_SDO[1] */ + <&gpz 5 2 0 0>, /* I2S_0_SDO[2] */ + <&gpz 6 2 0 0>; /* I2S_0_SDO[3] */ +}; diff --git a/Documentation/devicetree/bindings/sound/tlv320aic3x.txt b/Documentation/devicetree/bindings/sound/tlv320aic3x.txt index e7b98f41fa5f..f47c3f589fd0 100644 --- a/Documentation/devicetree/bindings/sound/tlv320aic3x.txt +++ b/Documentation/devicetree/bindings/sound/tlv320aic3x.txt @@ -11,6 +11,12 @@ Optional properties: - 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 000000000000..dceb3b1c2bb7 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/wm8962.txt @@ -0,0 +1,16 @@ +WM8962 audio CODEC + +This device supports I2C only. + +Required properties: + + - compatible : "wlf,wm8962" + + - reg : the I2C address of the device. + +Example: + +codec: wm8962@1a { + compatible = "wlf,wm8962"; + reg = <0x1a>; +}; diff --git a/Documentation/devicetree/bindings/spi/nvidia,tegra20-sflash.txt b/Documentation/devicetree/bindings/spi/nvidia,tegra20-sflash.txt new file mode 100644 index 000000000000..7b53da5cb75b --- /dev/null +++ b/Documentation/devicetree/bindings/spi/nvidia,tegra20-sflash.txt @@ -0,0 +1,26 @@ +NVIDIA Tegra20 SFLASH controller. + +Required properties: +- compatible : should be "nvidia,tegra20-sflash". +- reg: Should contain SFLASH registers location and length. +- interrupts: Should contain SFLASH interrupts. +- nvidia,dma-request-selector : The Tegra DMA controller's phandle and + request selector for this SFLASH controller. + +Recommended properties: +- spi-max-frequency: Definition as per + Documentation/devicetree/bindings/spi/spi-bus.txt + +Example: + +spi@7000c380 { + compatible = "nvidia,tegra20-sflash"; + reg = <0x7000c380 0x80>; + interrupts = <0 39 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/nvidia,tegra20-slink.txt b/Documentation/devicetree/bindings/spi/nvidia,tegra20-slink.txt new file mode 100644 index 000000000000..eefe15e3d95e --- /dev/null +++ b/Documentation/devicetree/bindings/spi/nvidia,tegra20-slink.txt @@ -0,0 +1,26 @@ +NVIDIA Tegra20/Tegra30 SLINK controller. + +Required properties: +- compatible : should be "nvidia,tegra20-slink", "nvidia,tegra30-slink". +- reg: Should contain SLINK registers location and length. +- interrupts: Should contain SLINK interrupts. +- nvidia,dma-request-selector : The Tegra DMA controller's phandle and + request selector for this SLINK controller. + +Recommended properties: +- spi-max-frequency: Definition as per + Documentation/devicetree/bindings/spi/spi-bus.txt + +Example: + +spi@7000d600 { + compatible = "nvidia,tegra20-slink"; + 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 81df374adbb9..938809c6829b 100644 --- a/Documentation/devicetree/bindings/spi/omap-spi.txt +++ b/Documentation/devicetree/bindings/spi/omap-spi.txt @@ -6,7 +6,9 @@ Required properties: - "ti,omap4-spi" for OMAP4+. - ti,spi-num-cs : Number of chipselect supported by the instance. - ti,hwmods: Name of the hwmod associated to the McSPI - +- ti,pindir-d0-out-d1-in: Select the D0 pin as output and D1 as + input. The default is D0 as input and + D1 as output. Example: diff --git a/Documentation/devicetree/bindings/spi/sh-msiof.txt b/Documentation/devicetree/bindings/spi/sh-msiof.txt new file mode 100644 index 000000000000..e6222106ca36 --- /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-bus.txt b/Documentation/devicetree/bindings/spi/spi-bus.txt index d2c33d0f533e..296015e3c632 100644 --- a/Documentation/devicetree/bindings/spi/spi-bus.txt +++ b/Documentation/devicetree/bindings/spi/spi-bus.txt @@ -12,6 +12,7 @@ The SPI master node requires the following properties: - #size-cells - should be zero. - compatible - name of SPI bus controller following generic names recommended practice. +- cs-gpios - (optional) gpios chip select. No other properties are required in the SPI bus node. It is assumed that a driver for an SPI bus device will understand that it is an SPI bus. However, the binding does not attempt to define the specific method for @@ -24,6 +25,22 @@ support describing the chip select layout. Optional property: - num-cs : total number of chipselects +If cs-gpios is used the number of chip select will automatically increased +with max(cs-gpios > hw cs) + +So if for example the controller has 2 CS lines, and the cs-gpios +property looks like this: + +cs-gpios = <&gpio1 0 0> <0> <&gpio1 1 0> <&gpio1 2 0>; + +Then it should be configured so that num_chipselect = 4 with the +following mapping: + +cs0 : &gpio1 0 0 +cs1 : native +cs2 : &gpio1 1 0 +cs3 : &gpio1 2 0 + SPI slave nodes must be children of the SPI master node and can contain the following properties. - reg - (required) chip select address of device. @@ -36,6 +53,11 @@ contain the following properties. shifted clock phase (CPHA) mode - spi-cs-high - (optional) Empty property indicating device requires chip select active high +- spi-3wire - (optional) Empty property indicating device requires + 3-wire mode. + +If a gpio chipselect is used for the SPI slave the gpio number will be passed +via the cs_gpio SPI example for an MPC5200 SPI bus: spi@f00 { diff --git a/Documentation/devicetree/bindings/spi/spi_atmel.txt b/Documentation/devicetree/bindings/spi/spi_atmel.txt new file mode 100644 index 000000000000..07e04cdc0c9e --- /dev/null +++ b/Documentation/devicetree/bindings/spi/spi_atmel.txt @@ -0,0 +1,26 @@ +Atmel SPI device + +Required properties: +- compatible : should be "atmel,at91rm9200-spi". +- reg: Address and length of the register set for the device +- interrupts: Should contain spi interrupt +- cs-gpios: chipselects + +Example: + +spi1: spi@fffcc000 { + compatible = "atmel,at91rm9200-spi"; + reg = <0xfffcc000 0x4000>; + interrupts = <13 4 5>; + #address-cells = <1>; + #size-cells = <0>; + cs-gpios = <&pioB 3 0>; + status = "okay"; + + mmc-slot@0 { + compatible = "mmc-spi-slot"; + reg = <0>; + gpios = <&pioC 4 0>; /* CD */ + spi-max-frequency = <25000000>; + }; +}; diff --git a/Documentation/devicetree/bindings/staging/iio/adc/mxs-lradc.txt b/Documentation/devicetree/bindings/staging/iio/adc/mxs-lradc.txt index 801d58cb6d4d..46882058b59b 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 @@ Required properties: - 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/thermal/db8500-thermal.txt b/Documentation/devicetree/bindings/thermal/db8500-thermal.txt new file mode 100644 index 000000000000..2e1c06fad81f --- /dev/null +++ b/Documentation/devicetree/bindings/thermal/db8500-thermal.txt @@ -0,0 +1,44 @@ +* ST-Ericsson DB8500 Thermal + +** Thermal node properties: + +- compatible : "stericsson,db8500-thermal"; +- reg : address range of the thermal sensor registers; +- interrupts : interrupts generated from PRCMU; +- interrupt-names : "IRQ_HOTMON_LOW" and "IRQ_HOTMON_HIGH"; +- num-trips : number of total trip points, this is required, set it 0 if none, + if greater than 0, the following properties must be defined; +- tripN-temp : temperature of trip point N, should be in ascending order; +- tripN-type : type of trip point N, should be one of "active" "passive" "hot" + "critical"; +- tripN-cdev-num : number of the cooling devices which can be bound to trip + point N, this is required if trip point N is defined, set it 0 if none, + otherwise the following cooling device names must be defined; +- tripN-cdev-nameM : name of the No. M cooling device of trip point N; + +Usually the num-trips and tripN-*** are separated in board related dts files. + +Example: +thermal@801573c0 { + compatible = "stericsson,db8500-thermal"; + reg = <0x801573c0 0x40>; + interrupts = <21 0x4>, <22 0x4>; + interrupt-names = "IRQ_HOTMON_LOW", "IRQ_HOTMON_HIGH"; + + num-trips = <3>; + + trip0-temp = <75000>; + trip0-type = "active"; + trip0-cdev-num = <1>; + trip0-cdev-name0 = "thermal-cpufreq-0"; + + trip1-temp = <80000>; + trip1-type = "active"; + trip1-cdev-num = <2>; + trip1-cdev-name0 = "thermal-cpufreq-0"; + trip1-cdev-name1 = "thermal-fan"; + + trip2-temp = <85000>; + trip2-type = "critical"; + trip2-cdev-num = <0>; +} diff --git a/Documentation/devicetree/bindings/thermal/dove-thermal.txt b/Documentation/devicetree/bindings/thermal/dove-thermal.txt new file mode 100644 index 000000000000..6f474677d472 --- /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 000000000000..8c0f5eb86da7 --- /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 000000000000..28ef498a66e5 --- /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/timer/allwinner,sunxi-timer.txt b/Documentation/devicetree/bindings/timer/allwinner,sunxi-timer.txt new file mode 100644 index 000000000000..0c7b64e95a61 --- /dev/null +++ b/Documentation/devicetree/bindings/timer/allwinner,sunxi-timer.txt @@ -0,0 +1,17 @@ +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/marvell,armada-370-xp-timer.txt b/Documentation/devicetree/bindings/timer/marvell,armada-370-xp-timer.txt new file mode 100644 index 000000000000..36381129d141 --- /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/nvidia,tegra20-timer.txt b/Documentation/devicetree/bindings/timer/nvidia,tegra20-timer.txt new file mode 100644 index 000000000000..e019fdc38773 --- /dev/null +++ b/Documentation/devicetree/bindings/timer/nvidia,tegra20-timer.txt @@ -0,0 +1,21 @@ +NVIDIA Tegra20 timer + +The Tegra20 timer provides four 29-bit timer channels and a single 32-bit free +running counter. The first two channels may also trigger a watchdog reset. + +Required properties: + +- compatible : should be "nvidia,tegra20-timer". +- reg : Specifies base physical address and size of the registers. +- interrupts : A list of 4 interrupts; one per timer channel. + +Example: + +timer { + compatible = "nvidia,tegra20-timer"; + reg = <0x60005000 0x60>; + interrupts = <0 0 0x04 + 0 1 0x04 + 0 41 0x04 + 0 42 0x04>; +}; diff --git a/Documentation/devicetree/bindings/timer/nvidia,tegra30-timer.txt b/Documentation/devicetree/bindings/timer/nvidia,tegra30-timer.txt new file mode 100644 index 000000000000..906109d4c593 --- /dev/null +++ b/Documentation/devicetree/bindings/timer/nvidia,tegra30-timer.txt @@ -0,0 +1,23 @@ +NVIDIA Tegra30 timer + +The Tegra30 timer provides ten 29-bit timer channels, a single 32-bit free +running counter, and 5 watchdog modules. The first two channels may also +trigger a legacy watchdog reset. + +Required properties: + +- compatible : should be "nvidia,tegra30-timer", "nvidia,tegra20-timer". +- reg : Specifies base physical address and size of the registers. +- interrupts : A list of 6 interrupts; one per each of timer channels 1 + through 5, and one for the shared interrupt for the remaining channels. + +timer { + compatible = "nvidia,tegra30-timer", "nvidia,tegra20-timer"; + reg = <0x60005000 0x400>; + interrupts = <0 0 0x04 + 0 1 0x04 + 0 41 0x04 + 0 42 0x04 + 0 121 0x04 + 0 122 0x04>; +}; 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 000000000000..5cae2eb686f8 --- /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 6588b6950a7f..8e080b893b49 100644 --- a/Documentation/devicetree/bindings/tty/serial/efm32-uart.txt +++ b/Documentation/devicetree/bindings/tty/serial/efm32-uart.txt @@ -5,10 +5,16 @@ Required properties: - 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-mxs-auart.txt b/Documentation/devicetree/bindings/tty/serial/fsl-mxs-auart.txt index 2ee903fad25c..273a8d5b3300 100644 --- a/Documentation/devicetree/bindings/tty/serial/fsl-mxs-auart.txt +++ b/Documentation/devicetree/bindings/tty/serial/fsl-mxs-auart.txt @@ -6,11 +6,19 @@ Required properties: - 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. + Example: auart0: serial@8006a000 { compatible = "fsl,imx28-auart", "fsl,imx23-auart"; reg = <0x8006a000 0x2000>; interrupts = <112 70 71>; + fsl,auart-dma-channel = <8 9>; }; 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 ba385f2e0ddc..8f01cb190f25 100644 --- a/Documentation/devicetree/bindings/tty/serial/of-serial.txt +++ b/Documentation/devicetree/bindings/tty/serial/of-serial.txt @@ -11,10 +11,16 @@ Required properties: - "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. -- clock-frequency : the input clock frequency for the UART. +- clock-frequency : the input clock frequency for the UART + or + clocks phandle to refer to the clk used as per Documentation/devicetree + /bindings/clock/clock-bindings.txt Optional properties: - current-speed : the current active speed of the UART. diff --git a/Documentation/devicetree/bindings/usb/am33xx-usb.txt b/Documentation/devicetree/bindings/usb/am33xx-usb.txt index ca8fa56e9f03..ea840f7f9258 100644 --- a/Documentation/devicetree/bindings/usb/am33xx-usb.txt +++ b/Documentation/devicetree/bindings/usb/am33xx-usb.txt @@ -1,14 +1,35 @@ AM33XX MUSB GLUE - compatible : Should be "ti,musb-am33xx" + - reg : offset and length of register sets, first usbss, then for musb instances + - interrupts : usbss, musb instance interrupts in order - ti,hwmods : must be "usb_otg_hs" - 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" - - port0_mode : Should be "3" to represent OTG. "1" signifies HOST and "2" + - ram-bits : Specifies the ram address size. Should be set to "12" + - port0-mode : Should be "3" to represent OTG. "1" signifies HOST and "2" represents PERIPHERAL. - - port1_mode : Should be "1" to represent HOST. "3" signifies OTG and "2" + - 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 500mA when operating in host mode. + +Example: + +usb@47400000 { + compatible = "ti,musb-am33xx"; + reg = <0x47400000 0x1000 /* usbss */ + 0x47401000 0x800 /* musb instance 0 */ + 0x47401800 0x800>; /* musb instance 1 */ + interrupts = <17 /* usbss */ + 18 /* musb instance 0 */ + 19>; /* musb instance 1 */ + multipoint = <1>; + num-eps = <16>; + ram-bits = <12>; + port0-mode = <3>; + port1-mode = <3>; + power = <250>; + ti,hwmods = "usb_otg_hs"; +}; diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt b/Documentation/devicetree/bindings/usb/dwc3.txt new file mode 100644 index 000000000000..7a95c651ceb3 --- /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-orion.txt b/Documentation/devicetree/bindings/usb/ehci-orion.txt new file mode 100644 index 000000000000..6bc09ec14c4d --- /dev/null +++ b/Documentation/devicetree/bindings/usb/ehci-orion.txt @@ -0,0 +1,15 @@ +* EHCI controller, Orion Marvell variants + +Required properties: +- compatible: must be "marvell,orion-ehci" +- reg: physical base address of the controller and length of memory mapped + region. +- interrupts: The EHCI interrupt + +Example: + + ehci@50000 { + compatible = "marvell,orion-ehci"; + reg = <0x50000 0x1000>; + interrupts = <19>; + }; diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra20-ehci.txt b/Documentation/devicetree/bindings/usb/nvidia,tegra20-ehci.txt index e9b005dc7625..34c952883276 100644 --- a/Documentation/devicetree/bindings/usb/nvidia,tegra20-ehci.txt +++ b/Documentation/devicetree/bindings/usb/nvidia,tegra20-ehci.txt @@ -11,6 +11,7 @@ Required properties : - 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. + - nvidia,phy : phandle of the PHY instance, the controller is connected to. Required properties for phy_type == ulpi: - nvidia,phy-reset-gpio : The GPIO used to reset the PHY. @@ -27,3 +28,5 @@ Optional properties: 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 Tegra2 + 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 000000000000..6bdaba2f0aa1 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/nvidia,tegra20-usb-phy.txt @@ -0,0 +1,17 @@ +Tegra SOC USB PHY + +The device node for Tegra SOC USB PHY: + +Required properties : + - compatible : Should be "nvidia,tegra20-usb-phy". + - reg : Address and length of the register set for the USB PHY interface. + - phy_type : Should be one of "ulpi" or "utmi". + +Required properties for phy_type == ulpi: + - nvidia,phy-reset-gpio : The GPIO used to reset the PHY. + +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.
\ No newline at end of file diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt b/Documentation/devicetree/bindings/usb/omap-usb.txt index 29a043ecda52..1ef0ce71f8fa 100644 --- a/Documentation/devicetree/bindings/usb/omap-usb.txt +++ b/Documentation/devicetree/bindings/usb/omap-usb.txt @@ -1,8 +1,11 @@ -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 @@ -16,13 +19,19 @@ OMAP MUSB GLUE - power : Should be "50". This signifies the controller can supply upto 100mA when operating in host mode. +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>; + ctrl-module = <&omap_control_usb>; }; Board specific device node entry @@ -31,3 +40,26 @@ Board specific device node entry mode = <3>; power = <50>; }; + +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 000000000000..033194934f64 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt @@ -0,0 +1,55 @@ +* Samsung's usb phy transceiver + +The Samsung's phy transceiver is used for controlling usb 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 +developement generic PHY driver. + +Required properties: + +Exynos4210: +- compatible : should be "samsung,exynos4210-usbphy" +- reg : base physical address of the phy registers and length of memory mapped + region. + +Exynos5250: +- compatible : should be "samsung,exynos5250-usbphy" +- 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-usbphy"; + reg = <0x125B0000 0x100>; + ranges; + + usbphy-sys { + /* USB device and host PHY_CONTROL registers */ + reg = <0x10020704 0x8>; + }; + }; diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt b/Documentation/devicetree/bindings/usb/usb-phy.txt index 80d4148cb661..61496f5cb095 100644 --- a/Documentation/devicetree/bindings/usb/usb-phy.txt +++ b/Documentation/devicetree/bindings/usb/usb-phy.txt @@ -4,14 +4,39 @@ OMAP USB2 PHY 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 000000000000..6813a715fc7d --- /dev/null +++ b/Documentation/devicetree/bindings/usb/usb3503.txt @@ -0,0 +1,20 @@ +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. +- 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>; + intn-gpios = <&gpx3 4 1>; + reset-gpios = <&gpx3 5 1>; + initial-mode = <1>; + }; diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 9de2b9ff9d6e..19e1ef73ab0d 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -5,6 +5,7 @@ using them to avoid name-space collisions. ad Avionic Design GmbH adi Analog Devices, Inc. +ak Asahi Kasei Corp. amcc Applied Micro Circuits Corporation (APM, formally AMCC) apm Applied Micro Circuits Corporation (APM) arm ARM Ltd. @@ -13,6 +14,7 @@ bosch Bosch Sensortec GmbH 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) denx Denx Software Engineering @@ -25,6 +27,7 @@ gef GE Fanuc Intelligent Platforms Embedded Systems, Inc. hp Hewlett Packard ibm International Business Machines (IBM) idt Integrated Device Technologies, Inc. +img Imagination Technologies Ltd. intercontrol Inter Control Group linux Linux-specific binding marvell Marvell Technology Group Ltd. @@ -34,21 +37,27 @@ national National Semiconductor nintendo Nintendo nvidia NVIDIA nxp NXP Semiconductors +onnn ON Semiconductor Corp. picochip Picochip Ltd -powervr Imagination Technologies +powervr PowerVR (deprecated, use img) qcom Qualcomm, Inc. ramtron Ramtron International realtek Realtek Semiconductor Corp. +renesas Renesas Electronics Corporation samsung Samsung Semiconductor sbs Smart Battery System schindler Schindler sil Silicon Image simtek sirf SiRF Technology, Inc. +snps Synopsys, Inc. st STMicroelectronics +ste ST-Ericsson stericsson ST-Ericsson ti Texas Instruments +toshiba Toshiba Corporation via VIA Technologies, Inc. wlf Wolfson Microelectronics wm Wondermedia Technologies, Inc. +winbond Winbond Electronics corp. xlnx Xilinx 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 000000000000..b4cffdaa4137 --- /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/display-timing.txt b/Documentation/devicetree/bindings/video/display-timing.txt new file mode 100644 index 000000000000..150038552bc3 --- /dev/null +++ b/Documentation/devicetree/bindings/video/display-timing.txt @@ -0,0 +1,109 @@ +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 + +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 new file mode 100644 index 000000000000..c60da67a5d76 --- /dev/null +++ b/Documentation/devicetree/bindings/video/exynos_dp.txt @@ -0,0 +1,80 @@ +The Exynos display port interface should be configured based on +the type of panel connected to it. + +We use two nodes: + -dp-controller node + -dptx-phy node(defined inside dp-controller node) + +For the DP-PHY initialization, we use the dptx-phy node. +Required properties for dptx-phy: + -reg: + Base address of DP PHY register. + -samsung,enable-mask: + The bit-mask used to enable/disable DP PHY. + +For the Panel initialization, we read data from dp-controller node. +Required properties for dp-controller: + -compatible: + should be "samsung,exynos5-dp". + -reg: + physical base address of the controller and length + of memory mapped region. + -interrupts: + interrupt combiner values. + -interrupt-parent: + phandle to Interrupt combiner node. + -samsung,color-space: + input video data format. + COLOR_RGB = 0, COLOR_YCBCR422 = 1, COLOR_YCBCR444 = 2 + -samsung,dynamic-range: + dynamic range for input video data. + VESA = 0, CEA = 1 + -samsung,ycbcr-coeff: + YCbCr co-efficients for input video. + COLOR_YCBCR601 = 0, COLOR_YCBCR709 = 1 + -samsung,color-depth: + number of bits per colour component. + COLOR_6 = 0, COLOR_8 = 1, COLOR_10 = 2, COLOR_12 = 3 + -samsung,link-rate: + link rate supported by the panel. + LINK_RATE_1_62GBPS = 0x6, LINK_RATE_2_70GBPS = 0x0A + -samsung,lane-count: + number of lanes supported by the panel. + LANE_COUNT1 = 1, LANE_COUNT2 = 2, LANE_COUNT4 = 4 + +Optional properties for dp-controller: + -interlaced: + interlace scan mode. + Progressive if defined, Interlaced if not defined + -vsync-active-high: + VSYNC polarity configuration. + High if defined, Low if not defined + -hsync-active-high: + HSYNC polarity configuration. + High if defined, Low if not defined + +Example: + +SOC specific portion: + dp-controller { + compatible = "samsung,exynos5-dp"; + reg = <0x145b0000 0x10000>; + interrupts = <10 3>; + interrupt-parent = <&combiner>; + + dptx-phy { + reg = <0x10040720>; + samsung,enable-mask = <1>; + }; + + }; + +Board Specific portion: + dp-controller { + samsung,color-space = <0>; + samsung,dynamic-range = <0>; + samsung,ycbcr-coeff = <0>; + samsung,color-depth = <1>; + samsung,link-rate = <0x0a>; + samsung,lane-count = <4>; + }; diff --git a/Documentation/devicetree/bindings/video/ssd1307fb.txt b/Documentation/devicetree/bindings/video/ssd1307fb.txt new file mode 100644 index 000000000000..3d0060cff062 --- /dev/null +++ b/Documentation/devicetree/bindings/video/ssd1307fb.txt @@ -0,0 +1,24 @@ +* Solomon SSD1307 Framebuffer Driver + +Required properties: + - compatible: Should be "solomon,ssd1307fb-<bus>". The only supported bus for + now is i2c. + - 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] + - reset-gpios: Should contain the GPIO used to reset the OLED display + +Optional properties: + - reset-active-low: Is the reset gpio is active on physical low? + +[0]: Documentation/devicetree/bindings/pwm/pwm.txt + +Examples: +ssd1307: oled@3c { + compatible = "solomon,ssd1307fb-i2c"; + reg = <0x3c>; + pwms = <&pwm 4 3000>; + reset-gpios = <&gpio2 7>; + reset-active-low; +}; 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 000000000000..ecf42c07684d --- /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 000000000000..d4d86cf8f9eb --- /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 new file mode 100644 index 000000000000..fcdd48f7dcff --- /dev/null +++ b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt @@ -0,0 +1,19 @@ +* Atmel Watchdog Timers + +** at91sam9-wdt + +Required properties: +- compatible: must be "atmel,at91sam9260-wdt". +- 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 new file mode 100644 index 000000000000..d209366b4a69 --- /dev/null +++ b/Documentation/devicetree/bindings/watchdog/brcm,bcm2835-pm-wdog.txt @@ -0,0 +1,13 @@ +BCM2835 Watchdog timer + +Required properties: + +- compatible : should be "brcm,bcm2835-pm-wdt" +- reg : Specifies base physical address and size of the registers. + +Example: + +watchdog { + compatible = "brcm,bcm2835-pm-wdt"; + reg = <0x7e100000 0x28>; +}; diff --git a/Documentation/devicetree/bindings/watchdog/davinci-wdt.txt b/Documentation/devicetree/bindings/watchdog/davinci-wdt.txt new file mode 100644 index 000000000000..75558ccd9a05 --- /dev/null +++ b/Documentation/devicetree/bindings/watchdog/davinci-wdt.txt @@ -0,0 +1,12 @@ +DaVinci Watchdog Timer (WDT) Controller + +Required properties: +- compatible : Should be "ti,davinci-wdt" +- reg : Should contain WDT registers location and length + +Examples: + +wdt: wdt@2320000 { + compatible = "ti,davinci-wdt"; + reg = <0x02320000 0x80>; +}; diff --git a/Documentation/devicetree/bindings/watchdog/marvel.txt b/Documentation/devicetree/bindings/watchdog/marvel.txt index 0b2503ab0a05..5dc8d30061ce 100644 --- a/Documentation/devicetree/bindings/watchdog/marvel.txt +++ b/Documentation/devicetree/bindings/watchdog/marvel.txt @@ -5,10 +5,15 @@ Required Properties: - 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 7c7f6887c796..556d06c17c92 100644 --- a/Documentation/devicetree/bindings/watchdog/pnx4008-wdt.txt +++ b/Documentation/devicetree/bindings/watchdog/pnx4008-wdt.txt @@ -5,9 +5,13 @@ Required properties: - 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 000000000000..7a89e5f85415 --- /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 79ead8263ae4..2aa486cc1ff6 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/sunxi-wdt.txt b/Documentation/devicetree/bindings/watchdog/sunxi-wdt.txt new file mode 100644 index 000000000000..0b2717775600 --- /dev/null +++ b/Documentation/devicetree/bindings/watchdog/sunxi-wdt.txt @@ -0,0 +1,13 @@ +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 000000000000..80a37193c0b8 --- /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 d4d66757354e..b2fb2f5e1922 100644 --- a/Documentation/devicetree/booting-without-of.txt +++ b/Documentation/devicetree/booting-without-of.txt @@ -1228,7 +1228,7 @@ hierarchy and routing of interrupts in the hardware. 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 dca90fe22a90..ef9d06c9f8fd 100644 --- a/Documentation/devicetree/usage-model.txt +++ b/Documentation/devicetree/usage-model.txt @@ -347,7 +347,7 @@ later), which will happily live at the base of the Linux /sys/devices tree. Therefore, if a DT node is at the root of the tree, then it really probably is best registered as a platform_device. -Linux board support code calls of_platform_populate(NULL, NULL, NULL) +Linux board support code calls of_platform_populate(NULL, NULL, NULL, NULL) to kick off discovery of devices at the root of the tree. The parameters are all NULL because when starting from the root of the tree, there is no need to provide a starting node (the first NULL), a diff --git a/Documentation/dma-buf-sharing.txt b/Documentation/dma-buf-sharing.txt index ad86fb86c9a0..4966b1be42ac 100644 --- a/Documentation/dma-buf-sharing.txt +++ b/Documentation/dma-buf-sharing.txt @@ -302,7 +302,11 @@ Access to a dma_buf from the kernel context involves three steps: 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 @@ -376,7 +380,7 @@ Being able to mmap an export dma-buf buffer object has 2 main use-cases: leaving the cpu domain and flushing caches at fault time. Note that all the dma_buf files share the same anon inode, hence the exporter needs to replace the dma_buf file stored in vma->vm_file with it's own if pte shootdown is - requred. This is because the kernel uses the underlying inode's address_space + required. This is because the kernel uses the underlying inode's address_space for vma tracking (and hence pte tracking at shootdown time with unmap_mapping_range). @@ -388,7 +392,7 @@ Being able to mmap an export dma-buf buffer object has 2 main use-cases: Exporters that shoot down mappings (for any reasons) shall not do any synchronization at fault time with outstanding device operations. Synchronization is an orthogonal issue to sharing the backing storage of a - buffer and hence should not be handled by dma-buf itself. This is explictly + buffer and hence should not be handled by dma-buf itself. This is explicitly mentioned here because many people seem to want something like this, but if different exporters handle this differently, buffer sharing can fail in interesting ways depending upong the exporter (if userspace starts depending diff --git a/Documentation/dontdiff b/Documentation/dontdiff index 74c25c8d8884..b89a739a3276 100644 --- a/Documentation/dontdiff +++ b/Documentation/dontdiff @@ -181,7 +181,6 @@ modversions.h* nconf ncscope.* offset.h -offsets.h oui.c* page-types parse.c diff --git a/Documentation/driver-model/devres.txt b/Documentation/driver-model/devres.txt index 43cff70465ab..b4671459857f 100644 --- a/Documentation/driver-model/devres.txt +++ b/Documentation/driver-model/devres.txt @@ -266,7 +266,8 @@ IOMAP 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 @@ PINCTRL 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 32bc56b13b1c..5d5ee4c13fa6 100755 --- a/Documentation/dvb/get_dvb_firmware +++ b/Documentation/dvb/get_dvb_firmware @@ -23,7 +23,7 @@ use IO::Handle; @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 @@ sub vp7041 { $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_h5 { } 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 6e1684981da2..72322c6d7352 100644 --- a/Documentation/dynamic-debug-howto.txt +++ b/Documentation/dynamic-debug-howto.txt @@ -6,8 +6,16 @@ This document describes how to use the dynamic debug (dyndbg) feature. Dynamic debug is designed to allow you to dynamically enable/disable kernel code to obtain additional kernel information. Currently, if -CONFIG_DYNAMIC_DEBUG is set, then all pr_debug()/dev_dbg() calls can -be dynamically enabled per-callsite. +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 @@ The flags are: 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). diff --git a/Documentation/fault-injection/notifier-error-inject.txt b/Documentation/fault-injection/notifier-error-inject.txt index c83526c364e5..09adabef513f 100644 --- a/Documentation/fault-injection/notifier-error-inject.txt +++ b/Documentation/fault-injection/notifier-error-inject.txt @@ -1,7 +1,7 @@ Notifier error injection ======================== -Notifier error injection provides the ability to inject artifical errors to +Notifier error injection provides the ability to inject artificial errors to specified notifier chain callbacks. It is useful to test the error handling of notifier call chain failures which is rarely executed. There are kernel modules that can be used to test the following notifiers. @@ -14,7 +14,7 @@ modules that can be used to test the following notifiers. CPU notifier error injection module ----------------------------------- This feature can be used to test the error handling of the CPU notifiers by -injecting artifical errors to CPU notifier chain callbacks. +injecting artificial errors to CPU notifier chain callbacks. If the notifier call chain should be failed with some events notified, write the error code to debugfs interface diff --git a/Documentation/filesystems/00-INDEX b/Documentation/filesystems/00-INDEX index 8c624a18f67d..8042050eb265 100644 --- a/Documentation/filesystems/00-INDEX +++ b/Documentation/filesystems/00-INDEX @@ -38,6 +38,8 @@ dnotify_test.c - example program for dnotify ecryptfs.txt - docs on eCryptfs: stacked cryptographic filesystem for Linux. +efivarfs.txt + - info for the efivarfs filesystem. exofs.txt - info, usage, mount options, design about EXOFS. ext2.txt @@ -48,6 +50,8 @@ ext4.txt - info, mount options and specifications for the Ext4 filesystem. files.txt - info on file management in the Linux kernel. +f2fs.txt + - info and mount options for the F2FS filesystem. fuse.txt - info on the Filesystem in User SpacE including mount options. gfs2.txt diff --git a/Documentation/filesystems/Locking b/Documentation/filesystems/Locking index e540a24e5d06..0706d32a61e6 100644 --- a/Documentation/filesystems/Locking +++ b/Documentation/filesystems/Locking @@ -10,6 +10,7 @@ be able to use diff(1). --------------------------- dentry_operations -------------------------- prototypes: int (*d_revalidate)(struct dentry *, unsigned int); + int (*d_weak_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 *, @@ -25,6 +26,7 @@ prototypes: 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 @@ -80,7 +82,6 @@ rename: yes (all) (see below) readlink: no follow_link: no put_link: no -truncate: yes (see below) setattr: yes permission: no (may not block if called in rcu-walk mode) get_acl: no @@ -96,11 +97,6 @@ atomic_open: yes Additionally, ->rmdir(), ->unlink() and ->rename() have ->i_mutex on victim. cross-directory ->rename() has (per-superblock) ->s_vfs_rename_sem. - ->truncate() is never called directly - it's a callback, not a -method. It's called by vmtruncate() - deprecated library function used by -->setattr(). Locking information above applies to that call (i.e. is -inherited from ->setattr() - vmtruncate() is used when ATTR_SIZE had been -passed). See Documentation/filesystems/directory-locking for more detailed discussion of the locking scheme for directory operations. diff --git a/Documentation/filesystems/caching/backend-api.txt b/Documentation/filesystems/caching/backend-api.txt index 382d52cdaf2d..d78bab9622c6 100644 --- a/Documentation/filesystems/caching/backend-api.txt +++ b/Documentation/filesystems/caching/backend-api.txt @@ -308,6 +308,18 @@ performed on the denizens of the cache. These are held in a structure of type: obtained by calling object->cookie->def->get_aux()/get_attr(). + (*) Invalidate data object [mandatory]: + + int (*invalidate_object)(struct fscache_operation *op) + + This is called to invalidate a data object (as pointed to by op->object). + All the data stored for this object should be discarded and an + attr_changed operation should be performed. The caller will follow up + with an object update operation. + + fscache_op_complete() must be called on op before returning. + + (*) Discard object [mandatory]: void (*drop_object)(struct fscache_object *object) @@ -419,7 +431,10 @@ performed on the denizens of the cache. These are held in a structure of type: If an I/O error occurs, fscache_io_error() should be called and -ENOBUFS returned if possible or fscache_end_io() called with a suitable error - code.. + code. + + fscache_put_retrieval() should be called after a page or pages are dealt + with. This will complete the operation when all pages are dealt with. (*) Request pages be read from cache [mandatory]: @@ -526,6 +541,27 @@ FS-Cache provides some utilities that a cache backend may make use of: error value should be 0 if successful and an error otherwise. + (*) Record that one or more pages being retrieved or allocated have been dealt + with: + + void fscache_retrieval_complete(struct fscache_retrieval *op, + int n_pages); + + This is called to record the fact that one or more pages have been dealt + with and are no longer the concern of this operation. When the number of + pages remaining in the operation reaches 0, the operation will be + completed. + + + (*) Record operation completion: + + void fscache_op_complete(struct fscache_operation *op); + + This is called to record the completion of an operation. This deducts + this operation from the parent object's run state, potentially permitting + one or more pending operations to start running. + + (*) Set highest store limit: void fscache_set_store_limit(struct fscache_object *object, diff --git a/Documentation/filesystems/caching/netfs-api.txt b/Documentation/filesystems/caching/netfs-api.txt index 7cc6bf2871eb..97e6c0ecc5ef 100644 --- a/Documentation/filesystems/caching/netfs-api.txt +++ b/Documentation/filesystems/caching/netfs-api.txt @@ -35,8 +35,9 @@ This document contains the following sections: (12) Index and data file update (13) Miscellaneous cookie operations (14) Cookie unregistration - (15) Index and data file invalidation - (16) FS-Cache specific page flags. + (15) Index invalidation + (16) Data file invalidation + (17) FS-Cache specific page flags. ============================= @@ -767,13 +768,42 @@ the cookies for "child" indices, objects and pages have been relinquished first. -================================ -INDEX AND DATA FILE INVALIDATION -================================ +================== +INDEX INVALIDATION +================== + +There is no direct way to invalidate an index subtree. To do this, the caller +should relinquish and retire the cookie they have, and then acquire a new one. + + +====================== +DATA FILE INVALIDATION +====================== + +Sometimes it will be necessary to invalidate an object that contains data. +Typically this will be necessary when the server tells the netfs of a foreign +change - at which point the netfs has to throw away all the state it had for an +inode and reload from the server. + +To indicate that a cache object should be invalidated, the following function +can be called: + + void fscache_invalidate(struct fscache_cookie *cookie); + +This can be called with spinlocks held as it defers the work to a thread pool. +All extant storage, retrieval and attribute change ops at this point are +cancelled and discarded. Some future operations will be rejected until the +cache has had a chance to insert a barrier in the operations queue. After +that, operations will be queued again behind the invalidation operation. + +The invalidation operation will perform an attribute change operation and an +auxiliary data update operation as it is very likely these will have changed. + +Using the following function, the netfs can wait for the invalidation operation +to have reached a point at which it can start submitting ordinary operations +once again: -There is no direct way to invalidate an index subtree or a data file. To do -this, the caller should relinquish and retire the cookie they have, and then -acquire a new one. + void fscache_wait_on_invalidate(struct fscache_cookie *cookie); =========================== diff --git a/Documentation/filesystems/caching/object.txt b/Documentation/filesystems/caching/object.txt index 58313348da87..100ff41127e4 100644 --- a/Documentation/filesystems/caching/object.txt +++ b/Documentation/filesystems/caching/object.txt @@ -216,7 +216,14 @@ servicing netfs requests: The normal running state. In this state, requests the netfs makes will be passed on to the cache. - (6) State FSCACHE_OBJECT_UPDATING. + (6) State FSCACHE_OBJECT_INVALIDATING. + + The object is undergoing invalidation. When the state comes here, it + discards all pending read, write and attribute change operations as it is + going to clear out the cache entirely and reinitialise it. It will then + continue to the FSCACHE_OBJECT_UPDATING state. + + (7) State FSCACHE_OBJECT_UPDATING. The state machine comes here to update the object in the cache from the netfs's records. This involves updating the auxiliary data that is used @@ -225,13 +232,13 @@ servicing netfs requests: And there are terminal states in which an object cleans itself up, deallocates memory and potentially deletes stuff from disk: - (7) State FSCACHE_OBJECT_LC_DYING. + (8) State FSCACHE_OBJECT_LC_DYING. The object comes here if it is dying because of a lookup or creation error. This would be due to a disk error or system error of some sort. Temporary data is cleaned up, and the parent is released. - (8) State FSCACHE_OBJECT_DYING. + (9) State FSCACHE_OBJECT_DYING. The object comes here if it is dying due to an error, because its parent cookie has been relinquished by the netfs or because the cache is being @@ -241,27 +248,27 @@ memory and potentially deletes stuff from disk: can destroy themselves. This object waits for all its children to go away before advancing to the next state. - (9) State FSCACHE_OBJECT_ABORT_INIT. +(10) State FSCACHE_OBJECT_ABORT_INIT. The object comes to this state if it was waiting on its parent in FSCACHE_OBJECT_INIT, but its parent died. The object will destroy itself so that the parent may proceed from the FSCACHE_OBJECT_DYING state. -(10) State FSCACHE_OBJECT_RELEASING. -(11) State FSCACHE_OBJECT_RECYCLING. +(11) State FSCACHE_OBJECT_RELEASING. +(12) State FSCACHE_OBJECT_RECYCLING. The object comes to one of these two states when dying once it is rid of all its children, if it is dying because the netfs relinquished its cookie. In the first state, the cached data is expected to persist, and in the second it will be deleted. -(12) State FSCACHE_OBJECT_WITHDRAWING. +(13) State FSCACHE_OBJECT_WITHDRAWING. The object transits to this state if the cache decides it wants to withdraw the object from service, perhaps to make space, but also due to error or just because the whole cache is being withdrawn. -(13) State FSCACHE_OBJECT_DEAD. +(14) State FSCACHE_OBJECT_DEAD. The object transits to this state when the in-memory object record is ready to be deleted. The object processor shouldn't ever see an object in diff --git a/Documentation/filesystems/caching/operations.txt b/Documentation/filesystems/caching/operations.txt index b6b070c57cbf..bee2a5f93d60 100644 --- a/Documentation/filesystems/caching/operations.txt +++ b/Documentation/filesystems/caching/operations.txt @@ -174,7 +174,7 @@ Operations are used through the following procedure: necessary (the object might have died whilst the thread was waiting). When it has finished doing its processing, it should call - fscache_put_operation() on it. + fscache_op_complete() and fscache_put_operation() on it. (4) The operation holds an effective lock upon the object, preventing other exclusive ops conflicting until it is released. The operation can be diff --git a/Documentation/filesystems/efivarfs.txt b/Documentation/filesystems/efivarfs.txt new file mode 100644 index 000000000000..c477af086e65 --- /dev/null +++ b/Documentation/filesystems/efivarfs.txt @@ -0,0 +1,16 @@ + +efivarfs - a (U)EFI variable filesystem + +The efivarfs filesystem was created to address the shortcomings of +using entries in sysfs to maintain EFI variables. The old sysfs EFI +variables code only supported variables of up to 1024 bytes. This +limitation existed in version 0.99 of the EFI specification, but was +removed before any full releases. Since variables can now be larger +than a single page, sysfs isn't the best interface for this. + +Variables can be created, deleted and modified with the efivarfs +filesystem. + +efivarfs is typically mounted like this, + + mount -t efivarfs none /sys/firmware/efi/efivars diff --git a/Documentation/filesystems/ext4.txt b/Documentation/filesystems/ext4.txt index 104322bf378c..34ea4f1fa6ea 100644 --- a/Documentation/filesystems/ext4.txt +++ b/Documentation/filesystems/ext4.txt @@ -200,12 +200,9 @@ inode_readahead_blks=n This tuning parameter controls the maximum table readahead algorithm will pre-read into the buffer cache. The default value is 32 blocks. -nouser_xattr Disables Extended User Attributes. If you have extended - attribute support enabled in the kernel configuration - (CONFIG_EXT4_FS_XATTR), extended attribute support - is enabled by default on mount. See the attr(5) manual - page and http://acl.bestbits.at/ for more information - about extended attributes. +nouser_xattr Disables Extended User Attributes. See the + attr(5) manual page and http://acl.bestbits.at/ + for more information about extended attributes. noacl This option disables POSIX Access Control List support. If ACL support is enabled in the kernel diff --git a/Documentation/filesystems/f2fs.txt b/Documentation/filesystems/f2fs.txt new file mode 100644 index 000000000000..dcf338e62b71 --- /dev/null +++ b/Documentation/filesystems/f2fs.txt @@ -0,0 +1,421 @@ +================================================================================ +WHAT IS Flash-Friendly File System (F2FS)? +================================================================================ + +NAND flash memory-based storage devices, such as SSD, eMMC, and SD cards, have +been equipped on a variety systems ranging from mobile to server systems. Since +they are known to have different characteristics from the conventional rotating +disks, a file system, an upper layer to the storage device, should adapt to the +changes from the sketch in the design level. + +F2FS is a file system exploiting NAND flash memory-based storage devices, which +is based on Log-structured File System (LFS). The design has been focused on +addressing the fundamental issues in LFS, which are snowball effect of wandering +tree and high cleaning overhead. + +Since a NAND flash memory-based storage device shows different characteristic +according to its internal geometry or flash memory management scheme, namely FTL, +F2FS and its tools support various parameters not only for configuring on-disk +layout, but also for selecting allocation and cleaning algorithms. + +The file system formatting tool, "mkfs.f2fs", is available from the following +git tree: +>> git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs-tools.git + +For reporting bugs and sending patches, please use the following mailing list: +>> linux-f2fs-devel@lists.sourceforge.net + +================================================================================ +BACKGROUND AND DESIGN ISSUES +================================================================================ + +Log-structured File System (LFS) +-------------------------------- +"A log-structured file system writes all modifications to disk sequentially in +a log-like structure, thereby speeding up both file writing and crash recovery. +The log is the only structure on disk; it contains indexing information so that +files can be read back from the log efficiently. In order to maintain large free +areas on disk for fast writing, we divide the log into segments and use a +segment cleaner to compress the live information from heavily fragmented +segments." from Rosenblum, M. and Ousterhout, J. K., 1992, "The design and +implementation of a log-structured file system", ACM Trans. Computer Systems +10, 1, 26–52. + +Wandering Tree Problem +---------------------- +In LFS, when a file data is updated and written to the end of log, its direct +pointer block is updated due to the changed location. Then the indirect pointer +block is also updated due to the direct pointer block update. In this manner, +the upper index structures such as inode, inode map, and checkpoint block are +also updated recursively. This problem is called as wandering tree problem [1], +and in order to enhance the performance, it should eliminate or relax the update +propagation as much as possible. + +[1] Bityutskiy, A. 2005. JFFS3 design issues. http://www.linux-mtd.infradead.org/ + +Cleaning Overhead +----------------- +Since LFS is based on out-of-place writes, it produces so many obsolete blocks +scattered across the whole storage. In order to serve new empty log space, it +needs to reclaim these obsolete blocks seamlessly to users. This job is called +as a cleaning process. + +The process consists of three operations as follows. +1. A victim segment is selected through referencing segment usage table. +2. It loads parent index structures of all the data in the victim identified by + segment summary blocks. +3. It checks the cross-reference between the data and its parent index structure. +4. It moves valid data selectively. + +This cleaning job may cause unexpected long delays, so the most important goal +is to hide the latencies to users. And also definitely, it should reduce the +amount of valid data to be moved, and move them quickly as well. + +================================================================================ +KEY FEATURES +================================================================================ + +Flash Awareness +--------------- +- Enlarge the random write area for better performance, but provide the high + spatial locality +- Align FS data structures to the operational units in FTL as best efforts + +Wandering Tree Problem +---------------------- +- Use a term, “node”, that represents inodes as well as various pointer blocks +- Introduce Node Address Table (NAT) containing the locations of all the “node” + blocks; this will cut off the update propagation. + +Cleaning Overhead +----------------- +- Support a background cleaning process +- Support greedy and cost-benefit algorithms for victim selection policies +- Support multi-head logs for static/dynamic hot and cold data separation +- Introduce adaptive logging for efficient block allocation + +================================================================================ +MOUNT OPTIONS +================================================================================ + +background_gc_off Turn off cleaning operations, namely garbage collection, + triggered in background when I/O subsystem is idle. +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 + segments for data from the beginning of main area, while + for node from the end of main area. +nouser_xattr Disable Extended User Attributes. Note: xattr is enabled + by default if CONFIG_F2FS_FS_XATTR is selected. +noacl Disable POSIX Access Control List. Note: acl is enabled + by default if CONFIG_F2FS_FS_POSIX_ACL is selected. +active_logs=%u Support configuring the number of active logs. In the + current design, f2fs supports only 2, 4, and 6 logs. + Default number is 6. +disable_ext_identify Disable the extension list configured by mkfs, so f2fs + does not aware of cold files such as media files. + +================================================================================ +DEBUGFS ENTRIES +================================================================================ + +/sys/kernel/debug/f2fs/ contains information about all the partitions mounted as +f2fs. Each file shows the whole f2fs information. + +/sys/kernel/debug/f2fs/status includes: + - major file system information managed by f2fs currently + - average SIT information about whole segments + - current memory footprint consumed by f2fs. + +================================================================================ +USAGE +================================================================================ + +1. Download userland tools and compile them. + +2. Skip, if f2fs was compiled statically inside kernel. + Otherwise, insert the f2fs.ko module. + # insmod f2fs.ko + +3. Create a directory trying to mount + # mkdir /mnt/f2fs + +4. Format the block device, and then mount as f2fs + # mkfs.f2fs -l label /dev/block_device + # mount -t f2fs /dev/block_device /mnt/f2fs + +Format options +-------------- +-l [label] : Give a volume label, up to 256 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. + 5 is set by default. +-s [int] : Set the number of segments per section. + 1 is set by default. +-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" + +================================================================================ +DESIGN +================================================================================ + +On-disk Layout +-------------- + +F2FS divides the whole volume into a number of segments, each of which is fixed +to 2MB in size. A section is composed of consecutive segments, and a zone +consists of a set of sections. By default, section and zone sizes are set to one +segment size identically, but users can easily modify the sizes by mkfs. + +F2FS splits the entire volume into six areas, and all the areas except superblock +consists of multiple segments as described below. + + align with the zone size <-| + |-> align with the segment size + _________________________________________________________________________ + | | | Segment | Node | Segment | | + | Superblock | Checkpoint | Info. | Address | Summary | Main | + | (SB) | (CP) | Table (SIT) | Table (NAT) | Area (SSA) | | + |____________|_____2______|______N______|______N______|______N_____|__N___| + . . + . . + . . + ._________________________________________. + |_Segment_|_..._|_Segment_|_..._|_Segment_| + . . + ._________._________ + |_section_|__...__|_ + . . + .________. + |__zone__| + +- Superblock (SB) + : It is located at the beginning of the partition, and there exist two copies + to avoid file system crash. It contains basic partition information and some + default parameters of f2fs. + +- Checkpoint (CP) + : It contains file system information, bitmaps for valid NAT/SIT sets, orphan + inode lists, and summary entries of current active segments. + +- 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. + +- Main Area + : It contains file and directory data including their indices. + +In order to avoid misalignment between file system and flash-based storage, F2FS +aligns the start block address of CP with the segment size. Also, it aligns the +start block address of Main area with the zone size by reserving some segments +in SSA area. + +Reference the following survey for additional technical details. +https://wiki.linaro.org/WorkingGroups/Kernel/Projects/FlashCardSurvey + +File System Metadata Structure +------------------------------ + +F2FS adopts the checkpointing scheme to maintain file system consistency. At +mount time, F2FS first tries to find the last valid checkpoint data by scanning +CP area. In order to reduce the scanning time, F2FS uses only two copies of CP. +One of them always indicates the last valid data, which is called as shadow copy +mechanism. In addition to CP, NAT and SIT also adopt the shadow copy mechanism. + +For file system consistency, each CP points to which NAT and SIT copies are +valid, as shown as below. + + +--------+----------+---------+ + | CP | SIT | NAT | + +--------+----------+---------+ + . . . . + . . . . + . . . . + +-------+-------+--------+--------+--------+--------+ + | CP #0 | CP #1 | SIT #0 | SIT #1 | NAT #0 | NAT #1 | + +-------+-------+--------+--------+--------+--------+ + | ^ ^ + | | | + `----------------------------------------' + +Index Structure +--------------- + +The key data structure to manage the data locations is a "node". Similar to +traditional file structures, F2FS has three types of node: inode, direct node, +indirect node. F2FS assigns 4KB to an inode block which contains 923 data block +indices, two direct node pointers, two indirect node pointers, and one double +indirect node pointer as described below. One direct node block contains 1018 +data blocks, and one indirect node block contains also 1018 node blocks. Thus, +one inode block (i.e., a file) covers: + + 4KB * (923 + 2 * 1018 + 2 * 1018 * 1018 + 1018 * 1018 * 1018) := 3.94TB. + + Inode block (4KB) + |- data (923) + |- direct node (2) + | `- data (1018) + |- indirect node (2) + | `- direct node (1018) + | `- data (1018) + `- double indirect node (1) + `- indirect node (1018) + `- direct node (1018) + `- data (1018) + +Note that, all the node blocks are mapped by NAT which means the location of +each node is translated by the NAT table. In the consideration of the wandering +tree problem, F2FS is able to cut off the propagation of node updates caused by +leaf data writes. + +Directory Structure +------------------- + +A directory entry occupies 11 bytes, which consists of the following attributes. + +- hash hash value of the file name +- ino inode number +- len the length of file name +- type file type such as directory, symlink, etc + +A dentry block consists of 214 dentry slots and file names. Therein a bitmap is +used to represent whether each dentry is valid or not. A dentry block occupies +4KB with the following composition. + + Dentry Block(4 K) = bitmap (27 bytes) + reserved (3 bytes) + + dentries(11 * 214 bytes) + file name (8 * 214 bytes) + + [Bucket] + +--------------------------------+ + |dentry block 1 | dentry block 2 | + +--------------------------------+ + . . + . . + . [Dentry Block Structure: 4KB] . + +--------+----------+----------+------------+ + | bitmap | reserved | dentries | file names | + +--------+----------+----------+------------+ + [Dentry Block: 4KB] . . + . . + . . + +------+------+-----+------+ + | hash | ino | len | type | + +------+------+-----+------+ + [Dentry Structure: 11 bytes] + +F2FS implements multi-level hash tables for directory structure. Each level has +a hash table with dedicated number of hash buckets as shown below. Note that +"A(2B)" means a bucket includes 2 data blocks. + +---------------------- +A : bucket +B : block +N : MAX_DIR_HASH_DEPTH +---------------------- + +level #0 | A(2B) + | +level #1 | A(2B) - A(2B) + | +level #2 | A(2B) - A(2B) - A(2B) - A(2B) + . | . . . . +level #N/2 | A(2B) - A(2B) - A(2B) - A(2B) - A(2B) - ... - A(2B) + . | . . . . +level #N | A(4B) - A(4B) - A(4B) - A(4B) - A(4B) - ... - A(4B) + +The number of blocks and buckets are determined by, + + ,- 2, if n < MAX_DIR_HASH_DEPTH / 2, + # of blocks in level #n = | + `- 4, Otherwise + + ,- 2^n, if n < MAX_DIR_HASH_DEPTH / 2, + # of buckets in level #n = | + `- 2^((MAX_DIR_HASH_DEPTH / 2) - 1), Otherwise + +When F2FS finds a file name in a directory, at first a hash value of the file +name is calculated. Then, F2FS scans the hash table in level #0 to find the +dentry consisting of the file name and its inode number. If not found, F2FS +scans the next hash table in level #1. In this way, F2FS scans hash tables in +each levels incrementally from 1 to N. In each levels F2FS needs to scan only +one bucket determined by the following equation, which shows O(log(# of files)) +complexity. + + bucket number to scan in level #n = (hash value) % (# of buckets in level #n) + +In the case of file creation, F2FS finds empty consecutive slots that cover the +file name. F2FS searches the empty slots in the hash tables of whole levels from +1 to N in the same way as the lookup operation. + +The following figure shows an example of two cases holding children. + --------------> Dir <-------------- + | | + child child + + child - child [hole] - child + + child - child - child [hole] - [hole] - child + + Case 1: Case 2: + Number of children = 6, Number of children = 3, + File size = 7 File size = 7 + +Default Block Allocation +------------------------ + +At runtime, F2FS manages six active logs inside "Main" area: Hot/Warm/Cold node +and Hot/Warm/Cold data. + +- Hot node contains direct node blocks of directories. +- Warm node contains direct node blocks except hot node blocks. +- Cold node contains indirect node blocks +- Hot data contains dentry blocks +- Warm data contains data blocks except hot and cold data blocks +- Cold data contains multimedia data or migrated data blocks + +LFS has two schemes for free space management: threaded log and copy-and-compac- +tion. The copy-and-compaction scheme which is known as cleaning, is well-suited +for devices showing very good sequential write performance, since free segments +are served all the time for writing new data. However, it suffers from cleaning +overhead under high utilization. Contrarily, the threaded log scheme suffers +from random writes, but no cleaning process is needed. F2FS adopts a hybrid +scheme where the copy-and-compaction scheme is adopted by default, but the +policy is dynamically changed to the threaded log scheme according to the file +system status. + +In order to align F2FS with underlying flash-based storage, F2FS allocates a +segment in a unit of section. F2FS expects that the section size would be the +same as the unit size of garbage collection in FTL. Furthermore, with respect +to the mapping granularity in FTL, F2FS allocates each section of the active +logs from different zones as much as possible, since FTL can write the data in +the active logs into one allocation unit according to its mapping granularity. + +Cleaning process +---------------- + +F2FS does cleaning both on demand and in the background. On-demand cleaning is +triggered when there are not enough free segments to serve VFS calls. Background +cleaner is operated by a kernel thread, and triggers the cleaning job when the +system is idle. + +F2FS supports two victim selection policies: greedy and cost-benefit algorithms. +In the greedy algorithm, F2FS selects a victim segment having the smallest number +of valid blocks. In the cost-benefit algorithm, F2FS selects a victim segment +according to the segment age and the number of valid blocks in order to address +log block thrashing problem in the greedy algorithm. F2FS adopts the greedy +algorithm for on-demand cleaner, while background cleaner adopts cost-benefit +algorithm. + +In order to identify whether the data in the victim segment are valid or not, +F2FS manages a bitmap. Each bit represents the validity of a block, and the +bitmap is composed of a bit stream covering whole blocks in main area. diff --git a/Documentation/filesystems/nfs/nfs41-server.txt b/Documentation/filesystems/nfs/nfs41-server.txt index 092fad92a3f0..01c2db769791 100644 --- a/Documentation/filesystems/nfs/nfs41-server.txt +++ b/Documentation/filesystems/nfs/nfs41-server.txt @@ -39,21 +39,10 @@ interoperability problems with future clients. Known issues: from a linux client are possible, but we aren't really conformant with the spec (for example, we don't use kerberos on the backchannel correctly). - - Incomplete backchannel support: incomplete backchannel gss - support and no support for BACKCHANNEL_CTL mean that - callbacks (hence delegations and layouts) may not be - available and clients confused by the incomplete - implementation may fail. - We do not support SSV, which provides security for shared client-server state (thus preventing unauthorized tampering with locks and opens, for example). It is mandatory for servers to support this, though no clients use it yet. - - Mandatory operations which we do not support, such as - DESTROY_CLIENTID, are not currently used by clients, but will be - (and the spec recommends their uses in common cases), and - clients should not be expected to know how to recover from the - case where they are not supported. This will eventually cause - interoperability failures. In addition, some limitations are inherited from the current NFSv4 implementation: @@ -89,7 +78,7 @@ Operations | | MNI | or OPT) | | +----------------------+------------+--------------+----------------+ | ACCESS | REQ | | Section 18.1 | -NS | BACKCHANNEL_CTL | REQ | | Section 18.33 | +I | BACKCHANNEL_CTL | REQ | | Section 18.33 | I | BIND_CONN_TO_SESSION | REQ | | Section 18.34 | | CLOSE | REQ | | Section 18.2 | | COMMIT | REQ | | Section 18.3 | @@ -99,7 +88,7 @@ NS*| DELEGPURGE | OPT | FDELG (REQ) | Section 18.5 | | DELEGRETURN | OPT | FDELG, | Section 18.6 | | | | DDELG, pNFS | | | | | (REQ) | | -NS | DESTROY_CLIENTID | REQ | | Section 18.50 | +I | DESTROY_CLIENTID | REQ | | Section 18.50 | I | DESTROY_SESSION | REQ | | Section 18.37 | I | EXCHANGE_ID | REQ | | Section 18.35 | I | FREE_STATEID | REQ | | Section 18.38 | @@ -192,7 +181,6 @@ EXCHANGE_ID: CREATE_SESSION: * backchannel attributes are ignored -* backchannel security parameters are ignored SEQUENCE: * no support for dynamic slot table renegotiation (optional) @@ -202,7 +190,7 @@ Nonstandard compound limitations: ca_maxrequestsize request and a ca_maxresponsesize reply, so we may fail to live up to the promise we made in CREATE_SESSION fore channel negotiation. -* No more than one IO operation (read, write, readdir) allowed per - compound. +* No more than one read-like operation allowed per compound; encoding + replies that cross page boundaries (except for read data) not handled. See also http://wiki.linux-nfs.org/wiki/index.php/Server_4.0_and_4.1_issues. diff --git a/Documentation/filesystems/porting b/Documentation/filesystems/porting index 0742feebc6e2..4db22f6491e0 100644 --- a/Documentation/filesystems/porting +++ b/Documentation/filesystems/porting @@ -281,7 +281,7 @@ ext2_write_failed and callers for an example. [mandatory] - ->truncate is going away. The whole truncate sequence needs to be + ->truncate is gone. The whole truncate sequence needs to be implemented in ->setattr, which is now mandatory for filesystems implementing on-disk size changes. Start with a copy of the old inode_setattr and vmtruncate, and the reorder the vmtruncate + foofs_vmtruncate sequence to @@ -441,3 +441,7 @@ d_make_root() drops the reference to inode if dentry allocation fails. 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. diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt index a1793d670cd0..fd8d0d594fc7 100644 --- a/Documentation/filesystems/proc.txt +++ b/Documentation/filesystems/proc.txt @@ -33,7 +33,7 @@ Table of Contents 2 Modifying System Parameters 3 Per-Process Parameters - 3.1 /proc/<pid>/oom_score_adj - Adjust the oom-killer + 3.1 /proc/<pid>/oom_adj & /proc/<pid>/oom_score_adj - Adjust the oom-killer score 3.2 /proc/<pid>/oom_score - Display current oom-killer score 3.3 /proc/<pid>/io - Display the IO accounting fields @@ -41,6 +41,7 @@ Table of Contents 3.5 /proc/<pid>/mountinfo - Information about mounts 3.6 /proc/<pid>/comm & /proc/<pid>/task/<tid>/comm 3.7 /proc/<pid>/task/<tid>/children - Information about task children + 3.8 /proc/<pid>/fdinfo/<fd> - Information about opened file 4 Configuring procfs 4.1 Mount options @@ -142,7 +143,7 @@ Table 1-1: Process specific entries in /proc pagemap Page table stack Report full stack trace, enable via CONFIG_STACKTRACE smaps a extension based on maps, showing the memory consumption of - each mapping + each mapping and flags associated with it .............................................................................. For example, to get the status information of a process, all you have to do is @@ -181,6 +182,7 @@ read the file /proc/PID/status: CapPrm: 0000000000000000 CapEff: 0000000000000000 CapBnd: ffffffffffffffff + Seccomp: 0 voluntary_ctxt_switches: 0 nonvoluntary_ctxt_switches: 1 @@ -237,6 +239,7 @@ Table 1-2: Contents of the status files (as of 2.6.30-rc7) CapPrm bitmap of permitted capabilities CapEff bitmap of effective capabilities CapBnd bitmap of capabilities bounding set + Seccomp seccomp mode, like prctl(PR_GET_SECCOMP, ...) Cpus_allowed mask of CPUs on which this process may run Cpus_allowed_list Same as previous, but in "list format" Mems_allowed mask of memory nodes allowed to this process @@ -415,8 +418,9 @@ Swap: 0 kB KernelPageSize: 4 kB MMUPageSize: 4 kB Locked: 374 kB +VmFlags: rd ex mr mw me de -The first of these lines shows the same information as is displayed for the +the first of these lines shows the same information as is displayed for the mapping in /proc/PID/maps. The remaining lines show the size of the mapping (size), the amount of the mapping that is currently resident in RAM (RSS), the process' proportional share of this mapping (PSS), the number of clean and @@ -430,6 +434,41 @@ and a page is modified, the file page is replaced by a private anonymous copy. "Swap" shows how much would-be-anonymous memory is also used, but out on swap. +"VmFlags" field deserves a separate description. This member represents the kernel +flags associated with the particular virtual memory area in two letter encoded +manner. The codes are the following: + rd - readable + wr - writeable + ex - executable + sh - shared + mr - may read + mw - may write + me - may execute + ms - may share + gd - stack segment growns down + pf - pure PFN range + dw - disabled write to the mapped file + lo - pages are locked in memory + io - memory mapped I/O area + sr - sequential read advise provided + rr - random read advise provided + dc - do not copy area on fork + de - do not expand area on remapping + ac - area is accountable + nr - swap space is not reserved for the area + ht - area uses huge tlb pages + nl - non-linear mapping + ar - architecture specific flag + dd - do not include area into core dump + mm - mixed map area + hg - huge page advise flag + nh - no-huge page advise flag + mg - mergable advise flag + +Note that there is no guarantee that every flag and associated mnemonic will +be present in all further kernel releases. Things get changed, the flags may +be vanished or the reverse -- new added. + This file is only present if the CONFIG_MMU kernel configuration option is enabled. @@ -1320,10 +1359,10 @@ of the kernel. CHAPTER 3: PER-PROCESS PARAMETERS ------------------------------------------------------------------------------ -3.1 /proc/<pid>/oom_score_adj- Adjust the oom-killer score +3.1 /proc/<pid>/oom_adj & /proc/<pid>/oom_score_adj- Adjust the oom-killer score -------------------------------------------------------------------------------- -This file can be used to adjust the badness heuristic used to select which +These file can be used to adjust the badness heuristic used to select which process gets killed in out of memory conditions. The badness heuristic assigns a value to each candidate task ranging from 0 @@ -1361,6 +1400,12 @@ same system, cpuset, mempolicy, or memory controller resources to use at least equivalent to discounting 50% of the task's allowed memory from being considered as scoring against the task. +For backwards compatibility with previous kernels, /proc/<pid>/oom_adj may also +be used to tune the badness score. Its acceptable values range from -16 +(OOM_ADJUST_MIN) to +15 (OOM_ADJUST_MAX) and a special value of -17 +(OOM_DISABLE) to disable oom killing entirely for that task. Its value is +scaled linearly with /proc/<pid>/oom_score_adj. + The value of /proc/<pid>/oom_score_adj may be reduced no lower than the last value set by a CAP_SYS_RESOURCE process. To reduce the value any lower requires CAP_SYS_RESOURCE. @@ -1375,7 +1420,9 @@ minimal amount of work. ------------------------------------------------------------- This file can be used to check the current score used by the oom-killer is for -any given <pid>. +any given <pid>. Use it together with /proc/<pid>/oom_score_adj to tune which +process should be killed in an out-of-memory situation. + 3.3 /proc/<pid>/io - Display the IO accounting fields ------------------------------------------------------- @@ -1587,6 +1634,93 @@ pids, so one need to either stop or freeze processes being inspected if precise results are needed. +3.7 /proc/<pid>/fdinfo/<fd> - Information about opened file +--------------------------------------------------------------- +This file provides information associated with an opened file. The regular +files have at least two fields -- 'pos' and 'flags'. The 'pos' represents +the current offset of the opened file in decimal form [see lseek(2) for +details] and 'flags' denotes the octal O_xxx mask the file has been +created with [see open(2) for details]. + +A typical output is + + pos: 0 + flags: 0100002 + +The files such as eventfd, fsnotify, signalfd, epoll among the regular pos/flags +pair provide additional information particular to the objects they represent. + + Eventfd files + ~~~~~~~~~~~~~ + pos: 0 + flags: 04002 + eventfd-count: 5a + + where 'eventfd-count' is hex value of a counter. + + Signalfd files + ~~~~~~~~~~~~~~ + pos: 0 + flags: 04002 + sigmask: 0000000000000200 + + where 'sigmask' is hex value of the signal mask associated + with a file. + + Epoll files + ~~~~~~~~~~~ + pos: 0 + flags: 02 + tfd: 5 events: 1d data: ffffffffffffffff + + where 'tfd' is a target file descriptor number in decimal form, + 'events' is events mask being watched and the 'data' is data + associated with a target [see epoll(7) for more details]. + + Fsnotify files + ~~~~~~~~~~~~~~ + For inotify files the format is the following + + pos: 0 + flags: 02000000 + inotify wd:3 ino:9e7e sdev:800013 mask:800afce ignored_mask:0 fhandle-bytes:8 fhandle-type:1 f_handle:7e9e0000640d1b6d + + where 'wd' is a watch descriptor in decimal form, ie a target file + descriptor number, 'ino' and 'sdev' are inode and device where the + target file resides and the 'mask' is the mask of events, all in hex + form [see inotify(7) for more details]. + + If the kernel was built with exportfs support, the path to the target + file is encoded as a file handle. The file handle is provided by three + fields 'fhandle-bytes', 'fhandle-type' and 'f_handle', all in hex + format. + + If the kernel is built without exportfs support the file handle won't be + printed out. + + If there is no inotify mark attached yet the 'inotify' line will be omitted. + + For fanotify files the format is + + pos: 0 + flags: 02 + fanotify flags:10 event-flags:0 + fanotify mnt_id:12 mflags:40 mask:38 ignored_mask:40000003 + fanotify ino:4f969 sdev:800013 mflags:0 mask:3b ignored_mask:40000000 fhandle-bytes:8 fhandle-type:1 f_handle:69f90400c275b5b4 + + where fanotify 'flags' and 'event-flags' are values used in fanotify_init + call, 'mnt_id' is the mount point identifier, 'mflags' is the value of + flags associated with mark which are tracked separately from events + mask. 'ino', 'sdev' are target inode and device, 'mask' is the events + mask and 'ignored_mask' is the mask of events which are to be ignored. + All in hex format. Incorporation of 'mflags', 'mask' and 'ignored_mask' + does provide information about flags and mask used in fanotify_mark + call [see fsnotify manpage for details]. + + While the first three lines are mandatory and always printed, the rest is + optional and may be omitted if no marks created yet. + + ------------------------------------------------------------------------------ Configuring procfs ------------------------------------------------------------------------------ diff --git a/Documentation/filesystems/vfat.txt b/Documentation/filesystems/vfat.txt index de1e6c4dccff..d230dd9c99b0 100644 --- a/Documentation/filesystems/vfat.txt +++ b/Documentation/filesystems/vfat.txt @@ -111,6 +111,15 @@ tz=UTC -- Interpret timestamps as UTC rather than local time. useful when mounting devices (like digital cameras) that are set to UTC in order to avoid the pitfalls of local time. +time_offset=minutes + -- Set offset for conversion of timestamps from local time + used by FAT to UTC. I.e. <minutes> minutes will be subtracted + from each timestamp to convert it to UTC used internally by + Linux. This is useful when time zone set in sys_tz is + not the time zone used by the filesystem. Note that this + option still does not provide correct time stamps in all + cases in presence of DST - time stamps in a different DST + setting will be off by one hour. showexec -- If set, the execute permission bits of the file will be allowed only if the extension part of the name is .EXE, diff --git a/Documentation/filesystems/vfs.txt b/Documentation/filesystems/vfs.txt index 2ee133e030c3..bc4b06b3160a 100644 --- a/Documentation/filesystems/vfs.txt +++ b/Documentation/filesystems/vfs.txt @@ -350,7 +350,6 @@ struct inode_operations { int (*readlink) (struct dentry *, char __user *,int); void * (*follow_link) (struct dentry *, struct nameidata *); void (*put_link) (struct dentry *, struct nameidata *, void *); - void (*truncate) (struct inode *); int (*permission) (struct inode *, int); int (*get_acl)(struct inode *, int); int (*setattr) (struct dentry *, struct iattr *); @@ -431,16 +430,6 @@ otherwise noted. started might not be in the page cache at the end of the walk). - truncate: Deprecated. This will not be called if ->setsize is defined. - Called by the VFS to change the size of a file. The - i_size field of the inode is set to the desired size by the - VFS before this method is called. This method is called by - the truncate(2) system call and related functionality. - - Note: ->truncate and vmtruncate are deprecated. Do not add new - instances/calls of these. Filesystems should be converted to do their - truncate sequence via ->setattr(). - permission: called by the VFS to check for access rights on a POSIX-like filesystem. @@ -911,6 +900,7 @@ defined: struct dentry_operations { int (*d_revalidate)(struct dentry *, unsigned int); + int (*d_weak_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 *, @@ -926,8 +916,13 @@ struct dentry_operations { 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 @@ -938,6 +933,20 @@ struct dentry_operations { 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. diff --git a/Documentation/filesystems/xfs.txt b/Documentation/filesystems/xfs.txt index 3fc0c31a6f5d..3e4b3dd1e046 100644 --- a/Documentation/filesystems/xfs.txt +++ b/Documentation/filesystems/xfs.txt @@ -43,7 +43,7 @@ When mounting an XFS filesystem, the following options are accepted. 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. This option is incompatible with the nodelaylog option. + impact. dmapi Enable the DMAPI (Data Management API) event callouts. @@ -72,8 +72,15 @@ When mounting an XFS filesystem, the following options are accepted. 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 - provided for backwards compatibility, but causes problems for - backup applications that cannot handle large inode numbers. + the default allocation option. Applications which do not handle + inode numbers bigger than 32 bits, should use inode32 option. + + 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. largeio/nolargeio If "nolargeio" is specified, the optimal I/O reported in diff --git a/Documentation/firmware_class/README b/Documentation/firmware_class/README index 815b711bcd85..43fada989e65 100644 --- a/Documentation/firmware_class/README +++ b/Documentation/firmware_class/README @@ -22,12 +22,17 @@ - calls request_firmware(&fw_entry, $FIRMWARE, device) - kernel searchs the fimware image with name $FIRMWARE directly in the below search path of root filesystem: + User customized search path by module parameter 'path'[1] "/lib/firmware/updates/" UTS_RELEASE, "/lib/firmware/updates", "/lib/firmware/" UTS_RELEASE, "/lib/firmware" - If found, goto 7), else goto 2) + [1], the 'path' is a string parameter which length should be less + than 256, user should pass 'firmware_class.path=$CUSTOMIZED_PATH' + if firmware_class is built in kernel(the general situation) + 2), userspace: - /sys/class/firmware/xxx/{loading,data} appear. - hotplug gets called with a firmware identifier in $FIRMWARE @@ -114,3 +119,10 @@ on the setup, so I think that the choice on what firmware to make persistent should be left to userspace. + about firmware cache: + -------------------- + After firmware cache mechanism is introduced during system sleep, + request_firmware can be called safely inside device's suspend and + resume callback, and callers need't cache the firmware by + themselves any more for dealing with firmware loss during system + resume. diff --git a/Documentation/gpio.txt b/Documentation/gpio.txt index e08a883de36e..77a1d11af723 100644 --- a/Documentation/gpio.txt +++ b/Documentation/gpio.txt @@ -439,6 +439,48 @@ slower clock delays the rising edge of SCK, and the I2C master adjusts its signaling rate accordingly. +GPIO controllers and the pinctrl subsystem +------------------------------------------ + +A GPIO controller on a SOC might be tightly coupled with the pinctrl +subsystem, in the sense that the pins can be used by other functions +together with an optional gpio feature. We have already covered the +case where e.g. a GPIO controller need to reserve a pin or set the +direction of a pin by calling any of: + +pinctrl_request_gpio() +pinctrl_free_gpio() +pinctrl_gpio_direction_input() +pinctrl_gpio_direction_output() + +But how does the pin control subsystem cross-correlate the GPIO +numbers (which are a global business) to a certain pin on a certain +pin controller? + +This is done by registering "ranges" of pins, which are essentially +cross-reference tables. These are described in +Documentation/pinctrl.txt + +While the pin allocation is totally managed by the pinctrl subsystem, +gpio (under gpiolib) is still maintained by gpio drivers. It may happen +that different pin ranges in a SoC is managed by different gpio drivers. + +This makes it logical to let gpio drivers announce their pin ranges to +the pin ctrl subsystem before it will call 'pinctrl_request_gpio' in order +to request the corresponding pin to be prepared by the pinctrl subsystem +before any gpio usage. + +For this, the gpio controller can register its pin range with pinctrl +subsystem. There are two ways of doing it currently: with or without DT. + +For with DT support refer to Documentation/devicetree/bindings/gpio/gpio.txt. + +For non-DT support, user can call gpiochip_add_pin_range() with appropriate +parameters to register a range of gpio pins with a pinctrl driver. For this +exact name string of pinctrl device has to be passed as one of the +argument to this routine. + + What do these conventions omit? =============================== One of the biggest things these conventions omit is pin multiplexing, since diff --git a/Documentation/hid/hid-sensor.txt b/Documentation/hid/hid-sensor.txt index 948b0989c433..948b0989c433 100755..100644 --- a/Documentation/hid/hid-sensor.txt +++ b/Documentation/hid/hid-sensor.txt diff --git a/Documentation/hid/uhid.txt b/Documentation/hid/uhid.txt index 4627c4241ece..3c741214dfbb 100644 --- a/Documentation/hid/uhid.txt +++ b/Documentation/hid/uhid.txt @@ -108,7 +108,7 @@ the request was handled successfully. UHID_FEATURE_ANSWER: If you receive a UHID_FEATURE request you must answer with this request. You must copy the "id" field from the request into the answer. Set the "err" field - to 0 if no error occured or to EIO if an I/O error occurred. + to 0 if no error occurred or to EIO if an I/O error occurred. If "err" is 0 then you should fill the buffer of the answer with the results of the feature request and set "size" correspondingly. diff --git a/Documentation/hwmon/adm1275 b/Documentation/hwmon/adm1275 index 2cfa25667123..15b4a20d5062 100644 --- a/Documentation/hwmon/adm1275 +++ b/Documentation/hwmon/adm1275 @@ -15,7 +15,7 @@ Supported chips: 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/ads7828 b/Documentation/hwmon/ads7828 index 2bbebe6f771f..f6e263e0f607 100644 --- a/Documentation/hwmon/ads7828 +++ b/Documentation/hwmon/ads7828 @@ -4,29 +4,47 @@ Kernel driver ads7828 Supported chips: * Texas Instruments/Burr-Brown ADS7828 Prefix: 'ads7828' - Addresses scanned: I2C 0x48, 0x49, 0x4a, 0x4b - Datasheet: Publicly available at the Texas Instruments website : + Datasheet: Publicly available at the Texas Instruments website: http://focus.ti.com/lit/ds/symlink/ads7828.pdf + * Texas Instruments ADS7830 + Prefix: 'ads7830' + Datasheet: Publicly available at the Texas Instruments website: + http://focus.ti.com/lit/ds/symlink/ads7830.pdf + Authors: Steve Hardy <shardy@redhat.com> + Vivien Didelot <vivien.didelot@savoirfairelinux.com> + Guillaume Roguez <guillaume.roguez@savoirfairelinux.com> + +Platform data +------------- + +The ads7828 driver accepts an optional ads7828_platform_data structure (defined +in include/linux/platform_data/ads7828.h). The structure fields are: -Module Parameters ------------------ +* diff_input: (bool) Differential operation + set to true for differential mode, false for default single ended mode. -* se_input: bool (default Y) - Single ended operation - set to N for differential mode -* int_vref: bool (default Y) - Operate with the internal 2.5V reference - set to N for external reference -* vref_mv: int (default 2500) - If using an external reference, set this to the reference voltage in mV +* ext_vref: (bool) External reference + set to true if it operates with an external reference, false for default + internal reference. + +* vref_mv: (unsigned int) Voltage reference + if using an external reference, set this to the reference voltage in mV, + otherwise it will default to the internal value (2500mV). This value will be + bounded with limits accepted by the chip, described in the datasheet. + + If no structure is provided, the configuration defaults to single ended + operation and internal voltage reference (2.5V). Description ----------- -This driver implements support for the Texas Instruments ADS7828. +This driver implements support for the Texas Instruments ADS7828 and ADS7830. -This device is a 12-bit 8-channel A-D converter. +The ADS7828 device is a 12-bit 8-channel A/D converter, while the ADS7830 does +8-bit sampling. It can operate in single ended mode (8 +ve inputs) or in differential mode, where 4 differential pairs can be measured. @@ -34,3 +52,7 @@ where 4 differential pairs can be measured. The chip also has the facility to use an external voltage reference. This may be required if your hardware supplies the ADS7828 from a 5V supply, see the datasheet for more details. + +There is no reliable way to identify this chip, so the driver will not scan +some addresses to try to auto-detect it. That means that you will have to +statically declare the device in the platform support code. diff --git a/Documentation/hwmon/adt7410 b/Documentation/hwmon/adt7410 index 96004000dc2a..58150c480e56 100644 --- a/Documentation/hwmon/adt7410 +++ b/Documentation/hwmon/adt7410 @@ -4,9 +4,14 @@ Kernel driver adt7410 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 Author: Hartmut Knaack <knaack.h@gmx.de> @@ -27,6 +32,10 @@ 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 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.) + Configuration Notes ------------------- diff --git a/Documentation/hwmon/coretemp b/Documentation/hwmon/coretemp index f17256f069ba..fec5a9bf755f 100644 --- a/Documentation/hwmon/coretemp +++ b/Documentation/hwmon/coretemp @@ -66,6 +66,7 @@ Process Processor TjMax(C) 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 @@ Process Processor TjMax(C) 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,14 +102,21 @@ Process Processor TjMax(C) 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 + N570/550 100 N475/470/455/450 100 N280/270 90 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/da9055 b/Documentation/hwmon/da9055 new file mode 100644 index 000000000000..855c3f536e00 --- /dev/null +++ b/Documentation/hwmon/da9055 @@ -0,0 +1,47 @@ +Supported chips: + * Dialog Semiconductors DA9055 PMIC + Prefix: 'da9055' + Datasheet: Datasheet is not publicly available. + +Authors: David Dajun Chen <dchen@diasemi.com> + +Description +----------- + +The DA9055 provides an Analogue to Digital Converter (ADC) with 10 bits +resolution and track and hold circuitry combined with an analogue input +multiplexer. The analogue input multiplexer will allow conversion of up to 5 +different inputs. The track and hold circuit ensures stable input voltages at +the input of the ADC during the conversion. + +The ADC is used to measure the following inputs: +Channel 0: VDDOUT - measurement of the system voltage +Channel 1: ADC_IN1 - high impedance input (0 - 2.5V) +Channel 2: ADC_IN2 - high impedance input (0 - 2.5V) +Channel 3: ADC_IN3 - high impedance input (0 - 2.5V) +Channel 4: Internal Tjunc. - sense (internal temp. sensor) + +By using sysfs attributes we can measure the system voltage VDDOUT, +chip junction temperature and auxiliary channels voltages. + +Voltage Monitoring +------------------ + +Voltages are sampled in a AUTO mode it can be manually sampled too and results +are stored in a 10 bit ADC. + +The system voltage is calculated as: + Milli volt = ((ADC value * 1000) / 85) + 2500 + +The voltages on ADC channels 1, 2 and 3 are calculated as: + Milli volt = (ADC value * 1000) / 102 + +Temperature Monitoring +---------------------- + +Temperatures are sampled by a 10 bit ADC. Junction temperatures +are monitored by the ADC channels. + +The junction temperature is calculated: + Degrees celsius = -0.4084 * (ADC_RES - T_OFFSET) + 307.6332 +The junction temperature attribute is supported by the driver. diff --git a/Documentation/hwmon/ina209 b/Documentation/hwmon/ina209 new file mode 100644 index 000000000000..672501de4509 --- /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/it87 b/Documentation/hwmon/it87 index 87850d86c559..c263740f0cba 100644 --- a/Documentation/hwmon/it87 +++ b/Documentation/hwmon/it87 @@ -30,6 +30,14 @@ Supported chips: 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 @@ Description ----------- 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 @@ The IT8726F is just bit enhanced IT8716F with additional hardware 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. @@ -209,3 +217,13 @@ doesn't use CPU cycles. Trip points must be set properly before switching to automatic fan speed control mode. The driver will perform basic integrity checks before actually switching to automatic control mode. + + +Temperature offset attributes +----------------------------- + +The driver supports temp[1-3]_offset sysfs attributes to adjust the reported +temperature for thermal diodes or diode-connected thermal transistors. +If a temperature sensor is configured for thermistors, the attribute values +are ignored. If the thermal sensor type is Intel PECI, the temperature offset +must be programmed to the critical CPU temperature. diff --git a/Documentation/hwmon/jc42 b/Documentation/hwmon/jc42 index 66ecb9fc8246..868d74d6b773 100644 --- a/Documentation/hwmon/jc42 +++ b/Documentation/hwmon/jc42 @@ -17,12 +17,13 @@ Supported chips: * 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 @@ Supported chips: 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 2ba5ed126858..83b2ddc160c8 100644 --- a/Documentation/hwmon/lineage-pem +++ b/Documentation/hwmon/lineage-pem @@ -8,7 +8,7 @@ Supported devices: 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 a21db81c4591..26025e419d35 100644 --- a/Documentation/hwmon/lm25066 +++ b/Documentation/hwmon/lm25066 @@ -19,7 +19,7 @@ Supported chips: Datasheet: http://www.national.com/pf/LM/LM5066.html -Author: Guenter Roeck <guenter.roeck@ericsson.com> +Author: Guenter Roeck <linux@roeck-us.net> Description diff --git a/Documentation/hwmon/lm73 b/Documentation/hwmon/lm73 new file mode 100644 index 000000000000..8af059dcb642 --- /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/ltc2978 b/Documentation/hwmon/ltc2978 index c365f9beb5dd..e4d75c606c97 100644 --- a/Documentation/hwmon/ltc2978 +++ b/Documentation/hwmon/ltc2978 @@ -5,13 +5,13 @@ Supported chips: * 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 -Author: Guenter Roeck <guenter.roeck@ericsson.com> +Author: Guenter Roeck <linux@roeck-us.net> Description diff --git a/Documentation/hwmon/ltc4261 b/Documentation/hwmon/ltc4261 index eba2e2c4b94d..9378a75c6134 100644 --- a/Documentation/hwmon/ltc4261 +++ b/Documentation/hwmon/ltc4261 @@ -8,7 +8,7 @@ Supported chips: 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 f8b478076f6d..d59cc7829bec 100644 --- a/Documentation/hwmon/max16064 +++ b/Documentation/hwmon/max16064 @@ -7,7 +7,7 @@ Supported chips: 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 c11f64a1f2ad..208a29e43010 100644 --- a/Documentation/hwmon/max16065 +++ b/Documentation/hwmon/max16065 @@ -24,7 +24,7 @@ Supported chips: 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 04482226db20..37cbf472a19d 100644 --- a/Documentation/hwmon/max34440 +++ b/Documentation/hwmon/max34440 @@ -16,8 +16,18 @@ Supported chips: 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 @@ Description 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 @@ temp[1-8]_reset_history Write any value to reset history. 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 000000000000..6594177ededa --- /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 fe849871df32..e78078638b91 100644 --- a/Documentation/hwmon/max8688 +++ b/Documentation/hwmon/max8688 @@ -7,7 +7,7 @@ Supported chips: 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/pmbus b/Documentation/hwmon/pmbus index f90f99920cc5..cf756ed48ff9 100644 --- a/Documentation/hwmon/pmbus +++ b/Documentation/hwmon/pmbus @@ -34,7 +34,7 @@ Supported chips: Addresses scanned: - Datasheet: n.a. -Author: Guenter Roeck <guenter.roeck@ericsson.com> +Author: Guenter Roeck <linux@roeck-us.net> Description @@ -138,7 +138,7 @@ Sysfs entries When probing the chip, the driver identifies which PMBus registers are supported, and determines available sensors from this information. -Attribute files only exist if respective sensors are suported by the chip. +Attribute files only exist if respective sensors are supported by the chip. Labels are provided to inform the user about the sensor associated with a given sysfs entry. diff --git a/Documentation/hwmon/smm665 b/Documentation/hwmon/smm665 index 59e316140542..a341eeedab75 100644 --- a/Documentation/hwmon/smm665 +++ b/Documentation/hwmon/smm665 @@ -29,7 +29,7 @@ Supported chips: 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/sysfs-interface b/Documentation/hwmon/sysfs-interface index 1f4dd855a299..79f8257dd790 100644 --- a/Documentation/hwmon/sysfs-interface +++ b/Documentation/hwmon/sysfs-interface @@ -722,14 +722,14 @@ add/subtract if it has been divided before the add/subtract. 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/ucd9000 b/Documentation/hwmon/ucd9000 index 0df5f276505b..805e33edb978 100644 --- a/Documentation/hwmon/ucd9000 +++ b/Documentation/hwmon/ucd9000 @@ -11,7 +11,7 @@ Supported chips: 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 fd7d07b1908a..1e8060e631bd 100644 --- a/Documentation/hwmon/ucd9200 +++ b/Documentation/hwmon/ucd9200 @@ -15,7 +15,7 @@ Supported chips: 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/vexpress b/Documentation/hwmon/vexpress new file mode 100644 index 000000000000..557d6d5ad90d --- /dev/null +++ b/Documentation/hwmon/vexpress @@ -0,0 +1,34 @@ +Kernel driver vexpress +====================== + +Supported systems: + * ARM Ltd. Versatile Express platform + Prefix: 'vexpress' + Datasheets: + * "Hardware Description" sections of the Technical Reference Manuals + for the Versatile Express boards: + http://infocenter.arm.com/help/topic/com.arm.doc.subset.boards.express/index.html + * Section "4.4.14. System Configuration registers" of the V2M-P1 TRM: + http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0447-/index.html + +Author: Pawel Moll + +Description +----------- + +Versatile Express platform (http://www.arm.com/versatileexpress/) is a +reference & prototyping system for ARM Ltd. processors. It can be set up +from a wide range of boards, each of them containing (apart of the main +chip/FPGA) a number of microcontrollers responsible for platform +configuration and control. Theses microcontrollers can also monitor the +board and its environment by a number of internal and external sensors, +providing information about power lines voltages and currents, board +temperature and power usage. Some of them also calculate consumed energy +and provide a cumulative use counter. + +The configuration devices are _not_ memory mapped and must be accessed +via a custom interface, abstracted by the "vexpress_config" API. + +As these devices are non-discoverable, they must be described in a Device +Tree passed to the kernel. Details of the DT binding for them can be found +in Documentation/devicetree/bindings/hwmon/vexpress.txt. diff --git a/Documentation/hwmon/zl6100 b/Documentation/hwmon/zl6100 index a995b41724fd..756b57c6b73e 100644 --- a/Documentation/hwmon/zl6100 +++ b/Documentation/hwmon/zl6100 @@ -54,7 +54,7 @@ http://archive.ericsson.net/service/internet/picov/get?DocNo=28701-EN/LZT146401 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_max_alarm Input voltage high alarm. 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 minumum 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-i801 b/Documentation/i2c/busses/i2c-i801 index 157416e78cc4..d55b8ab2d10f 100644 --- a/Documentation/i2c/busses/i2c-i801 +++ b/Documentation/i2c/busses/i2c-i801 @@ -22,6 +22,8 @@ Supported adapters: * Intel Panther Point (PCH) * Intel Lynx Point (PCH) * Intel Lynx Point-LP (PCH) + * Intel Avoton (SOC) + * Intel Wellsburg (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 000000000000..737355822c0b --- /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-sis630 b/Documentation/i2c/busses/i2c-sis630 index 0b9697366930..ee7943631074 100644 --- a/Documentation/i2c/busses/i2c-sis630 +++ b/Documentation/i2c/busses/i2c-sis630 @@ -4,9 +4,11 @@ Supported adapters: * 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 @@ Module Parameters * 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 @@ or like this: 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 abf63615ee05..22182660dda7 100644 --- a/Documentation/i2c/instantiating-devices +++ b/Documentation/i2c/instantiating-devices @@ -91,7 +91,7 @@ Example (from the nxp OHCI driver): 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 49f5b680809d..6012b12b3510 100644 --- a/Documentation/i2c/smbus-protocol +++ b/Documentation/i2c/smbus-protocol @@ -23,6 +23,12 @@ don't match these function names. For some of the operations which pass a single data byte, the functions using SMBus protocol operation names execute a different protocol operation entirely. +Each transaction type corresponds to a functionality flag. Before calling a +transaction function, a device driver should always check (just once) for +the corresponding functionality flag to ensure that the underlying I2C +adapter supports the transaction in question. See +<file:Documentation/i2c/functionality> for the details. + Key to symbols ============== @@ -49,6 +55,8 @@ This sends a single bit to the device, at the place of the Rd/Wr bit. A Addr Rd/Wr [A] P +Functionality flag: I2C_FUNC_SMBUS_QUICK + SMBus Receive Byte: i2c_smbus_read_byte() ========================================== @@ -60,6 +68,8 @@ the previous SMBus command. S Addr Rd [A] [Data] NA P +Functionality flag: I2C_FUNC_SMBUS_READ_BYTE + SMBus Send Byte: i2c_smbus_write_byte() ======================================== @@ -69,6 +79,8 @@ to a device. See Receive Byte for more information. S Addr Wr [A] Data [A] P +Functionality flag: I2C_FUNC_SMBUS_WRITE_BYTE + SMBus Read Byte: i2c_smbus_read_byte_data() ============================================ @@ -78,6 +90,8 @@ The register is specified through the Comm byte. S Addr Wr [A] Comm [A] S Addr Rd [A] [Data] NA P +Functionality flag: I2C_FUNC_SMBUS_READ_BYTE_DATA + SMBus Read Word: i2c_smbus_read_word_data() ============================================ @@ -88,6 +102,8 @@ byte. But this time, the data is a complete word (16 bits). S Addr Wr [A] Comm [A] S Addr Rd [A] [DataLow] A [DataHigh] NA P +Functionality flag: I2C_FUNC_SMBUS_READ_WORD_DATA + Note the convenience function i2c_smbus_read_word_swapped is available for reads where the two data bytes are the other way around (not SMBus compliant, but very popular.) @@ -102,6 +118,8 @@ the Read Byte operation. S Addr Wr [A] Comm [A] Data [A] P +Functionality flag: I2C_FUNC_SMBUS_WRITE_BYTE_DATA + SMBus Write Word: i2c_smbus_write_word_data() ============================================== @@ -112,13 +130,15 @@ specified through the Comm byte. S Addr Wr [A] Comm [A] DataLow [A] DataHigh [A] P +Functionality flag: I2C_FUNC_SMBUS_WRITE_WORD_DATA + Note the convenience function i2c_smbus_write_word_swapped is available for writes where the two data bytes are the other way 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. @@ -126,6 +146,8 @@ This command selects a device register (through the Comm byte), sends S Addr Wr [A] Comm [A] DataLow [A] DataHigh [A] S Addr Rd [A] [DataLow] A [DataHigh] NA P +Functionality flag: I2C_FUNC_SMBUS_PROC_CALL + SMBus Block Read: i2c_smbus_read_block_data() ============================================== @@ -137,6 +159,8 @@ of data is specified by the device in the Count byte. S Addr Wr [A] Comm [A] S Addr Rd [A] [Count] A [Data] A [Data] A ... A [Data] NA P +Functionality flag: I2C_FUNC_SMBUS_READ_BLOCK_DATA + SMBus Block Write: i2c_smbus_write_block_data() ================================================ @@ -147,6 +171,8 @@ Comm byte. The amount of data is specified in the Count byte. S Addr Wr [A] Comm [A] Count [A] Data [A] Data [A] ... [A] Data [A] P +Functionality flag: I2C_FUNC_SMBUS_WRITE_BLOCK_DATA + SMBus Block Write - Block Read Process Call =========================================== @@ -160,6 +186,8 @@ This command selects a device register (through the Comm byte), sends S Addr Wr [A] Comm [A] Count [A] Data [A] ... S Addr Rd [A] [Count] A [Data] ... A P +Functionality flag: I2C_FUNC_SMBUS_BLOCK_PROC_CALL + SMBus Host Notify ================= @@ -229,15 +257,7 @@ designated register that is specified through the Comm byte. S Addr Wr [A] Comm [A] S Addr Rd [A] [Data] A [Data] A ... A [Data] NA P - -I2C Block Read (2 Comm bytes) -============================= - -This command reads a block of bytes from a device, from a -designated register that is specified through the two Comm bytes. - -S Addr Wr [A] Comm1 [A] Comm2 [A] - S Addr Rd [A] [Data] A [Data] A ... A [Data] NA P +Functionality flag: I2C_FUNC_SMBUS_READ_I2C_BLOCK I2C Block Write: i2c_smbus_write_i2c_block_data() @@ -249,3 +269,5 @@ Comm byte. Note that command lengths of 0, 2, or more bytes are supported as they are indistinguishable from data. S Addr Wr [A] Comm [A] Data [A] Data [A] ... [A] Data [A] P + +Functionality flag: I2C_FUNC_SMBUS_WRITE_I2C_BLOCK diff --git a/Documentation/i2c/writing-clients b/Documentation/i2c/writing-clients index 3a94b0e6f601..6b344b516bff 100644 --- a/Documentation/i2c/writing-clients +++ b/Documentation/i2c/writing-clients @@ -365,8 +365,6 @@ in terms of it. Never use this function directly! 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 @@ These ones were removed from i2c-core because they had no users, but could 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/input/alps.txt b/Documentation/input/alps.txt index 9b1084c8c0b3..e544c7ff8cfa 100644 --- a/Documentation/input/alps.txt +++ b/Documentation/input/alps.txt @@ -161,7 +161,7 @@ number of contacts (f1 and f0 in the table below). This packet only appears after a position packet with the mt bit set, and usually only appears when there are two or more contacts (although -occassionally it's seen with only a single contact). +occasionally it's seen with only a single contact). The final v3 packet type is the trackstick packet. diff --git a/Documentation/input/event-codes.txt b/Documentation/input/event-codes.txt index 53305bd08182..f1ea2c69648d 100644 --- a/Documentation/input/event-codes.txt +++ b/Documentation/input/event-codes.txt @@ -196,6 +196,17 @@ EV_MSC: EV_MSC events are used for input and output events that do not fall under other categories. +A few EV_MSC codes have special meaning: + +* MSC_TIMESTAMP: + - Used to report the number of microseconds since the last reset. This event + should be coded as an uint32 value, which is allowed to wrap around with + no special consequence. It is assumed that the time difference between two + consecutive events is reliable on a reasonable time scale (hours). + A reset to zero can happen, in which case the time since the last event is + unknown. If the device does not provide this information, the driver must + not provide it to user space. + EV_LED: ---------- EV_LED events are used for input and output to set and query the state of diff --git a/Documentation/intel_txt.txt b/Documentation/intel_txt.txt index 849de1a78e77..91d89c540709 100644 --- a/Documentation/intel_txt.txt +++ b/Documentation/intel_txt.txt @@ -192,7 +192,7 @@ grub.conf needs to be modified as follows: 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 2152b0e7237d..3210540f8bd3 100644 --- a/Documentation/ioctl/ioctl-number.txt +++ b/Documentation/ioctl/ioctl-number.txt @@ -179,7 +179,7 @@ Code Seq#(hex) Include File Comments '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/kbuild/kconfig-language.txt b/Documentation/kbuild/kconfig-language.txt index a686f9cd69c1..c858f8419eba 100644 --- a/Documentation/kbuild/kconfig-language.txt +++ b/Documentation/kbuild/kconfig-language.txt @@ -388,26 +388,3 @@ config FOO 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 a09f1a6a830c..b8b77bbc784f 100644 --- a/Documentation/kbuild/kconfig.txt +++ b/Documentation/kbuild/kconfig.txt @@ -46,6 +46,12 @@ KCONFIG_OVERWRITECONFIG 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' diff --git a/Documentation/kbuild/makefiles.txt b/Documentation/kbuild/makefiles.txt index ec9ae6708691..5198b742fde1 100644 --- a/Documentation/kbuild/makefiles.txt +++ b/Documentation/kbuild/makefiles.txt @@ -1175,15 +1175,39 @@ When kbuild executes, the following steps are followed (roughly): in an init section in the image. Platform code *must* copy the blob to non-init memory prior to calling unflatten_device_tree(). - Example: - #arch/x86/platform/ce4100/Makefile - clean-files := *dtb.S + To use this command, simply add *.dtb into obj-y or targets, or make + some other target depend on %.dtb - DTC_FLAGS := -p 1024 - obj-y += foo.dtb.o + A central rule exists to create $(obj)/%.dtb from $(src)/%.dts; + architecture Makefiles do no need to explicitly write out that rule. - $(obj)/%.dtb: $(src)/%.dts - $(call cmd,dtc) + Example: + targets += $(dtb-y) + 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 diff --git a/Documentation/kbuild/modules.txt b/Documentation/kbuild/modules.txt index 3fb39e0116b4..69372fb98cf8 100644 --- a/Documentation/kbuild/modules.txt +++ b/Documentation/kbuild/modules.txt @@ -470,7 +470,7 @@ build. Sometimes, an external module uses exported symbols from another external module. kbuild needs to have full knowledge of - all symbols to avoid spitting out warnings about undefined + all symbols to avoid spliitting out warnings about undefined symbols. Three solutions exist for this situation. NOTE: The method with a top-level kbuild file is recommended diff --git a/Documentation/kernel-doc-nano-HOWTO.txt b/Documentation/kernel-doc-nano-HOWTO.txt index 3d8a97747f77..99b57abddf8a 100644 --- a/Documentation/kernel-doc-nano-HOWTO.txt +++ b/Documentation/kernel-doc-nano-HOWTO.txt @@ -64,6 +64,8 @@ Example kernel-doc function comment: * comment lines. * * The longer description can have multiple paragraphs. + * + * Return: Describe the return value of foobar. */ The short description following the subject can span multiple lines @@ -78,6 +80,8 @@ If a function parameter is "..." (varargs), it should be listed in kernel-doc notation as: * @...: description +The return value, if any, should be described in a dedicated section +named "Return". Example kernel-doc data structure comment. @@ -222,6 +226,9 @@ only a "*"). "section header:" names must be unique per function (or struct, union, typedef, enum). +Use the section header "Return" for sections describing the return value +of a function. + Avoid putting a spurious blank line after the function name, or else the description will be repeated! @@ -237,21 +244,21 @@ patterns, which are highlighted appropriately. NOTE 1: The multi-line descriptive text you provide does *not* recognize line breaks, so if you try to format some text nicely, as in: - Return codes + Return: 0 - cool 1 - invalid arg 2 - out of memory this will all run together and produce: - Return codes 0 - cool 1 - invalid arg 2 - out of memory + Return: 0 - cool 1 - invalid arg 2 - out of memory NOTE 2: If the descriptive text you provide has lines that begin with some phrase followed by a colon, each of those phrases will be taken as a new section heading, which means you should similarly try to avoid text like: - Return codes: + Return: 0: cool 1: invalid arg 2: out of memory diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 9776f068306b..4609e81dbc37 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -446,12 +446,6 @@ bytes respectively. Such letter suffixes can also be entirely omitted. possible to determine what the correct size should be. This option provides an override for these situations. - capability.disable= - [SECURITY] Disable capabilities. This would normally - be used only if an alternative security model is to be - configured. Potentially dangerous and should only be - used if you are entirely sure of the consequences. - ccw_timeout_log [S390] See Documentation/s390/CommonIO for details. @@ -570,6 +564,8 @@ bytes respectively. Such letter suffixes can also be entirely omitted. 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 @@ -600,6 +596,9 @@ bytes respectively. Such letter suffixes can also be entirely omitted. is selected automatically. Check Documentation/kdump/kdump.txt for further details. + crashkernel_low=size[KMG] + [KNL, x86] parts under 4G. + crashkernel=range1:size1[,range2:size2,...][@offset] [KNL] Same as above, but depends on the memory in the running system. The syntax of range is @@ -760,6 +759,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted. earlyprintk= [X86,SH,BLACKFIN] earlyprintk=vga + earlyprintk=xen earlyprintk=serial[,ttySn[,baudrate]] earlyprintk=ttySn[,baudrate] earlyprintk=dbgp[debugController#] @@ -777,6 +777,8 @@ bytes respectively. Such letter suffixes can also be entirely omitted. 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 @@ -905,6 +907,24 @@ bytes respectively. Such letter suffixes can also be entirely omitted. gpt [EFI] Forces disk with valid GPT signature but invalid Protective MBR to be treated as GPT. + grcan.enable0= [HW] Configuration of physical interface 0. Determines + the "Enable 0" bit of the configuration register. + Format: 0 | 1 + Default: 0 + grcan.enable1= [HW] Configuration of physical interface 1. Determines + the "Enable 0" bit of the configuration register. + Format: 0 | 1 + Default: 0 + grcan.select= [HW] Select which physical interface to use. + Format: 0 | 1 + Default: 0 + grcan.txsize= [HW] Sets the size of the tx buffer. + Format: <unsigned int> such that (txsize & ~0x1fffc0) == 0. + Default: 1024 + grcan.rxsize= [HW] Sets the size of the rx buffer. + Format: <unsigned int> such that (rxsize & ~0x1fffc0) == 0. + Default: 1024 + hashdist= [KNL,NUMA] Large hashes allocated during boot are distributed across NUMA nodes. Defaults on for 64-bit NUMA, off otherwise. @@ -958,6 +978,10 @@ bytes respectively. Such letter suffixes can also be entirely omitted. 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 @@ -1027,16 +1051,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted. 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 @@ -1119,6 +1138,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted. 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 @@ -1304,6 +1328,10 @@ bytes respectively. Such letter suffixes can also be entirely omitted. lapic [X86-32,APIC] Enable the local APIC even if BIOS disabled it. + lapic= [x86,APIC] "notscdeadline" Do not use TSC deadline + value for LAPIC timer one-shot implementation. Default + back to the programmable timer unit in the LAPIC. + lapic_timer_c2_ok [X86,APIC] trust the local apic timer in C2 power state. @@ -1481,9 +1509,10 @@ bytes respectively. Such letter suffixes can also be entirely omitted. mem=nn[KMG] [KNL,BOOT] Force usage of a specific amount of memory Amount of memory to be used when the kernel is not able to see the whole system memory or for test. - [X86-32] Use together with memmap= to avoid physical - address space collisions. Without memmap= PCI devices - could be placed at addresses belonging to unused RAM. + [X86] Work as limiting max address. Use together + with memmap= to avoid physical address space collisions. + Without memmap= PCI devices could be placed at addresses + belonging to unused RAM. mem=nopentium [BUGS=X86-32] Disable usage of 4MB pages for kernel memory. @@ -1869,10 +1898,6 @@ bytes respectively. Such letter suffixes can also be entirely omitted. 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. @@ -1984,6 +2009,20 @@ bytes respectively. Such letter suffixes can also be entirely omitted. nox2apic [X86-64,APIC] Do not enable x2APIC mode. + cpu0_hotplug [X86] Turn on CPU0 hotplug feature when + CONFIG_BOOTPARAM_HOTPLUG_CPU0 is off. + Some features depend on CPU0. Known dependencies are: + 1. Resume from suspend/hibernate depends on CPU0. + Suspend/hibernate will fail if CPU0 is offline and you + need to online CPU0 before suspend/hibernate. + 2. PIC interrupts also depend on CPU0. CPU0 can't be + removed if a PIC interrupt is detected. + It's said poweroff/reboot may depend on CPU0 on some + machines although I haven't seen such issues so far + after CPU0 is offline on a few tested machines. + If the dependencies are under your control, you can + turn on cpu0_hotplug. + nptcg= [IA-64] Override max number of concurrent global TLB purges which is reported from either PAL_VM_SUMMARY or SAL PALO. @@ -1996,6 +2035,9 @@ bytes respectively. Such letter suffixes can also be entirely omitted. nr_uarts= [SERIAL] maximum number of UARTs to be registered. + numa_balancing= [KNL,X86] Enable or disable automatic NUMA balancing. + Allowed values are enable and disable + numa_zonelist_order= [KNL, BOOT] Select zonelist order for NUMA. one of ['zone', 'node', 'default'] can be specified This can be set from sysctl after boot. @@ -2193,6 +2235,21 @@ bytes respectively. Such letter suffixes can also be entirely omitted. 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. @@ -2214,6 +2271,12 @@ bytes respectively. Such letter suffixes can also be entirely omitted. 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 @@ -2394,6 +2457,27 @@ bytes respectively. Such letter suffixes can also be entirely omitted. ramdisk_size= [RAM] Sizes of RAM disks in kilobytes See Documentation/blockdev/ramdisk.txt. + rcu_nocbs= [KNL,BOOT] + 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 + offloaded CPUs, which can be useful for HPC and + real-time workloads. It can also improve energy + efficiency for asymmetric multiprocessors. + + rcu_nocb_poll [KNL,BOOT] + Rather than requiring that offloaded CPUs + (specified by rcu_nocbs= above) explicitly + awaken the corresponding "rcuoN" kthreads, + make these kthreads poll for callbacks. + This improves the real-time response for the + offloaded CPUs by relieving them of the need to + wake up the corresponding kthread, but degrades + energy efficiency by requiring that the kthreads + periodically wake up to do the polling. + rcutree.blimit= [KNL,BOOT] Set maximum number of finished RCU callbacks to process in one batch. @@ -2859,6 +2943,22 @@ bytes respectively. Such letter suffixes can also be entirely omitted. to facilitate early boot debugging. See also Documentation/trace/events.txt + trace_options=[option-list] + [FTRACE] Enable or disable tracer options at boot. + The option-list is a comma delimited list of options + that can be enabled or disabled just as if you were + to echo the option name into + + /sys/kernel/debug/tracing/trace_options + + For example, to enable stacktrace option (to dump the + stack trace of each event), add to the command line: + + trace_options=stacktrace + + See also Documentation/trace/ftrace.txt "trace options" + section. + transparent_hugepage= [KNL] Format: [always|madvise|never] diff --git a/Documentation/kref.txt b/Documentation/kref.txt index 48ba715d5a63..ddf85a5dde0c 100644 --- a/Documentation/kref.txt +++ b/Documentation/kref.txt @@ -213,3 +213,91 @@ presentation on krefs, which can be found at: and: http://www.kroah.com/linux/talks/ols_2004_kref_talk/ + +The above example could also be optimized using kref_get_unless_zero() in +the following way: + +static struct my_data *get_entry() +{ + struct my_data *entry = NULL; + mutex_lock(&mutex); + if (!list_empty(&q)) { + entry = container_of(q.next, struct my_data, link); + if (!kref_get_unless_zero(&entry->refcount)) + entry = NULL; + } + mutex_unlock(&mutex); + return entry; +} + +static void release_entry(struct kref *ref) +{ + struct my_data *entry = container_of(ref, struct my_data, refcount); + + mutex_lock(&mutex); + list_del(&entry->link); + mutex_unlock(&mutex); + kfree(entry); +} + +static void put_entry(struct my_data *entry) +{ + kref_put(&entry->refcount, release_entry); +} + +Which is useful to remove the mutex lock around kref_put() in put_entry(), but +it's important that kref_get_unless_zero is enclosed in the same critical +section that finds the entry in the lookup table, +otherwise kref_get_unless_zero may reference already freed memory. +Note that it is illegal to use kref_get_unless_zero without checking its +return value. If you are sure (by already having a valid pointer) that +kref_get_unless_zero() will return true, then use kref_get() instead. + +The function kref_get_unless_zero also makes it possible to use rcu +locking for lookups in the above example: + +struct my_data +{ + struct rcu_head rhead; + . + struct kref refcount; + . + . +}; + +static struct my_data *get_entry_rcu() +{ + struct my_data *entry = NULL; + rcu_read_lock(); + if (!list_empty(&q)) { + entry = container_of(q.next, struct my_data, link); + if (!kref_get_unless_zero(&entry->refcount)) + entry = NULL; + } + rcu_read_unlock(); + return entry; +} + +static void release_entry_rcu(struct kref *ref) +{ + struct my_data *entry = container_of(ref, struct my_data, refcount); + + mutex_lock(&mutex); + list_del_rcu(&entry->link); + mutex_unlock(&mutex); + kfree_rcu(entry, rhead); +} + +static void put_entry(struct my_data *entry) +{ + kref_put(&entry->refcount, release_entry_rcu); +} + +But note that the struct kref member needs to remain in valid memory for a +rcu grace period after release_entry_rcu was called. That can be accomplished +by using kfree_rcu(entry, rhead) as done above, or by calling synchronize_rcu() +before using kfree, but note that synchronize_rcu() may sleep for a +substantial amount of time. + + +Thomas Hellstrom <thellstrom@vmware.com> diff --git a/Documentation/laptops/thinkpad-acpi.txt b/Documentation/laptops/thinkpad-acpi.txt index 9d666828915a..cf7bc6cb9719 100644 --- a/Documentation/laptops/thinkpad-acpi.txt +++ b/Documentation/laptops/thinkpad-acpi.txt @@ -1398,7 +1398,7 @@ Sysfs notes: 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 5fefe374892f..5246090ef15c 100644 --- a/Documentation/leds/00-INDEX +++ b/Documentation/leds/00-INDEX @@ -6,5 +6,7 @@ leds-lp5521.txt - notes on how to use the leds-lp5521 driver. leds-lp5523.txt - notes on how to use the leds-lp5523 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 0e542ab3d4a0..270f57196339 100644 --- a/Documentation/leds/leds-lp5521.txt +++ b/Documentation/leds/leds-lp5521.txt @@ -17,19 +17,8 @@ lp5521:channelx, where x is 0 .. 2 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 @@ The name of each channel can be configurable. 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 @@ static void lp5521_enable(bool state) /* 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, @@ -105,47 +94,9 @@ example of update_config : LP5521_CP_MODE_AUTO | LP5521_R_TO_BATT | \ LP5521_CLK_INT) -static struct lp5521_platform_data lp5521_pdata = { +static struct lp55xx_platform_data lp5521_pdata = { .led_config = lp5521_led_config, .num_channels = ARRAY_SIZE(lp5521_led_config), - .clock_mode = LP5521_CLOCK_INT, + .clock_mode = LP55XX_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 c2743f59f9ac..899fdad509fe 100644 --- a/Documentation/leds/leds-lp5523.txt +++ b/Documentation/leds/leds-lp5523.txt @@ -27,25 +27,8 @@ c) Default 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 @@ Example platform data: 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 @@ static void lp5523_enable(bool state) /* 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-lp55xx.txt b/Documentation/leds/leds-lp55xx.txt new file mode 100644 index 000000000000..ced41868d2d1 --- /dev/null +++ b/Documentation/leds/leds-lp55xx.txt @@ -0,0 +1,118 @@ +LP5521/LP5523/LP55231 Common Driver +=================================== + +Authors: Milo(Woogyom) Kim <milo.kim@ti.com> + +Description +----------- +LP5521, LP5523/55231 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. diff --git a/Documentation/lockstat.txt b/Documentation/lockstat.txt index cef00d42ed5b..dd2f7b26ca30 100644 --- a/Documentation/lockstat.txt +++ b/Documentation/lockstat.txt @@ -65,7 +65,7 @@ that had to wait on lock acquisition. - CONFIGURATION -Lock statistics are enabled via CONFIG_LOCK_STATS. +Lock statistics are enabled via CONFIG_LOCK_STAT. - USAGE diff --git a/Documentation/magic-number.txt b/Documentation/magic-number.txt index 82761a31d64d..76d80a64bbe1 100644 --- a/Documentation/magic-number.txt +++ b/Documentation/magic-number.txt @@ -122,7 +122,7 @@ SLAB_C_MAGIC 0x4f17a36d kmem_cache mm/slab.c 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/media-framework.txt b/Documentation/media-framework.txt index 802875413873..77bd0a42f19d 100644 --- a/Documentation/media-framework.txt +++ b/Documentation/media-framework.txt @@ -336,7 +336,7 @@ Calls to media_entity_pipeline_start() can be nested. The pipeline pointer must 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 2759f7c188f0..fa5d8a9ae205 100644 --- a/Documentation/memory-barriers.txt +++ b/Documentation/memory-barriers.txt @@ -251,12 +251,13 @@ And there are a number of things that _must_ or _must_not_ be assumed: And for: - *A = X; Y = *A; + *A = X; *(A + 4) = Y; - we may get either of: + we may get any of: - STORE *A = X; Y = LOAD *A; - STORE *A = Y = X; + STORE *A = X; STORE *(A + 4) = Y; + STORE *(A + 4) = Y; STORE *A = X; + STORE {*A, *(A + 4) } = {X, Y}; ========================= @@ -1684,6 +1685,7 @@ explicit lock operations, described later). These include: xchg(); cmpxchg(); + atomic_xchg(); atomic_cmpxchg(); atomic_inc_return(); atomic_dec_return(); diff --git a/Documentation/memory-hotplug.txt b/Documentation/memory-hotplug.txt index 6d0c2519cf47..8e5eacbdcfa3 100644 --- a/Documentation/memory-hotplug.txt +++ b/Documentation/memory-hotplug.txt @@ -161,7 +161,8 @@ a recent addition and not present on older kernels. in the memory block. 'state' : read-write at read: contains online/offline state of memory. - at write: user can specify "online", "offline" command + at write: user can specify "online_kernel", + "online_movable", "online", "offline" command which will be performed on al sections in the block. 'phys_device' : read-only: designed to show the name of physical memory device. This is not well implemented now. @@ -255,6 +256,17 @@ For onlining, you have to write "online" to the section's state file as: % echo online > /sys/devices/system/memory/memoryXXX/state +This onlining will not change the ZONE type of the target memory section, +If the memory section is in ZONE_NORMAL, you can change it to ZONE_MOVABLE: + +% echo online_movable > /sys/devices/system/memory/memoryXXX/state +(NOTE: current limit: this memory section must be adjacent to ZONE_MOVABLE) + +And if the memory section is in ZONE_MOVABLE, you can change it to ZONE_NORMAL: + +% echo online_kernel > /sys/devices/system/memory/memoryXXX/state +(NOTE: current limit: this memory section must be adjacent to ZONE_NORMAL) + After this, section memoryXXX's state will be 'online' and the amount of available memory will be increased. @@ -377,15 +389,21 @@ The third argument is passed by pointer of struct memory_notify. struct memory_notify { unsigned long start_pfn; unsigned long nr_pages; + int status_change_nid_normal; + int status_change_nid_high; int status_change_nid; } start_pfn is start_pfn of online/offline memory. nr_pages is # of pages of online/offline memory. -status_change_nid is set node id when N_HIGH_MEMORY of nodemask is (will be) +status_change_nid_normal is set node id when N_NORMAL_MEMORY of nodemask +is (will be) set/clear, if this is -1, then nodemask status is not changed. +status_change_nid_high is set node id when N_HIGH_MEMORY of nodemask +is (will be) set/clear, if this is -1, then nodemask status is not changed. +status_change_nid is set node id when N_MEMORY of nodemask is (will be) set/clear. It means a new(memoryless) node gets new memory by online and a node loses all memory. If this is -1, then nodemask status is not changed. -If status_changed_nid >= 0, callback should create/discard structures for the +If status_changed_nid* >= 0, callback should create/discard structures for the node if necessary. -------------- diff --git a/Documentation/metag/00-INDEX b/Documentation/metag/00-INDEX new file mode 100644 index 000000000000..db11c513bd5c --- /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 000000000000..7b8dee83b9c1 --- /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. Futher +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-amt-version.c b/Documentation/misc-devices/mei/mei-amt-version.c index 01804f216312..49e4f770864a 100644 --- a/Documentation/misc-devices/mei/mei-amt-version.c +++ b/Documentation/misc-devices/mei/mei-amt-version.c @@ -214,7 +214,7 @@ out: } /*************************************************************************** - * Intel Advanced Management Technolgy ME Client + * Intel Advanced Management Technology ME Client ***************************************************************************/ #define AMT_MAJOR_VERSION 1 @@ -256,7 +256,7 @@ struct amt_code_versions { } __attribute__((packed)); /*************************************************************************** - * Intel Advanced Management Technolgy Host Interface + * Intel Advanced Management Technology Host Interface ***************************************************************************/ struct amt_host_if_msg_header { diff --git a/Documentation/mmc/mmc-dev-attrs.txt b/Documentation/mmc/mmc-dev-attrs.txt index 22ae8441489f..0d98fac8893b 100644 --- a/Documentation/mmc/mmc-dev-attrs.txt +++ b/Documentation/mmc/mmc-dev-attrs.txt @@ -25,6 +25,8 @@ All attributes are read-only. serial Product Serial Number (from CID Register) erase_size Erase group size preferred_erase_size Preferred erase size + raw_rpmb_size_mult RPMB partition size + rel_sectors Reliable write sector count Note on Erase Size and Preferred Erase Size: @@ -65,6 +67,11 @@ Note on Erase Size and Preferred Erase Size: "preferred_erase_size" is in bytes. +Note on raw_rpmb_size_mult: + "raw_rpmb_size_mult" is a mutliple of 128kB block. + RPMB size in byte is calculated by using the following equation: + RPMB partition size = 128kB x raw_rpmb_size_mult + SD/MMC/SDIO Clock Gating Attribute ================================== diff --git a/Documentation/namespaces/resource-control.txt b/Documentation/namespaces/resource-control.txt new file mode 100644 index 000000000000..abc13c394738 --- /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/00-INDEX b/Documentation/networking/00-INDEX index 2cc3c7733a2f..258d9b92c36f 100644 --- a/Documentation/networking/00-INDEX +++ b/Documentation/networking/00-INDEX @@ -52,8 +52,6 @@ de4x5.txt - 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 @@ e1000e.txt - 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 @@ -126,8 +122,6 @@ ltpc.txt - 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 55d24433d151..000000000000 --- 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 e7fb2c6023bc..2ae3b64983ab 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/batman-adv.txt b/Documentation/networking/batman-adv.txt index a173d2a879f5..c1d82047a4b1 100644 --- a/Documentation/networking/batman-adv.txt +++ b/Documentation/networking/batman-adv.txt @@ -203,7 +203,8 @@ abled during run time. Following log_levels are defined: 2 - Enable messages related to route added / changed / deleted 4 - Enable messages related to translation table operations 8 - Enable messages related to bridge loop avoidance -15 - enable all messages +16 - Enable messaged related to DAT, ARP snooping and parsing +31 - Enable all messages The debug output can be changed at runtime using the file /sys/class/net/bat0/mesh/log_level. e.g. diff --git a/Documentation/networking/cs89x0.txt b/Documentation/networking/cs89x0.txt index c725d33b316f..0e190180eec8 100644 --- a/Documentation/networking/cs89x0.txt +++ b/Documentation/networking/cs89x0.txt @@ -36,7 +36,6 @@ TABLE OF CONTENTS 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 @@ The compile-time optionality for DMA was removed in the 2.3 kernel 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 24c6b26e5658..000000000000 --- 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 90e9e5f16e6b..000000000000 --- 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 bbf2005270b5..cdb3e40b9d14 100644 --- a/Documentation/networking/filter.txt +++ b/Documentation/networking/filter.txt @@ -17,12 +17,12 @@ creating filters. 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 @@ the old one and placing your new one in its place, assuming your 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/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt index c7fc10724948..dc2dc87d2557 100644 --- a/Documentation/networking/ip-sysctl.txt +++ b/Documentation/networking/ip-sysctl.txt @@ -26,20 +26,33 @@ route/max_size - INTEGER 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: 256 + neigh/default/gc_thresh3 - INTEGER Maximum number of neighbor entries allowed. Increase this when using large numbers of interfaces and when communicating with large numbers of directly-connected peers. + Default: 1024 neigh/default/unres_qlen_bytes - INTEGER 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) + Setting negative value is meaningless and will return error. + Default: 65536 Bytes(64KB) neigh/default/unres_qlen - INTEGER The maximum number of packets which may be queued for each unresolved address by other network layers. (deprecated in linux 3.3) : use unres_qlen_bytes instead. + Prior to linux 3.3, the default value is 3 which may cause + unexpected packet loss. The current default value is calculated + according to default value of unres_qlen_bytes and true size of + packet. + Default: 31 mtu_expires - INTEGER Time, in seconds, that cached PMTU information is kept. @@ -117,17 +130,6 @@ somaxconn - INTEGER 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 @@ -199,15 +201,17 @@ tcp_early_retrans - INTEGER Default: 2 tcp_ecn - INTEGER - Enable Explicit Congestion Notification (ECN) in TCP. ECN is only - used when both ends of the TCP flow support it. It is useful to - avoid losses due to congestion (when the bottleneck router supports - ECN). + Control use of Explicit Congestion Notification (ECN) by TCP. + ECN is used only when both ends of the TCP connection indicate + support for it. This feature is useful in avoiding losses due + to congestion by allowing supporting routers to signal + congestion before having to drop packets. Possible values are: - 0 disable ECN - 1 ECN enabled - 2 Only server-side ECN enabled. If the other end does - not support ECN, behavior is like with ECN disabled. + 0 Disable ECN. Neither initiate nor accept ECN. + 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 tcp_fack - BOOLEAN @@ -215,15 +219,14 @@ tcp_fack - BOOLEAN The value is not used, if tcp_sack is not enabled. tcp_fin_timeout - INTEGER - Time to hold socket in state FIN-WAIT-2, if it was closed - by our side. Peer can be broken and never close its side, - or even died unexpectedly. Default value is 60sec. - Usual value used in 2.2 was 180 seconds, you may restore - it, but remember that if your machine is even underloaded WEB server, - you risk to overflow memory with kilotons of dead sockets, - FIN-WAIT-2 sockets are less dangerous than FIN-WAIT-1, - because they eat maximum 1.5K of memory, but they tend - to live longer. Cf. tcp_max_orphans. + The length of time an orphaned (no longer referenced by any + application) connection will remain in the FIN_WAIT_2 state + before it is aborted at the local end. While a perfectly + valid "receive only" state for an un-orphaned connection, an + orphaned connection in FIN_WAIT_2 state could otherwise wait + forever for the remote to close its end of the connection. + Cf. tcp_max_orphans + Default: 60 seconds tcp_frto - INTEGER Enables Forward RTO-Recovery (F-RTO) defined in RFC4138. @@ -495,7 +498,7 @@ tcp_fastopen - INTEGER 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. @@ -1323,6 +1326,12 @@ force_tllao - BOOLEAN 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. @@ -1514,6 +1523,20 @@ cookie_preserve_enable - BOOLEAN Default: 1 +cookie_hmac_alg - STRING + Select the hmac algorithm used when generating the cookie value sent by + a listening sctp socket to a connecting client in the INIT-ACK chunk. + Valid values are: + * md5 + * sha1 + * none + Ability to assign md5 or sha1 as the selected alg is predicated on the + configuration of those algorithms at build time (CONFIG_CRYPTO_MD5 and + CONFIG_CRYPTO_SHA1). + + Default: Dependent on configuration. MD5 if available, else SHA1 if + available, else none. + rcvbuf_policy - INTEGER Determines if the receive buffer is attributed to the socket or to association. SCTP supports the capability to create multiple @@ -1526,7 +1549,7 @@ rcvbuf_policy - INTEGER 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/multicast.txt b/Documentation/networking/multicast.txt deleted file mode 100644 index b06c8c69266f..000000000000 --- 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 2e9e0ae2cd45..a5d574a9ae09 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 @@ Examples: 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/netdev-features.txt b/Documentation/networking/netdev-features.txt index 4164f5c02e4b..f310edec8a77 100644 --- a/Documentation/networking/netdev-features.txt +++ b/Documentation/networking/netdev-features.txt @@ -164,4 +164,4 @@ read the CRC recorded by the NIC on receipt of the packet. This requests that the NIC receive all possible frames, including errored frames (such as bad FCS, etc). This can be helpful when sniffing a link with bad packets on it. Some NICs may receive more packets if also put into normal -PROMISC mdoe. +PROMISC mode. diff --git a/Documentation/networking/nf_conntrack-sysctl.txt b/Documentation/networking/nf_conntrack-sysctl.txt new file mode 100644 index 000000000000..70da5086153d --- /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 1a77a3cfae54..97694572338b 100644 --- a/Documentation/networking/operstates.txt +++ b/Documentation/networking/operstates.txt @@ -88,6 +88,10 @@ set this flag. On netif_carrier_off(), the scheduler stops sending 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 1c08a4b0981f..94444b152fbc 100644 --- a/Documentation/networking/packet_mmap.txt +++ b/Documentation/networking/packet_mmap.txt @@ -3,9 +3,9 @@ -------------------------------------------------------------------------------- This file documents the mmap() facility available with the PACKET -socket interface on 2.4 and 2.6 kernels. This type of sockets is used for -capture network traffic with utilities like tcpdump or any other that needs -raw access to network interface. +socket interface on 2.4/2.6/3.x kernels. This type of sockets is used for +i) capture network traffic with utilities like tcpdump, ii) transmit network +traffic, or any other that needs raw access to network interface. You can find the latest version of this document at: http://wiki.ipxwarzone.com/index.php5?title=Linux_packet_mmap @@ -21,19 +21,18 @@ Please send your comments to + Why use PACKET_MMAP -------------------------------------------------------------------------------- -In Linux 2.4/2.6 if PACKET_MMAP is not enabled, the capture process is very -inefficient. It uses very limited buffers and requires one system call -to capture each packet, it requires two if you want to get packet's -timestamp (like libpcap always does). +In Linux 2.4/2.6/3.x if PACKET_MMAP is not enabled, the capture process is very +inefficient. It uses very limited buffers and requires one system call to +capture each packet, it requires two if you want to get packet's timestamp +(like libpcap always does). In the other hand PACKET_MMAP is very efficient. PACKET_MMAP provides a size configurable circular buffer mapped in user space that can be used to either send or receive packets. This way reading packets just needs to wait for them, most of the time there is no need to issue a single system call. Concerning transmission, multiple packets can be sent through one system call to get the -highest bandwidth. -By using a shared buffer between the kernel and the user also has the benefit -of minimizing packet copies. +highest bandwidth. By using a shared buffer between the kernel and the user +also has the benefit of minimizing packet copies. It's fine to use PACKET_MMAP to improve the performance of the capture and transmission process, but it isn't everything. At least, if you are capturing @@ -41,7 +40,8 @@ at high speeds (this is relative to the cpu speed), you should check if the device driver of your network interface card supports some sort of interrupt load mitigation or (even better) if it supports NAPI, also make sure it is enabled. For transmission, check the MTU (Maximum Transmission Unit) used and -supported by devices of your network. +supported by devices of your network. CPU IRQ pinning of your network interface +card can also be an advantage. -------------------------------------------------------------------------------- + How to use mmap() to improve capture process @@ -87,9 +87,7 @@ the following process: socket creation and destruction is straight forward, and is done the same way with or without PACKET_MMAP: -int fd; - -fd= socket(PF_PACKET, mode, htons(ETH_P_ALL)) + int fd = socket(PF_PACKET, mode, htons(ETH_P_ALL)); where mode is SOCK_RAW for the raw interface were link level information can be captured or SOCK_DGRAM for the cooked @@ -163,11 +161,23 @@ As capture, each frame contains two parts: A complete tutorial is available at: http://wiki.gnu-log.net/ +By default, the user should put data at : + frame base + TPACKET_HDRLEN - sizeof(struct sockaddr_ll) + +So, whatever you choose for the socket mode (SOCK_DGRAM or SOCK_RAW), +the beginning of the user data will be at : + frame base + TPACKET_ALIGN(sizeof(struct tpacket_hdr)) + +If you wish to put user data at a custom offset from the beginning of +the frame (for payload alignment with SOCK_RAW mode for instance) you +can set tp_net (with SOCK_DGRAM) or tp_mac (with SOCK_RAW). In order +to make this work it must be enabled previously with setsockopt() +and the PACKET_TX_HAS_OFF option. + -------------------------------------------------------------------------------- + PACKET_MMAP settings -------------------------------------------------------------------------------- - To setup PACKET_MMAP from user level code is done with a call like - Capture process @@ -201,7 +211,6 @@ indeed, packet_set_ring checks that the following condition is true frames_per_block * tp_block_nr == tp_frame_nr - Lets see an example, with the following values: tp_block_size= 4096 @@ -227,7 +236,6 @@ be spawned across two blocks, so there are some details you have to take into account when choosing the frame_size. See "Mapping and use of the circular buffer (ring)". - -------------------------------------------------------------------------------- + PACKET_MMAP setting constraints -------------------------------------------------------------------------------- @@ -264,7 +272,6 @@ User space programs can include /usr/include/sys/user.h and The pagesize can also be determined dynamically with the getpagesize (2) system call. - Block number limit -------------------- @@ -284,7 +291,6 @@ called pg_vec, its size limits the number of blocks that can be allocated. v block #2 block #1 - kmalloc allocates any number of bytes of physically contiguous memory from a pool of pre-determined sizes. This pool of memory is maintained by the slab allocator which is at the end the responsible for doing the allocation and @@ -299,7 +305,6 @@ pointers to blocks is 131072/4 = 32768 blocks - PACKET_MMAP buffer size calculator ------------------------------------ @@ -340,7 +345,6 @@ and a value for <frame size> of 2048 bytes. These parameters will yield and hence the buffer will have a 262144 MiB size. So it can hold 262144 MiB / 2048 bytes = 134217728 frames - Actually, this buffer size is not possible with an i386 architecture. Remember that the memory is allocated in kernel space, in the case of an i386 kernel's memory size is limited to 1GiB. @@ -372,7 +376,6 @@ the following (from include/linux/if_packet.h): - Start+tp_net: Packet data, aligned to TPACKET_ALIGNMENT=16. - Pad to align to TPACKET_ALIGNMENT=16 */ - The following are conditions that are checked in packet_set_ring @@ -413,7 +416,6 @@ and the following flags apply: #define TP_STATUS_LOSING 4 #define TP_STATUS_CSUMNOTREADY 8 - TP_STATUS_COPY : This flag indicates that the frame (and associated meta information) has been truncated because it's larger than tp_frame_size. This packet can be @@ -462,7 +464,6 @@ packets are in the ring: It doesn't incur in a race condition to first check the status value and then poll for frames. - ++ Transmission process Those defines are also used for transmission: @@ -494,6 +495,196 @@ The user can also use poll() to check if a buffer is available: retval = poll(&pfd, 1, timeout); ------------------------------------------------------------------------------- ++ What TPACKET versions are available and when to use them? +------------------------------------------------------------------------------- + + int val = tpacket_version; + setsockopt(fd, SOL_PACKET, PACKET_VERSION, &val, sizeof(val)); + getsockopt(fd, SOL_PACKET, PACKET_VERSION, &val, sizeof(val)); + +where 'tpacket_version' can be TPACKET_V1 (default), TPACKET_V2, TPACKET_V3. + +TPACKET_V1: + - Default if not otherwise specified by setsockopt(2) + - RX_RING, TX_RING available + - VLAN metadata information available for packets + (TP_STATUS_VLAN_VALID) + +TPACKET_V1 --> TPACKET_V2: + - Made 64 bit clean due to unsigned long usage in TPACKET_V1 + structures, thus this also works on 64 bit kernel with 32 bit + userspace and the like + - Timestamp resolution in nanoseconds instead of microseconds + - RX_RING, TX_RING available + - How to switch to TPACKET_V2: + 1. Replace struct tpacket_hdr by struct tpacket2_hdr + 2. Query header len and save + 3. Set protocol version to 2, set up ring as usual + 4. For getting the sockaddr_ll, + use (void *)hdr + TPACKET_ALIGN(hdrlen) instead of + (void *)hdr + TPACKET_ALIGN(sizeof(struct tpacket_hdr)) + +TPACKET_V2 --> TPACKET_V3: + - Flexible buffer implementation: + 1. Blocks can be configured with non-static frame-size + 2. Read/poll is at a block-level (as opposed to packet-level) + 3. Added poll timeout to avoid indefinite user-space wait + on idle links + 4. Added user-configurable knobs: + 4.1 block::timeout + 4.2 tpkt_hdr::sk_rxhash + - RX Hash data available in user space + - Currently only RX_RING available + +------------------------------------------------------------------------------- ++ AF_PACKET fanout mode +------------------------------------------------------------------------------- + +In the AF_PACKET fanout mode, packet reception can be load balanced among +processes. This also works in combination with mmap(2) on packet sockets. + +Minimal example code by David S. Miller (try things like "./test eth0 hash", +"./test eth0 lb", etc.): + +#include <stddef.h> +#include <stdlib.h> +#include <stdio.h> +#include <string.h> + +#include <sys/types.h> +#include <sys/wait.h> +#include <sys/socket.h> +#include <sys/ioctl.h> + +#include <unistd.h> + +#include <linux/if_ether.h> +#include <linux/if_packet.h> + +#include <net/if.h> + +static const char *device_name; +static int fanout_type; +static int fanout_id; + +#ifndef PACKET_FANOUT +# define PACKET_FANOUT 18 +# define PACKET_FANOUT_HASH 0 +# define PACKET_FANOUT_LB 1 +#endif + +static int setup_socket(void) +{ + int err, fd = socket(AF_PACKET, SOCK_RAW, htons(ETH_P_IP)); + struct sockaddr_ll ll; + struct ifreq ifr; + int fanout_arg; + + if (fd < 0) { + perror("socket"); + return EXIT_FAILURE; + } + + memset(&ifr, 0, sizeof(ifr)); + strcpy(ifr.ifr_name, device_name); + err = ioctl(fd, SIOCGIFINDEX, &ifr); + if (err < 0) { + perror("SIOCGIFINDEX"); + return EXIT_FAILURE; + } + + memset(&ll, 0, sizeof(ll)); + ll.sll_family = AF_PACKET; + ll.sll_ifindex = ifr.ifr_ifindex; + err = bind(fd, (struct sockaddr *) &ll, sizeof(ll)); + if (err < 0) { + perror("bind"); + return EXIT_FAILURE; + } + + fanout_arg = (fanout_id | (fanout_type << 16)); + err = setsockopt(fd, SOL_PACKET, PACKET_FANOUT, + &fanout_arg, sizeof(fanout_arg)); + if (err) { + perror("setsockopt"); + return EXIT_FAILURE; + } + + return fd; +} + +static void fanout_thread(void) +{ + int fd = setup_socket(); + int limit = 10000; + + if (fd < 0) + exit(fd); + + while (limit-- > 0) { + char buf[1600]; + int err; + + err = read(fd, buf, sizeof(buf)); + if (err < 0) { + perror("read"); + exit(EXIT_FAILURE); + } + if ((limit % 10) == 0) + fprintf(stdout, "(%d) \n", getpid()); + } + + fprintf(stdout, "%d: Received 10000 packets\n", getpid()); + + close(fd); + exit(0); +} + +int main(int argc, char **argp) +{ + int fd, err; + int i; + + if (argc != 3) { + fprintf(stderr, "Usage: %s INTERFACE {hash|lb}\n", argp[0]); + return EXIT_FAILURE; + } + + if (!strcmp(argp[2], "hash")) + fanout_type = PACKET_FANOUT_HASH; + else if (!strcmp(argp[2], "lb")) + fanout_type = PACKET_FANOUT_LB; + else { + fprintf(stderr, "Unknown fanout type [%s]\n", argp[2]); + exit(EXIT_FAILURE); + } + + device_name = argp[1]; + fanout_id = getpid() & 0xffff; + + for (i = 0; i < 4; i++) { + pid_t pid = fork(); + + switch (pid) { + case 0: + fanout_thread(); + + case -1: + perror("fork"); + exit(EXIT_FAILURE); + } + } + + for (i = 0; i < 4; i++) { + int status; + + wait(&status); + } + + return 0; +} + +------------------------------------------------------------------------------- + PACKET_TIMESTAMP ------------------------------------------------------------------------------- @@ -519,6 +710,13 @@ the networking stack is used (the behavior before this setting was added). See include/linux/net_tstamp.h and Documentation/networking/timestamping for more information on hardware timestamps. +------------------------------------------------------------------------------- ++ Miscellaneous bits +------------------------------------------------------------------------------- + +- Packet sockets work well together with Linux socket filters, thus you also + might want to have a look at Documentation/networking/filter.txt + -------------------------------------------------------------------------------- + THANKS -------------------------------------------------------------------------------- diff --git a/Documentation/networking/phy.txt b/Documentation/networking/phy.txt index 95e5f5985a2a..d5b1a3935245 100644 --- a/Documentation/networking/phy.txt +++ b/Documentation/networking/phy.txt @@ -103,7 +103,7 @@ Letting the PHY Abstraction Layer do Everything 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 @@ Letting the PHY Abstraction Layer do Everything 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 @@ Doing it all yourself 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/stmmac.txt b/Documentation/networking/stmmac.txt index ef9ee71b4d7f..f9fa6db40a52 100644 --- a/Documentation/networking/stmmac.txt +++ b/Documentation/networking/stmmac.txt @@ -29,11 +29,9 @@ The kernel configuration option is STMMAC_ETH: dma_txsize: DMA tx ring size; buf_sz: DMA buffer size; tc: control the HW FIFO threshold; - tx_coe: Enable/Disable Tx Checksum Offload engine; watchdog: transmit timeout (in milliseconds); flow_ctrl: Flow control ability [on/off]; pause: Flow Control Pause Time; - tmrate: timer period (only if timer optimisation is configured). 3) Command line options Driver parameters can be also passed in command line by using: @@ -60,17 +58,19 @@ Then the poll method will be scheduled at some future point. The incoming packets are stored, by the DMA, in a list of pre-allocated socket buffers in order to avoid the memcpy (Zero-copy). -4.3) Timer-Driver Interrupt -Instead of having the device that asynchronously notifies the frame receptions, -the driver configures a timer to generate an interrupt at regular intervals. -Based on the granularity of the timer, the frames that are received by the -device will experience different levels of latency. Some NICs have dedicated -timer device to perform this task. STMMAC can use either the RTC device or the -TMU channel 2 on STLinux platforms. -The timers frequency can be passed to the driver as parameter; when change it, -take care of both hardware capability and network stability/performance impact. -Several performance tests on STM platforms showed this optimisation allows to -spare the CPU while having the maximum throughput. +4.3) Interrupt Mitigation +The driver is able to mitigate the number of its DMA interrupts +using NAPI for the reception on chips older than the 3.50. +New chips have an HW RX-Watchdog used for this mitigation. + +On Tx-side, the mitigation schema is based on a SW timer that calls the +tx function (stmmac_tx) to reclaim the resource after transmitting the +frames. +Also there is another parameter (like a threshold) used to program +the descriptors avoiding to set the interrupt on completion bit in +when the frame is sent (xmit). + +Mitigation parameters can be tuned by ethtool. 4.4) WOL Wake up on Lan feature through Magic and Unicast frames are supported for the @@ -121,6 +121,7 @@ struct plat_stmmacenet_data { int bugged_jumbo; int pmt; int force_sf_dma_mode; + int riwt_off; void (*fix_mac_speed)(void *priv, unsigned int speed); void (*bus_setup)(void __iomem *ioaddr); int (*init)(struct platform_device *pdev); @@ -156,6 +157,7 @@ Where: o pmt: core has the embedded power module (optional). o force_sf_dma_mode: force DMA to use the Store and Forward mode instead of the Threshold. + o riwt_off: force to disable the RX watchdog feature and switch to NAPI mode. o fix_mac_speed: this callback is used for modifying some syscfg registers (on ST SoCs) according to the link speed negotiated by the physical layer . diff --git a/Documentation/networking/tuntap.txt b/Documentation/networking/tuntap.txt index c0aab985bad9..949d5dcdd9a3 100644 --- a/Documentation/networking/tuntap.txt +++ b/Documentation/networking/tuntap.txt @@ -105,6 +105,83 @@ Copyright (C) 1999-2000 Maxim Krasnyansky <max_mk@yahoo.com> 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/vxlan.txt b/Documentation/networking/vxlan.txt index 5b34b762d7d5..6d993510f091 100644 --- a/Documentation/networking/vxlan.txt +++ b/Documentation/networking/vxlan.txt @@ -32,7 +32,7 @@ no entry is in the forwarding table. # ip link delete vxlan0 3. Show vxlan info - # ip -d show vxlan0 + # ip -d link show vxlan0 It is possible to create, destroy and display the vxlan forwarding table using the new bridge command. @@ -41,7 +41,7 @@ forwarding table using the new bridge command. # bridge fdb add to 00:17:42:8a:b4:05 dst 192.19.0.2 dev vxlan0 2. Delete forwarding table entry - # bridge fdb delete 00:17:42:8a:b4:05 + # bridge fdb delete 00:17:42:8a:b4:05 dev vxlan0 3. Show forwarding table # bridge fdb show dev vxlan0 diff --git a/Documentation/nfc/nfc-hci.txt b/Documentation/nfc/nfc-hci.txt index 89a339c9b079..0686c9e211c2 100644 --- a/Documentation/nfc/nfc-hci.txt +++ b/Documentation/nfc/nfc-hci.txt @@ -17,10 +17,12 @@ HCI 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 @@ The Session initialization is an HCI standard which must unfortunately 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 @@ without knowing the pipe connected to it. 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 @@ struct nfc_hci_ops { 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 +-------------- + +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 -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 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 @@ Execution Contexts 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 @@ waiting command execution. Response processing involves invoking the completion 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 2fcac9f5996e..b36ca14ca2d6 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 @@ and third (LSB) bytes of the message. The maximum FW message length is 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/pinctrl.txt b/Documentation/pinctrl.txt index 3b4ee5328868..a2b57e0a1db0 100644 --- a/Documentation/pinctrl.txt +++ b/Documentation/pinctrl.txt @@ -364,6 +364,9 @@ 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. +Calling pinctrl_add_gpio_range from pinctrl driver is DEPRECATED. Please see +section 2.1 of Documentation/devicetree/bindings/gpio/gpio.txt on how to bind +pinctrl and gpio drivers. PINMUX interfaces ================= @@ -969,6 +972,18 @@ pinmux core. 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 @@ -1094,9 +1109,9 @@ situations that can be electrically unpleasant, you will certainly want to 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 @@ -1193,4 +1208,6 @@ foo_switch() ... } -The above has to be done from process context. +The above has to be done from process context. The reservation of the pins +will be done when the state is activated, so in effect one specific pin +can be used by different functions at different times on a running system. diff --git a/Documentation/power/freezing-of-tasks.txt b/Documentation/power/freezing-of-tasks.txt index 6ec291ea1c78..85894d83b352 100644 --- a/Documentation/power/freezing-of-tasks.txt +++ b/Documentation/power/freezing-of-tasks.txt @@ -223,3 +223,8 @@ since they ask the freezer to skip freezing this task, since it is anyway 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/opp.txt b/Documentation/power/opp.txt index 3035d00757ad..425c51d56aef 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 @@ Contents 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 17e130a80347..79a2a58425ee 100644 --- a/Documentation/power/pm_qos_interface.txt +++ b/Documentation/power/pm_qos_interface.txt @@ -99,7 +99,7 @@ reading the aggregated value does not require any locking mechanism. From kernel mode the use of this interface is the following: -int dev_pm_qos_add_request(device, handle, value): +int dev_pm_qos_add_request(device, handle, type, value): Will insert an element into the list for that identified device with the target value. Upon change to this list the new target is recomputed and any registered notifiers are called only if the target value is now different. diff --git a/Documentation/power/power_supply_class.txt b/Documentation/power/power_supply_class.txt index 9c647bd7c5a9..3f10b39b0346 100644 --- a/Documentation/power/power_supply_class.txt +++ b/Documentation/power/power_supply_class.txt @@ -123,6 +123,9 @@ CONSTANT_CHARGE_VOLTAGE - constant charge voltage programmed by charger. CONSTANT_CHARGE_VOLTAGE_MAX - maximum charge voltage supported by the power supply object. +CHARGE_CONTROL_LIMIT - current charge control limit setting +CHARGE_CONTROL_LIMIT_MAX - maximum charge control limit setting + ENERGY_FULL, ENERGY_EMPTY - same as above but for energy. CAPACITY - capacity in percents. diff --git a/Documentation/power/runtime_pm.txt b/Documentation/power/runtime_pm.txt index 4abe83e1045a..6c9f5d9aa115 100644 --- a/Documentation/power/runtime_pm.txt +++ b/Documentation/power/runtime_pm.txt @@ -426,6 +426,10 @@ drivers/base/power/runtime.c and include/linux/pm_runtime.h: '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 +646,13 @@ out the following operations: * 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 diff --git a/Documentation/powerpc/cpu_features.txt b/Documentation/powerpc/cpu_features.txt index ffa4183fdb8b..ae09df8722c8 100644 --- a/Documentation/powerpc/cpu_features.txt +++ b/Documentation/powerpc/cpu_features.txt @@ -11,10 +11,10 @@ split instruction and data caches, and if the CPU supports the DOZE and NAP 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 @@ should be used in the majority of cases. 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/ptrace.txt b/Documentation/powerpc/ptrace.txt index f4a5499b7bc6..f2a7a3919772 100644 --- a/Documentation/powerpc/ptrace.txt +++ b/Documentation/powerpc/ptrace.txt @@ -127,6 +127,22 @@ Some examples of using the structure to: p.addr2 = (uint64_t) end_range; p.condition_value = 0; +- set a watchpoint in server processors (BookS) + + p.version = 1; + p.trigger_type = PPC_BREAKPOINT_TRIGGER_RW; + p.addr_mode = PPC_BREAKPOINT_MODE_RANGE_INCLUSIVE; + or + p.addr_mode = PPC_BREAKPOINT_MODE_EXACT; + + p.condition_mode = PPC_BREAKPOINT_CONDITION_NONE; + p.addr = (uint64_t) begin_range; + /* For PPC_BREAKPOINT_MODE_RANGE_INCLUSIVE addr2 needs to be specified, where + * addr2 - addr <= 8 Bytes. + */ + p.addr2 = (uint64_t) end_range; + p.condition_value = 0; + 3. PTRACE_DELHWDEBUG Takes an integer which identifies an existing breakpoint or watchpoint diff --git a/Documentation/powerpc/transactional_memory.txt b/Documentation/powerpc/transactional_memory.txt new file mode 100644 index 000000000000..c907be41d60f --- /dev/null +++ b/Documentation/powerpc/transactional_memory.txt @@ -0,0 +1,175 @@ +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); + } + + +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_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. + +These can be checked by the user program's abort handler as TEXASR[0:7]. + + +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/prctl/seccomp_filter.txt b/Documentation/prctl/seccomp_filter.txt index 597c3c581375..1e469ef75778 100644 --- a/Documentation/prctl/seccomp_filter.txt +++ b/Documentation/prctl/seccomp_filter.txt @@ -95,12 +95,15 @@ SECCOMP_RET_KILL: SECCOMP_RET_TRAP: Results in the kernel sending a SIGSYS signal to the triggering - task without executing the system call. The kernel will - rollback the register state to just before the system call - entry such that a signal handler in the task will be able to - inspect the ucontext_t->uc_mcontext registers and emulate - system call success or failure upon return from the signal - handler. + task without executing the system call. siginfo->si_call_addr + will show the address of the system call instruction, and + siginfo->si_syscall and siginfo->si_arch will indicate which + syscall was attempted. The program counter will be as though + the syscall happened (i.e. it will not point to the syscall + instruction). The return value register will contain an arch- + dependent value -- if resuming execution, set it to something + sensible. (The architecture dependency is because replacing + it with -ENOSYS could overwrite some useful information.) The SECCOMP_RET_DATA portion of the return value will be passed as si_errno. @@ -123,6 +126,18 @@ SECCOMP_RET_TRACE: the BPF program return value will be available to the tracer via PTRACE_GETEVENTMSG. + The tracer can skip the system call by changing the syscall number + to -1. Alternatively, the tracer can change the system call + requested by changing the system call to a valid syscall number. If + the tracer asks to skip the system call, then the system call will + appear to return the value that the tracer puts in the return value + register. + + The seccomp check will not be run again after the tracer is + notified. (This means that seccomp-based sandboxes MUST NOT + allow use of ptrace, even of other sandboxed processes, without + extreme care; ptracers can use this mechanism to escape.) + SECCOMP_RET_ALLOW: Results in the system call being executed. @@ -161,3 +176,50 @@ architecture supports both ptrace_event and seccomp, it will be able to support seccomp filter with minor fixup: SIGSYS support and seccomp return value checking. Then it must just add CONFIG_HAVE_ARCH_SECCOMP_FILTER to its arch-specific Kconfig. + + + +Caveats +------- + +The vDSO can cause some system calls to run entirely in userspace, +leading to surprises when you run programs on different machines that +fall back to real syscalls. To minimize these surprises on x86, make +sure you test with +/sys/devices/system/clocksource/clocksource0/current_clocksource set to +something like acpi_pm. + +On x86-64, vsyscall emulation is enabled by default. (vsyscalls are +legacy variants on vDSO calls.) Currently, emulated vsyscalls will honor seccomp, with a few oddities: + +- A return value of SECCOMP_RET_TRAP will set a si_call_addr pointing to + the vsyscall entry for the given call and not the address after the + 'syscall' instruction. Any code which wants to restart the call + should be aware that (a) a ret instruction has been emulated and (b) + trying to resume the syscall will again trigger the standard vsyscall + emulation security checks, making resuming the syscall mostly + pointless. + +- A return value of SECCOMP_RET_TRACE will signal the tracer as usual, + but the syscall may not be changed to another system call using the + orig_rax register. It may only be changed to -1 order to skip the + currently emulated call. Any other change MAY terminate the process. + The rip value seen by the tracer will be the syscall entry address; + this is different from normal behavior. The tracer MUST NOT modify + rip or rsp. (Do not rely on other changes terminating the process. + They might work. For example, on some kernels, choosing a syscall + that only exists in future kernels will be correctly emulated (by + returning -ENOSYS). + +To detect this quirky behavior, check for addr & ~0x0C00 == +0xFFFFFFFFFF600000. (For SECCOMP_RET_TRACE, use rip. For +SECCOMP_RET_TRAP, use siginfo->si_call_addr.) Do not check any other +condition: future kernels may improve vsyscall emulation and current +kernels in vsyscall=native mode will behave differently, but the +instructions at 0xF...F600{0,4,8,C}00 will not be system calls in these +cases. + +Note that modern systems are unlikely to use vsyscalls at all -- they +are a legacy feature and they are considerably slower than standard +syscalls. New code will use the vDSO, and vDSO-issued system calls +are indistinguishable from normal system calls. diff --git a/Documentation/printk-formats.txt b/Documentation/printk-formats.txt index 8ffb274367c7..6e953564de03 100644 --- a/Documentation/printk-formats.txt +++ b/Documentation/printk-formats.txt @@ -53,6 +53,14 @@ Struct Resources: 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 @@ -150,9 +158,9 @@ s64 SHOULD be printed with %lld/%llx, (long long): 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 +170,5 @@ Reminder: sizeof() result is of type size_t. 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/rpmsg.txt b/Documentation/rpmsg.txt index 409d9f964c5b..f7edc3aa1e92 100644 --- a/Documentation/rpmsg.txt +++ b/Documentation/rpmsg.txt @@ -236,7 +236,7 @@ static int rpmsg_sample_probe(struct rpmsg_channel *rpdev) 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 @@ static struct rpmsg_driver rpmsg_sample_client = { .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/scsi/ChangeLog.megaraid_sas b/Documentation/scsi/ChangeLog.megaraid_sas index da03146c182a..09673c7fc8ee 100644 --- a/Documentation/scsi/ChangeLog.megaraid_sas +++ b/Documentation/scsi/ChangeLog.megaraid_sas @@ -1,3 +1,12 @@ +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/hptiop.txt b/Documentation/scsi/hptiop.txt index 9605179711f4..4a4f47e759cd 100644 --- a/Documentation/scsi/hptiop.txt +++ b/Documentation/scsi/hptiop.txt @@ -37,7 +37,7 @@ For Intel IOP based adapters, the controller IOP is accessed via PCI BAR0: 0x40 Inbound Queue Port 0x44 Outbound Queue Port -For Marvell IOP based adapters, the IOP is accessed via PCI BAR0 and BAR1: +For Marvell not Frey IOP based adapters, the IOP is accessed via PCI BAR0 and BAR1: BAR0 offset Register 0x20400 Inbound Doorbell Register @@ -55,9 +55,31 @@ For Marvell IOP based adapters, the IOP is accessed via PCI BAR0 and BAR1: 0x40-0x1040 Inbound Queue 0x1040-0x2040 Outbound Queue +For Marvell Frey IOP based adapters, the IOP is accessed via PCI BAR0 and BAR1: -I/O Request Workflow ----------------------- + BAR0 offset Register + 0x0 IOP configuration information. + + BAR1 offset Register + 0x4000 Inbound List Base Address Low + 0x4004 Inbound List Base Address High + 0x4018 Inbound List Write Pointer + 0x402C Inbound List Configuration and Control + 0x4050 Outbound List Base Address Low + 0x4054 Outbound List Base Address High + 0x4058 Outbound List Copy Pointer Shadow Base Address Low + 0x405C Outbound List Copy Pointer Shadow Base Address High + 0x4088 Outbound List Interrupt Cause + 0x408C Outbound List Interrupt Enable + 0x1020C PCIe Function 0 Interrupt Enable + 0x10400 PCIe Function 0 to CPU Message A + 0x10420 CPU to PCIe Function 0 Message A + 0x10480 CPU to PCIe Function 0 Doorbell + 0x10484 CPU to PCIe Function 0 Doorbell Enable + + +I/O Request Workflow of Not Marvell Frey +------------------------------------------ All queued requests are handled via inbound/outbound queue port. A request packet can be allocated in either IOP or host memory. @@ -101,6 +123,45 @@ register 0. An outbound message with the same value indicates the completion of an inbound message. +I/O Request Workflow of Marvell Frey +-------------------------------------- + +All queued requests are handled via inbound/outbound list. + +To send a request to the controller: + + - Allocate a free request in host DMA coherent memory. + + Requests allocated in host memory must be aligned on 32-bytes boundary. + + - Fill the request with index of the request in the flag. + + Fill a free inbound list unit with the physical address and the size of + the request. + + Set up the inbound list write pointer with the index of previous unit, + round to 0 if the index reaches the supported count of requests. + + - Post the inbound list writer pointer to IOP. + + - The IOP process the request. When the request is completed, the flag of + the request with or-ed IOPMU_QUEUE_MASK_HOST_BITS will be put into a + free outbound list unit and the index of the outbound list unit will be + put into the copy pointer shadow register. An outbound interrupt will be + generated. + + - The host read the outbound list copy pointer shadow register and compare + with previous saved read ponter N. If they are different, the host will + read the (N+1)th outbound list unit. + + The host get the index of the request from the (N+1)th outbound list + unit and complete the request. + +Non-queued requests (reset communication/reset/flush etc) can be sent via PCIe +Function 0 to CPU Message A register. The CPU to PCIe Function 0 Message register +with the same value indicates the completion of message. + + User-level Interface --------------------- @@ -112,7 +173,7 @@ The driver exposes following sysfs attributes: ----------------------------------------------------------------------------- -Copyright (C) 2006-2009 HighPoint Technologies, Inc. All Rights Reserved. +Copyright (C) 2006-2012 HighPoint Technologies, Inc. All Rights Reserved. This file is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of diff --git a/Documentation/security/00-INDEX b/Documentation/security/00-INDEX index eeed1de546d4..414235c1fcfc 100644 --- a/Documentation/security/00-INDEX +++ b/Documentation/security/00-INDEX @@ -12,6 +12,8 @@ apparmor.txt - documentation on the AppArmor security extension. credentials.txt - documentation about credentials in Linux. +keys-ecryptfs.txt + - description of the encryption keys for the ecryptfs filesystem. keys-request-key.txt - description of the kernel key request service. keys-trusted-encrypted.txt diff --git a/Documentation/security/keys.txt b/Documentation/security/keys.txt index 7d9ca92022d8..7b4145d00452 100644 --- a/Documentation/security/keys.txt +++ b/Documentation/security/keys.txt @@ -994,6 +994,23 @@ payload contents" for more information. reference pointer if successful. +(*) A keyring can be created by: + + struct key *keyring_alloc(const char *description, uid_t uid, gid_t gid, + const struct cred *cred, + key_perm_t perm, + unsigned long flags, + struct key *dest); + + This creates a keyring with the given attributes and returns it. If dest + is not NULL, the new keyring will be linked into the keyring to which it + points. No permission checks are made upon the destination keyring. + + Error EDQUOT can be returned if the keyring would overload the quota (pass + KEY_ALLOC_NOT_IN_QUOTA in flags if the keyring shouldn't be accounted + towards the user's quota). Error ENOMEM can also be returned. + + (*) To check the validity of a key, this function can be called: int validate_key(struct key *key); diff --git a/Documentation/serial/driver b/Documentation/serial/driver index 0a25a9191864..067c47d46917 100644 --- a/Documentation/serial/driver +++ b/Documentation/serial/driver @@ -133,6 +133,16 @@ hardware. 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 @@ hardware. 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 @@ hardware. 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 @@ hardware. 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/sound/alsa/ALSA-Configuration.txt b/Documentation/sound/alsa/ALSA-Configuration.txt index d90d8ec2853d..ce6581c8ca26 100644 --- a/Documentation/sound/alsa/ALSA-Configuration.txt +++ b/Documentation/sound/alsa/ALSA-Configuration.txt @@ -890,8 +890,9 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. enable_msi - Enable Message Signaled Interrupt (MSI) (default = off) power_save - Automatic power-saving timeout (in second, 0 = disable) - power_save_controller - Reset HD-audio controller in power-saving mode - (default = on) + power_save_controller - Support runtime D3 of HD-audio controller + (-1 = on for supported chip (default), false = off, + true = force to on even for unsupported hardware) align_buffer_size - Force rounding of buffer/period sizes to multiples of 128 bytes. This is more efficient in terms of memory access but isn't required by the HDA spec and prevents @@ -1905,7 +1906,6 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. vid - Vendor ID for the device (optional) pid - Product ID for the device (optional) nrpacks - Max. number of packets per URB (default: 8) - async_unlink - Use async unlink mode (default: yes) device_setup - Device specific magic number (optional) - Influence depends on the device - Default: 0x0000 @@ -1917,8 +1917,6 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. NB: nrpacks parameter can be modified dynamically via sysfs. Don't put the value over 20. Changing via sysfs has no sanity check. - NB: async_unlink=0 would cause Oops. It remains just for - debugging purpose (if any). NB: ignore_ctl_error=1 may help when you get an error at accessing the mixer element such as URB error -22. This happens on some buggy USB device or the controller. diff --git a/Documentation/sound/alsa/HD-Audio-Models.txt b/Documentation/sound/alsa/HD-Audio-Models.txt index 16dfe57f1731..bb8b0dc532b8 100644 --- a/Documentation/sound/alsa/HD-Audio-Models.txt +++ b/Documentation/sound/alsa/HD-Audio-Models.txt @@ -53,7 +53,7 @@ ALC882/883/885/888/889 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) + 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 7813c06a5c71..d4faa63ff352 100644 --- a/Documentation/sound/alsa/HD-Audio.txt +++ b/Documentation/sound/alsa/HD-Audio.txt @@ -176,14 +176,14 @@ support the automatic probing (yet as of 2.6.28). And, BIOS is often, 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 @@ non-working HD-audio hardware is to check HD-audio codec and several 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 @@ init_verbs:: (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,61 @@ re-configure based on that state, run like below: ------------------------------------------------------------------------ +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_out_jack_modes (bool): add "xxx Jack Mode" enum controls to each + output jack for allowing to change the headphone amp capability +- add_in_jack_modes (bool): add "xxx Jack Mode" enum controls to each + input jack for allowing to change the mic bias vref +- power_down_unused (bool): power down the unused widgets +- 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 +494,7 @@ A patch file is a plain text file which looks like below: 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 +580,13 @@ cable is unplugged. Thus, if you hear noises, suspect first the 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 +643,9 @@ The latest development codes for HD-audio are found on sound git tree: - 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 +756,11 @@ won't be always updated. For example, the volume values are usually 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 +838,18 @@ A git repository is available: 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 90e9b3a11abc..0bcc55155911 100644 --- a/Documentation/sound/alsa/compress_offload.txt +++ b/Documentation/sound/alsa/compress_offload.txt @@ -145,6 +145,52 @@ Modifications include: - 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/sparse.txt b/Documentation/sparse.txt index 4909d4116356..eceab1308a8c 100644 --- a/Documentation/sparse.txt +++ b/Documentation/sparse.txt @@ -49,6 +49,24 @@ be generated without __CHECK_ENDIAN__. __bitwise - noisy stuff; in particular, __le*/__be* are that. We really don't want to drown in noise unless we'd explicitly asked for it. +Using sparse for lock checking +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The following macros are undefined for gcc and defined during a sparse +run to use the "context" tracking feature of sparse, applied to +locking. These annotations tell sparse when a lock is held, with +regard to the annotated function's entry and exit. + +__must_hold - The specified lock is held on function entry and exit. + +__acquires - The specified lock is held on function exit, but not entry. + +__releases - The specified lock is held on function entry, but not exit. + +If the function enters and exits without the lock held, acquiring and +releasing the lock inside the function in a balanced way, no +annotation is needed. The tree annotations above are for cases where +sparse would otherwise report a context imbalance. Getting sparse ~~~~~~~~~~~~~~ diff --git a/Documentation/spi/spi-summary b/Documentation/spi/spi-summary index 7312ec14dd89..2331eb214146 100644 --- a/Documentation/spi/spi-summary +++ b/Documentation/spi/spi-summary @@ -345,7 +345,7 @@ SPI protocol drivers somewhat resemble platform device drivers: }, .probe = CHIP_probe, - .remove = __devexit_p(CHIP_remove), + .remove = CHIP_remove, .suspend = CHIP_suspend, .resume = CHIP_resume, }; @@ -355,7 +355,7 @@ device whose board_info gave a modalias of "CHIP". Your probe() code 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/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt index 2907ba6c3607..ccd42589e124 100644 --- a/Documentation/sysctl/kernel.txt +++ b/Documentation/sysctl/kernel.txt @@ -38,6 +38,7 @@ show up in /proc/sys/kernel: - l2cr [ PPC only ] - modprobe ==> Documentation/debugging-modules.txt - modules_disabled +- msg_next_id [ sysv ipc ] - msgmax - msgmnb - msgmni @@ -62,7 +63,9 @@ show up in /proc/sys/kernel: - 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 ] @@ -320,6 +323,22 @@ to false. ============================================================== +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 @@ -542,6 +561,19 @@ are doing anyway :) ============================================================== +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 diff --git a/Documentation/telephony/00-INDEX b/Documentation/telephony/00-INDEX deleted file mode 100644 index 4ffe0ed5b6fb..000000000000 --- a/Documentation/telephony/00-INDEX +++ /dev/null @@ -1,4 +0,0 @@ -00-INDEX - - this file. -ixj.txt - - document describing the Quicknet drivers. diff --git a/Documentation/telephony/ixj.txt b/Documentation/telephony/ixj.txt deleted file mode 100644 index db94fb6c5678..000000000000 --- a/Documentation/telephony/ixj.txt +++ /dev/null @@ -1,394 +0,0 @@ -Linux Quicknet-Drivers-Howto -Quicknet Technologies, Inc. (www.quicknet.net) -Version 0.3.4 December 18, 1999 - -1.0 Introduction - -This document describes the first GPL release version of the Linux -driver for the Quicknet Internet PhoneJACK and Internet LineJACK -cards. More information about these cards is available at -www.quicknet.net. The driver version discussed in this document is -0.3.4. - -These cards offer nice telco style interfaces to use your standard -telephone/key system/PBX as the user interface for VoIP applications. -The Internet LineJACK also offers PSTN connectivity for a single line -Internet to PSTN gateway. Of course, you can add more than one card -to a system to obtain multi-line functionality. At this time, the -driver supports the POTS port on both the Internet PhoneJACK and the -Internet LineJACK, but the PSTN port on the latter card is not yet -supported. - -This document, and the drivers for the cards, are intended for a -limited audience that includes technically capable programmers who -would like to experiment with Quicknet cards. The drivers are -considered in ALPHA status and are not yet considered stable enough -for general, widespread use in an unlimited audience. - -That's worth saying again: - -THE LINUX DRIVERS FOR QUICKNET CARDS ARE PRESENTLY IN A ALPHA STATE -AND SHOULD NOT BE CONSIDERED AS READY FOR NORMAL WIDESPREAD USE. - -They are released early in the spirit of Internet development and to -make this technology available to innovators who would benefit from -early exposure. - -When we promote the device driver to "beta" level it will be -considered ready for non-programmer, non-technical users. Until then, -please be aware that these drivers may not be stable and may affect -the performance of your system. - - -1.1 Latest Additions/Improvements - -The 0.3.4 version of the driver is the first GPL release. Several -features had to be removed from the prior binary only module, mostly -for reasons of Intellectual Property rights. We can't release -information that is not ours - so certain aspects of the driver had to -be removed to protect the rights of others. - -Specifically, very old Internet PhoneJACK cards have non-standard -G.723.1 codecs (due to the early nature of the DSPs in those days). -The auto-conversion code to bring those cards into compliance with -today's standards is available as a binary only module to those people -needing it. If you bought your card after 1997 or so, you are OK - -it's only the very old cards that are affected. - -Also, the code to download G.728/G.729/G.729a codecs to the DSP is -available as a binary only module as well. This IP is not ours to -release. - -Hooks are built into the GPL driver to allow it to work with other -companion modules that are completely separate from this module. - -1.2 Copyright, Trademarks, Disclaimer, & Credits - -Copyright - -Copyright (c) 1999 Quicknet Technologies, Inc. Permission is granted -to freely copy and distribute this document provided you preserve it -in its original form. For corrections and minor changes contact the -maintainer at linux@quicknet.net. - -Trademarks - -Internet PhoneJACK and Internet LineJACK are registered trademarks of -Quicknet Technologies, Inc. - -Disclaimer - -Much of the info in this HOWTO is early information released by -Quicknet Technologies, Inc. for the express purpose of allowing early -testing and use of the Linux drivers developed for their products. -While every attempt has been made to be thorough, complete and -accurate, the information contained here may be unreliable and there -are likely a number of errors in this document. Please let the -maintainer know about them. Since this is free documentation, it -should be obvious that neither I nor previous authors can be held -legally responsible for any errors. - -Credits - -This HOWTO was written by: - - Greg Herlein <gherlein@quicknet.net> - Ed Okerson <eokerson@quicknet.net> - -1.3 Future Plans: You Can Help - -Please let the maintainer know of any errors in facts, opinions, -logic, spelling, grammar, clarity, links, etc. But first, if the date -is over a month old, check to see that you have the latest -version. Please send any info that you think belongs in this document. - -You can also contribute code and/or bug-fixes for the sample -applications. - - -1.4 Where to get things - -Info on latest versions of the driver are here: - -http://web.archive.org/web/*/http://www.quicknet.net/develop.htm - -1.5 Mailing List - -Quicknet operates a mailing list to provide a public forum on using -these drivers. - -To subscribe to the linux-sdk mailing list, send an email to: - - majordomo@linux.quicknet.net - -In the body of the email, type: - - subscribe linux-sdk <your-email-address> - -Please delete any signature block that you would normally add to the -bottom of your email - it tends to confuse majordomo. - -To send mail to the list, address your mail to - - linux-sdk@linux.quicknet.net - -Your message will go out to everyone on the list. - -To unsubscribe to the linux-sdk mailing list, send an email to: - - majordomo@linux.quicknet.net - -In the body of the email, type: - - unsubscribe linux-sdk <your-email-address> - - - -2.0 Requirements - -2.1 Quicknet Card(s) - -You will need at least one Internet PhoneJACK or Internet LineJACK -cards. These are ISA or PCI bus devices that use Plug-n-Play for -configuration, and use no IRQs. The driver will support up to 16 -cards in any one system, of any mix between the two types. - -Note that you will need two cards to do any useful testing alone, since -you will need a card on both ends of the connection. Of course, if -you are doing collaborative work, perhaps your friends or coworkers -have cards too. If not, we'll gladly sell them some! - - -2.2 ISAPNP - -Since the Quicknet cards are Plug-n-Play devices, you will need the -isapnp tools package to configure the cards, or you can use the isapnp -module to autoconfigure them. The former package probably came with -your Linux distribution. Documentation on this package is available -online at: - -http://mailer.wiwi.uni-marburg.de/linux/LDP/HOWTO/Plug-and-Play-HOWTO.html - -The isapnp autoconfiguration is available on the Quicknet website at: - - http://www.quicknet.net/develop.htm - -though it may be in the kernel by the time you read this. - - -3.0 Card Configuration - -If you did not get your drivers as part of the linux kernel, do the -following to install them: - - a. untar the distribution file. We use the following command: - tar -xvzf ixj-0.x.x.tgz - -This creates a subdirectory holding all the necessary files. Go to that -subdirectory. - - b. run the "ixj_dev_create" script to remove any stray device -files left in the /dev directory, and to create the new officially -designated device files. Note that the old devices were called -/dev/ixj, and the new method uses /dev/phone. - - c. type "make;make install" - this will compile and install the -module. - - d. type "depmod -av" to rebuild all your kernel version dependencies. - - e. if you are using the isapnp module to configure the cards - automatically, then skip to step f. Otherwise, ensure that you - have run the isapnp configuration utility to properly configure - the cards. - - e1. The Internet PhoneJACK has one configuration register that - requires 16 IO ports. The Internet LineJACK card has two - configuration registers and isapnp reports that IO 0 - requires 16 IO ports and IO 1 requires 8. The Quicknet - driver assumes that these registers are configured to be - contiguous, i.e. if IO 0 is set to 0x340 then IO 1 should - be set to 0x350. - - Make sure that none of the cards overlap if you have - multiple cards in the system. - - If you are new to the isapnp tools, you can jumpstart - yourself by doing the following: - - e2. go to the /etc directory and run pnpdump to get a blank - isapnp.conf file. - - pnpdump > /etc/isapnp.conf - - e3. edit the /etc/isapnp.conf file to set the IO warnings and - the register IO addresses. The IO warnings means that you - should find the line in the file that looks like this: - - (CONFLICT (IO FATAL)(IRQ FATAL)(DMA FATAL)(MEM FATAL)) # or WARNING - - and you should edit the line to look like this: - - (CONFLICT (IO WARNING)(IRQ FATAL)(DMA FATAL)(MEM FATAL)) # - or WARNING - - The next step is to set the IO port addresses. The issue - here is that isapnp does not identify all of the ports out - there. Specifically any device that does not have a driver - or module loaded by Linux will not be registered. This - includes older sound cards and network cards. We have - found that the IO port 0x300 is often used even though - isapnp claims that no-one is using those ports. We - recommend that for a single card installation that port - 0x340 (and 0x350) be used. The IO port line should change - from this: - - (IO 0 (SIZE 16) (BASE 0x0300) (CHECK)) - - to this: - - (IO 0 (SIZE 16) (BASE 0x0340) ) - - e4. if you have multiple Quicknet cards, make sure that you do - not have any overlaps. Be especially careful if you are - mixing Internet PhoneJACK and Internet LineJACK cards in - the same system. In these cases we recommend moving the - IO port addresses to the 0x400 block. Please note that on - a few machines the 0x400 series are used. Feel free to - experiment with other addresses. Our cards have been - proven to work using IO addresses of up to 0xFF0. - - e5. the last step is to uncomment the activation line so the - drivers will be associated with the port. This means the - line (immediately below) the IO line should go from this: - - # (ACT Y) - - to this: - - (ACT Y) - - Once you have finished editing the isapnp.conf file you - must submit it into the pnp driverconfigure the cards. - This is done using the following command: - - isapnp isapnp.conf - - If this works you should see a line that identifies the - Quicknet device, the IO port(s) chosen, and a message - "Enabled OK". - - f. if you are loading the module by hand, use insmod. An example -of this would look like this: - - insmod phonedev - insmod ixj dspio=0x320,0x310 xio=0,0x330 - -Then verify the module loaded by running lsmod. If you are not using a -module that matches your kernel version, you may need to "force" the -load using the -f option in the insmod command. - - insmod phonedev - insmod -f ixj dspio=0x320,0x310 xio=0,0x330 - - -If you are using isapnp to autoconfigure your card, then you do NOT -need any of the above, though you need to use depmod to load the -driver, like this: - - depmod ixj - -which will result in the needed drivers getting loaded automatically. - - g. if you are planning on having the kernel automatically request -the module for you, then you need to edit /etc/conf.modules and add the -following lines: - - options ixj dspio=0x340 xio=0x330 ixjdebug=0 - -If you do this, then when you execute an application that uses the -module the kernel will request that it is loaded. - - h. if you want non-root users to be able to read and write to the -ixj devices (this is a good idea!) you should do the following: - - - decide upon a group name to use and create that group if - needed. Add the user names to that group that you wish to - have access to the device. For example, we typically will - create a group named "ixj" in /etc/group and add all users - to that group that we want to run software that can use the - ixjX devices. - - - change the permissions on the device files, like this: - - chgrp ixj /dev/ixj* - chmod 660 /dev/ixj* - -Once this is done, then non-root users should be able to use the -devices. If you have enabled autoloading of modules, then the user -should be able to open the device and have the module loaded -automatically for them. - - -4.0 Driver Installation problems. - -We have tested these drivers on the 2.2.9, 2.2.10, 2.2.12, and 2.2.13 kernels -and in all cases have eventually been able to get the drivers to load and -run. We have found four types of problems that prevent this from happening. -The problems and solutions are: - - a. A step was missed in the installation. Go back and use section 3 -as a checklist. Many people miss running the ixj_dev_create script and thus -never load the device names into the filesystem. - - b. The kernel is inconsistently linked. We have found this problem in -the Out Of the Box installation of several distributions. The symptoms -are that neither driver will load, and that the unknown symbols include "jiffy" -and "kmalloc". The solution is to recompile both the kernel and the -modules. The command string for the final compile looks like this: - - In the kernel directory: - 1. cp .config /tmp - 2. make mrproper - 3. cp /tmp/.config . - 4. make clean;make bzImage;make modules;make modules_install - -This rebuilds both the kernel and all the modules and makes sure they all -have the same linkages. This generally solves the problem once the new -kernel is installed and the system rebooted. - - c. The kernel has been patched, then unpatched. This happens when -someone decides to use an earlier kernel after they load a later kernel. -The symptoms are proceeding through all three above steps and still not -being able to load the driver. What has happened is that the generated -header files are out of sync with the kernel itself. The solution is -to recompile (again) using "make mrproper". This will remove and then -regenerate all the necessary header files. Once this is done, then you -need to install and reboot the kernel. We have not seen any problem -loading one of our drivers after this treatment. - -5.0 Known Limitations - -We cannot currently play "dial-tone" and listen for DTMF digits at the -same time using the ISA PhoneJACK. This is a bug in the 8020 DSP chip -used on that product. All other Quicknet products function normally -in this regard. We have a work-around, but it's not done yet. Until -then, if you want dial-tone, you can always play a recorded dial-tone -sound into the audio until you have gathered the DTMF digits. - - - - - - - - - - - - - - - - - diff --git a/Documentation/thermal/exynos_thermal_emulation b/Documentation/thermal/exynos_thermal_emulation new file mode 100644 index 000000000000..b73bbfb697bb --- /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_EXYNOS_THERMAL_EMUL option will make this support in available. +When it's enabled, sysfs node will be created under +/sys/bus/platform/devices/'exynos device name'/ with name of 'emulation'. + +The sysfs node, 'emulation', 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 changable 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 000000000000..332de4a39b5a --- /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 000000000000..efceb7828f54 --- /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 ca1a1a34970e..6859661c9d31 100644 --- a/Documentation/thermal/sysfs-api.txt +++ b/Documentation/thermal/sysfs-api.txt @@ -55,6 +55,8 @@ temperature) and throttle appropriate devices. .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. 1.1.2 void thermal_zone_device_unregister(struct thermal_zone_device *tz) @@ -112,6 +114,29 @@ temperature) and throttle appropriate devices. trip: indicates which trip point the cooling devices is associated with in this thermal zone. +1.4 Thermal Zone Parameters +1.4.1 struct thermal_bind_params + This structure defines the following parameters that are used to bind + a zone with a cooling device for a particular trip point. + .cdev: The cooling device pointer + .weight: The 'influence' of a particular cooling device on this zone. + This is on a percentage scale. The sum of all these weights + (for a particular zone) cannot exceed 100. + .trip_mask:This is a bit mask that gives the binding relation between + this thermal zone and cdev, for a particular trip point. + If nth bit is set, then the cdev and thermal zone are bound + for trip point n. + .match: This call back returns success(0) if the 'tz and cdev' need to + be bound, as per platform data. +1.4.2 struct thermal_zone_params + This structure defines the platform level parameters for a thermal zone. + This data, for each thermal zone should come from the platform layer. + This is an optional feature where some platforms can choose not to + provide this data. + .governor_name: Name of the thermal governor used for this zone + .num_tbps: Number of thermal_bind_params entries for this zone + .tbp: thermal_bind_params entries + 2. sysfs attributes structure RO read only value @@ -126,9 +151,11 @@ Thermal zone device sys I/F, created once it's registered: |---type: Type of the thermal zone |---temp: Current temperature |---mode: Working mode of the thermal zone + |---policy: Thermal governor used for this zone |---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-*]: @@ -187,6 +214,10 @@ mode charge of the thermal management. RW, Optional +policy + One of the various thermal governors used for a particular zone. + RW, Required + trip_point_[0-*]_temp The temperature above which trip point will be fired. Unit: millidegree Celsius @@ -224,6 +255,16 @@ passive 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 + ***************************** * Cooling device attributes * ***************************** @@ -264,6 +305,7 @@ method, the sys I/F structure will be built like this: |---type: acpitz |---temp: 37000 |---mode: enabled + |---policy: step_wise |---trip_point_0_temp: 100000 |---trip_point_0_type: critical |---trip_point_1_temp: 80000 @@ -300,8 +342,44 @@ The framework includes a simple notification mechanism, in the form of a 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. + +5. Export Symbol APIs: + +5.1: get_tz_trend: +This function returns the trend of a thermal zone, i.e the rate of change +of temperature of the thermal zone. Ideally, the thermal sensor drivers +are supposed to implement the callback. If they don't, the thermal +framework calculated the trend by comparing the previous and the current +temperature values. + +5.2:get_thermal_instance: +This function returns the thermal_instance corresponding to a given +{thermal_zone, cooling_device, trip_point} combination. Returns NULL +if such an instance does not exist. + +5.3:notify_thermal_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, +and does actual throttling for other trip points i.e ACTIVE and PASSIVE. +The throttling policy is based on the configured platform data; if no +platform data is provided, this uses the step_wise throttling policy. + +5.4:thermal_cdev_update: +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/trace/events-power.txt b/Documentation/trace/events-power.txt index cf794af22855..e1498ff8cf94 100644 --- a/Documentation/trace/events-power.txt +++ b/Documentation/trace/events-power.txt @@ -17,7 +17,7 @@ Cf. include/trace/events/power.h for the events definitions. 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 @@ The event which has 'state=4294967295' in the trace is very important to the use 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 diff --git a/Documentation/trace/ftrace.txt b/Documentation/trace/ftrace.txt index 6f51fed45f2d..a372304aef10 100644 --- a/Documentation/trace/ftrace.txt +++ b/Documentation/trace/ftrace.txt @@ -1842,6 +1842,89 @@ an error. # cat buffer_size_kb 85 +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 + ----------- More details can be found in the source code, in the diff --git a/Documentation/usb/error-codes.txt b/Documentation/usb/error-codes.txt index b3f606b81a03..9c3eb845ebe5 100644 --- a/Documentation/usb/error-codes.txt +++ b/Documentation/usb/error-codes.txt @@ -21,6 +21,8 @@ Non-USB-specific: USB-specific: +-EBUSY The URB is already active. + -ENODEV specified USB-device or bus doesn't exist -ENOENT specified interface or endpoint does not exist or @@ -35,9 +37,8 @@ USB-specific: d) ISO: number_of_packets is < 0 e) various other cases --EAGAIN a) specified ISO start frame too early - b) (using ISO-ASAP) too much scheduled for the future - wait some time and try again. +-EXDEV ISO: URB_ISO_ASAP wasn't specified and all the frames + the URB would be scheduled in have already expired. -EFBIG Host controller driver can't schedule that many ISO frames. diff --git a/Documentation/usb/mass-storage.txt b/Documentation/usb/mass-storage.txt index e9b9334627bf..59063ad7a60d 100644 --- a/Documentation/usb/mass-storage.txt +++ b/Documentation/usb/mass-storage.txt @@ -20,9 +20,9 @@ This document describes how to use the gadget from user space, its relation to mass storage function (or MSF) and different gadgets - using it, and how it differs from File Storage Gadget (or FSG). It - will talk only briefly about how to use MSF within composite - gadgets. + using it, and how it differs from File Storage Gadget (or FSG) + (which is no longer included in Linux). It will talk only briefly + about how to use MSF within composite gadgets. * Module parameters @@ -198,16 +198,15 @@ The Mass Storage Function and thus the Mass Storage Gadget has been based on the File Storage Gadget. The difference between the two is that MSG is a composite gadget (ie. uses the composite framework) - while file storage gadget is a traditional gadget. From userspace + while file storage gadget was a traditional gadget. From userspace point of view this distinction does not really matter, but from kernel hacker's point of view, this means that (i) MSG does not duplicate code needed for handling basic USB protocol commands and (ii) MSF can be used in any other composite gadget. - Because of that, File Storage Gadget has been deprecated and - scheduled to be removed in Linux 3.8. All users need to transition - to the Mass Storage Gadget by that time. The two gadgets behave - mostly the same from the outside except: + Because of that, File Storage Gadget has been removed in Linux 3.8. + All users need to transition to the Mass Storage Gadget. The two + gadgets behave mostly the same from the outside except: 1. In FSG the “removable” and “cdrom” module parameters set the flag for all logical units whereas in MSG they accept a list of y/n diff --git a/Documentation/video4linux/CARDLIST.au0828 b/Documentation/video4linux/CARDLIST.au0828 index a8a65753e544..55a21deab7db 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.cx23885 b/Documentation/video4linux/CARDLIST.cx23885 index 1299b5e82d7f..9f056d512e35 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 d99262dda533..3f12865b2a88 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] 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,4 @@ 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] diff --git a/Documentation/video4linux/CARDLIST.saa7134 b/Documentation/video4linux/CARDLIST.saa7134 index 94d9025aa82d..b3ad68309109 100644 --- a/Documentation/video4linux/CARDLIST.saa7134 +++ b/Documentation/video4linux/CARDLIST.saa7134 @@ -189,3 +189,4 @@ 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 diff --git a/Documentation/video4linux/bttv/Cards b/Documentation/video4linux/bttv/Cards index db833ced2cb8..a8fb6e2d3c8b 100644 --- a/Documentation/video4linux/bttv/Cards +++ b/Documentation/video4linux/bttv/Cards @@ -43,7 +43,7 @@ Very nice card if you only have satellite TV but several tuners connected to the card via composite. Many thanks to Matrix-Vision for giving us 2 cards for free which made -Bt848a/Bt849 single crytal operation support possible!!! +Bt848a/Bt849 single crystal operation support possible!!! diff --git a/Documentation/video4linux/bttv/Sound-FAQ b/Documentation/video4linux/bttv/Sound-FAQ index 395f6c6fdd98..d3f1d7783d1c 100644 --- a/Documentation/video4linux/bttv/Sound-FAQ +++ b/Documentation/video4linux/bttv/Sound-FAQ @@ -82,7 +82,7 @@ card installed, you might to check out if you can read these registers values used by the windows driver. A tool to do this is available from ftp://telepresence.dmem.strath.ac.uk/pub/bt848/winutil, but it does'nt work with bt878 boards according to some reports I received. -Another one with bt878 suport is available from +Another one with bt878 support is available from http://btwincap.sourceforge.net/Files/btspy2.00.zip You might also dig around in the *.ini files of the Windows applications. diff --git a/Documentation/video4linux/et61x251.txt b/Documentation/video4linux/et61x251.txt deleted file mode 100644 index e0cdae491858..000000000000 --- 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 index 47877deae6d7..47877deae6d7 100644..100755 --- a/Documentation/video4linux/extract_xc3028.pl +++ b/Documentation/video4linux/extract_xc3028.pl diff --git a/Documentation/video4linux/fimc.txt b/Documentation/video4linux/fimc.txt index fd02d9a4930a..25f4d3402722 100644 --- a/Documentation/video4linux/fimc.txt +++ b/Documentation/video4linux/fimc.txt @@ -58,7 +58,7 @@ Not currently supported: 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 diff --git a/Documentation/video4linux/ibmcam.txt b/Documentation/video4linux/ibmcam.txt deleted file mode 100644 index a51055211e62..000000000000 --- 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 4450ab13f37b..000000000000 --- 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 b3326b167ada..000000000000 --- 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 bd6526ec8dd7..000000000000 --- 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 3a7823e01b4d..98c32925eb39 100644 --- a/Documentation/video4linux/si470x.txt +++ b/Documentation/video4linux/si470x.txt @@ -53,6 +53,9 @@ Testing is usually done with most application under Debian/testing: - 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 @@ commands. Please adjust the audio devices to your needs (/dev/dsp* and hw:x,x). 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/soc-camera.txt b/Documentation/video4linux/soc-camera.txt index 3f87c7da4ca2..f62fcdbc8b9f 100644 --- a/Documentation/video4linux/soc-camera.txt +++ b/Documentation/video4linux/soc-camera.txt @@ -9,32 +9,36 @@ The following terms are used in this document: 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 @@ soc_camera_host_register(struct soc_camera_host *); 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 @@ Camera API 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 ---------------------------------------- @@ -153,8 +140,25 @@ implemented. 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 e3de33645308..000000000000 --- 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 cfe52c798d74..676f87366025 100644 --- a/Documentation/video4linux/v4l2-controls.txt +++ b/Documentation/video4linux/v4l2-controls.txt @@ -715,14 +715,20 @@ a control of this type whenever the first control belonging to a new control class is added. -Proposals for Extensions -======================== +Adding Notify Callbacks +======================= + +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: -Some ideas for future extensions to the spec: +void v4l2_ctrl_notify(struct v4l2_ctrl *ctrl, + void (*notify)(struct v4l2_ctrl *ctrl, void *priv), void *priv); -1) Add a V4L2_CTRL_FLAG_HEX to have values shown as hexadecimal instead of -decimal. Useful for e.g. video_mute_yuv. +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. -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. +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 32bfe926e8d7..a300b283a1a0 100644 --- a/Documentation/video4linux/v4l2-framework.txt +++ b/Documentation/video4linux/v4l2-framework.txt @@ -68,8 +68,7 @@ Structure of the framework 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 @@ The recommended approach is as follows: 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; diff --git a/Documentation/video4linux/w9968cf.txt b/Documentation/video4linux/w9968cf.txt deleted file mode 100644 index 9649450f3b90..000000000000 --- 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 b41c83cf09f4..000000000000 --- 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/kvm/api.txt b/Documentation/virtual/kvm/api.txt index f6ec3a92e621..119358dfb742 100644 --- a/Documentation/virtual/kvm/api.txt +++ b/Documentation/virtual/kvm/api.txt @@ -219,19 +219,6 @@ 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. -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 @@ kvm_run' (see below). 4.11 KVM_GET_REGS Capability: basic -Architectures: all +Architectures: all except ARM Type: vcpu ioctl Parameters: struct kvm_regs (out) Returns: 0 on success, -1 on error @@ -314,7 +301,7 @@ struct kvm_regs { 4.12 KVM_SET_REGS Capability: basic -Architectures: all +Architectures: all except ARM Type: vcpu ioctl Parameters: struct kvm_regs (in) Returns: 0 on success, -1 on error @@ -345,7 +332,7 @@ struct kvm_sregs { __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 @@ struct kvm_fpu { 4.24 KVM_CREATE_IRQCHIP Capability: KVM_CAP_IRQCHIP -Architectures: x86, ia64 +Architectures: x86, ia64, ARM Type: vm ioctl Parameters: none Returns: 0 on success, -1 on error @@ -608,21 +595,39 @@ Returns: 0 on success, -1 on error 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, a GIC is +created. 4.25 KVM_IRQ_LINE Capability: KVM_CAP_IRQCHIP -Architectures: x86, ia64 +Architectures: x86, ia64, arm 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 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 +879,12 @@ It is recommended that the lower 21 bits of guest_phys_addr and userspace_addr 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 +918,7 @@ documentation when it pops into existence). 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 @@ -1194,12 +1199,15 @@ struct kvm_ppc_pvinfo { This ioctl fetches PV specific information that need to be passed to the guest using the device tree or other means from vm context. -For now the only implemented piece of information distributed here is an array -of 4 instructions that make up a hypercall. +The hcall array defines 4 instructions that make up a hypercall. If any additional field gets added to this structure later on, a bit for that additional piece of information will be set in the flags bitmap. +The flags bitmap is defined as: + + /* the host supports the ePAPR idle hcall + #define KVM_PPC_PVINFO_FLAGS_EV_IDLE (1<<0) 4.48 KVM_ASSIGN_PCI_DEVICE @@ -1731,7 +1739,68 @@ registers, find a list below: Arch | Register | Width (bits) | | PPC | KVM_REG_PPC_HIOR | 64 - + PPC | KVM_REG_PPC_IAC1 | 64 + PPC | KVM_REG_PPC_IAC2 | 64 + PPC | KVM_REG_PPC_IAC3 | 64 + PPC | KVM_REG_PPC_IAC4 | 64 + PPC | KVM_REG_PPC_DAC1 | 64 + PPC | KVM_REG_PPC_DAC2 | 64 + PPC | KVM_REG_PPC_DABR | 64 + PPC | KVM_REG_PPC_DSCR | 64 + PPC | KVM_REG_PPC_PURR | 64 + PPC | KVM_REG_PPC_SPURR | 64 + PPC | KVM_REG_PPC_DAR | 64 + PPC | KVM_REG_PPC_DSISR | 32 + PPC | KVM_REG_PPC_AMR | 64 + PPC | KVM_REG_PPC_UAMOR | 64 + PPC | KVM_REG_PPC_MMCR0 | 64 + PPC | KVM_REG_PPC_MMCR1 | 64 + PPC | KVM_REG_PPC_MMCRA | 64 + PPC | KVM_REG_PPC_PMC1 | 32 + PPC | KVM_REG_PPC_PMC2 | 32 + PPC | KVM_REG_PPC_PMC3 | 32 + PPC | KVM_REG_PPC_PMC4 | 32 + PPC | KVM_REG_PPC_PMC5 | 32 + PPC | KVM_REG_PPC_PMC6 | 32 + PPC | KVM_REG_PPC_PMC7 | 32 + PPC | KVM_REG_PPC_PMC8 | 32 + PPC | KVM_REG_PPC_FPR0 | 64 + ... + PPC | KVM_REG_PPC_FPR31 | 64 + PPC | KVM_REG_PPC_VR0 | 128 + ... + PPC | KVM_REG_PPC_VR31 | 128 + PPC | KVM_REG_PPC_VSR0 | 128 + ... + PPC | KVM_REG_PPC_VSR31 | 128 + PPC | KVM_REG_PPC_FPSCR | 64 + PPC | KVM_REG_PPC_VSCR | 32 + PPC | KVM_REG_PPC_VPA_ADDR | 64 + 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 + +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: + 0x4002 0000 0010 <index into the kvm_regs struct:16> + +ARM 32-bit CP15 registers have the following id bit patterns: + 0x4002 0000 000F <zero:1> <crn:4> <crm:4> <opc1:4> <opc2:3> + +ARM 64-bit CP15 registers have the following id bit patterns: + 0x4003 0000 000F <zero:1> <zero:4> <crm:4> <opc1:4> <zero:3> + +ARM CCSIDR registers are demultiplexed by CSSELR value: + 0x4002 0000 0011 00 <csselr:8> + +ARM 32-bit VFP control registers have the following id bit patterns: + 0x4002 0000 0012 1 <regno:12> + +ARM 64-bit FP registers have the following id bit patterns: + 0x4002 0000 0012 0 <regno:12> 4.69 KVM_GET_ONE_REG @@ -1747,7 +1816,7 @@ kvm_one_reg struct passed in. On success, the register value can be found at the memory location pointed to by "addr". The list of registers accessible using this interface is identical to the -list in 4.64. +list in 4.68. 4.70 KVM_KVMCLOCK_CTRL @@ -1997,6 +2066,183 @@ return the hash table order in the parameter. (If the guest is using the virtualized real-mode area (VRMA) facility, the kernel will re-create the VMRA HPTEs on the next KVM_RUN of any vcpu.) +4.77 KVM_S390_INTERRUPT + +Capability: basic +Architectures: s390 +Type: vm ioctl, vcpu ioctl +Parameters: struct kvm_s390_interrupt (in) +Returns: 0 on success, -1 on error + +Allows to inject an interrupt to the guest. Interrupts can be floating +(vm ioctl) or per cpu (vcpu ioctl), depending on the interrupt type. + +Interrupt parameters are passed via kvm_s390_interrupt: + +struct kvm_s390_interrupt { + __u32 type; + __u32 parm; + __u64 parm64; +}; + +type can be one of the following: + +KVM_S390_SIGP_STOP (vcpu) - sigp restart +KVM_S390_PROGRAM_INT (vcpu) - program check; code in parm +KVM_S390_SIGP_SET_PREFIX (vcpu) - sigp set prefix; prefix address in parm +KVM_S390_RESTART (vcpu) - restart +KVM_S390_INT_VIRTIO (vm) - virtio external interrupt; external interrupt + parameters in parm and parm64 +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. + +4.78 KVM_PPC_GET_HTAB_FD + +Capability: KVM_CAP_PPC_HTAB_FD +Architectures: powerpc +Type: vm ioctl +Parameters: Pointer to struct kvm_get_htab_fd (in) +Returns: file descriptor number (>= 0) on success, -1 on error + +This returns a file descriptor that can be used either to read out the +entries in the guest's hashed page table (HPT), or to write entries to +initialize the HPT. The returned fd can only be written to if the +KVM_GET_HTAB_WRITE bit is set in the flags field of the argument, and +can only be read if that bit is clear. The argument struct looks like +this: + +/* For KVM_PPC_GET_HTAB_FD */ +struct kvm_get_htab_fd { + __u64 flags; + __u64 start_index; + __u64 reserved[2]; +}; + +/* Values for kvm_get_htab_fd.flags */ +#define KVM_GET_HTAB_BOLTED_ONLY ((__u64)0x1) +#define KVM_GET_HTAB_WRITE ((__u64)0x2) + +The `start_index' field gives the index in the HPT of the entry at +which to start reading. It is ignored when writing. + +Reads on the fd will initially supply information about all +"interesting" HPT entries. Interesting entries are those with the +bolted bit set, if the KVM_GET_HTAB_BOLTED_ONLY bit is set, otherwise +all entries. When the end of the HPT is reached, the read() will +return. If read() is called again on the fd, it will start again from +the beginning of the HPT, but will only return HPT entries that have +changed since they were last read. + +Data read or written is structured as a header (8 bytes) followed by a +series of valid HPT entries (16 bytes) each. The header indicates how +many valid HPT entries there are and how many invalid entries follow +the valid entries. The invalid entries are not represented explicitly +in the stream. The header format is: + +struct kvm_get_htab_header { + __u32 index; + __u16 n_valid; + __u16 n_invalid; +}; + +Writes to the fd create HPT entries starting at the index given in the +header; first `n_valid' valid entries with contents from the data +written, then `n_invalid' invalid entries, invalidating any previously +valid entries found. + + +4.77 KVM_ARM_VCPU_INIT + +Capability: basic +Architectures: arm +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. + + +4.78 KVM_GET_REG_LIST + +Capability: basic +Architectures: arm +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.80 KVM_ARM_SET_DEVICE_ADDR + +Capability: KVM_CAP_ARM_SET_DEVICE_ADDR +Architectures: arm +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 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 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. + 5. The kvm_run structure ------------------------ @@ -2109,7 +2355,8 @@ executed a memory-mapped I/O instruction which could not be satisfied 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 and KVM_EXIT_OSI, 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 @@ -2212,6 +2459,41 @@ The possible hypercalls are defined in the Power Architecture Platform 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]; }; @@ -2333,3 +2615,34 @@ For mmu types KVM_MMU_FSL_BOOKE_NOHV and KVM_MMU_FSL_BOOKE_HV: 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. diff --git a/Documentation/virtual/kvm/mmu.txt b/Documentation/virtual/kvm/mmu.txt index fa5f1dbc6b23..43fcb761ed16 100644 --- a/Documentation/virtual/kvm/mmu.txt +++ b/Documentation/virtual/kvm/mmu.txt @@ -187,13 +187,6 @@ Shadow pages contain the following information: 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 diff --git a/Documentation/vm/frontswap.txt b/Documentation/vm/frontswap.txt index 5ef2d1366425..c71a019be600 100644 --- a/Documentation/vm/frontswap.txt +++ b/Documentation/vm/frontswap.txt @@ -193,7 +193,7 @@ faster. or maybe swap-over-nbd/NFS)? No. First, the existing swap subsystem doesn't allow for any kind of -swap hierarchy. Perhaps it could be rewritten to accomodate a hierarchy, +swap hierarchy. Perhaps it could be rewritten to accommodate a hierarchy, but this would require fairly drastic changes. Even if it were rewritten, the existing swap subsystem uses the block I/O layer which assumes a swap device is fixed size and any page in it is linearly diff --git a/Documentation/vm/ksm.txt b/Documentation/vm/ksm.txt index b392e496f816..f34a8ee6f860 100644 --- a/Documentation/vm/ksm.txt +++ b/Documentation/vm/ksm.txt @@ -58,6 +58,21 @@ sleep_millisecs - how many milliseconds ksmd should sleep before next scan 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/transhuge.txt b/Documentation/vm/transhuge.txt index f734bb2a78dc..8785fb87d9c7 100644 --- a/Documentation/vm/transhuge.txt +++ b/Documentation/vm/transhuge.txt @@ -116,6 +116,13 @@ echo always >/sys/kernel/mm/transparent_hugepage/defrag echo madvise >/sys/kernel/mm/transparent_hugepage/defrag echo never >/sys/kernel/mm/transparent_hugepage/defrag +By default kernel tries to use huge zero page on read page fault. +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 + khugepaged will be automatically started when transparent_hugepage/enabled is set to "always" or "madvise, and it'll be automatically shutdown if it's set to "never". @@ -197,6 +204,14 @@ thp_split is incremented every time a huge page is split into base pages. This can happen for a variety of reasons but a common reason is that a huge page is old and is being reclaimed. +thp_zero_page_alloc is incremented every time a huge zero page is + successfully allocated. It includes allocations which where + dropped due race with other allocation. Note, it doesn't count + every map of the huge zero page, only its allocation. + +thp_zero_page_alloc_failed is incremented if kernel fails to allocate + huge zero page and falls back to using small pages. + As the system ages, allocating huge pages may be expensive as the system uses memory compaction to copy data around memory to free a huge page for use. There are some counters in /proc/vmstat to help @@ -276,7 +291,7 @@ unaffected. libhugetlbfs will also work fine as usual. == Graceful fallback == Code walking pagetables but unware about huge pmds can simply call -split_huge_page_pmd(mm, pmd) where the pmd is the one returned by +split_huge_page_pmd(vma, addr, pmd) where the pmd is the one returned by pmd_offset. It's trivial to make the code transparent hugepage aware by just grepping for "pmd_offset" and adding split_huge_page_pmd where missing after pmd_offset returns the pmd. Thanks to the graceful @@ -299,7 +314,7 @@ diff --git a/mm/mremap.c b/mm/mremap.c return NULL; pmd = pmd_offset(pud, addr); -+ split_huge_page_pmd(mm, pmd); ++ split_huge_page_pmd(vma, addr, pmd); if (pmd_none_or_clear_bad(pmd)) return NULL; diff --git a/Documentation/w1/slaves/w1_therm b/Documentation/w1/slaves/w1_therm index 874a8ca93feb..cc62a95e4776 100644 --- a/Documentation/w1/slaves/w1_therm +++ b/Documentation/w1/slaves/w1_therm @@ -34,9 +34,16 @@ currently supported. The driver also doesn't support reduced 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/watchdog/watchdog-kernel-api.txt b/Documentation/watchdog/watchdog-kernel-api.txt index 086638f6c82d..a0438f3957ca 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 @@ driver specific data to and a pointer to the data itself. 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/x86/boot.txt b/Documentation/x86/boot.txt index 9efceff51bfb..3840b6f28afb 100644 --- a/Documentation/x86/boot.txt +++ b/Documentation/x86/boot.txt @@ -57,6 +57,10 @@ Protocol 2.10: (Kernel 2.6.31) Added a protocol for relaxed alignment 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 @@ Offset Proto Name Meaning 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 @@ -373,7 +377,7 @@ Protocol: 2.00+ 1 Loadlin 2 bootsect-loader (0x20, all other values reserved) 3 Syslinux - 4 Etherboot/gPXE + 4 Etherboot/gPXE/iPXE 5 ELILO 7 GRUB 8 U-Boot @@ -381,10 +385,12 @@ Protocol: 2.00+ A Gujin B Qemu C Arcturus Networks uCbootloader + D kexec-tools E Extended (see ext_loader_type) 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. @@ -581,6 +587,27 @@ Protocol: 2.10+ 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 @@ -1013,7 +1040,7 @@ boot_params as that of 16-bit boot protocol, the boot loader should also fill the additional fields of the struct boot_params as that described in zero-page.txt. -After setupping the struct boot_params, the boot loader can load the +After setting up the struct boot_params, the boot loader can load the 32/64-bit kernel in the same way as that of 16-bit boot protocol. In 32-bit boot protocol, the kernel is started by jumping to the @@ -1023,11 +1050,49 @@ In 32-bit boot protocol, the kernel is started by jumping to the At entry, the CPU must be in 32-bit protected mode with paging disabled; a GDT must be loaded with the descriptors for selectors __BOOT_CS(0x10) and __BOOT_DS(0x18); both descriptors must be 4G flat -segment; __BOOS_CS must have execute/read permission, and __BOOT_DS +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; %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 000000000000..4aaf0dfb0cb8 --- /dev/null +++ b/Documentation/x86/early-microcode.txt @@ -0,0 +1,43 @@ +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: +kernel/x86/microcode/GenuineIntel.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 kernel +mkdir kernel/x86 +mkdir kernel/x86/microcode +cp ../microcode.bin kernel/x86/microcode/GenuineIntel.bin +find .|cpio -oc >../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 de38429beb71..e015a83c3996 100644 --- a/Documentation/x86/x86_64/boot-options.txt +++ b/Documentation/x86/x86_64/boot-options.txt @@ -112,10 +112,6 @@ Timing 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/zero-page.txt b/Documentation/x86/zero-page.txt index cf5437deda81..199f453cb4de 100644 --- a/Documentation/x86/zero-page.txt +++ b/Documentation/x86/zero-page.txt @@ -19,6 +19,9 @@ Offset Proto Name Meaning 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 @@ Offset Proto Name Meaning 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/atomctl.txt b/Documentation/xtensa/atomctl.txt new file mode 100644 index 000000000000..10a8d1ff35ec --- /dev/null +++ b/Documentation/xtensa/atomctl.txt @@ -0,0 +1,44 @@ +We Have Atomic Operation Control (ATOMCTL) Register. +This register determines the effect of using a S32C1I instruction +with various combinations of: + + 1. With and without an Coherent Cache Controller which + can do Atomic Transactions to the memory internally. + + 2. With and without An Intelligent Memory Controller which + can do Atomic Transactions itself. + +The Core comes up with a default value of for the three types of cache ops: + + 0x28: (WB: Internal, WT: Internal, BY:Exception) + +On the FPGA Cards we typically simulate an Intelligent Memory controller +which can implement RCW transactions. For FPGA cards with an External +Memory controller we let it to the atomic operations internally while +doing a Cached (WB) transaction and use the Memory RCW for un-cached +operations. + +For systems without an coherent cache controller, non-MX, we always +use the memory controllers RCW, thought non-MX controlers likely +support the Internal Operation. + +CUSTOMER-WARNING: + Virtually all customers buy their memory controllers from vendors that + don't support atomic RCW memory transactions and will likely want to + configure this register to not use RCW. + +Developers might find using RCW in Bypass mode convenient when testing +with the cache being bypassed; for example studying cache alias problems. + +See Section 4.3.12.4 of ISA; Bits: + + WB WT BY + 5 4 | 3 2 | 1 0 + 2 Bit + Field + Values WB - Write Back WT - Write Thru BY - Bypass +--------- --------------- ----------------- ---------------- + 0 Exception Exception Exception + 1 RCW Transaction RCW Transaction RCW Transaction + 2 Internal Operation Exception Reserved + 3 Reserved Reserved Reserved diff --git a/Documentation/zh_CN/CodingStyle b/Documentation/zh_CN/CodingStyle index ecd9307a641f..654afd72eb24 100644 --- a/Documentation/zh_CN/CodingStyle +++ b/Documentation/zh_CN/CodingStyle @@ -462,13 +462,6 @@ config AUDIT 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/arm/kernel_user_helpers.txt b/Documentation/zh_CN/arm/kernel_user_helpers.txt new file mode 100644 index 000000000000..cd7fc8f34cf9 --- /dev/null +++ b/Documentation/zh_CN/arm/kernel_user_helpers.txt @@ -0,0 +1,284 @@ +Chinese translated version of Documentation/arm/kernel_user_helpers.txt + +If you have any comment or update to the content, please contact the +original document maintainer directly. However, if you have a problem +communicating in English you can also ask the Chinese maintainer for +help. Contact the Chinese maintainer if this translation is outdated +or if there is a problem with the translation. + +Maintainer: Nicolas Pitre <nicolas.pitre@linaro.org> + Dave Martin <dave.martin@linaro.org> +Chinese maintainer: Fu Wei <tekkamanninja@gmail.com> +--------------------------------------------------------------------- +Documentation/arm/kernel_user_helpers.txt 的中文翻译 + +如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文 +交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻 +译存在问题，请联系中文版维护者。 +英文版维护者： Nicolas Pitre <nicolas.pitre@linaro.org> + Dave Martin <dave.martin@linaro.org> +中文版维护者： 傅炜 Fu Wei <tekkamanninja@gmail.com> +中文版翻译者： 傅炜 Fu Wei <tekkamanninja@gmail.com> +中文版校译者： 宋冬生 Dongsheng Song <dongshneg.song@gmail.com> + 傅炜 Fu Wei <tekkamanninja@gmail.com> + + +以下为正文 +--------------------------------------------------------------------- +内核提供的用户空间辅助代码 +========================= + +在内核内存空间的固定地址处，有一个由内核提供并可从用户空间访问的代码 +段。它用于向用户空间提供因在许多 ARM CPU 中未实现的特性和/或指令而需 +内核提供帮助的某些操作。这些代码直接在用户模式下执行的想法是为了获得 +最佳效率，但那些与内核计数器联系过于紧密的部分，则被留给了用户库实现。 +事实上，此代码甚至可能因不同的 CPU 而异，这取决于其可用的指令集或它 +是否为 SMP 系统。换句话说，内核保留在不作出警告的情况下根据需要更改 +这些代码的权利。只有本文档描述的入口及其结果是保证稳定的。 + +这与完全成熟的 VDSO 实现不同（但两者并不冲突），尽管如此，VDSO 可阻止 +某些通过常量高效跳转到那些代码段的汇编技巧。且由于那些代码段在返回用户 +代码前仅使用少量的代码周期，则一个 VDSO 间接远程调用将会在这些简单的 +操作上增加一个可测量的开销。 + +在对那些拥有原生支持的新型处理器进行代码优化时，仅在已为其他操作使用 +了类似的新增指令，而导致二进制结果已与早期 ARM 处理器不兼容的情况下， +用户空间才应绕过这些辅助代码，并在内联函数中实现这些操作（无论是通过 +编译器在代码中直接放置，还是作为库函数调用实现的一部分）。也就是说， +如果你编译的代码不会为了其他目的使用新指令，则不要仅为了避免使用这些 +内核辅助代码，导致二进制程序无法在早期处理器上运行。 + +新的辅助代码可能随着时间的推移而增加，所以新内核中的某些辅助代码在旧 +内核中可能不存在。因此，程序必须在对任何辅助代码调用假设是安全之前， +检测 __kuser_helper_version 的值（见下文）。理想情况下，这种检测应该 +只在进程启动时执行一次；如果内核版本不支持所需辅助代码，则该进程可尽早 +中止执行。 + +kuser_helper_version +-------------------- + +位置: 0xffff0ffc + +参考声明: + + extern int32_t __kuser_helper_version; + +定义: + + 这个区域包含了当前运行内核实现的辅助代码版本号。用户空间可以通过读 + 取此版本号以确定特定的辅助代码是否存在。 + +使用范例: + +#define __kuser_helper_version (*(int32_t *)0xffff0ffc) + +void check_kuser_version(void) +{ + if (__kuser_helper_version < 2) { + fprintf(stderr, "can't do atomic operations, kernel too old\n"); + abort(); + } +} + +注意: + + 用户空间可以假设这个域的值不会在任何单个进程的生存期内改变。也就 + 是说，这个域可以仅在库的初始化阶段或进程启动阶段读取一次。 + +kuser_get_tls +------------- + +位置: 0xffff0fe0 + +参考原型: + + void * __kuser_get_tls(void); + +输入: + + lr = 返回地址 + +输出: + + r0 = TLS 值 + +被篡改的寄存器: + + 无 + +定义: + + 获取之前通过 __ARM_NR_set_tls 系统调用设置的 TLS 值。 + +使用范例: + +typedef void * (__kuser_get_tls_t)(void); +#define __kuser_get_tls (*(__kuser_get_tls_t *)0xffff0fe0) + +void foo() +{ + void *tls = __kuser_get_tls(); + printf("TLS = %p\n", tls); +} + +注意: + + - 仅在 __kuser_helper_version >= 1 时，此辅助代码存在 + （从内核版本 2.6.12 开始）。 + +kuser_cmpxchg +------------- + +位置: 0xffff0fc0 + +参考原型: + + int __kuser_cmpxchg(int32_t oldval, int32_t newval, volatile int32_t *ptr); + +输入: + + r0 = oldval + r1 = newval + r2 = ptr + lr = 返回地址 + +输出: + + r0 = 成功代码 (零或非零) + C flag = 如果 r0 == 0 则置 1，如果 r0 != 0 则清零。 + +被篡改的寄存器: + + r3, ip, flags + +定义: + + 仅在 *ptr 为 oldval 时原子保存 newval 于 *ptr 中。 + 如果 *ptr 被改变，则返回值为零，否则为非零值。 + 如果 *ptr 被改变，则 C flag 也会被置 1，以实现调用代码中的汇编 + 优化。 + +使用范例: + +typedef int (__kuser_cmpxchg_t)(int oldval, int newval, volatile int *ptr); +#define __kuser_cmpxchg (*(__kuser_cmpxchg_t *)0xffff0fc0) + +int atomic_add(volatile int *ptr, int val) +{ + int old, new; + + do { + old = *ptr; + new = old + val; + } while(__kuser_cmpxchg(old, new, ptr)); + + return new; +} + +注意: + + - 这个例程已根据需要包含了内存屏障。 + + - 仅在 __kuser_helper_version >= 2 时，此辅助代码存在 + （从内核版本 2.6.12 开始）。 + +kuser_memory_barrier +-------------------- + +位置: 0xffff0fa0 + +参考原型: + + void __kuser_memory_barrier(void); + +输入: + + lr = 返回地址 + +输出: + + 无 + +被篡改的寄存器: + + 无 + +定义: + + 应用于任何需要内存屏障以防止手动数据修改带来的一致性问题，以及 + __kuser_cmpxchg 中。 + +使用范例: + +typedef void (__kuser_dmb_t)(void); +#define __kuser_dmb (*(__kuser_dmb_t *)0xffff0fa0) + +注意: + + - 仅在 __kuser_helper_version >= 3 时，此辅助代码存在 + （从内核版本 2.6.15 开始）。 + +kuser_cmpxchg64 +--------------- + +位置: 0xffff0f60 + +参考原型: + + int __kuser_cmpxchg64(const int64_t *oldval, + const int64_t *newval, + volatile int64_t *ptr); + +输入: + + r0 = 指向 oldval + r1 = 指向 newval + r2 = 指向目标值 + lr = 返回地址 + +输出: + + r0 = 成功代码 (零或非零) + C flag = 如果 r0 == 0 则置 1，如果 r0 != 0 则清零。 + +被篡改的寄存器: + + r3, lr, flags + +定义: + + 仅在 *ptr 等于 *oldval 指向的 64 位值时，原子保存 *newval + 指向的 64 位值于 *ptr 中。如果 *ptr 被改变，则返回值为零， + 否则为非零值。 + + 如果 *ptr 被改变，则 C flag 也会被置 1，以实现调用代码中的汇编 + 优化。 + +使用范例: + +typedef int (__kuser_cmpxchg64_t)(const int64_t *oldval, + const int64_t *newval, + volatile int64_t *ptr); +#define __kuser_cmpxchg64 (*(__kuser_cmpxchg64_t *)0xffff0f60) + +int64_t atomic_add64(volatile int64_t *ptr, int64_t val) +{ + int64_t old, new; + + do { + old = *ptr; + new = old + val; + } while(__kuser_cmpxchg64(&old, &new, ptr)); + + return new; +} + +注意: + + - 这个例程已根据需要包含了内存屏障。 + + - 由于这个过程的代码长度（此辅助代码跨越 2 个常规的 kuser “槽”）， + 因此 0xffff0f80 不被作为有效的入口点。 + + - 仅在 __kuser_helper_version >= 5 时，此辅助代码存在 + （从内核版本 3.1 开始）。 diff --git a/Documentation/zh_CN/arm64/memory.txt b/Documentation/zh_CN/arm64/memory.txt index 83b519314706..a5f6283829f9 100644 --- a/Documentation/zh_CN/arm64/memory.txt +++ b/Documentation/zh_CN/arm64/memory.txt @@ -47,21 +47,21 @@ AArch64 Linux 内存布局： ----------------------------------------------------------------------- 0000000000000000 0000007fffffffff 512GB 用户空间 -ffffff8000000000 ffffffbbfffcffff ~240GB vmalloc +ffffff8000000000 ffffffbbfffeffff ~240GB vmalloc -ffffffbbfffd0000 ffffffbcfffdffff 64KB [防护页] +ffffffbbffff0000 ffffffbbffffffff 64KB [防护页] -ffffffbbfffe0000 ffffffbcfffeffff 64KB PCI I/O 空间 +ffffffbc00000000 ffffffbdffffffff 8GB vmemmap -ffffffbbffff0000 ffffffbcffffffff 64KB [防护页] +ffffffbe00000000 ffffffbffbbfffff ~8GB [防护页，未来用于 vmmemap] -ffffffbc00000000 ffffffbdffffffff 8GB vmemmap +ffffffbffbe00000 ffffffbffbe0ffff 64KB PCI I/O 空间 -ffffffbe00000000 ffffffbffbffffff ~8GB [防护页，未来用于 vmmemap] +ffffffbbffff0000 ffffffbcffffffff ~2MB [防护页] ffffffbffc000000 ffffffbfffffffff 64MB 模块 -ffffffc000000000 ffffffffffffffff 256GB 内存空间 +ffffffc000000000 ffffffffffffffff 256GB 内核逻辑内存映射 4KB 页大小的转换表查找： diff --git a/Documentation/zh_CN/magic-number.txt b/Documentation/zh_CN/magic-number.txt index 4263022f5002..2ebe539f5450 100644 --- a/Documentation/zh_CN/magic-number.txt +++ b/Documentation/zh_CN/magic-number.txt @@ -122,7 +122,7 @@ SLAB_C_MAGIC 0x4f17a36d kmem_cache mm/slab.c 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 3e74f13af426..44c1d934c4e3 100644 --- a/Documentation/zh_CN/video4linux/v4l2-framework.txt +++ b/Documentation/zh_CN/video4linux/v4l2-framework.txt @@ -182,8 +182,7 @@ int iterate(void *p) 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; |