Merge branch 'power-supply-scope' of git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen
This commit is contained in:
Anton Vorontsov
commit
251f39fe42
10955 changed files with 604178 additions and 381478 deletions
.mailmapCodingStyleDMA-API.txt
Documentation
ABI
removed
stable
testing
DocBook
PCI
RCU
blackfin
block
blockdev
bus-virt-phys-mapping.txtcdrom
cgroups
cpu-freq
development-process
device-mapper
devicetree/bindings
arm
ata
crypto
gpio
i2c
mmc
mtd
net
pinmux
powerpc/fsl
serial
sound
soc/codecs
wm8510.txtwm8523.txtwm8580.txtwm8711.txtwm8728.txtwm8731.txtwm8737.txtwm8741.txtwm8750.txtwm8753.txtwm8770.txtwm8776.txtwm8804.txtspi
tty/serial
2
.mailmap
2
.mailmap
|
|
@ -68,6 +68,7 @@ Juha Yrjola <juha.yrjola@solidboot.com>
|
|||
Kay Sievers <kay.sievers@vrfy.org>
|
||||
Kenneth W Chen <kenneth.w.chen@intel.com>
|
||||
Koushik <raghavendra.koushik@neterion.com>
|
||||
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
|
||||
Leonid I Ananiev <leonid.i.ananiev@intel.com>
|
||||
Linas Vepstas <linas@austin.ibm.com>
|
||||
Mark Brown <broonie@sirena.org.uk>
|
||||
|
|
@ -111,3 +112,4 @@ Uwe Kleine-König <ukl@pengutronix.de>
|
|||
Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com>
|
||||
Valdis Kletnieks <Valdis.Kletnieks@vt.edu>
|
||||
Takashi YOSHII <takashi.yoshii.zj@renesas.com>
|
||||
Yusuke Goda <goda.yusuke@renesas.com>
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
What: /sys/o2cb symlink
|
||||
Date: May 2011
|
||||
KernelVersion: 2.6.40
|
||||
KernelVersion: 3.0
|
||||
Contact: ocfs2-devel@oss.oracle.com
|
||||
Description: This is a symlink: /sys/o2cb to /sys/fs/o2cb. The symlink is
|
||||
removed when new versions of ocfs2-tools which know to look
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ Description:
|
|||
/dev/raw1394 was a character device file that allowed low-level
|
||||
access to FireWire buses. Its major drawbacks were its inability
|
||||
to implement sensible device security policies, and its low level
|
||||
of abstraction that required userspace clients do duplicate much
|
||||
of abstraction that required userspace clients to duplicate much
|
||||
of the kernel's ieee1394 core functionality.
|
||||
Replaced by /dev/fw*, i.e. the <linux/firewire-cdev.h> ABI of
|
||||
firewire-core.
|
||||
|
|
|
|||
22
Documentation/ABI/stable/sysfs-acpi-pmprofile
Normal file
22
Documentation/ABI/stable/sysfs-acpi-pmprofile
Normal file
|
|
@ -0,0 +1,22 @@
|
|||
What: /sys/firmware/acpi/pm_profile
|
||||
Date: 03-Nov-2011
|
||||
KernelVersion: v3.2
|
||||
Contact: linux-acpi@vger.kernel.org
|
||||
Description: The ACPI pm_profile sysfs interface exports the platform
|
||||
power management (and performance) requirement expectations
|
||||
as provided by BIOS. The integer value is directly passed as
|
||||
retrieved from the FADT ACPI table.
|
||||
Values: For possible values see ACPI specification:
|
||||
5.2.9 Fixed ACPI Description Table (FADT)
|
||||
Field: Preferred_PM_Profile
|
||||
|
||||
Currently these values are defined by spec:
|
||||
0 Unspecified
|
||||
1 Desktop
|
||||
2 Mobile
|
||||
3 Workstation
|
||||
4 Enterprise Server
|
||||
5 SOHO Server
|
||||
6 Appliance PC
|
||||
7 Performance Server
|
||||
>7 Reserved
|
||||
19
Documentation/ABI/testing/debugfs-ideapad
Normal file
19
Documentation/ABI/testing/debugfs-ideapad
Normal file
|
|
@ -0,0 +1,19 @@
|
|||
What: /sys/kernel/debug/ideapad/cfg
|
||||
Date: Sep 2011
|
||||
KernelVersion: 3.2
|
||||
Contact: Ike Panhc <ike.pan@canonical.com>
|
||||
Description:
|
||||
|
||||
cfg shows the return value of _CFG method in VPC2004 device. It tells machine
|
||||
capability and what graphic component within the machine.
|
||||
|
||||
|
||||
What: /sys/kernel/debug/ideapad/status
|
||||
Date: Sep 2011
|
||||
KernelVersion: 3.2
|
||||
Contact: Ike Panhc <ike.pan@canonical.com>
|
||||
Description:
|
||||
|
||||
status shows infos we can read and tells its meaning and value.
|
||||
|
||||
|
||||
23
Documentation/ABI/testing/evm
Normal file
23
Documentation/ABI/testing/evm
Normal file
|
|
@ -0,0 +1,23 @@
|
|||
What: security/evm
|
||||
Date: March 2011
|
||||
Contact: Mimi Zohar <zohar@us.ibm.com>
|
||||
Description:
|
||||
EVM protects a file's security extended attributes(xattrs)
|
||||
against integrity attacks. The initial method maintains an
|
||||
HMAC-sha1 value across the extended attributes, storing the
|
||||
value as the extended attribute 'security.evm'.
|
||||
|
||||
EVM depends on the Kernel Key Retention System to provide it
|
||||
with a trusted/encrypted key for the HMAC-sha1 operation.
|
||||
The key is loaded onto the root's keyring using keyctl. Until
|
||||
EVM receives notification that the key has been successfully
|
||||
loaded onto the keyring (echo 1 > <securityfs>/evm), EVM
|
||||
can not create or validate the 'security.evm' xattr, but
|
||||
returns INTEGRITY_UNKNOWN. Loading the key and signaling EVM
|
||||
should be done as early as possible. Normally this is done
|
||||
in the initramfs, which has already been measured as part
|
||||
of the trusted boot. For more information on creating and
|
||||
loading existing trusted/encrypted keys, refer to:
|
||||
Documentation/keys-trusted-encrypted.txt. (A sample dracut
|
||||
patch, which loads the trusted/encrypted key and enables
|
||||
EVM, is available from http://linux-ima.sourceforge.net/#EVM.)
|
||||
|
|
@ -206,3 +206,16 @@ Description:
|
|||
when a discarded area is read the discard_zeroes_data
|
||||
parameter will be set to one. Otherwise it will be 0 and
|
||||
the result of reading a discarded area is undefined.
|
||||
What: /sys/block/<disk>/alias
|
||||
Date: Aug 2011
|
||||
Contact: Nao Nishijima <nao.nishijima.xt@hitachi.com>
|
||||
Description:
|
||||
A raw device name of a disk does not always point a same disk
|
||||
each boot-up time. Therefore, users have to use persistent
|
||||
device names, which udev creates when the kernel finds a disk,
|
||||
instead of raw device name. However, kernel doesn't show those
|
||||
persistent names on its messages (e.g. dmesg).
|
||||
This file can store an alias of the disk and it would be
|
||||
appeared in kernel messages if it is set. A disk can have an
|
||||
alias which length is up to 255bytes. Users can use alphabets,
|
||||
numbers, "-" and "_" in alias name. This file is writeonce.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
What: /sys/bus/bcma/devices/.../manuf
|
||||
Date: May 2011
|
||||
KernelVersion: 2.6.40
|
||||
KernelVersion: 3.0
|
||||
Contact: Rafał Miłecki <zajec5@gmail.com>
|
||||
Description:
|
||||
Each BCMA core has it's manufacturer id. See
|
||||
|
|
@ -8,7 +8,7 @@ Description:
|
|||
|
||||
What: /sys/bus/bcma/devices/.../id
|
||||
Date: May 2011
|
||||
KernelVersion: 2.6.40
|
||||
KernelVersion: 3.0
|
||||
Contact: Rafał Miłecki <zajec5@gmail.com>
|
||||
Description:
|
||||
There are a few types of BCMA cores, they can be identified by
|
||||
|
|
@ -16,7 +16,7 @@ Description:
|
|||
|
||||
What: /sys/bus/bcma/devices/.../rev
|
||||
Date: May 2011
|
||||
KernelVersion: 2.6.40
|
||||
KernelVersion: 3.0
|
||||
Contact: Rafał Miłecki <zajec5@gmail.com>
|
||||
Description:
|
||||
BCMA cores of the same type can still slightly differ depending
|
||||
|
|
@ -24,7 +24,7 @@ Description:
|
|||
|
||||
What: /sys/bus/bcma/devices/.../class
|
||||
Date: May 2011
|
||||
KernelVersion: 2.6.40
|
||||
KernelVersion: 3.0
|
||||
Contact: Rafał Miłecki <zajec5@gmail.com>
|
||||
Description:
|
||||
Each BCMA core is identified by few fields, including class it
|
||||
|
|
|
|||
|
|
@ -71,3 +71,10 @@ Description: Value of 1 indicates the controller can honor the reset_devices
|
|||
a dump device, as kdump requires resetting the device in order
|
||||
to work reliably.
|
||||
|
||||
Where: /sys/bus/pci/devices/<dev>/ccissX/transport_mode
|
||||
Date: July 2011
|
||||
Kernel Version: 3.0
|
||||
Contact: iss_storagedev@hp.com
|
||||
Description: Value of "simple" indicates that the controller has been placed
|
||||
in "simple mode". Value of "performant" indicates that the
|
||||
controller has been placed in "performant mode".
|
||||
|
|
|
|||
46
Documentation/ABI/testing/sysfs-bus-pci-drivers-ehci_hcd
Normal file
46
Documentation/ABI/testing/sysfs-bus-pci-drivers-ehci_hcd
Normal file
|
|
@ -0,0 +1,46 @@
|
|||
What: /sys/bus/pci/drivers/ehci_hcd/.../companion
|
||||
/sys/bus/usb/devices/usbN/../companion
|
||||
Date: January 2007
|
||||
KernelVersion: 2.6.21
|
||||
Contact: Alan Stern <stern@rowland.harvard.edu>
|
||||
Description:
|
||||
PCI-based EHCI USB controllers (i.e., high-speed USB-2.0
|
||||
controllers) are often implemented along with a set of
|
||||
"companion" full/low-speed USB-1.1 controllers. When a
|
||||
high-speed device is plugged in, the connection is routed
|
||||
to the EHCI controller; when a full- or low-speed device
|
||||
is plugged in, the connection is routed to the companion
|
||||
controller.
|
||||
|
||||
Sometimes you want to force a high-speed device to connect
|
||||
at full speed, which can be accomplished by forcing the
|
||||
connection to be routed to the companion controller.
|
||||
That's what this file does. Writing a port number to the
|
||||
file causes connections on that port to be routed to the
|
||||
companion controller, and writing the negative of a port
|
||||
number returns the port to normal operation.
|
||||
|
||||
For example: To force the high-speed device attached to
|
||||
port 4 on bus 2 to run at full speed:
|
||||
|
||||
echo 4 >/sys/bus/usb/devices/usb2/../companion
|
||||
|
||||
To return the port to high-speed operation:
|
||||
|
||||
echo -4 >/sys/bus/usb/devices/usb2/../companion
|
||||
|
||||
Reading the file gives the list of ports currently forced
|
||||
to the companion controller.
|
||||
|
||||
Note: Some EHCI controllers do not have companions; they
|
||||
may contain an internal "transaction translator" or they
|
||||
may be attached directly to a "rate-matching hub". This
|
||||
mechanism will not work with such controllers. Also, it
|
||||
cannot be used to force a port on a high-speed hub to
|
||||
connect at full speed.
|
||||
|
||||
Note: When this file was first added, it appeared in a
|
||||
different sysfs directory. The location given above is
|
||||
correct for 2.6.35 (and probably several earlier kernel
|
||||
versions as well).
|
||||
|
||||
|
|
@ -142,3 +142,18 @@ Description:
|
|||
such devices.
|
||||
Users:
|
||||
usb_modeswitch
|
||||
|
||||
What: /sys/bus/usb/devices/.../power/usb2_hardware_lpm
|
||||
Date: September 2011
|
||||
Contact: Andiry Xu <andiry.xu@amd.com>
|
||||
Description:
|
||||
If CONFIG_USB_SUSPEND is set and a USB 2.0 lpm-capable device
|
||||
is plugged in to a xHCI host which support link PM, it will
|
||||
perform a LPM test; if the test is passed and host supports
|
||||
USB2 hardware LPM (xHCI 1.0 feature), USB2 hardware LPM will
|
||||
be enabled for the device and the USB device directory will
|
||||
contain a file named power/usb2_hardware_lpm. The file holds
|
||||
a string value (enable or disable) indicating whether or not
|
||||
USB2 hardware LPM is enabled for the device. Developer can
|
||||
write y/Y/1 or n/N/0 to the file to enable/disable the
|
||||
feature.
|
||||
|
|
|
|||
|
|
@ -4,8 +4,8 @@ What: /sys/class/backlight/<backlight>/l2_bright_max
|
|||
What: /sys/class/backlight/<backlight>/l3_office_max
|
||||
What: /sys/class/backlight/<backlight>/l4_indoor_max
|
||||
What: /sys/class/backlight/<backlight>/l5_dark_max
|
||||
Date: Mai 2011
|
||||
KernelVersion: 2.6.40
|
||||
Date: May 2011
|
||||
KernelVersion: 3.0
|
||||
Contact: device-drivers-devel@blackfin.uclinux.org
|
||||
Description:
|
||||
Control the maximum brightness for <ambient light zone>
|
||||
|
|
@ -18,8 +18,8 @@ What: /sys/class/backlight/<backlight>/l2_bright_dim
|
|||
What: /sys/class/backlight/<backlight>/l3_office_dim
|
||||
What: /sys/class/backlight/<backlight>/l4_indoor_dim
|
||||
What: /sys/class/backlight/<backlight>/l5_dark_dim
|
||||
Date: Mai 2011
|
||||
KernelVersion: 2.6.40
|
||||
Date: May 2011
|
||||
KernelVersion: 3.0
|
||||
Contact: device-drivers-devel@blackfin.uclinux.org
|
||||
Description:
|
||||
Control the dim brightness for <ambient light zone>
|
||||
|
|
@ -29,8 +29,8 @@ Description:
|
|||
this <ambient light zone>.
|
||||
|
||||
What: /sys/class/backlight/<backlight>/ambient_light_level
|
||||
Date: Mai 2011
|
||||
KernelVersion: 2.6.40
|
||||
Date: May 2011
|
||||
KernelVersion: 3.0
|
||||
Contact: device-drivers-devel@blackfin.uclinux.org
|
||||
Description:
|
||||
Get conversion value of the light sensor.
|
||||
|
|
@ -39,8 +39,8 @@ Description:
|
|||
8000 (max ambient brightness)
|
||||
|
||||
What: /sys/class/backlight/<backlight>/ambient_light_zone
|
||||
Date: Mai 2011
|
||||
KernelVersion: 2.6.40
|
||||
Date: May 2011
|
||||
KernelVersion: 3.0
|
||||
Contact: device-drivers-devel@blackfin.uclinux.org
|
||||
Description:
|
||||
Get/Set current ambient light zone. Reading returns
|
||||
|
|
|
|||
52
Documentation/ABI/testing/sysfs-class-devfreq
Normal file
52
Documentation/ABI/testing/sysfs-class-devfreq
Normal file
|
|
@ -0,0 +1,52 @@
|
|||
What: /sys/class/devfreq/.../
|
||||
Date: September 2011
|
||||
Contact: MyungJoo Ham <myungjoo.ham@samsung.com>
|
||||
Description:
|
||||
Provide a place in sysfs for the devfreq objects.
|
||||
This allows accessing various devfreq specific variables.
|
||||
The name of devfreq object denoted as ... is same as the
|
||||
name of device using devfreq.
|
||||
|
||||
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
|
||||
governor used by the corresponding devfreq object.
|
||||
|
||||
What: /sys/class/devfreq/.../cur_freq
|
||||
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.
|
||||
|
||||
What: /sys/class/devfreq/.../central_polling
|
||||
Date: September 2011
|
||||
Contact: MyungJoo Ham <myungjoo.ham@samsung.com>
|
||||
Description:
|
||||
The /sys/class/devfreq/.../central_polling shows whether
|
||||
the devfreq ojbect is using devfreq-provided central
|
||||
polling mechanism or not.
|
||||
|
||||
What: /sys/class/devfreq/.../polling_interval
|
||||
Date: September 2011
|
||||
Contact: MyungJoo Ham <myungjoo.ham@samsung.com>
|
||||
Description:
|
||||
The /sys/class/devfreq/.../polling_interval shows and sets
|
||||
the requested polling interval of the corresponding devfreq
|
||||
object. The values are represented in ms. If the value is
|
||||
less than 1 jiffy, it is considered to be 0, which means
|
||||
no polling. This value is meaningless if the governor is
|
||||
not polling; thus. If the governor is not using
|
||||
devfreq-provided central polling
|
||||
(/sys/class/devfreq/.../central_polling is 0), this value
|
||||
may be useless.
|
||||
|
||||
What: /sys/class/devfreq/.../userspace/set_freq
|
||||
Date: September 2011
|
||||
Contact: MyungJoo Ham <myungjoo.ham@samsung.com>
|
||||
Description:
|
||||
The /sys/class/devfreq/.../userspace/set_freq shows and
|
||||
sets the requested frequency for the devfreq object if
|
||||
userspace governor is in effect.
|
||||
|
|
@ -22,6 +22,14 @@ 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>
|
||||
|
|
|
|||
|
|
@ -0,0 +1,7 @@
|
|||
What: /sys/module/hid_logitech/drivers/hid:logitech/<dev>/range.
|
||||
Date: July 2011
|
||||
KernelVersion: 3.2
|
||||
Contact: Michal Malý <madcatxster@gmail.com>
|
||||
Description: Display minimum, maximum and current range of the steering
|
||||
wheel. Writing a value within min and max boundaries sets the
|
||||
range of the wheel.
|
||||
72
Documentation/ABI/testing/sysfs-driver-wacom
Normal file
72
Documentation/ABI/testing/sysfs-driver-wacom
Normal file
|
|
@ -0,0 +1,72 @@
|
|||
What: /sys/class/hidraw/hidraw*/device/speed
|
||||
Date: April 2010
|
||||
Kernel Version: 2.6.35
|
||||
Contact: linux-bluetooth@vger.kernel.org
|
||||
Description:
|
||||
The /sys/class/hidraw/hidraw*/device/speed file controls
|
||||
reporting speed of Wacom bluetooth tablet. Reading from
|
||||
this file returns 1 if tablet reports in high speed mode
|
||||
or 0 otherwise. Writing to this file one of these values
|
||||
switches reporting speed.
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/led
|
||||
Date: August 2011
|
||||
Contact: linux-input@vger.kernel.org
|
||||
Description:
|
||||
Attribute group for control of the status LEDs and the OLEDs.
|
||||
This attribute group is only available for Intuos 4 M, L,
|
||||
and XL (with LEDs and OLEDs) and Cintiq 21UX2 (LEDs only).
|
||||
Therefore its presence implicitly signifies the presence of
|
||||
said LEDs and OLEDs on the tablet device.
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/status0_luminance
|
||||
Date: August 2011
|
||||
Contact: linux-input@vger.kernel.org
|
||||
Description:
|
||||
Writing to this file sets the status LED luminance (1..127)
|
||||
when the stylus does not touch the tablet surface, and no
|
||||
button is pressed on the stylus. This luminance level is
|
||||
normally lower than the level when a button is pressed.
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/status1_luminance
|
||||
Date: August 2011
|
||||
Contact: linux-input@vger.kernel.org
|
||||
Description:
|
||||
Writing to this file sets the status LED luminance (1..127)
|
||||
when the stylus touches the tablet surface, or any button is
|
||||
pressed on the stylus.
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/status_led0_select
|
||||
Date: August 2011
|
||||
Contact: linux-input@vger.kernel.org
|
||||
Description:
|
||||
Writing to this file sets which one of the four (for Intuos 4)
|
||||
or of the right four (for Cintiq 21UX2) status LEDs is active (0..3).
|
||||
The other three LEDs on the same side are always inactive.
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/status_led1_select
|
||||
Date: September 2011
|
||||
Contact: linux-input@vger.kernel.org
|
||||
Description:
|
||||
Writing to this file sets which one of the left four (for Cintiq 21UX2)
|
||||
status LEDs is active (0..3). The other three LEDs on the left are always
|
||||
inactive.
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/buttons_luminance
|
||||
Date: August 2011
|
||||
Contact: linux-input@vger.kernel.org
|
||||
Description:
|
||||
Writing to this file sets the overall luminance level (0..15)
|
||||
of all eight button OLED displays.
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/button<n>_rawimg
|
||||
Date: August 2011
|
||||
Contact: linux-input@vger.kernel.org
|
||||
Description:
|
||||
When writing a 1024 byte raw image in Wacom Intuos 4
|
||||
interleaving format to the file, the image shows up on Button N
|
||||
of the device. The image is a 64x32 pixel 4-bit gray image. The
|
||||
1024 byte binary is split up into 16x 64 byte chunks. Each 64
|
||||
byte chunk encodes the image data for two consecutive lines on
|
||||
the display. The low nibble of each byte contains the first
|
||||
line, and the high nibble contains the second line.
|
||||
|
|
@ -5,19 +5,4 @@ Contact: "Ike Panhc <ike.pan@canonical.com>"
|
|||
Description:
|
||||
Control the power of camera module. 1 means on, 0 means off.
|
||||
|
||||
What: /sys/devices/platform/ideapad/cfg
|
||||
Date: Jun 2011
|
||||
KernelVersion: 3.1
|
||||
Contact: "Ike Panhc <ike.pan@canonical.com>"
|
||||
Description:
|
||||
Ideapad capability bits.
|
||||
Bit 8-10: 1 - Intel graphic only
|
||||
2 - ATI graphic only
|
||||
3 - Nvidia graphic only
|
||||
4 - Intel and ATI graphic
|
||||
5 - Intel and Nvidia graphic
|
||||
Bit 16: Bluetooth exist (1 for exist)
|
||||
Bit 17: 3G exist (1 for exist)
|
||||
Bit 18: Wifi exist (1 for exist)
|
||||
Bit 19: Camera exist (1 for exist)
|
||||
|
||||
|
|
|
|||
|
|
@ -1,10 +0,0 @@
|
|||
What: /sys/class/hidraw/hidraw*/device/speed
|
||||
Date: April 2010
|
||||
Kernel Version: 2.6.35
|
||||
Contact: linux-bluetooth@vger.kernel.org
|
||||
Description:
|
||||
The /sys/class/hidraw/hidraw*/device/speed file controls
|
||||
reporting speed of wacom bluetooth tablet. Reading from
|
||||
this file returns 1 if tablet reports in high speed mode
|
||||
or 0 otherwise. Writing to this file one of these values
|
||||
switches reporting speed.
|
||||
|
|
@ -166,8 +166,8 @@ if (condition)
|
|||
else
|
||||
do_that();
|
||||
|
||||
This does not apply if one branch of a conditional statement is a single
|
||||
statement. Use braces in both branches.
|
||||
This does not apply if only one branch of a conditional statement is a single
|
||||
statement; in the latter case use braces in both branches:
|
||||
|
||||
if (condition) {
|
||||
do_this();
|
||||
|
|
|
|||
|
|
@ -50,6 +50,13 @@ specify the GFP_ flags (see kmalloc) for the allocation (the
|
|||
implementation may choose to ignore flags that affect the location of
|
||||
the returned memory, like GFP_DMA).
|
||||
|
||||
void *
|
||||
dma_zalloc_coherent(struct device *dev, size_t size,
|
||||
dma_addr_t *dma_handle, gfp_t flag)
|
||||
|
||||
Wraps dma_alloc_coherent() and also zeroes the returned memory if the
|
||||
allocation attempt succeeded.
|
||||
|
||||
void
|
||||
dma_free_coherent(struct device *dev, size_t size, void *cpu_addr,
|
||||
dma_addr_t dma_handle)
|
||||
|
|
|
|||
|
|
@ -433,8 +433,18 @@
|
|||
Insert notes about VLAN interfaces with hw crypto here or
|
||||
in the hw crypto chapter.
|
||||
</para>
|
||||
<section id="ps-client">
|
||||
<title>support for powersaving clients</title>
|
||||
!Pinclude/net/mac80211.h AP support for powersaving clients
|
||||
</section>
|
||||
!Finclude/net/mac80211.h ieee80211_get_buffered_bc
|
||||
!Finclude/net/mac80211.h ieee80211_beacon_get
|
||||
!Finclude/net/mac80211.h ieee80211_sta_eosp_irqsafe
|
||||
!Finclude/net/mac80211.h ieee80211_frame_release_type
|
||||
!Finclude/net/mac80211.h ieee80211_sta_ps_transition
|
||||
!Finclude/net/mac80211.h ieee80211_sta_ps_transition_ni
|
||||
!Finclude/net/mac80211.h ieee80211_sta_set_buffered
|
||||
!Finclude/net/mac80211.h ieee80211_sta_block_awake
|
||||
</chapter>
|
||||
|
||||
<chapter id="multi-iface">
|
||||
|
|
@ -460,7 +470,6 @@
|
|||
!Finclude/net/mac80211.h sta_notify_cmd
|
||||
!Finclude/net/mac80211.h ieee80211_find_sta
|
||||
!Finclude/net/mac80211.h ieee80211_find_sta_by_ifaddr
|
||||
!Finclude/net/mac80211.h ieee80211_sta_block_awake
|
||||
</chapter>
|
||||
|
||||
<chapter id="hardware-scan-offload">
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@
|
|||
The Linux DRM layer contains code intended to support the needs
|
||||
of complex graphics devices, usually containing programmable
|
||||
pipelines well suited to 3D graphics acceleration. Graphics
|
||||
drivers in the kernel can make use of DRM functions to make
|
||||
drivers in the kernel may make use of DRM functions to make
|
||||
tasks like memory management, interrupt handling and DMA easier,
|
||||
and provide a uniform interface to applications.
|
||||
</para>
|
||||
|
|
@ -57,10 +57,10 @@
|
|||
existing drivers.
|
||||
</para>
|
||||
<para>
|
||||
First, we'll go over some typical driver initialization
|
||||
First, we go over some typical driver initialization
|
||||
requirements, like setting up command buffers, creating an
|
||||
initial output configuration, and initializing core services.
|
||||
Subsequent sections will cover core internals in more detail,
|
||||
Subsequent sections cover core internals in more detail,
|
||||
providing implementation notes and examples.
|
||||
</para>
|
||||
<para>
|
||||
|
|
@ -74,7 +74,7 @@
|
|||
</para>
|
||||
<para>
|
||||
The core of every DRM driver is struct drm_driver. Drivers
|
||||
will typically statically initialize a drm_driver structure,
|
||||
typically statically initialize a drm_driver structure,
|
||||
then pass it to drm_init() at load time.
|
||||
</para>
|
||||
|
||||
|
|
@ -88,8 +88,8 @@
|
|||
</para>
|
||||
<programlisting>
|
||||
static struct drm_driver driver = {
|
||||
/* don't use mtrr's here, the Xserver or user space app should
|
||||
* deal with them for intel hardware.
|
||||
/* Don't use MTRRs here; the Xserver or userspace app should
|
||||
* deal with them for Intel hardware.
|
||||
*/
|
||||
.driver_features =
|
||||
DRIVER_USE_AGP | DRIVER_REQUIRE_AGP |
|
||||
|
|
@ -154,8 +154,8 @@
|
|||
</programlisting>
|
||||
<para>
|
||||
In the example above, taken from the i915 DRM driver, the driver
|
||||
sets several flags indicating what core features it supports.
|
||||
We'll go over the individual callbacks in later sections. Since
|
||||
sets several flags indicating what core features it supports;
|
||||
we go over the individual callbacks in later sections. Since
|
||||
flags indicate which features your driver supports to the DRM
|
||||
core, you need to set most of them prior to calling drm_init(). Some,
|
||||
like DRIVER_MODESET can be set later based on user supplied parameters,
|
||||
|
|
@ -203,8 +203,8 @@
|
|||
<term>DRIVER_HAVE_IRQ</term><term>DRIVER_IRQ_SHARED</term>
|
||||
<listitem>
|
||||
<para>
|
||||
DRIVER_HAVE_IRQ indicates whether the driver has a IRQ
|
||||
handler, DRIVER_IRQ_SHARED indicates whether the device &
|
||||
DRIVER_HAVE_IRQ indicates whether the driver has an IRQ
|
||||
handler. DRIVER_IRQ_SHARED indicates whether the device &
|
||||
handler support shared IRQs (note that this is required of
|
||||
PCI drivers).
|
||||
</para>
|
||||
|
|
@ -214,8 +214,8 @@
|
|||
<term>DRIVER_DMA_QUEUE</term>
|
||||
<listitem>
|
||||
<para>
|
||||
If the driver queues DMA requests and completes them
|
||||
asynchronously, this flag should be set. Deprecated.
|
||||
Should be set if the driver queues DMA requests and completes them
|
||||
asynchronously. Deprecated.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
|
@ -238,7 +238,7 @@
|
|||
</variablelist>
|
||||
<para>
|
||||
In this specific case, the driver requires AGP and supports
|
||||
IRQs. DMA, as we'll see, is handled by device specific ioctls
|
||||
IRQs. DMA, as discussed later, is handled by device-specific ioctls
|
||||
in this case. It also supports the kernel mode setting APIs, though
|
||||
unlike in the actual i915 driver source, this example unconditionally
|
||||
exports KMS capability.
|
||||
|
|
@ -269,36 +269,34 @@
|
|||
initial output configuration.
|
||||
</para>
|
||||
<para>
|
||||
Note that the tasks performed at driver load time must not
|
||||
conflict with DRM client requirements. For instance, if user
|
||||
If compatibility is a concern (e.g. with drivers converted over
|
||||
to the new interfaces from the old ones), care must be taken to
|
||||
prevent device initialization and control that is incompatible with
|
||||
currently active userspace drivers. For instance, if user
|
||||
level mode setting drivers are in use, it would be problematic
|
||||
to perform output discovery & configuration at load time.
|
||||
Likewise, if pre-memory management aware user level drivers are
|
||||
Likewise, if user-level drivers unaware of memory management are
|
||||
in use, memory management and command buffer setup may need to
|
||||
be omitted. These requirements are driver specific, and care
|
||||
be omitted. These requirements are driver-specific, and care
|
||||
needs to be taken to keep both old and new applications and
|
||||
libraries working. The i915 driver supports the "modeset"
|
||||
module parameter to control whether advanced features are
|
||||
enabled at load time or in legacy fashion. If compatibility is
|
||||
a concern (e.g. with drivers converted over to the new interfaces
|
||||
from the old ones), care must be taken to prevent incompatible
|
||||
device initialization and control with the currently active
|
||||
userspace drivers.
|
||||
enabled at load time or in legacy fashion.
|
||||
</para>
|
||||
|
||||
<sect2>
|
||||
<title>Driver private & performance counters</title>
|
||||
<para>
|
||||
The driver private hangs off the main drm_device structure and
|
||||
can be used for tracking various device specific bits of
|
||||
can be used for tracking various device-specific bits of
|
||||
information, like register offsets, command buffer status,
|
||||
register state for suspend/resume, etc. At load time, a
|
||||
driver can simply allocate one and set drm_device.dev_priv
|
||||
appropriately; at unload the driver can free it and set
|
||||
drm_device.dev_priv to NULL.
|
||||
driver may simply allocate one and set drm_device.dev_priv
|
||||
appropriately; it should be freed and drm_device.dev_priv set
|
||||
to NULL when the driver is unloaded.
|
||||
</para>
|
||||
<para>
|
||||
The DRM supports several counters which can be used for rough
|
||||
The DRM supports several counters which may be used for rough
|
||||
performance characterization. Note that the DRM stat counter
|
||||
system is not often used by applications, and supporting
|
||||
additional counters is completely optional.
|
||||
|
|
@ -307,15 +305,15 @@
|
|||
These interfaces are deprecated and should not be used. If performance
|
||||
monitoring is desired, the developer should investigate and
|
||||
potentially enhance the kernel perf and tracing infrastructure to export
|
||||
GPU related performance information to performance monitoring
|
||||
tools and applications.
|
||||
GPU related performance information for consumption by performance
|
||||
monitoring tools and applications.
|
||||
</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Configuring the device</title>
|
||||
<para>
|
||||
Obviously, device configuration will be device specific.
|
||||
Obviously, device configuration is device-specific.
|
||||
However, there are several common operations: finding a
|
||||
device's PCI resources, mapping them, and potentially setting
|
||||
up an IRQ handler.
|
||||
|
|
@ -323,10 +321,10 @@
|
|||
<para>
|
||||
Finding & mapping resources is fairly straightforward. The
|
||||
DRM wrapper functions, drm_get_resource_start() and
|
||||
drm_get_resource_len() can be used to find BARs on the given
|
||||
drm_get_resource_len(), may be used to find BARs on the given
|
||||
drm_device struct. Once those values have been retrieved, the
|
||||
driver load function can call drm_addmap() to create a new
|
||||
mapping for the BAR in question. Note you'll probably want a
|
||||
mapping for the BAR in question. Note that you probably want a
|
||||
drm_local_map_t in your driver private structure to track any
|
||||
mappings you create.
|
||||
<!-- !Fdrivers/gpu/drm/drm_bufs.c drm_get_resource_* -->
|
||||
|
|
@ -335,20 +333,20 @@
|
|||
<para>
|
||||
if compatibility with other operating systems isn't a concern
|
||||
(DRM drivers can run under various BSD variants and OpenSolaris),
|
||||
native Linux calls can be used for the above, e.g. pci_resource_*
|
||||
native Linux calls may be used for the above, e.g. pci_resource_*
|
||||
and iomap*/iounmap. See the Linux device driver book for more
|
||||
info.
|
||||
</para>
|
||||
<para>
|
||||
Once you have a register map, you can use the DRM_READn() and
|
||||
Once you have a register map, you may use the DRM_READn() and
|
||||
DRM_WRITEn() macros to access the registers on your device, or
|
||||
use driver specific versions to offset into your MMIO space
|
||||
relative to a driver specific base pointer (see I915_READ for
|
||||
example).
|
||||
use driver-specific versions to offset into your MMIO space
|
||||
relative to a driver-specific base pointer (see I915_READ for
|
||||
an example).
|
||||
</para>
|
||||
<para>
|
||||
If your device supports interrupt generation, you may want to
|
||||
setup an interrupt handler at driver load time as well. This
|
||||
set up an interrupt handler when the driver is loaded. This
|
||||
is done using the drm_irq_install() function. If your device
|
||||
supports vertical blank interrupts, it should call
|
||||
drm_vblank_init() to initialize the core vblank handling code before
|
||||
|
|
@ -357,7 +355,7 @@
|
|||
</para>
|
||||
<!--!Fdrivers/char/drm/drm_irq.c drm_irq_install-->
|
||||
<para>
|
||||
Once your interrupt handler is registered (it'll use your
|
||||
Once your interrupt handler is registered (it uses your
|
||||
drm_driver.irq_handler as the actual interrupt handling
|
||||
function), you can safely enable interrupts on your device,
|
||||
assuming any other state your interrupt handler uses is also
|
||||
|
|
@ -371,10 +369,10 @@
|
|||
using the pci_map_rom() call, a convenience function that
|
||||
takes care of mapping the actual ROM, whether it has been
|
||||
shadowed into memory (typically at address 0xc0000) or exists
|
||||
on the PCI device in the ROM BAR. Note that once you've
|
||||
mapped the ROM and extracted any necessary information, be
|
||||
sure to unmap it; on many devices the ROM address decoder is
|
||||
shared with other BARs, so leaving it mapped can cause
|
||||
on the PCI device in the ROM BAR. Note that after the ROM
|
||||
has been mapped and any necessary information has been extracted,
|
||||
it should be unmapped; on many devices, the ROM address decoder is
|
||||
shared with other BARs, so leaving it mapped could cause
|
||||
undesired behavior like hangs or memory corruption.
|
||||
<!--!Fdrivers/pci/rom.c pci_map_rom-->
|
||||
</para>
|
||||
|
|
@ -389,9 +387,9 @@
|
|||
should support a memory manager.
|
||||
</para>
|
||||
<para>
|
||||
If your driver supports memory management (it should!), you'll
|
||||
If your driver supports memory management (it should!), you
|
||||
need to set that up at load time as well. How you initialize
|
||||
it depends on which memory manager you're using, TTM or GEM.
|
||||
it depends on which memory manager you're using: TTM or GEM.
|
||||
</para>
|
||||
<sect3>
|
||||
<title>TTM initialization</title>
|
||||
|
|
@ -401,7 +399,7 @@
|
|||
and devices with dedicated video RAM (VRAM), i.e. most discrete
|
||||
graphics devices. If your device has dedicated RAM, supporting
|
||||
TTM is desirable. TTM also integrates tightly with your
|
||||
driver specific buffer execution function. See the radeon
|
||||
driver-specific buffer execution function. See the radeon
|
||||
driver for examples.
|
||||
</para>
|
||||
<para>
|
||||
|
|
@ -429,21 +427,21 @@
|
|||
created by the memory manager at runtime. Your global TTM should
|
||||
have a type of TTM_GLOBAL_TTM_MEM. The size field for the global
|
||||
object should be sizeof(struct ttm_mem_global), and the init and
|
||||
release hooks should point at your driver specific init and
|
||||
release routines, which will probably eventually call
|
||||
ttm_mem_global_init and ttm_mem_global_release respectively.
|
||||
release hooks should point at your driver-specific init and
|
||||
release routines, which probably eventually call
|
||||
ttm_mem_global_init and ttm_mem_global_release, respectively.
|
||||
</para>
|
||||
<para>
|
||||
Once your global TTM accounting structure is set up and initialized
|
||||
(done by calling ttm_global_item_ref on the global object you
|
||||
just created), you'll need to create a buffer object TTM to
|
||||
by calling ttm_global_item_ref() on it,
|
||||
you need to create a buffer object TTM to
|
||||
provide a pool for buffer object allocation by clients and the
|
||||
kernel itself. The type of this object should be TTM_GLOBAL_TTM_BO,
|
||||
and its size should be sizeof(struct ttm_bo_global). Again,
|
||||
driver specific init and release functions can be provided,
|
||||
likely eventually calling ttm_bo_global_init and
|
||||
ttm_bo_global_release, respectively. Also like the previous
|
||||
object, ttm_global_item_ref is used to create an initial reference
|
||||
driver-specific init and release functions may be provided,
|
||||
likely eventually calling ttm_bo_global_init() and
|
||||
ttm_bo_global_release(), respectively. Also, like the previous
|
||||
object, ttm_global_item_ref() is used to create an initial reference
|
||||
count for the TTM, which will call your initialization function.
|
||||
</para>
|
||||
</sect3>
|
||||
|
|
@ -453,27 +451,26 @@
|
|||
GEM is an alternative to TTM, designed specifically for UMA
|
||||
devices. It has simpler initialization and execution requirements
|
||||
than TTM, but has no VRAM management capability. Core GEM
|
||||
initialization is comprised of a basic drm_mm_init call to create
|
||||
is initialized by calling drm_mm_init() to create
|
||||
a GTT DRM MM object, which provides an address space pool for
|
||||
object allocation. In a KMS configuration, the driver will
|
||||
need to allocate and initialize a command ring buffer following
|
||||
basic GEM initialization. Most UMA devices have a so-called
|
||||
object allocation. In a KMS configuration, the driver
|
||||
needs to allocate and initialize a command ring buffer following
|
||||
core GEM initialization. A UMA device usually has what is called a
|
||||
"stolen" memory region, which provides space for the initial
|
||||
framebuffer and large, contiguous memory regions required by the
|
||||
device. This space is not typically managed by GEM, and must
|
||||
device. This space is not typically managed by GEM, and it must
|
||||
be initialized separately into its own DRM MM object.
|
||||
</para>
|
||||
<para>
|
||||
Initialization will be driver specific, and will depend on
|
||||
the architecture of the device. In the case of Intel
|
||||
Initialization is driver-specific. In the case of Intel
|
||||
integrated graphics chips like 965GM, GEM initialization can
|
||||
be done by calling the internal GEM init function,
|
||||
i915_gem_do_init(). Since the 965GM is a UMA device
|
||||
(i.e. it doesn't have dedicated VRAM), GEM will manage
|
||||
(i.e. it doesn't have dedicated VRAM), GEM manages
|
||||
making regular RAM available for GPU operations. Memory set
|
||||
aside by the BIOS (called "stolen" memory by the i915
|
||||
driver) will be managed by the DRM memrange allocator; the
|
||||
rest of the aperture will be managed by GEM.
|
||||
driver) is managed by the DRM memrange allocator; the
|
||||
rest of the aperture is managed by GEM.
|
||||
<programlisting>
|
||||
/* Basic memrange allocator for stolen space (aka vram) */
|
||||
drm_memrange_init(&dev_priv->vram, 0, prealloc_size);
|
||||
|
|
@ -483,7 +480,7 @@
|
|||
<!--!Edrivers/char/drm/drm_memrange.c-->
|
||||
</para>
|
||||
<para>
|
||||
Once the memory manager has been set up, we can allocate the
|
||||
Once the memory manager has been set up, we may allocate the
|
||||
command buffer. In the i915 case, this is also done with a
|
||||
GEM function, i915_gem_init_ringbuffer().
|
||||
</para>
|
||||
|
|
@ -493,16 +490,25 @@
|
|||
<sect2>
|
||||
<title>Output configuration</title>
|
||||
<para>
|
||||
The final initialization task is output configuration. This involves
|
||||
finding and initializing the CRTCs, encoders and connectors
|
||||
for your device, creating an initial configuration and
|
||||
registering a framebuffer console driver.
|
||||
The final initialization task is output configuration. This involves:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
Finding and initializing the CRTCs, encoders, and connectors
|
||||
for the device.
|
||||
</listitem>
|
||||
<listitem>
|
||||
Creating an initial configuration.
|
||||
</listitem>
|
||||
<listitem>
|
||||
Registering a framebuffer console driver.
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
<sect3>
|
||||
<title>Output discovery and initialization</title>
|
||||
<para>
|
||||
Several core functions exist to create CRTCs, encoders and
|
||||
connectors, namely drm_crtc_init(), drm_connector_init() and
|
||||
Several core functions exist to create CRTCs, encoders, and
|
||||
connectors, namely: drm_crtc_init(), drm_connector_init(), and
|
||||
drm_encoder_init(), along with several "helper" functions to
|
||||
perform common tasks.
|
||||
</para>
|
||||
|
|
@ -555,10 +561,10 @@ void intel_crt_init(struct drm_device *dev)
|
|||
</programlisting>
|
||||
<para>
|
||||
In the example above (again, taken from the i915 driver), a
|
||||
CRT connector and encoder combination is created. A device
|
||||
specific i2c bus is also created, for fetching EDID data and
|
||||
CRT connector and encoder combination is created. A device-specific
|
||||
i2c bus is also created for fetching EDID data and
|
||||
performing monitor detection. Once the process is complete,
|
||||
the new connector is registered with sysfs, to make its
|
||||
the new connector is registered with sysfs to make its
|
||||
properties available to applications.
|
||||
</para>
|
||||
<sect4>
|
||||
|
|
@ -567,12 +573,12 @@ void intel_crt_init(struct drm_device *dev)
|
|||
Since many PC-class graphics devices have similar display output
|
||||
designs, the DRM provides a set of helper functions to make
|
||||
output management easier. The core helper routines handle
|
||||
encoder re-routing and disabling of unused functions following
|
||||
mode set. Using the helpers is optional, but recommended for
|
||||
encoder re-routing and the disabling of unused functions following
|
||||
mode setting. Using the helpers is optional, but recommended for
|
||||
devices with PC-style architectures (i.e. a set of display planes
|
||||
for feeding pixels to encoders which are in turn routed to
|
||||
connectors). Devices with more complex requirements needing
|
||||
finer grained management can opt to use the core callbacks
|
||||
finer grained management may opt to use the core callbacks
|
||||
directly.
|
||||
</para>
|
||||
<para>
|
||||
|
|
@ -580,17 +586,25 @@ void intel_crt_init(struct drm_device *dev)
|
|||
</para>
|
||||
</sect4>
|
||||
<para>
|
||||
For each encoder, CRTC and connector, several functions must
|
||||
be provided, depending on the object type. Encoder objects
|
||||
need to provide a DPMS (basically on/off) function, mode fixup
|
||||
(for converting requested modes into native hardware timings),
|
||||
and prepare, set and commit functions for use by the core DRM
|
||||
helper functions. Connector helpers need to provide mode fetch and
|
||||
validity functions as well as an encoder matching function for
|
||||
returning an ideal encoder for a given connector. The core
|
||||
connector functions include a DPMS callback, (deprecated)
|
||||
save/restore routines, detection, mode probing, property handling,
|
||||
and cleanup functions.
|
||||
Each encoder object needs to provide:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
A DPMS (basically on/off) function.
|
||||
</listitem>
|
||||
<listitem>
|
||||
A mode-fixup function (for converting requested modes into
|
||||
native hardware timings).
|
||||
</listitem>
|
||||
<listitem>
|
||||
Functions (prepare, set, and commit) for use by the core DRM
|
||||
helper functions.
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
Connector helpers need to provide functions (mode-fetch, validity,
|
||||
and encoder-matching) for returning an ideal encoder for a given
|
||||
connector. The core connector functions include a DPMS callback,
|
||||
save/restore routines (deprecated), detection, mode probing,
|
||||
property handling, and cleanup functions.
|
||||
</para>
|
||||
<!--!Edrivers/char/drm/drm_crtc.h-->
|
||||
<!--!Edrivers/char/drm/drm_crtc.c-->
|
||||
|
|
@ -605,22 +619,33 @@ void intel_crt_init(struct drm_device *dev)
|
|||
<title>VBlank event handling</title>
|
||||
<para>
|
||||
The DRM core exposes two vertical blank related ioctls:
|
||||
DRM_IOCTL_WAIT_VBLANK and DRM_IOCTL_MODESET_CTL.
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>DRM_IOCTL_WAIT_VBLANK</term>
|
||||
<listitem>
|
||||
<para>
|
||||
This takes a struct drm_wait_vblank structure as its argument,
|
||||
and it is used to block or request a signal when a specified
|
||||
vblank event occurs.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>DRM_IOCTL_MODESET_CTL</term>
|
||||
<listitem>
|
||||
<para>
|
||||
This should be called by application level drivers before and
|
||||
after mode setting, since on many devices the vertical blank
|
||||
counter is reset at that time. Internally, the DRM snapshots
|
||||
the last vblank count when the ioctl is called with the
|
||||
_DRM_PRE_MODESET command, so that the counter won't go backwards
|
||||
(which is dealt with when _DRM_POST_MODESET is used).
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
<!--!Edrivers/char/drm/drm_irq.c-->
|
||||
</para>
|
||||
<para>
|
||||
DRM_IOCTL_WAIT_VBLANK takes a struct drm_wait_vblank structure
|
||||
as its argument, and is used to block or request a signal when a
|
||||
specified vblank event occurs.
|
||||
</para>
|
||||
<para>
|
||||
DRM_IOCTL_MODESET_CTL should be called by application level
|
||||
drivers before and after mode setting, since on many devices the
|
||||
vertical blank counter will be reset at that time. Internally,
|
||||
the DRM snapshots the last vblank count when the ioctl is called
|
||||
with the _DRM_PRE_MODESET command so that the counter won't go
|
||||
backwards (which is dealt with when _DRM_POST_MODESET is used).
|
||||
</para>
|
||||
<para>
|
||||
To support the functions above, the DRM core provides several
|
||||
helper functions for tracking vertical blank counters, and
|
||||
|
|
@ -632,24 +657,24 @@ void intel_crt_init(struct drm_device *dev)
|
|||
register. The enable and disable vblank callbacks should enable
|
||||
and disable vertical blank interrupts, respectively. In the
|
||||
absence of DRM clients waiting on vblank events, the core DRM
|
||||
code will use the disable_vblank() function to disable
|
||||
interrupts, which saves power. They'll be re-enabled again when
|
||||
code uses the disable_vblank() function to disable
|
||||
interrupts, which saves power. They are re-enabled again when
|
||||
a client calls the vblank wait ioctl above.
|
||||
</para>
|
||||
<para>
|
||||
Devices that don't provide a count register can simply use an
|
||||
A device that doesn't provide a count register may simply use an
|
||||
internal atomic counter incremented on every vertical blank
|
||||
interrupt, and can make their enable and disable vblank
|
||||
functions into no-ops.
|
||||
interrupt (and then treat the enable_vblank() and disable_vblank()
|
||||
callbacks as no-ops).
|
||||
</para>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Memory management</title>
|
||||
<para>
|
||||
The memory manager lies at the heart of many DRM operations, and
|
||||
is also required to support advanced client features like OpenGL
|
||||
pbuffers. The DRM currently contains two memory managers, TTM
|
||||
The memory manager lies at the heart of many DRM operations; it
|
||||
is required to support advanced client features like OpenGL
|
||||
pbuffers. The DRM currently contains two memory managers: TTM
|
||||
and GEM.
|
||||
</para>
|
||||
|
||||
|
|
@ -679,41 +704,46 @@ void intel_crt_init(struct drm_device *dev)
|
|||
<para>
|
||||
GEM-enabled drivers must provide gem_init_object() and
|
||||
gem_free_object() callbacks to support the core memory
|
||||
allocation routines. They should also provide several driver
|
||||
specific ioctls to support command execution, pinning, buffer
|
||||
allocation routines. They should also provide several driver-specific
|
||||
ioctls to support command execution, pinning, buffer
|
||||
read & write, mapping, and domain ownership transfers.
|
||||
</para>
|
||||
<para>
|
||||
On a fundamental level, GEM involves several operations: memory
|
||||
allocation and freeing, command execution, and aperture management
|
||||
at command execution time. Buffer object allocation is relatively
|
||||
On a fundamental level, GEM involves several operations:
|
||||
<itemizedlist>
|
||||
<listitem>Memory allocation and freeing</listitem>
|
||||
<listitem>Command execution</listitem>
|
||||
<listitem>Aperture management at command execution time</listitem>
|
||||
</itemizedlist>
|
||||
Buffer object allocation is relatively
|
||||
straightforward and largely provided by Linux's shmem layer, which
|
||||
provides memory to back each object. When mapped into the GTT
|
||||
or used in a command buffer, the backing pages for an object are
|
||||
flushed to memory and marked write combined so as to be coherent
|
||||
with the GPU. Likewise, when the GPU finishes rendering to an object,
|
||||
if the CPU accesses it, it must be made coherent with the CPU's view
|
||||
with the GPU. Likewise, if the CPU accesses an object after the GPU
|
||||
has finished rendering to the object, then the object must be made
|
||||
coherent with the CPU's view
|
||||
of memory, usually involving GPU cache flushing of various kinds.
|
||||
This core CPU<->GPU coherency management is provided by the GEM
|
||||
set domain function, which evaluates an object's current domain and
|
||||
This core CPU<->GPU coherency management is provided by a
|
||||
device-specific ioctl, which evaluates an object's current domain and
|
||||
performs any necessary flushing or synchronization to put the object
|
||||
into the desired coherency domain (note that the object may be busy,
|
||||
i.e. an active render target; in that case the set domain function
|
||||
will block the client and wait for rendering to complete before
|
||||
i.e. an active render target; in that case, setting the domain
|
||||
blocks the client and waits for rendering to complete before
|
||||
performing any necessary flushing operations).
|
||||
</para>
|
||||
<para>
|
||||
Perhaps the most important GEM function is providing a command
|
||||
execution interface to clients. Client programs construct command
|
||||
buffers containing references to previously allocated memory objects
|
||||
and submit them to GEM. At that point, GEM will take care to bind
|
||||
buffers containing references to previously allocated memory objects,
|
||||
and then submit them to GEM. At that point, GEM takes care to bind
|
||||
all the objects into the GTT, execute the buffer, and provide
|
||||
necessary synchronization between clients accessing the same buffers.
|
||||
This often involves evicting some objects from the GTT and re-binding
|
||||
others (a fairly expensive operation), and providing relocation
|
||||
support which hides fixed GTT offsets from clients. Clients must
|
||||
take care not to submit command buffers that reference more objects
|
||||
than can fit in the GTT or GEM will reject them and no rendering
|
||||
than can fit in the GTT; otherwise, GEM will reject them and no rendering
|
||||
will occur. Similarly, if several objects in the buffer require
|
||||
fence registers to be allocated for correct rendering (e.g. 2D blits
|
||||
on pre-965 chips), care must be taken not to require more fence
|
||||
|
|
@ -729,7 +759,7 @@ void intel_crt_init(struct drm_device *dev)
|
|||
<title>Output management</title>
|
||||
<para>
|
||||
At the core of the DRM output management code is a set of
|
||||
structures representing CRTCs, encoders and connectors.
|
||||
structures representing CRTCs, encoders, and connectors.
|
||||
</para>
|
||||
<para>
|
||||
A CRTC is an abstraction representing a part of the chip that
|
||||
|
|
@ -765,21 +795,19 @@ void intel_crt_init(struct drm_device *dev)
|
|||
<sect1>
|
||||
<title>Framebuffer management</title>
|
||||
<para>
|
||||
In order to set a mode on a given CRTC, encoder and connector
|
||||
configuration, clients need to provide a framebuffer object which
|
||||
will provide a source of pixels for the CRTC to deliver to the encoder(s)
|
||||
and ultimately the connector(s) in the configuration. A framebuffer
|
||||
is fundamentally a driver specific memory object, made into an opaque
|
||||
handle by the DRM addfb function. Once an fb has been created this
|
||||
way it can be passed to the KMS mode setting routines for use in
|
||||
a configuration.
|
||||
Clients need to provide a framebuffer object which provides a source
|
||||
of pixels for a CRTC to deliver to the encoder(s) and ultimately the
|
||||
connector(s). A framebuffer is fundamentally a driver-specific memory
|
||||
object, made into an opaque handle by the DRM's addfb() function.
|
||||
Once a framebuffer has been created this way, it may be passed to the
|
||||
KMS mode setting routines for use in a completed configuration.
|
||||
</para>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Command submission & fencing</title>
|
||||
<para>
|
||||
This should cover a few device specific command submission
|
||||
This should cover a few device-specific command submission
|
||||
implementations.
|
||||
</para>
|
||||
</sect1>
|
||||
|
|
@ -789,7 +817,7 @@ void intel_crt_init(struct drm_device *dev)
|
|||
<para>
|
||||
The DRM core provides some suspend/resume code, but drivers
|
||||
wanting full suspend/resume support should provide save() and
|
||||
restore() functions. These will be called at suspend,
|
||||
restore() functions. These are called at suspend,
|
||||
hibernate, or resume time, and should perform any state save or
|
||||
restore required by your device across suspend or hibernate
|
||||
states.
|
||||
|
|
@ -812,8 +840,8 @@ void intel_crt_init(struct drm_device *dev)
|
|||
<para>
|
||||
The DRM core exports several interfaces to applications,
|
||||
generally intended to be used through corresponding libdrm
|
||||
wrapper functions. In addition, drivers export device specific
|
||||
interfaces for use by userspace drivers & device aware
|
||||
wrapper functions. In addition, drivers export device-specific
|
||||
interfaces for use by userspace drivers & device-aware
|
||||
applications through ioctls and sysfs files.
|
||||
</para>
|
||||
<para>
|
||||
|
|
@ -822,8 +850,8 @@ void intel_crt_init(struct drm_device *dev)
|
|||
management, memory management, and output management.
|
||||
</para>
|
||||
<para>
|
||||
Cover generic ioctls and sysfs layout here. Only need high
|
||||
level info, since man pages will cover the rest.
|
||||
Cover generic ioctls and sysfs layout here. We only need high-level
|
||||
info, since man pages should cover the rest.
|
||||
</para>
|
||||
</chapter>
|
||||
|
||||
|
|
|
|||
|
|
@ -352,6 +352,7 @@ typedef enum fe_delivery_system {
|
|||
SYS_CMMB,
|
||||
SYS_DAB,
|
||||
SYS_DVBT2,
|
||||
SYS_TURBO,
|
||||
} fe_delivery_system_t;
|
||||
</programlisting>
|
||||
</section>
|
||||
|
|
@ -809,6 +810,8 @@ typedef enum fe_hierarchy {
|
|||
<listitem><para><link linkend="DTV-INVERSION"><constant>DTV_INVERSION</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-SYMBOL-RATE"><constant>DTV_SYMBOL_RATE</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-INNER-FEC"><constant>DTV_INNER_FEC</constant></link></para></listitem>
|
||||
<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>Future implementations might add those two missing parameters:</para>
|
||||
<itemizedlist mark='opencircle'>
|
||||
|
|
@ -818,25 +821,18 @@ typedef enum fe_hierarchy {
|
|||
</section>
|
||||
<section id="dvbs2-params">
|
||||
<title>DVB-S2 delivery system</title>
|
||||
<para>The following parameters are valid for DVB-S2:</para>
|
||||
<para>In addition to all parameters valid for DVB-S, DVB-S2 supports the following parameters:</para>
|
||||
<itemizedlist mark='opencircle'>
|
||||
<listitem><para><link linkend="DTV-API-VERSION"><constant>DTV_API_VERSION</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-DELIVERY-SYSTEM"><constant>DTV_DELIVERY_SYSTEM</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-TUNE"><constant>DTV_TUNE</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-CLEAR"><constant>DTV_CLEAR</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-FREQUENCY"><constant>DTV_FREQUENCY</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-INVERSION"><constant>DTV_INVERSION</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-SYMBOL-RATE"><constant>DTV_SYMBOL_RATE</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-INNER-FEC"><constant>DTV_INNER_FEC</constant></link></para></listitem>
|
||||
<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>
|
||||
<listitem><para><link linkend="DTV-MODULATION"><constant>DTV_MODULATION</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-PILOT"><constant>DTV_PILOT</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-ROLLOFF"><constant>DTV_ROLLOFF</constant></link></para></listitem>
|
||||
</itemizedlist>
|
||||
<para>Future implementations might add those two missing parameters:</para>
|
||||
</section>
|
||||
<section id="turbo-params">
|
||||
<title>Turbo code delivery system</title>
|
||||
<para>In addition to all parameters valid for DVB-S, turbo code supports the following parameters:</para>
|
||||
<itemizedlist mark='opencircle'>
|
||||
<listitem><para><link linkend="DTV-DISEQC-MASTER"><constant>DTV_DISEQC_MASTER</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-DISEQC-SLAVE-REPLY"><constant>DTV_DISEQC_SLAVE_REPLY</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-MODULATION"><constant>DTV_MODULATION</constant></link></para></listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
<section id="isdbs-params">
|
||||
|
|
|
|||
|
|
@ -205,7 +205,7 @@ a partial path like:</para>
|
|||
additional include file <emphasis
|
||||
role="tt">linux/dvb/version.h</emphasis> exists, which defines the
|
||||
constant <emphasis role="tt">DVB_API_VERSION</emphasis>. This document
|
||||
describes <emphasis role="tt">DVB_API_VERSION 3</emphasis>.
|
||||
describes <emphasis role="tt">DVB_API_VERSION 5.4</emphasis>.
|
||||
</para>
|
||||
|
||||
</section>
|
||||
|
|
|
|||
|
|
@ -2370,6 +2370,14 @@ that used it. It was originally scheduled for removal in 2.6.35.
|
|||
</listitem>
|
||||
</orderedlist>
|
||||
</section>
|
||||
<section>
|
||||
<title>V4L2 in Linux 3.2</title>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>V4L2_CTRL_FLAG_VOLATILE was added to signal volatile controls to userspace.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</section>
|
||||
|
||||
<section id="other">
|
||||
<title>Relation of V4L2 to other Linux multimedia APIs</title>
|
||||
|
|
@ -2478,6 +2486,9 @@ ioctls.</para>
|
|||
<listitem>
|
||||
<para>Flash API. <xref linkend="flash-controls" /></para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>&VIDIOC-CREATE-BUFS; and &VIDIOC-PREPARE-BUF; ioctls.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
|
||||
|
|
|
|||
|
|
@ -232,8 +232,9 @@ control is deprecated. New drivers and applications should use the
|
|||
<entry>Enables a power line frequency filter to avoid
|
||||
flicker. Possible values for <constant>enum v4l2_power_line_frequency</constant> are:
|
||||
<constant>V4L2_CID_POWER_LINE_FREQUENCY_DISABLED</constant> (0),
|
||||
<constant>V4L2_CID_POWER_LINE_FREQUENCY_50HZ</constant> (1) and
|
||||
<constant>V4L2_CID_POWER_LINE_FREQUENCY_60HZ</constant> (2).</entry>
|
||||
<constant>V4L2_CID_POWER_LINE_FREQUENCY_50HZ</constant> (1),
|
||||
<constant>V4L2_CID_POWER_LINE_FREQUENCY_60HZ</constant> (2) and
|
||||
<constant>V4L2_CID_POWER_LINE_FREQUENCY_AUTO</constant> (3).</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_CID_HUE_AUTO</constant></entry>
|
||||
|
|
|
|||
|
|
@ -266,7 +266,7 @@
|
|||
|
||||
<para>When satisfied with the try results, applications can set the active
|
||||
formats by setting the <structfield>which</structfield> argument to
|
||||
<constant>V4L2_SUBDEV_FORMAT_TRY</constant>. Active formats are changed
|
||||
<constant>V4L2_SUBDEV_FORMAT_ACTIVE</constant>. Active formats are changed
|
||||
exactly as try formats by drivers. To avoid modifying the hardware state
|
||||
during format negotiation, applications should negotiate try formats first
|
||||
and then modify the active settings using the try formats returned during
|
||||
|
|
|
|||
|
|
@ -927,6 +927,33 @@ ioctl is called.</entry>
|
|||
Applications set or clear this flag before calling the
|
||||
<constant>VIDIOC_QBUF</constant> ioctl.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_BUF_FLAG_PREPARED</constant></entry>
|
||||
<entry>0x0400</entry>
|
||||
<entry>The buffer has been prepared for I/O and can be queued by the
|
||||
application. Drivers set or clear this flag when the
|
||||
<link linkend="vidioc-querybuf">VIDIOC_QUERYBUF</link>, <link
|
||||
linkend="vidioc-qbuf">VIDIOC_PREPARE_BUF</link>, <link
|
||||
linkend="vidioc-qbuf">VIDIOC_QBUF</link> or <link
|
||||
linkend="vidioc-qbuf">VIDIOC_DQBUF</link> ioctl is called.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_BUF_FLAG_NO_CACHE_INVALIDATE</constant></entry>
|
||||
<entry>0x0400</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
|
||||
passed on to a DMA-capable hardware unit for further processing or output.
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_BUF_FLAG_NO_CACHE_CLEAN</constant></entry>
|
||||
<entry>0x0800</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>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
|
|
|
|||
|
|
@ -127,6 +127,13 @@ structs, ioctls) must be noted in more detail in the history chapter
|
|||
(compat.xml), along with the possible impact on existing drivers and
|
||||
applications. -->
|
||||
|
||||
<revision>
|
||||
<revnumber>3.2</revnumber>
|
||||
<date>2011-08-26</date>
|
||||
<authorinitials>hv</authorinitials>
|
||||
<revremark>Added V4L2_CTRL_FLAG_VOLATILE.</revremark>
|
||||
</revision>
|
||||
|
||||
<revision>
|
||||
<revnumber>3.1</revnumber>
|
||||
<date>2011-06-27</date>
|
||||
|
|
@ -410,7 +417,7 @@ and discussions on the V4L mailing list.</revremark>
|
|||
</partinfo>
|
||||
|
||||
<title>Video for Linux Two API Specification</title>
|
||||
<subtitle>Revision 3.1</subtitle>
|
||||
<subtitle>Revision 3.2</subtitle>
|
||||
|
||||
<chapter id="common">
|
||||
&sub-common;
|
||||
|
|
@ -462,6 +469,7 @@ and discussions on the V4L mailing list.</revremark>
|
|||
&sub-close;
|
||||
&sub-ioctl;
|
||||
<!-- All ioctls go here. -->
|
||||
&sub-create-bufs;
|
||||
&sub-cropcap;
|
||||
&sub-dbg-g-chip-ident;
|
||||
&sub-dbg-g-register;
|
||||
|
|
@ -504,6 +512,7 @@ and discussions on the V4L mailing list.</revremark>
|
|||
&sub-queryctrl;
|
||||
&sub-query-dv-preset;
|
||||
&sub-querystd;
|
||||
&sub-prepare-buf;
|
||||
&sub-reqbufs;
|
||||
&sub-s-hw-freq-seek;
|
||||
&sub-streamon;
|
||||
|
|
|
|||
139
Documentation/DocBook/media/v4l/vidioc-create-bufs.xml
Normal file
139
Documentation/DocBook/media/v4l/vidioc-create-bufs.xml
Normal file
|
|
@ -0,0 +1,139 @@
|
|||
<refentry id="vidioc-create-bufs">
|
||||
<refmeta>
|
||||
<refentrytitle>ioctl VIDIOC_CREATE_BUFS</refentrytitle>
|
||||
&manvol;
|
||||
</refmeta>
|
||||
|
||||
<refnamediv>
|
||||
<refname>VIDIOC_CREATE_BUFS</refname>
|
||||
<refpurpose>Create buffers for Memory Mapped or User Pointer I/O</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_create_buffers *<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_CREATE_BUFS</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><parameter>argp</parameter></term>
|
||||
<listitem>
|
||||
<para></para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
<title>Description</title>
|
||||
|
||||
<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>
|
||||
|
||||
<para>To allocate device buffers applications initialize relevant fields of
|
||||
the <structname>v4l2_create_buffers</structname> structure. They set the
|
||||
<structfield>type</structfield> field in the
|
||||
<structname>v4l2_format</structname> structure, embedded in this
|
||||
structure, to the respective stream or buffer type.
|
||||
<structfield>count</structfield> must be set to the number of required buffers.
|
||||
<structfield>memory</structfield> specifies the required I/O method. The
|
||||
<structfield>format</structfield> field shall typically be filled in using
|
||||
either the <constant>VIDIOC_TRY_FMT</constant> or
|
||||
<constant>VIDIOC_G_FMT</constant> ioctl(). Additionally, applications can adjust
|
||||
<structfield>sizeimage</structfield> fields to fit their specific needs. The
|
||||
<structfield>reserved</structfield> array must be zeroed.</para>
|
||||
|
||||
<para>When the ioctl is called with a pointer to this structure the driver
|
||||
will attempt to allocate up to the requested number of buffers and store the
|
||||
actual number allocated and the starting index in the
|
||||
<structfield>count</structfield> and the <structfield>index</structfield> fields
|
||||
respectively. On return <structfield>count</structfield> can be smaller than
|
||||
the number requested. The driver may also increase buffer sizes if required,
|
||||
however, it will not update <structfield>sizeimage</structfield> field values.
|
||||
The user has to use <constant>VIDIOC_QUERYBUF</constant> to retrieve that
|
||||
information.</para>
|
||||
|
||||
<table pgwide="1" frame="none" id="v4l2-create-buffers">
|
||||
<title>struct <structname>v4l2_create_buffers</structname></title>
|
||||
<tgroup cols="3">
|
||||
&cs-str;
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>index</structfield></entry>
|
||||
<entry>The starting buffer index, returned by the driver.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>count</structfield></entry>
|
||||
<entry>The number of buffers requested or granted.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>&v4l2-memory;</entry>
|
||||
<entry><structfield>memory</structfield></entry>
|
||||
<entry>Applications set this field to
|
||||
<constant>V4L2_MEMORY_MMAP</constant> or
|
||||
<constant>V4L2_MEMORY_USERPTR</constant>.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>&v4l2-format;</entry>
|
||||
<entry><structfield>format</structfield></entry>
|
||||
<entry>Filled in by the application, preserved by the driver.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>reserved</structfield>[8]</entry>
|
||||
<entry>A place holder for future extensions.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
&return-value;
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><errorcode>ENOMEM</errorcode></term>
|
||||
<listitem>
|
||||
<para>No memory to allocate buffers for <link linkend="mmap">memory
|
||||
mapped</link> I/O.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><errorcode>EINVAL</errorcode></term>
|
||||
<listitem>
|
||||
<para>The buffer type (<structfield>type</structfield> field) or the
|
||||
requested I/O method (<structfield>memory</structfield>) is not
|
||||
supported.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</refsect1>
|
||||
</refentry>
|
||||
|
|
@ -86,6 +86,12 @@
|
|||
<entry>Event data for event V4L2_EVENT_CTRL.
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry>&v4l2-event-frame-sync;</entry>
|
||||
<entry><structfield>frame</structfield></entry>
|
||||
<entry>Event data for event V4L2_EVENT_FRAME_SYNC.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry>__u8</entry>
|
||||
|
|
@ -135,6 +141,129 @@
|
|||
</tgroup>
|
||||
</table>
|
||||
|
||||
<table frame="none" pgwide="1" id="v4l2-event-vsync">
|
||||
<title>struct <structname>v4l2_event_vsync</structname></title>
|
||||
<tgroup cols="3">
|
||||
&cs-str;
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry>__u8</entry>
|
||||
<entry><structfield>field</structfield></entry>
|
||||
<entry>The upcoming field. See &v4l2-field;.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
|
||||
<table frame="none" pgwide="1" id="v4l2-event-ctrl">
|
||||
<title>struct <structname>v4l2_event_ctrl</structname></title>
|
||||
<tgroup cols="4">
|
||||
&cs-str;
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>changes</structfield></entry>
|
||||
<entry></entry>
|
||||
<entry>A bitmask that tells what has changed. See <xref linkend="changes-flags" />.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>type</structfield></entry>
|
||||
<entry></entry>
|
||||
<entry>The type of the control. See &v4l2-ctrl-type;.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>union (anonymous)</entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry>__s32</entry>
|
||||
<entry><structfield>value</structfield></entry>
|
||||
<entry>The 32-bit value of the control for 32-bit control types.
|
||||
This is 0 for string controls since the value of a string
|
||||
cannot be passed using &VIDIOC-DQEVENT;.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry>__s64</entry>
|
||||
<entry><structfield>value64</structfield></entry>
|
||||
<entry>The 64-bit value of the control for 64-bit control types.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>flags</structfield></entry>
|
||||
<entry></entry>
|
||||
<entry>The control flags. See <xref linkend="control-flags" />.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__s32</entry>
|
||||
<entry><structfield>minimum</structfield></entry>
|
||||
<entry></entry>
|
||||
<entry>The minimum value of the control. See &v4l2-queryctrl;.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__s32</entry>
|
||||
<entry><structfield>maximum</structfield></entry>
|
||||
<entry></entry>
|
||||
<entry>The maximum value of the control. See &v4l2-queryctrl;.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__s32</entry>
|
||||
<entry><structfield>step</structfield></entry>
|
||||
<entry></entry>
|
||||
<entry>The step value of the control. See &v4l2-queryctrl;.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__s32</entry>
|
||||
<entry><structfield>default_value</structfield></entry>
|
||||
<entry></entry>
|
||||
<entry>The default value value of the control. See &v4l2-queryctrl;.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
|
||||
<table frame="none" pgwide="1" id="v4l2-event-frame-sync">
|
||||
<title>struct <structname>v4l2_event_frame_sync</structname></title>
|
||||
<tgroup cols="3">
|
||||
&cs-str;
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>frame_sequence</structfield></entry>
|
||||
<entry>
|
||||
The sequence number of the frame being received.
|
||||
</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
|
||||
<table pgwide="1" frame="none" id="changes-flags">
|
||||
<title>Changes</title>
|
||||
<tgroup cols="3">
|
||||
&cs-def;
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry><constant>V4L2_EVENT_CTRL_CH_VALUE</constant></entry>
|
||||
<entry>0x0001</entry>
|
||||
<entry>This control event was triggered because the value of the control
|
||||
changed. Special case: if a button control is pressed, then this
|
||||
event is sent as well, even though there is not explicit value
|
||||
associated with a button control.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_EVENT_CTRL_CH_FLAGS</constant></entry>
|
||||
<entry>0x0002</entry>
|
||||
<entry>This control event was triggered because the control flags
|
||||
changed.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
</refsect1>
|
||||
<refsect1>
|
||||
&return-value;
|
||||
|
|
|
|||
88
Documentation/DocBook/media/v4l/vidioc-prepare-buf.xml
Normal file
88
Documentation/DocBook/media/v4l/vidioc-prepare-buf.xml
Normal file
|
|
@ -0,0 +1,88 @@
|
|||
<refentry id="vidioc-prepare-buf">
|
||||
<refmeta>
|
||||
<refentrytitle>ioctl VIDIOC_PREPARE_BUF</refentrytitle>
|
||||
&manvol;
|
||||
</refmeta>
|
||||
|
||||
<refnamediv>
|
||||
<refname>VIDIOC_PREPARE_BUF</refname>
|
||||
<refpurpose>Prepare a buffer for I/O</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_buffer *<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_PREPARE_BUF</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><parameter>argp</parameter></term>
|
||||
<listitem>
|
||||
<para></para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
<title>Description</title>
|
||||
|
||||
<para>Applications can optionally call the
|
||||
<constant>VIDIOC_PREPARE_BUF</constant> ioctl to pass ownership of the buffer
|
||||
to the driver before actually enqueuing it, using the
|
||||
<constant>VIDIOC_QBUF</constant> ioctl, and to prepare it for future I/O.
|
||||
Such preparations may include cache invalidation or cleaning. Performing them
|
||||
in advance saves time during the actual I/O. In case such cache operations are
|
||||
not required, the application can use one of
|
||||
<constant>V4L2_BUF_FLAG_NO_CACHE_INVALIDATE</constant> and
|
||||
<constant>V4L2_BUF_FLAG_NO_CACHE_CLEAN</constant> flags to skip the respective
|
||||
step.</para>
|
||||
|
||||
<para>The <structname>v4l2_buffer</structname> structure is
|
||||
specified in <xref linkend="buffer" />.</para>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
&return-value;
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><errorcode>EBUSY</errorcode></term>
|
||||
<listitem>
|
||||
<para>File I/O is in progress.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><errorcode>EINVAL</errorcode></term>
|
||||
<listitem>
|
||||
<para>The buffer <structfield>type</structfield> is not
|
||||
supported, or the <structfield>index</structfield> is out of bounds,
|
||||
or no buffers have been allocated yet, or the
|
||||
<structfield>userptr</structfield> or
|
||||
<structfield>length</structfield> are invalid.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</refsect1>
|
||||
</refentry>
|
||||
|
|
@ -406,6 +406,15 @@ flag is typically present for relative controls or action controls where
|
|||
writing a value will cause the device to carry out a given action
|
||||
(⪚ motor control) but no meaningful value can be returned.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_CTRL_FLAG_VOLATILE</constant></entry>
|
||||
<entry>0x0080</entry>
|
||||
<entry>This control is volatile, which means that the value of the control
|
||||
changes continuously. A typical example would be the current gain value if the device
|
||||
is in auto-gain mode. In such a case the hardware calculates the gain value based on
|
||||
the lighting conditions which can change over time. Note that setting a new value for
|
||||
a volatile control will have no effect. The new value will just be ignored.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
|
|
|
|||
|
|
@ -138,6 +138,22 @@
|
|||
field of the oldest event.</para>
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_EVENT_FRAME_SYNC</constant></entry>
|
||||
<entry>4</entry>
|
||||
<entry>
|
||||
<para>Triggered immediately when the reception of a
|
||||
frame has begun. This event has a
|
||||
&v4l2-event-frame-sync; associated with it.</para>
|
||||
|
||||
<para>If the hardware needs to be stopped in the case of a
|
||||
buffer underrun it might not be able to generate this event.
|
||||
In such cases the <structfield>frame_sequence</structfield>
|
||||
field in &v4l2-event-frame-sync; will not be incremented. This
|
||||
causes two consecutive frame sequence numbers to have n times
|
||||
frame interval in between them.</para>
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_EVENT_PRIVATE_START</constant></entry>
|
||||
<entry>0x08000000</entry>
|
||||
|
|
@ -183,113 +199,6 @@
|
|||
</tgroup>
|
||||
</table>
|
||||
|
||||
<table frame="none" pgwide="1" id="v4l2-event-vsync">
|
||||
<title>struct <structname>v4l2_event_vsync</structname></title>
|
||||
<tgroup cols="3">
|
||||
&cs-str;
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry>__u8</entry>
|
||||
<entry><structfield>field</structfield></entry>
|
||||
<entry>The upcoming field. See &v4l2-field;.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
|
||||
<table frame="none" pgwide="1" id="v4l2-event-ctrl">
|
||||
<title>struct <structname>v4l2_event_ctrl</structname></title>
|
||||
<tgroup cols="4">
|
||||
&cs-str;
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>changes</structfield></entry>
|
||||
<entry></entry>
|
||||
<entry>A bitmask that tells what has changed. See <xref linkend="changes-flags" />.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>type</structfield></entry>
|
||||
<entry></entry>
|
||||
<entry>The type of the control. See &v4l2-ctrl-type;.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>union (anonymous)</entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry>__s32</entry>
|
||||
<entry><structfield>value</structfield></entry>
|
||||
<entry>The 32-bit value of the control for 32-bit control types.
|
||||
This is 0 for string controls since the value of a string
|
||||
cannot be passed using &VIDIOC-DQEVENT;.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry>__s64</entry>
|
||||
<entry><structfield>value64</structfield></entry>
|
||||
<entry>The 64-bit value of the control for 64-bit control types.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>flags</structfield></entry>
|
||||
<entry></entry>
|
||||
<entry>The control flags. See <xref linkend="control-flags" />.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__s32</entry>
|
||||
<entry><structfield>minimum</structfield></entry>
|
||||
<entry></entry>
|
||||
<entry>The minimum value of the control. See &v4l2-queryctrl;.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__s32</entry>
|
||||
<entry><structfield>maximum</structfield></entry>
|
||||
<entry></entry>
|
||||
<entry>The maximum value of the control. See &v4l2-queryctrl;.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__s32</entry>
|
||||
<entry><structfield>step</structfield></entry>
|
||||
<entry></entry>
|
||||
<entry>The step value of the control. See &v4l2-queryctrl;.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__s32</entry>
|
||||
<entry><structfield>default_value</structfield></entry>
|
||||
<entry></entry>
|
||||
<entry>The default value value of the control. See &v4l2-queryctrl;.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
|
||||
<table pgwide="1" frame="none" id="changes-flags">
|
||||
<title>Changes</title>
|
||||
<tgroup cols="3">
|
||||
&cs-def;
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry><constant>V4L2_EVENT_CTRL_CH_VALUE</constant></entry>
|
||||
<entry>0x0001</entry>
|
||||
<entry>This control event was triggered because the value of the control
|
||||
changed. Special case: if a button control is pressed, then this
|
||||
event is sent as well, even though there is not explicit value
|
||||
associated with a button control.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_EVENT_CTRL_CH_FLAGS</constant></entry>
|
||||
<entry>0x0002</entry>
|
||||
<entry>This control event was triggered because the control flags
|
||||
changed.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
</refsect1>
|
||||
<refsect1>
|
||||
&return-value;
|
||||
|
|
|
|||
|
|
@ -572,7 +572,7 @@ static void board_select_chip (struct mtd_info *mtd, int chip)
|
|||
</para>
|
||||
<para>
|
||||
The simplest way to activate the FLASH based bad block table support
|
||||
is to set the option NAND_USE_FLASH_BBT in the option field of
|
||||
is to set the option NAND_BBT_USE_FLASH in the bbt_option field of
|
||||
the nand chip structure before calling nand_scan(). For AG-AND
|
||||
chips is this done by default.
|
||||
This activates the default FLASH based bad block table functionality
|
||||
|
|
@ -773,20 +773,6 @@ struct nand_oobinfo {
|
|||
done according to the default builtin scheme.
|
||||
</para>
|
||||
</sect2>
|
||||
<sect2 id="User_space_placement_selection">
|
||||
<title>User space placement selection</title>
|
||||
<para>
|
||||
All non ecc functions like mtd->read and mtd->write use an internal
|
||||
structure, which can be set by an ioctl. This structure is preset
|
||||
to the autoplacement default.
|
||||
<programlisting>
|
||||
ioctl (fd, MEMSETOOBSEL, oobsel);
|
||||
</programlisting>
|
||||
oobsel is a pointer to a user supplied structure of type
|
||||
nand_oobconfig. The contents of this structure must match the
|
||||
criteria of the filesystem, which will be used. See an example in utils/nandwrite.c.
|
||||
</para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
<sect1 id="Spare_area_autoplacement_default">
|
||||
<title>Spare area autoplacement default schemes</title>
|
||||
|
|
@ -1158,9 +1144,6 @@ in this page</entry>
|
|||
These constants are defined in nand.h. They are ored together to describe
|
||||
the functionality.
|
||||
<programlisting>
|
||||
/* Use a flash based bad block table. This option is parsed by the
|
||||
* default bad block table function (nand_default_bbt). */
|
||||
#define NAND_USE_FLASH_BBT 0x00010000
|
||||
/* The hw ecc generator provides a syndrome instead a ecc value on read
|
||||
* This can only work if we have the ecc bytes directly behind the
|
||||
* data bytes. Applies for DOC and AG-AND Renesas HW Reed Solomon generators */
|
||||
|
|
|
|||
|
|
@ -529,7 +529,7 @@ memory (e.g. allocated with <function>kmalloc()</function>). There's also
|
|||
</para></listitem>
|
||||
|
||||
<listitem><para>
|
||||
<varname>unsigned long addr</varname>: Required if the mapping is used.
|
||||
<varname>phys_addr_t addr</varname>: Required if the mapping is used.
|
||||
Fill in the address of your memory block. This address is the one that
|
||||
appears in sysfs.
|
||||
</para></listitem>
|
||||
|
|
|
|||
|
|
@ -4288,7 +4288,7 @@ struct _snd_pcm_runtime {
|
|||
<![CDATA[
|
||||
struct snd_rawmidi *rmidi;
|
||||
snd_mpu401_uart_new(card, 0, MPU401_HW_MPU401, port, info_flags,
|
||||
irq, irq_flags, &rmidi);
|
||||
irq, &rmidi);
|
||||
]]>
|
||||
</programlisting>
|
||||
</informalexample>
|
||||
|
|
@ -4343,6 +4343,13 @@ struct _snd_pcm_runtime {
|
|||
by itself to start processing the output stream in the irq handler.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
If the MPU-401 interface shares its interrupt with the other logical
|
||||
devices on the card, set <constant>MPU401_INFO_IRQ_HOOK</constant>
|
||||
(see <link linkend="midi-interface-interrupt-handler"><citetitle>
|
||||
below</citetitle></link>).
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Usually, the port address corresponds to the command port and
|
||||
port + 1 corresponds to the data port. If not, you may change
|
||||
|
|
@ -4375,14 +4382,12 @@ struct _snd_pcm_runtime {
|
|||
</para>
|
||||
|
||||
<para>
|
||||
The 6th argument specifies the irq number for UART. If the irq
|
||||
is already allocated, pass 0 to the 7th argument
|
||||
(<parameter>irq_flags</parameter>). Otherwise, pass the flags
|
||||
for irq allocation
|
||||
(<constant>SA_XXX</constant> bits) to it, and the irq will be
|
||||
reserved by the mpu401-uart layer. If the card doesn't generate
|
||||
UART interrupts, pass -1 as the irq number. Then a timer
|
||||
interrupt will be invoked for polling.
|
||||
The 6th argument specifies the ISA irq number that will be
|
||||
allocated. If no interrupt is to be allocated (because your
|
||||
code is already allocating a shared interrupt, or because the
|
||||
device does not use interrupts), pass -1 instead.
|
||||
For a MPU-401 device without an interrupt, a polling timer
|
||||
will be used instead.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
|
|
@ -4390,12 +4395,13 @@ struct _snd_pcm_runtime {
|
|||
<title>Interrupt Handler</title>
|
||||
<para>
|
||||
When the interrupt is allocated in
|
||||
<function>snd_mpu401_uart_new()</function>, the private
|
||||
interrupt handler is used, hence you don't have anything else to do
|
||||
than creating the mpu401 stuff. Otherwise, you have to call
|
||||
<function>snd_mpu401_uart_interrupt()</function> explicitly when
|
||||
a UART interrupt is invoked and checked in your own interrupt
|
||||
handler.
|
||||
<function>snd_mpu401_uart_new()</function>, an exclusive ISA
|
||||
interrupt handler is automatically used, hence you don't have
|
||||
anything else to do than creating the mpu401 stuff. Otherwise, you
|
||||
have to set <constant>MPU401_INFO_IRQ_HOOK</constant>, and call
|
||||
<function>snd_mpu401_uart_interrupt()</function> explicitly from your
|
||||
own interrupt handler when it has determined that a UART interrupt
|
||||
has occurred.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
|
|
|||
|
|
@ -314,7 +314,7 @@ from the PCI device config space. Use the values in the pci_dev structure
|
|||
as the PCI "bus address" might have been remapped to a "host physical"
|
||||
address by the arch/chip-set specific kernel support.
|
||||
|
||||
See Documentation/IO-mapping.txt for how to access device registers
|
||||
See Documentation/io-mapping.txt for how to access device registers
|
||||
or device memory.
|
||||
|
||||
The device driver needs to call pci_request_region() to verify
|
||||
|
|
|
|||
|
|
@ -95,7 +95,7 @@ not to return until all ongoing NMI handlers exit. It is therefore safe
|
|||
to free up the handler's data as soon as synchronize_sched() returns.
|
||||
|
||||
Important note: for this to work, the architecture in question must
|
||||
invoke irq_enter() and irq_exit() on NMI entry and exit, respectively.
|
||||
invoke nmi_enter() and nmi_exit() on NMI entry and exit, respectively.
|
||||
|
||||
|
||||
Answer to Quick Quiz
|
||||
|
|
|
|||
110
Documentation/RCU/lockdep-splat.txt
Normal file
110
Documentation/RCU/lockdep-splat.txt
Normal file
|
|
@ -0,0 +1,110 @@
|
|||
Lockdep-RCU was added to the Linux kernel in early 2010
|
||||
(http://lwn.net/Articles/371986/). This facility checks for some common
|
||||
misuses of the RCU API, most notably using one of the rcu_dereference()
|
||||
family to access an RCU-protected pointer without the proper protection.
|
||||
When such misuse is detected, an lockdep-RCU splat is emitted.
|
||||
|
||||
The usual cause of a lockdep-RCU slat is someone accessing an
|
||||
RCU-protected data structure without either (1) being in the right kind of
|
||||
RCU read-side critical section or (2) holding the right update-side lock.
|
||||
This problem can therefore be serious: it might result in random memory
|
||||
overwriting or worse. There can of course be false positives, this
|
||||
being the real world and all that.
|
||||
|
||||
So let's look at an example RCU lockdep splat from 3.0-rc5, one that
|
||||
has long since been fixed:
|
||||
|
||||
===============================
|
||||
[ INFO: suspicious RCU usage. ]
|
||||
-------------------------------
|
||||
block/cfq-iosched.c:2776 suspicious rcu_dereference_protected() usage!
|
||||
|
||||
other info that might help us debug this:
|
||||
|
||||
|
||||
rcu_scheduler_active = 1, debug_locks = 0
|
||||
3 locks held by scsi_scan_6/1552:
|
||||
#0: (&shost->scan_mutex){+.+.+.}, at: [<ffffffff8145efca>]
|
||||
scsi_scan_host_selected+0x5a/0x150
|
||||
#1: (&eq->sysfs_lock){+.+...}, at: [<ffffffff812a5032>]
|
||||
elevator_exit+0x22/0x60
|
||||
#2: (&(&q->__queue_lock)->rlock){-.-...}, at: [<ffffffff812b6233>]
|
||||
cfq_exit_queue+0x43/0x190
|
||||
|
||||
stack backtrace:
|
||||
Pid: 1552, comm: scsi_scan_6 Not tainted 3.0.0-rc5 #17
|
||||
Call Trace:
|
||||
[<ffffffff810abb9b>] lockdep_rcu_dereference+0xbb/0xc0
|
||||
[<ffffffff812b6139>] __cfq_exit_single_io_context+0xe9/0x120
|
||||
[<ffffffff812b626c>] cfq_exit_queue+0x7c/0x190
|
||||
[<ffffffff812a5046>] elevator_exit+0x36/0x60
|
||||
[<ffffffff812a802a>] blk_cleanup_queue+0x4a/0x60
|
||||
[<ffffffff8145cc09>] scsi_free_queue+0x9/0x10
|
||||
[<ffffffff81460944>] __scsi_remove_device+0x84/0xd0
|
||||
[<ffffffff8145dca3>] scsi_probe_and_add_lun+0x353/0xb10
|
||||
[<ffffffff817da069>] ? error_exit+0x29/0xb0
|
||||
[<ffffffff817d98ed>] ? _raw_spin_unlock_irqrestore+0x3d/0x80
|
||||
[<ffffffff8145e722>] __scsi_scan_target+0x112/0x680
|
||||
[<ffffffff812c690d>] ? trace_hardirqs_off_thunk+0x3a/0x3c
|
||||
[<ffffffff817da069>] ? error_exit+0x29/0xb0
|
||||
[<ffffffff812bcc60>] ? kobject_del+0x40/0x40
|
||||
[<ffffffff8145ed16>] scsi_scan_channel+0x86/0xb0
|
||||
[<ffffffff8145f0b0>] scsi_scan_host_selected+0x140/0x150
|
||||
[<ffffffff8145f149>] do_scsi_scan_host+0x89/0x90
|
||||
[<ffffffff8145f170>] do_scan_async+0x20/0x160
|
||||
[<ffffffff8145f150>] ? do_scsi_scan_host+0x90/0x90
|
||||
[<ffffffff810975b6>] kthread+0xa6/0xb0
|
||||
[<ffffffff817db154>] kernel_thread_helper+0x4/0x10
|
||||
[<ffffffff81066430>] ? finish_task_switch+0x80/0x110
|
||||
[<ffffffff817d9c04>] ? retint_restore_args+0xe/0xe
|
||||
[<ffffffff81097510>] ? __init_kthread_worker+0x70/0x70
|
||||
[<ffffffff817db150>] ? gs_change+0xb/0xb
|
||||
|
||||
Line 2776 of block/cfq-iosched.c in v3.0-rc5 is as follows:
|
||||
|
||||
if (rcu_dereference(ioc->ioc_data) == cic) {
|
||||
|
||||
This form says that it must be in a plain vanilla RCU read-side critical
|
||||
section, but the "other info" list above shows that this is not the
|
||||
case. Instead, we hold three locks, one of which might be RCU related.
|
||||
And maybe that lock really does protect this reference. If so, the fix
|
||||
is to inform RCU, perhaps by changing __cfq_exit_single_io_context() to
|
||||
take the struct request_queue "q" from cfq_exit_queue() as an argument,
|
||||
which would permit us to invoke rcu_dereference_protected as follows:
|
||||
|
||||
if (rcu_dereference_protected(ioc->ioc_data,
|
||||
lockdep_is_held(&q->queue_lock)) == cic) {
|
||||
|
||||
With this change, there would be no lockdep-RCU splat emitted if this
|
||||
code was invoked either from within an RCU read-side critical section
|
||||
or with the ->queue_lock held. In particular, this would have suppressed
|
||||
the above lockdep-RCU splat because ->queue_lock is held (see #2 in the
|
||||
list above).
|
||||
|
||||
On the other hand, perhaps we really do need an RCU read-side critical
|
||||
section. In this case, the critical section must span the use of the
|
||||
return value from rcu_dereference(), or at least until there is some
|
||||
reference count incremented or some such. One way to handle this is to
|
||||
add rcu_read_lock() and rcu_read_unlock() as follows:
|
||||
|
||||
rcu_read_lock();
|
||||
if (rcu_dereference(ioc->ioc_data) == cic) {
|
||||
spin_lock(&ioc->lock);
|
||||
rcu_assign_pointer(ioc->ioc_data, NULL);
|
||||
spin_unlock(&ioc->lock);
|
||||
}
|
||||
rcu_read_unlock();
|
||||
|
||||
With this change, the rcu_dereference() is always within an RCU
|
||||
read-side critical section, which again would have suppressed the
|
||||
above lockdep-RCU splat.
|
||||
|
||||
But in this particular case, we don't actually deference the pointer
|
||||
returned from rcu_dereference(). Instead, that pointer is just compared
|
||||
to the cic pointer, which means that the rcu_dereference() can be replaced
|
||||
by rcu_access_pointer() as follows:
|
||||
|
||||
if (rcu_access_pointer(ioc->ioc_data) == cic) {
|
||||
|
||||
Because it is legal to invoke rcu_access_pointer() without protection,
|
||||
this change would also suppress the above lockdep-RCU splat.
|
||||
|
|
@ -32,9 +32,27 @@ checking of rcu_dereference() primitives:
|
|||
srcu_dereference(p, sp):
|
||||
Check for SRCU read-side critical section.
|
||||
rcu_dereference_check(p, c):
|
||||
Use explicit check expression "c". This is useful in
|
||||
code that is invoked by both readers and updaters.
|
||||
rcu_dereference_raw(p)
|
||||
Use explicit check expression "c" along with
|
||||
rcu_read_lock_held(). This is useful in code that is
|
||||
invoked by both RCU readers and updaters.
|
||||
rcu_dereference_bh_check(p, c):
|
||||
Use explicit check expression "c" along with
|
||||
rcu_read_lock_bh_held(). This is useful in code that
|
||||
is invoked by both RCU-bh readers and updaters.
|
||||
rcu_dereference_sched_check(p, c):
|
||||
Use explicit check expression "c" along with
|
||||
rcu_read_lock_sched_held(). This is useful in code that
|
||||
is invoked by both RCU-sched readers and updaters.
|
||||
srcu_dereference_check(p, c):
|
||||
Use explicit check expression "c" along with
|
||||
srcu_read_lock_held()(). This is useful in code that
|
||||
is invoked by both SRCU readers and updaters.
|
||||
rcu_dereference_index_check(p, c):
|
||||
Use explicit check expression "c", but the caller
|
||||
must supply one of the rcu_read_lock_held() functions.
|
||||
This is useful in code that uses RCU-protected arrays
|
||||
that is invoked by both RCU readers and updaters.
|
||||
rcu_dereference_raw(p):
|
||||
Don't check. (Use sparingly, if at all.)
|
||||
rcu_dereference_protected(p, c):
|
||||
Use explicit check expression "c", and omit all barriers
|
||||
|
|
@ -48,13 +66,11 @@ checking of rcu_dereference() primitives:
|
|||
value of the pointer itself, for example, against NULL.
|
||||
|
||||
The rcu_dereference_check() check expression can be any boolean
|
||||
expression, but would normally include one of the rcu_read_lock_held()
|
||||
family of functions and a lockdep expression. However, any boolean
|
||||
expression can be used. For a moderately ornate example, consider
|
||||
the following:
|
||||
expression, but would normally include a lockdep expression. However,
|
||||
any boolean expression can be used. For a moderately ornate example,
|
||||
consider the following:
|
||||
|
||||
file = rcu_dereference_check(fdt->fd[fd],
|
||||
rcu_read_lock_held() ||
|
||||
lockdep_is_held(&files->file_lock) ||
|
||||
atomic_read(&files->count) == 1);
|
||||
|
||||
|
|
@ -62,7 +78,7 @@ This expression picks up the pointer "fdt->fd[fd]" in an RCU-safe manner,
|
|||
and, if CONFIG_PROVE_RCU is configured, verifies that this expression
|
||||
is used in:
|
||||
|
||||
1. An RCU read-side critical section, or
|
||||
1. An RCU read-side critical section (implicit), or
|
||||
2. with files->file_lock held, or
|
||||
3. on an unshared files_struct.
|
||||
|
||||
|
|
|
|||
|
|
@ -42,7 +42,7 @@ fqs_holdoff Holdoff time (in microseconds) between consecutive calls
|
|||
fqs_stutter Wait time (in seconds) between consecutive bursts
|
||||
of calls to force_quiescent_state().
|
||||
|
||||
irqreaders Says to invoke RCU readers from irq level. This is currently
|
||||
irqreader Says to invoke RCU readers from irq level. This is currently
|
||||
done via timers. Defaults to "1" for variants of RCU that
|
||||
permit this. (Or, more accurately, variants of RCU that do
|
||||
-not- permit this know to ignore this variable.)
|
||||
|
|
@ -79,19 +79,68 @@ stutter The length of time to run the test before pausing for this
|
|||
Specifying "stutter=0" causes the test to run continuously
|
||||
without pausing, which is the old default behavior.
|
||||
|
||||
test_boost Whether or not to test the ability of RCU to do priority
|
||||
boosting. Defaults to "test_boost=1", which performs
|
||||
RCU priority-inversion testing only if the selected
|
||||
RCU implementation supports priority boosting. Specifying
|
||||
"test_boost=0" never performs RCU priority-inversion
|
||||
testing. Specifying "test_boost=2" performs RCU
|
||||
priority-inversion testing even if the selected RCU
|
||||
implementation does not support RCU priority boosting,
|
||||
which can be used to test rcutorture's ability to
|
||||
carry out RCU priority-inversion testing.
|
||||
|
||||
test_boost_interval
|
||||
The number of seconds in an RCU priority-inversion test
|
||||
cycle. Defaults to "test_boost_interval=7". It is
|
||||
usually wise for this value to be relatively prime to
|
||||
the value selected for "stutter".
|
||||
|
||||
test_boost_duration
|
||||
The number of seconds to do RCU priority-inversion testing
|
||||
within any given "test_boost_interval". Defaults to
|
||||
"test_boost_duration=4".
|
||||
|
||||
test_no_idle_hz Whether or not to test the ability of RCU to operate in
|
||||
a kernel that disables the scheduling-clock interrupt to
|
||||
idle CPUs. Boolean parameter, "1" to test, "0" otherwise.
|
||||
Defaults to omitting this test.
|
||||
|
||||
torture_type The type of RCU to test: "rcu" for the rcu_read_lock() API,
|
||||
"rcu_sync" for rcu_read_lock() with synchronous reclamation,
|
||||
"rcu_bh" for the rcu_read_lock_bh() API, "rcu_bh_sync" for
|
||||
rcu_read_lock_bh() with synchronous reclamation, "srcu" for
|
||||
the "srcu_read_lock()" API, "sched" for the use of
|
||||
preempt_disable() together with synchronize_sched(),
|
||||
and "sched_expedited" for the use of preempt_disable()
|
||||
with synchronize_sched_expedited().
|
||||
torture_type The type of RCU to test, with string values as follows:
|
||||
|
||||
"rcu": rcu_read_lock(), rcu_read_unlock() and call_rcu().
|
||||
|
||||
"rcu_sync": rcu_read_lock(), rcu_read_unlock(), and
|
||||
synchronize_rcu().
|
||||
|
||||
"rcu_expedited": rcu_read_lock(), rcu_read_unlock(), and
|
||||
synchronize_rcu_expedited().
|
||||
|
||||
"rcu_bh": rcu_read_lock_bh(), rcu_read_unlock_bh(), and
|
||||
call_rcu_bh().
|
||||
|
||||
"rcu_bh_sync": rcu_read_lock_bh(), rcu_read_unlock_bh(),
|
||||
and synchronize_rcu_bh().
|
||||
|
||||
"rcu_bh_expedited": rcu_read_lock_bh(), rcu_read_unlock_bh(),
|
||||
and synchronize_rcu_bh_expedited().
|
||||
|
||||
"srcu": srcu_read_lock(), srcu_read_unlock() and
|
||||
synchronize_srcu().
|
||||
|
||||
"srcu_expedited": srcu_read_lock(), srcu_read_unlock() and
|
||||
synchronize_srcu_expedited().
|
||||
|
||||
"sched": preempt_disable(), preempt_enable(), and
|
||||
call_rcu_sched().
|
||||
|
||||
"sched_sync": preempt_disable(), preempt_enable(), and
|
||||
synchronize_sched().
|
||||
|
||||
"sched_expedited": preempt_disable(), preempt_enable(), and
|
||||
synchronize_sched_expedited().
|
||||
|
||||
Defaults to "rcu".
|
||||
|
||||
verbose Enable debug printk()s. Default is disabled.
|
||||
|
||||
|
|
@ -100,12 +149,12 @@ OUTPUT
|
|||
|
||||
The statistics output is as follows:
|
||||
|
||||
rcu-torture: --- Start of test: nreaders=16 stat_interval=0 verbose=0
|
||||
rcu-torture: rtc: 0000000000000000 ver: 1916 tfle: 0 rta: 1916 rtaf: 0 rtf: 1915
|
||||
rcu-torture: Reader Pipe: 1466408 9747 0 0 0 0 0 0 0 0 0
|
||||
rcu-torture: Reader Batch: 1464477 11678 0 0 0 0 0 0 0 0
|
||||
rcu-torture: Free-Block Circulation: 1915 1915 1915 1915 1915 1915 1915 1915 1915 1915 0
|
||||
rcu-torture: --- End of test
|
||||
rcu-torture:--- Start of test: nreaders=16 nfakewriters=4 stat_interval=30 verbose=0 test_no_idle_hz=1 shuffle_interval=3 stutter=5 irqreader=1 fqs_duration=0 fqs_holdoff=0 fqs_stutter=3 test_boost=1/0 test_boost_interval=7 test_boost_duration=4
|
||||
rcu-torture: rtc: (null) ver: 155441 tfle: 0 rta: 155441 rtaf: 8884 rtf: 155440 rtmbe: 0 rtbke: 0 rtbre: 0 rtbf: 0 rtb: 0 nt: 3055767
|
||||
rcu-torture: Reader Pipe: 727860534 34213 0 0 0 0 0 0 0 0 0
|
||||
rcu-torture: Reader Batch: 727877838 17003 0 0 0 0 0 0 0 0 0
|
||||
rcu-torture: Free-Block Circulation: 155440 155440 155440 155440 155440 155440 155440 155440 155440 155440 0
|
||||
rcu-torture:--- End of test: SUCCESS: nreaders=16 nfakewriters=4 stat_interval=30 verbose=0 test_no_idle_hz=1 shuffle_interval=3 stutter=5 irqreader=1 fqs_duration=0 fqs_holdoff=0 fqs_stutter=3 test_boost=1/0 test_boost_interval=7 test_boost_duration=4
|
||||
|
||||
The command "dmesg | grep torture:" will extract this information on
|
||||
most systems. On more esoteric configurations, it may be necessary to
|
||||
|
|
@ -113,26 +162,55 @@ use other commands to access the output of the printk()s used by
|
|||
the RCU torture test. The printk()s use KERN_ALERT, so they should
|
||||
be evident. ;-)
|
||||
|
||||
The first and last lines show the rcutorture module parameters, and the
|
||||
last line shows either "SUCCESS" or "FAILURE", based on rcutorture's
|
||||
automatic determination as to whether RCU operated correctly.
|
||||
|
||||
The entries are as follows:
|
||||
|
||||
o "rtc": The hexadecimal address of the structure currently visible
|
||||
to readers.
|
||||
|
||||
o "ver": The number of times since boot that the rcutw writer task
|
||||
o "ver": The number of times since boot that the RCU writer task
|
||||
has changed the structure visible to readers.
|
||||
|
||||
o "tfle": If non-zero, indicates that the "torture freelist"
|
||||
containing structure to be placed into the "rtc" area is empty.
|
||||
containing structures to be placed into the "rtc" area is empty.
|
||||
This condition is important, since it can fool you into thinking
|
||||
that RCU is working when it is not. :-/
|
||||
|
||||
o "rta": Number of structures allocated from the torture freelist.
|
||||
|
||||
o "rtaf": Number of allocations from the torture freelist that have
|
||||
failed due to the list being empty.
|
||||
failed due to the list being empty. It is not unusual for this
|
||||
to be non-zero, but it is bad for it to be a large fraction of
|
||||
the value indicated by "rta".
|
||||
|
||||
o "rtf": Number of frees into the torture freelist.
|
||||
|
||||
o "rtmbe": A non-zero value indicates that rcutorture believes that
|
||||
rcu_assign_pointer() and rcu_dereference() are not working
|
||||
correctly. This value should be zero.
|
||||
|
||||
o "rtbke": rcutorture was unable to create the real-time kthreads
|
||||
used to force RCU priority inversion. This value should be zero.
|
||||
|
||||
o "rtbre": Although rcutorture successfully created the kthreads
|
||||
used to force RCU priority inversion, it was unable to set them
|
||||
to the real-time priority level of 1. This value should be zero.
|
||||
|
||||
o "rtbf": The number of times that RCU priority boosting failed
|
||||
to resolve RCU priority inversion.
|
||||
|
||||
o "rtb": The number of times that rcutorture attempted to force
|
||||
an RCU priority inversion condition. If you are testing RCU
|
||||
priority boosting via the "test_boost" module parameter, this
|
||||
value should be non-zero.
|
||||
|
||||
o "nt": The number of times rcutorture ran RCU read-side code from
|
||||
within a timer handler. This value should be non-zero only
|
||||
if you specified the "irqreader" module parameter.
|
||||
|
||||
o "Reader Pipe": Histogram of "ages" of structures seen by readers.
|
||||
If any entries past the first two are non-zero, RCU is broken.
|
||||
And rcutorture prints the error flag string "!!!" to make sure
|
||||
|
|
@ -162,26 +240,15 @@ o "Free-Block Circulation": Shows the number of torture structures
|
|||
somehow gets incremented farther than it should.
|
||||
|
||||
Different implementations of RCU can provide implementation-specific
|
||||
additional information. For example, SRCU provides the following:
|
||||
additional information. For example, SRCU provides the following
|
||||
additional line:
|
||||
|
||||
srcu-torture: rtc: f8cf46a8 ver: 355 tfle: 0 rta: 356 rtaf: 0 rtf: 346 rtmbe: 0
|
||||
srcu-torture: Reader Pipe: 559738 939 0 0 0 0 0 0 0 0 0
|
||||
srcu-torture: Reader Batch: 560434 243 0 0 0 0 0 0 0 0
|
||||
srcu-torture: Free-Block Circulation: 355 354 353 352 351 350 349 348 347 346 0
|
||||
srcu-torture: per-CPU(idx=1): 0(0,1) 1(0,1) 2(0,0) 3(0,1)
|
||||
|
||||
The first four lines are similar to those for RCU. The last line shows
|
||||
the per-CPU counter state. The numbers in parentheses are the values
|
||||
of the "old" and "current" counters for the corresponding CPU. The
|
||||
"idx" value maps the "old" and "current" values to the underlying array,
|
||||
and is useful for debugging.
|
||||
|
||||
Similarly, sched_expedited RCU provides the following:
|
||||
|
||||
sched_expedited-torture: rtc: d0000000016c1880 ver: 1090796 tfle: 0 rta: 1090796 rtaf: 0 rtf: 1090787 rtmbe: 0 nt: 27713319
|
||||
sched_expedited-torture: Reader Pipe: 12660320201 95875 0 0 0 0 0 0 0 0 0
|
||||
sched_expedited-torture: Reader Batch: 12660424885 0 0 0 0 0 0 0 0 0 0
|
||||
sched_expedited-torture: Free-Block Circulation: 1090795 1090795 1090794 1090793 1090792 1090791 1090790 1090789 1090788 1090787 0
|
||||
This line shows the per-CPU counter state. The numbers in parentheses are
|
||||
the values of the "old" and "current" counters for the corresponding CPU.
|
||||
The "idx" value maps the "old" and "current" values to the underlying
|
||||
array, and is useful for debugging.
|
||||
|
||||
|
||||
USAGE
|
||||
|
|
|
|||
|
|
@ -33,23 +33,23 @@ rcu/rcuboost:
|
|||
The output of "cat rcu/rcudata" looks as follows:
|
||||
|
||||
rcu_sched:
|
||||
0 c=20972 g=20973 pq=1 pqc=20972 qp=0 dt=545/1/0 df=50 of=0 ri=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 pqc=20972 qp=0 dt=967/1/0 df=58 of=0 ri=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 pqc=20972 qp=0 dt=1081/1/0 df=175 of=0 ri=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 pqc=20942 qp=1 dt=1846/0/0 df=404 of=0 ri=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 pqc=20972 qp=0 dt=369/1/0 df=83 of=0 ri=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 pqc=20972 qp=0 dt=381/1/0 df=64 of=0 ri=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 pqc=20972 qp=0 dt=1037/1/0 df=183 of=0 ri=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 pqc=20896 qp=0 dt=1572/0/0 df=382 of=0 ri=0 ql=0 qs=.... kt=0/W/7 ktl=cf15 b=10 ci=75006 co=0 ca=0
|
||||
0 c=20972 g=20973 pq=1 pgp=20973 qp=0 dt=545/1/0 df=50 of=0 ri=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 ri=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 ri=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 ri=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 ri=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 ri=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 ri=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 ri=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 pqc=1479 qp=0 dt=545/1/0 df=6 of=0 ri=1 ql=0 qs=.... kt=0/W/0 ktl=ebc3 b=10 ci=0 co=0 ca=0
|
||||
1 c=1480 g=1480 pq=1 pqc=1479 qp=0 dt=967/1/0 df=3 of=0 ri=1 ql=0 qs=.... kt=0/W/1 ktl=58c b=10 ci=151 co=0 ca=0
|
||||
2 c=1480 g=1480 pq=1 pqc=1479 qp=0 dt=1081/1/0 df=6 of=0 ri=1 ql=0 qs=.... kt=0/W/2 ktl=da94 b=10 ci=0 co=0 ca=0
|
||||
3 c=1480 g=1480 pq=1 pqc=1479 qp=0 dt=1846/0/0 df=8 of=0 ri=1 ql=0 qs=.... kt=0/W/3 ktl=d1cd b=10 ci=0 co=0 ca=0
|
||||
4 c=1480 g=1480 pq=1 pqc=1479 qp=0 dt=369/1/0 df=6 of=0 ri=1 ql=0 qs=.... kt=0/W/4 ktl=e0e7 b=10 ci=0 co=0 ca=0
|
||||
5 c=1480 g=1480 pq=1 pqc=1479 qp=0 dt=381/1/0 df=4 of=0 ri=1 ql=0 qs=.... kt=0/W/5 ktl=fb2f b=10 ci=0 co=0 ca=0
|
||||
6 c=1480 g=1480 pq=1 pqc=1479 qp=0 dt=1037/1/0 df=6 of=0 ri=1 ql=0 qs=.... kt=0/W/6 ktl=d2ad b=10 ci=0 co=0 ca=0
|
||||
7 c=1474 g=1474 pq=1 pqc=1473 qp=0 dt=1572/0/0 df=8 of=0 ri=1 ql=0 qs=.... kt=0/W/7 ktl=cf15 b=10 ci=0 co=0 ca=0
|
||||
0 c=1480 g=1480 pq=1 pgp=1480 qp=0 dt=545/1/0 df=6 of=0 ri=1 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 ri=1 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 ri=1 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 ri=1 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 ri=1 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 ri=1 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 ri=1 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 ri=1 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
|
||||
|
|
@ -84,7 +84,7 @@ 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 "pqc" indicates which grace period the last-observed quiescent
|
||||
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
|
||||
|
|
@ -184,10 +184,14 @@ o "kt" is the per-CPU kernel-thread state. The digit preceding
|
|||
The number after the final slash is the CPU that the kthread
|
||||
is actually running on.
|
||||
|
||||
This field is displayed only for CONFIG_RCU_BOOST kernels.
|
||||
|
||||
o "ktl" is the low-order 16 bits (in hexadecimal) of the count of
|
||||
the number of times that this CPU's per-CPU kthread has gone
|
||||
through its loop servicing invoke_rcu_cpu_kthread() requests.
|
||||
|
||||
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.
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
/*
|
||||
* File: Documentation/blackfin/bfin-gpio-note.txt
|
||||
* File: Documentation/blackfin/bfin-gpio-notes.txt
|
||||
* Based on:
|
||||
* Author:
|
||||
*
|
||||
|
|
|
|||
|
|
@ -186,7 +186,7 @@ a virtual address mapping (unlike the earlier scheme of virtual address
|
|||
do not have a corresponding kernel virtual address space mapping) and
|
||||
low-memory pages.
|
||||
|
||||
Note: Please refer to Documentation/PCI/PCI-DMA-mapping.txt for a discussion
|
||||
Note: Please refer to Documentation/DMA-API-HOWTO.txt for a discussion
|
||||
on PCI high mem DMA aspects and mapping of scatter gather lists, and support
|
||||
for 64 bit PCI.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
To choose IO schedulers at boot time, use the argument 'elevator=deadline'.
|
||||
'noop', 'as' and 'cfq' (the default) are also available. IO schedulers are
|
||||
assigned globally at boot time only presently.
|
||||
'noop' and 'cfq' (the default) are also available. IO schedulers are assigned
|
||||
globally at boot time only presently.
|
||||
|
||||
Each io queue has a set of io scheduler tunables associated with it. These
|
||||
tunables control how the io scheduler works. You can find these entries
|
||||
|
|
|
|||
|
|
@ -78,6 +78,16 @@ The device naming scheme is:
|
|||
/dev/cciss/c1d1p2 Controller 1, disk 1, partition 2
|
||||
/dev/cciss/c1d1p3 Controller 1, disk 1, partition 3
|
||||
|
||||
CCISS simple mode support
|
||||
-------------------------
|
||||
|
||||
The "cciss_simple_mode=1" boot parameter may be used to prevent the driver
|
||||
from putting the controller into "performant" mode. The difference is that
|
||||
with simple mode, each command completion requires an interrupt, while with
|
||||
"performant mode" (the default, and ordinarily better performing) it is
|
||||
possible to have multiple command completions indicated by a single
|
||||
interrupt.
|
||||
|
||||
SCSI tape drive and medium changer support
|
||||
------------------------------------------
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
[ NOTE: The virt_to_bus() and bus_to_virt() functions have been
|
||||
superseded by the functionality provided by the PCI DMA interface
|
||||
(see Documentation/PCI/PCI-DMA-mapping.txt). They continue
|
||||
(see Documentation/DMA-API-HOWTO.txt). They continue
|
||||
to be documented below for historical purposes, but new code
|
||||
must not use them. --davidm 00/12/12 ]
|
||||
|
||||
|
|
|
|||
|
|
@ -109,7 +109,7 @@ this interface. (see http://tom.ist-im-web.de/download/pktcdvd )
|
|||
|
||||
For a description of the sysfs interface look into the file:
|
||||
|
||||
Documentation/ABI/testing/sysfs-block-pktcdvd
|
||||
Documentation/ABI/testing/sysfs-class-pktcdvd
|
||||
|
||||
|
||||
Using the pktcdvd debugfs interface
|
||||
|
|
|
|||
|
|
@ -454,8 +454,8 @@ mounted hierarchy, to remove a task from its current cgroup you must
|
|||
move it into a new cgroup (possibly the root cgroup) by writing to the
|
||||
new cgroup's tasks file.
|
||||
|
||||
Note: If the ns cgroup is active, moving a process to another cgroup can
|
||||
fail.
|
||||
Note: Due to some restrictions enforced by some cgroup subsystems, moving
|
||||
a process to another cgroup can fail.
|
||||
|
||||
2.3 Mounting hierarchies by name
|
||||
--------------------------------
|
||||
|
|
|
|||
|
|
@ -33,9 +33,9 @@ demonstrate this problem using nested bash shells:
|
|||
|
||||
From a second, unrelated bash shell:
|
||||
$ kill -SIGSTOP 16690
|
||||
$ kill -SIGCONT 16990
|
||||
$ kill -SIGCONT 16690
|
||||
|
||||
<at this point 16990 exits and causes 16644 to exit too>
|
||||
<at this point 16690 exits and causes 16644 to exit too>
|
||||
|
||||
This happens because bash can observe both signals and choose how it
|
||||
responds to them.
|
||||
|
|
|
|||
|
|
@ -418,7 +418,6 @@ total_unevictable - sum of all children's "unevictable"
|
|||
|
||||
# The following additional stats are dependent on CONFIG_DEBUG_VM.
|
||||
|
||||
inactive_ratio - VM internal parameter. (see mm/page_alloc.c)
|
||||
recent_rotated_anon - VM internal parameter. (see mm/vmscan.c)
|
||||
recent_rotated_file - VM internal parameter. (see mm/vmscan.c)
|
||||
recent_scanned_anon - VM internal parameter. (see mm/vmscan.c)
|
||||
|
|
|
|||
|
|
@ -132,7 +132,7 @@ The sampling rate is limited by the HW transition latency:
|
|||
transition_latency * 100
|
||||
Or by kernel restrictions:
|
||||
If CONFIG_NO_HZ is set, the limit is 10ms fixed.
|
||||
If CONFIG_NO_HZ is not set or no_hz=off boot parameter is used, the
|
||||
If CONFIG_NO_HZ is not set or nohz=off boot parameter is used, the
|
||||
limits depend on the CONFIG_HZ option:
|
||||
HZ=1000: min=20000us (20ms)
|
||||
HZ=250: min=80000us (80ms)
|
||||
|
|
|
|||
|
|
@ -278,7 +278,7 @@ enabled, a configurable percentage of memory allocations will be made to
|
|||
fail; these failures can be restricted to a specific range of code.
|
||||
Running with fault injection enabled allows the programmer to see how the
|
||||
code responds when things go badly. See
|
||||
Documentation/fault-injection/fault-injection.text for more information on
|
||||
Documentation/fault-injection/fault-injection.txt for more information on
|
||||
how to use this facility.
|
||||
|
||||
Other kinds of errors can be found with the "sparse" static analysis tool.
|
||||
|
|
|
|||
|
|
@ -48,7 +48,7 @@ kernel and userspace, 'connector' is used as the interface for
|
|||
communication.
|
||||
|
||||
There are currently two userspace log implementations that leverage this
|
||||
framework - "clustered_disk" and "clustered_core". These implementations
|
||||
framework - "clustered-disk" and "clustered-core". These implementations
|
||||
provide a cluster-coherent log for shared-storage. Device-mapper mirroring
|
||||
can be used in a shared-storage environment when the cluster log implementations
|
||||
are employed.
|
||||
|
|
|
|||
84
Documentation/device-mapper/persistent-data.txt
Normal file
84
Documentation/device-mapper/persistent-data.txt
Normal file
|
|
@ -0,0 +1,84 @@
|
|||
Introduction
|
||||
============
|
||||
|
||||
The more-sophisticated device-mapper targets require complex metadata
|
||||
that is managed in kernel. In late 2010 we were seeing that various
|
||||
different targets were rolling their own data strutures, for example:
|
||||
|
||||
- Mikulas Patocka's multisnap implementation
|
||||
- Heinz Mauelshagen's thin provisioning target
|
||||
- Another btree-based caching target posted to dm-devel
|
||||
- Another multi-snapshot target based on a design of Daniel Phillips
|
||||
|
||||
Maintaining these data structures takes a lot of work, so if possible
|
||||
we'd like to reduce the number.
|
||||
|
||||
The persistent-data library is an attempt to provide a re-usable
|
||||
framework for people who want to store metadata in device-mapper
|
||||
targets. It's currently used by the thin-provisioning target and an
|
||||
upcoming hierarchical storage target.
|
||||
|
||||
Overview
|
||||
========
|
||||
|
||||
The main documentation is in the header files which can all be found
|
||||
under drivers/md/persistent-data.
|
||||
|
||||
The block manager
|
||||
-----------------
|
||||
|
||||
dm-block-manager.[hc]
|
||||
|
||||
This provides access to the data on disk in fixed sized-blocks. There
|
||||
is a read/write locking interface to prevent concurrent accesses, and
|
||||
keep data that is being used in the cache.
|
||||
|
||||
Clients of persistent-data are unlikely to use this directly.
|
||||
|
||||
The transaction manager
|
||||
-----------------------
|
||||
|
||||
dm-transaction-manager.[hc]
|
||||
|
||||
This restricts access to blocks and enforces copy-on-write semantics.
|
||||
The only way you can get hold of a writable block through the
|
||||
transaction manager is by shadowing an existing block (ie. doing
|
||||
copy-on-write) or allocating a fresh one. Shadowing is elided within
|
||||
the same transaction so performance is reasonable. The commit method
|
||||
ensures that all data is flushed before it writes the superblock.
|
||||
On power failure your metadata will be as it was when last committed.
|
||||
|
||||
The Space Maps
|
||||
--------------
|
||||
|
||||
dm-space-map.h
|
||||
dm-space-map-metadata.[hc]
|
||||
dm-space-map-disk.[hc]
|
||||
|
||||
On-disk data structures that keep track of reference counts of blocks.
|
||||
Also acts as the allocator of new blocks. Currently two
|
||||
implementations: a simpler one for managing blocks on a different
|
||||
device (eg. thinly-provisioned data blocks); and one for managing
|
||||
the metadata space. The latter is complicated by the need to store
|
||||
its own data within the space it's managing.
|
||||
|
||||
The data structures
|
||||
-------------------
|
||||
|
||||
dm-btree.[hc]
|
||||
dm-btree-remove.c
|
||||
dm-btree-spine.c
|
||||
dm-btree-internal.h
|
||||
|
||||
Currently there is only one data structure, a hierarchical btree.
|
||||
There are plans to add more. For example, something with an
|
||||
array-like interface would see a lot of use.
|
||||
|
||||
The btree is 'hierarchical' in that you can define it to be composed
|
||||
of nested btrees, and take multiple keys. For example, the
|
||||
thin-provisioning target uses a btree with two levels of nesting.
|
||||
The first maps a device id to a mapping tree, and that in turn maps a
|
||||
virtual block to a physical block.
|
||||
|
||||
Values stored in the btrees can have arbitrary size. Keys are always
|
||||
64bits, although nesting allows you to use multiple keys.
|
||||
285
Documentation/device-mapper/thin-provisioning.txt
Normal file
285
Documentation/device-mapper/thin-provisioning.txt
Normal file
|
|
@ -0,0 +1,285 @@
|
|||
Introduction
|
||||
============
|
||||
|
||||
This document descibes a collection of device-mapper targets that
|
||||
between them implement thin-provisioning and snapshots.
|
||||
|
||||
The main highlight of this implementation, compared to the previous
|
||||
implementation of snapshots, is that it allows many virtual devices to
|
||||
be stored on the same data volume. This simplifies administration and
|
||||
allows the sharing of data between volumes, thus reducing disk usage.
|
||||
|
||||
Another significant feature is support for an arbitrary depth of
|
||||
recursive snapshots (snapshots of snapshots of snapshots ...). The
|
||||
previous implementation of snapshots did this by chaining together
|
||||
lookup tables, and so performance was O(depth). This new
|
||||
implementation uses a single data structure to avoid this degradation
|
||||
with depth. Fragmentation may still be an issue, however, in some
|
||||
scenarios.
|
||||
|
||||
Metadata is stored on a separate device from data, giving the
|
||||
administrator some freedom, for example to:
|
||||
|
||||
- Improve metadata resilience by storing metadata on a mirrored volume
|
||||
but data on a non-mirrored one.
|
||||
|
||||
- Improve performance by storing the metadata on SSD.
|
||||
|
||||
Status
|
||||
======
|
||||
|
||||
These targets are very much still in the EXPERIMENTAL state. Please
|
||||
do not yet rely on them in production. But do experiment and offer us
|
||||
feedback. Different use cases will have different performance
|
||||
characteristics, for example due to fragmentation of the data volume.
|
||||
|
||||
If you find this software is not performing as expected please mail
|
||||
dm-devel@redhat.com with details and we'll try our best to improve
|
||||
things for you.
|
||||
|
||||
Userspace tools for checking and repairing the metadata are under
|
||||
development.
|
||||
|
||||
Cookbook
|
||||
========
|
||||
|
||||
This section describes some quick recipes for using thin provisioning.
|
||||
They use the dmsetup program to control the device-mapper driver
|
||||
directly. End users will be advised to use a higher-level volume
|
||||
manager such as LVM2 once support has been added.
|
||||
|
||||
Pool device
|
||||
-----------
|
||||
|
||||
The pool device ties together the metadata volume and the data volume.
|
||||
It maps I/O linearly to the data volume and updates the metadata via
|
||||
two mechanisms:
|
||||
|
||||
- Function calls from the thin targets
|
||||
|
||||
- Device-mapper 'messages' from userspace which control the creation of new
|
||||
virtual devices amongst other things.
|
||||
|
||||
Setting up a fresh pool device
|
||||
------------------------------
|
||||
|
||||
Setting up a pool device requires a valid metadata device, and a
|
||||
data device. If you do not have an existing metadata device you can
|
||||
make one by zeroing the first 4k to indicate empty metadata.
|
||||
|
||||
dd if=/dev/zero of=$metadata_dev bs=4096 count=1
|
||||
|
||||
The amount of metadata you need will vary according to how many blocks
|
||||
are shared between thin devices (i.e. through snapshots). If you have
|
||||
less sharing than average you'll need a larger-than-average metadata device.
|
||||
|
||||
As a guide, we suggest you calculate the number of bytes to use in the
|
||||
metadata device as 48 * $data_dev_size / $data_block_size but round it up
|
||||
to 2MB if the answer is smaller. The largest size supported is 16GB.
|
||||
|
||||
If you're creating large numbers of snapshots which are recording large
|
||||
amounts of change, you may need find you need to increase this.
|
||||
|
||||
Reloading a pool table
|
||||
----------------------
|
||||
|
||||
You may reload a pool's table, indeed this is how the pool is resized
|
||||
if it runs out of space. (N.B. While specifying a different metadata
|
||||
device when reloading is not forbidden at the moment, things will go
|
||||
wrong if it does not route I/O to exactly the same on-disk location as
|
||||
previously.)
|
||||
|
||||
Using an existing pool device
|
||||
-----------------------------
|
||||
|
||||
dmsetup create pool \
|
||||
--table "0 20971520 thin-pool $metadata_dev $data_dev \
|
||||
$data_block_size $low_water_mark"
|
||||
|
||||
$data_block_size gives the smallest unit of disk space that can be
|
||||
allocated at a time expressed in units of 512-byte sectors. People
|
||||
primarily interested in thin provisioning may want to use a value such
|
||||
as 1024 (512KB). People doing lots of snapshotting may want a smaller value
|
||||
such as 128 (64KB). If you are not zeroing newly-allocated data,
|
||||
a larger $data_block_size in the region of 256000 (128MB) is suggested.
|
||||
$data_block_size must be the same for the lifetime of the
|
||||
metadata device.
|
||||
|
||||
$low_water_mark is expressed in blocks of size $data_block_size. If
|
||||
free space on the data device drops below this level then a dm event
|
||||
will be triggered which a userspace daemon should catch allowing it to
|
||||
extend the pool device. Only one such event will be sent.
|
||||
Resuming a device with a new table itself triggers an event so the
|
||||
userspace daemon can use this to detect a situation where a new table
|
||||
already exceeds the threshold.
|
||||
|
||||
Thin provisioning
|
||||
-----------------
|
||||
|
||||
i) Creating a new thinly-provisioned volume.
|
||||
|
||||
To create a new thinly- provisioned volume you must send a message to an
|
||||
active pool device, /dev/mapper/pool in this example.
|
||||
|
||||
dmsetup message /dev/mapper/pool 0 "create_thin 0"
|
||||
|
||||
Here '0' is an identifier for the volume, a 24-bit number. It's up
|
||||
to the caller to allocate and manage these identifiers. If the
|
||||
identifier is already in use, the message will fail with -EEXIST.
|
||||
|
||||
ii) Using a thinly-provisioned volume.
|
||||
|
||||
Thinly-provisioned volumes are activated using the 'thin' target:
|
||||
|
||||
dmsetup create thin --table "0 2097152 thin /dev/mapper/pool 0"
|
||||
|
||||
The last parameter is the identifier for the thinp device.
|
||||
|
||||
Internal snapshots
|
||||
------------------
|
||||
|
||||
i) Creating an internal snapshot.
|
||||
|
||||
Snapshots are created with another message to the pool.
|
||||
|
||||
N.B. If the origin device that you wish to snapshot is active, you
|
||||
must suspend it before creating the snapshot to avoid corruption.
|
||||
This is NOT enforced at the moment, so please be careful!
|
||||
|
||||
dmsetup suspend /dev/mapper/thin
|
||||
dmsetup message /dev/mapper/pool 0 "create_snap 1 0"
|
||||
dmsetup resume /dev/mapper/thin
|
||||
|
||||
Here '1' is the identifier for the volume, a 24-bit number. '0' is the
|
||||
identifier for the origin device.
|
||||
|
||||
ii) Using an internal snapshot.
|
||||
|
||||
Once created, the user doesn't have to worry about any connection
|
||||
between the origin and the snapshot. Indeed the snapshot is no
|
||||
different from any other thinly-provisioned device and can be
|
||||
snapshotted itself via the same method. It's perfectly legal to
|
||||
have only one of them active, and there's no ordering requirement on
|
||||
activating or removing them both. (This differs from conventional
|
||||
device-mapper snapshots.)
|
||||
|
||||
Activate it exactly the same way as any other thinly-provisioned volume:
|
||||
|
||||
dmsetup create snap --table "0 2097152 thin /dev/mapper/pool 1"
|
||||
|
||||
Deactivation
|
||||
------------
|
||||
|
||||
All devices using a pool must be deactivated before the pool itself
|
||||
can be.
|
||||
|
||||
dmsetup remove thin
|
||||
dmsetup remove snap
|
||||
dmsetup remove pool
|
||||
|
||||
Reference
|
||||
=========
|
||||
|
||||
'thin-pool' target
|
||||
------------------
|
||||
|
||||
i) Constructor
|
||||
|
||||
thin-pool <metadata dev> <data dev> <data block size (sectors)> \
|
||||
<low water mark (blocks)> [<number of feature args> [<arg>]*]
|
||||
|
||||
Optional feature arguments:
|
||||
- 'skip_block_zeroing': skips the zeroing of newly-provisioned blocks.
|
||||
|
||||
Data block size must be between 64KB (128 sectors) and 1GB
|
||||
(2097152 sectors) inclusive.
|
||||
|
||||
|
||||
ii) Status
|
||||
|
||||
<transaction id> <used metadata blocks>/<total metadata blocks>
|
||||
<used data blocks>/<total data blocks> <held metadata root>
|
||||
|
||||
|
||||
transaction id:
|
||||
A 64-bit number used by userspace to help synchronise with metadata
|
||||
from volume managers.
|
||||
|
||||
used data blocks / total data blocks
|
||||
If the number of free blocks drops below the pool's low water mark a
|
||||
dm event will be sent to userspace. This event is edge-triggered and
|
||||
it will occur only once after each resume so volume manager writers
|
||||
should register for the event and then check the target's status.
|
||||
|
||||
held metadata root:
|
||||
The location, in sectors, of the metadata root that has been
|
||||
'held' for userspace read access. '-' indicates there is no
|
||||
held root. This feature is not yet implemented so '-' is
|
||||
always returned.
|
||||
|
||||
iii) Messages
|
||||
|
||||
create_thin <dev id>
|
||||
|
||||
Create a new thinly-provisioned device.
|
||||
<dev id> is an arbitrary unique 24-bit identifier chosen by
|
||||
the caller.
|
||||
|
||||
create_snap <dev id> <origin id>
|
||||
|
||||
Create a new snapshot of another thinly-provisioned device.
|
||||
<dev id> is an arbitrary unique 24-bit identifier chosen by
|
||||
the caller.
|
||||
<origin id> is the identifier of the thinly-provisioned device
|
||||
of which the new device will be a snapshot.
|
||||
|
||||
delete <dev id>
|
||||
|
||||
Deletes a thin device. Irreversible.
|
||||
|
||||
trim <dev id> <new size in sectors>
|
||||
|
||||
Delete mappings from the end of a thin device. Irreversible.
|
||||
You might want to use this if you're reducing the size of
|
||||
your thinly-provisioned device. In many cases, due to the
|
||||
sharing of blocks between devices, it is not possible to
|
||||
determine in advance how much space 'trim' will release. (In
|
||||
future a userspace tool might be able to perform this
|
||||
calculation.)
|
||||
|
||||
set_transaction_id <current id> <new id>
|
||||
|
||||
Userland volume managers, such as LVM, need a way to
|
||||
synchronise their external metadata with the internal metadata of the
|
||||
pool target. The thin-pool target offers to store an
|
||||
arbitrary 64-bit transaction id and return it on the target's
|
||||
status line. To avoid races you must provide what you think
|
||||
the current transaction id is when you change it with this
|
||||
compare-and-swap message.
|
||||
|
||||
'thin' target
|
||||
-------------
|
||||
|
||||
i) Constructor
|
||||
|
||||
thin <pool dev> <dev id>
|
||||
|
||||
pool dev:
|
||||
the thin-pool device, e.g. /dev/mapper/my_pool or 253:0
|
||||
|
||||
dev id:
|
||||
the internal device identifier of the device to be
|
||||
activated.
|
||||
|
||||
The pool doesn't store any size against the thin devices. If you
|
||||
load a thin target that is smaller than you've been using previously,
|
||||
then you'll have no access to blocks mapped beyond the end. If you
|
||||
load a target that is bigger than before, then extra blocks will be
|
||||
provisioned as and when needed.
|
||||
|
||||
If you wish to reduce the size of your thin device and potentially
|
||||
regain some space then send the 'trim' message to the pool.
|
||||
|
||||
ii) Status
|
||||
|
||||
<nr mapped sectors> <highest mapped sector>
|
||||
8
Documentation/devicetree/bindings/arm/calxeda.txt
Normal file
8
Documentation/devicetree/bindings/arm/calxeda.txt
Normal file
|
|
@ -0,0 +1,8 @@
|
|||
Calxeda Highbank Platforms Device Tree Bindings
|
||||
-----------------------------------------------
|
||||
|
||||
Boards with Calxeda Cortex-A9 based Highbank SOC shall have the following
|
||||
properties.
|
||||
|
||||
Required root node properties:
|
||||
- compatible = "calxeda,highbank";
|
||||
26
Documentation/devicetree/bindings/arm/fsl.txt
Normal file
26
Documentation/devicetree/bindings/arm/fsl.txt
Normal file
|
|
@ -0,0 +1,26 @@
|
|||
Freescale i.MX Platforms Device Tree Bindings
|
||||
-----------------------------------------------
|
||||
|
||||
i.MX51 Babbage Board
|
||||
Required root node properties:
|
||||
- compatible = "fsl,imx51-babbage", "fsl,imx51";
|
||||
|
||||
i.MX53 Automotive Reference Design Board
|
||||
Required root node properties:
|
||||
- compatible = "fsl,imx53-ard", "fsl,imx53";
|
||||
|
||||
i.MX53 Evaluation Kit
|
||||
Required root node properties:
|
||||
- compatible = "fsl,imx53-evk", "fsl,imx53";
|
||||
|
||||
i.MX53 Quick Start Board
|
||||
Required root node properties:
|
||||
- compatible = "fsl,imx53-qsb", "fsl,imx53";
|
||||
|
||||
i.MX53 Smart Mobile Reference Design Board
|
||||
Required root node properties:
|
||||
- compatible = "fsl,imx53-smd", "fsl,imx53";
|
||||
|
||||
i.MX6 Quad SABRE Automotive Board
|
||||
Required root node properties:
|
||||
- compatible = "fsl,imx6q-sabreauto", "fsl,imx6q";
|
||||
55
Documentation/devicetree/bindings/arm/gic.txt
Normal file
55
Documentation/devicetree/bindings/arm/gic.txt
Normal file
|
|
@ -0,0 +1,55 @@
|
|||
* ARM Generic Interrupt Controller
|
||||
|
||||
ARM SMP cores are often associated with a GIC, providing per processor
|
||||
interrupts (PPI), shared processor interrupts (SPI) and software
|
||||
generated interrupts (SGI).
|
||||
|
||||
Primary GIC is attached directly to the CPU and typically has PPIs and SGIs.
|
||||
Secondary GICs are cascaded into the upward interrupt controller and do not
|
||||
have PPIs or SGIs.
|
||||
|
||||
Main node required properties:
|
||||
|
||||
- compatible : should be one of:
|
||||
"arm,cortex-a9-gic"
|
||||
"arm,arm11mp-gic"
|
||||
- interrupt-controller : Identifies the node as an interrupt controller
|
||||
- #interrupt-cells : Specifies the number of cells needed to encode an
|
||||
interrupt source. The type shall be a <u32> and the value shall be 3.
|
||||
|
||||
The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI
|
||||
interrupts.
|
||||
|
||||
The 2nd cell contains the interrupt number for the interrupt type.
|
||||
SPI interrupts are in the range [0-987]. PPI interrupts are in the
|
||||
range [0-15].
|
||||
|
||||
The 3rd cell is the flags, encoded as follows:
|
||||
bits[3:0] trigger type and level flags.
|
||||
1 = low-to-high edge triggered
|
||||
2 = high-to-low edge triggered
|
||||
4 = active high level-sensitive
|
||||
8 = active low level-sensitive
|
||||
bits[15:8] PPI interrupt cpu mask. Each bit corresponds to each of
|
||||
the 8 possible cpus attached to the GIC. A bit set to '1' indicated
|
||||
the interrupt is wired to that CPU. Only valid for PPI interrupts.
|
||||
|
||||
- reg : Specifies base physical address(s) and size of the GIC registers. The
|
||||
first region is the GIC distributor register base and size. The 2nd region is
|
||||
the GIC cpu interface register base and size.
|
||||
|
||||
Optional
|
||||
- interrupts : Interrupt source of the parent interrupt controller. Only
|
||||
present on secondary GICs.
|
||||
|
||||
Example:
|
||||
|
||||
intc: interrupt-controller@fff11000 {
|
||||
compatible = "arm,cortex-a9-gic";
|
||||
#interrupt-cells = <3>;
|
||||
#address-cells = <1>;
|
||||
interrupt-controller;
|
||||
reg = <0xfff11000 0x1000>,
|
||||
<0xfff10100 0x100>;
|
||||
};
|
||||
|
||||
44
Documentation/devicetree/bindings/arm/l2cc.txt
Normal file
44
Documentation/devicetree/bindings/arm/l2cc.txt
Normal file
|
|
@ -0,0 +1,44 @@
|
|||
* ARM L2 Cache Controller
|
||||
|
||||
ARM cores often have a separate level 2 cache controller. There are various
|
||||
implementations of the L2 cache controller with compatible programming models.
|
||||
The ARM L2 cache representation in the device tree should be done as follows:
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : should be one of:
|
||||
"arm,pl310-cache"
|
||||
"arm,l220-cache"
|
||||
"arm,l210-cache"
|
||||
- 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
|
||||
registers.
|
||||
|
||||
Optional properties:
|
||||
|
||||
- arm,data-latency : Cycles of latency for Data RAM accesses. Specifies 3 cells of
|
||||
read, write and setup latencies. Minimum valid values are 1. Controllers
|
||||
without setup latency control should use a value of 0.
|
||||
- arm,tag-latency : Cycles of latency for Tag RAM accesses. Specifies 3 cells of
|
||||
read, write and setup latencies. Controllers without setup latency control
|
||||
should use 0. Controllers without separate read and write Tag RAM latency
|
||||
values should only use the first cell.
|
||||
- arm,dirty-latency : Cycles of latency for Dirty RAMs. This is a single cell.
|
||||
- arm,filter-ranges : <start length> Starting address and length of window to
|
||||
filter. Addresses in the filter window are directed to the M1 port. Other
|
||||
addresses will go to the M0 port.
|
||||
- interrupts : 1 combined interrupt.
|
||||
|
||||
Example:
|
||||
|
||||
L2: cache-controller {
|
||||
compatible = "arm,pl310-cache";
|
||||
reg = <0xfff12000 0x1000>;
|
||||
arm,data-latency = <1 1 1>;
|
||||
arm,tag-latency = <2 2 2>;
|
||||
arm,filter-latency = <0x80000000 0x8000000>;
|
||||
cache-unified;
|
||||
cache-level = <2>;
|
||||
interrupts = <45>;
|
||||
};
|
||||
14
Documentation/devicetree/bindings/arm/omap/dsp.txt
Normal file
14
Documentation/devicetree/bindings/arm/omap/dsp.txt
Normal file
|
|
@ -0,0 +1,14 @@
|
|||
* TI - DSP (Digital Signal Processor)
|
||||
|
||||
TI DSP included in OMAP SoC
|
||||
|
||||
Required properties:
|
||||
- compatible : Should be "ti,omap3-c64" for OMAP3 & 4
|
||||
- ti,hwmods: "dsp"
|
||||
|
||||
Examples:
|
||||
|
||||
dsp {
|
||||
compatible = "ti,omap3-c64";
|
||||
ti,hwmods = "dsp";
|
||||
};
|
||||
19
Documentation/devicetree/bindings/arm/omap/iva.txt
Normal file
19
Documentation/devicetree/bindings/arm/omap/iva.txt
Normal file
|
|
@ -0,0 +1,19 @@
|
|||
* TI - IVA (Imaging and Video Accelerator) subsystem
|
||||
|
||||
The IVA contain various audio, video or imaging HW accelerator
|
||||
depending of the version.
|
||||
|
||||
Required properties:
|
||||
- compatible : Should be:
|
||||
- "ti,ivahd" for OMAP4
|
||||
- "ti,iva2.2" for OMAP3
|
||||
- "ti,iva2.1" for OMAP2430
|
||||
- "ti,iva1" for OMAP2420
|
||||
- ti,hwmods: "iva"
|
||||
|
||||
Examples:
|
||||
|
||||
iva {
|
||||
compatible = "ti,ivahd", "ti,iva";
|
||||
ti,hwmods = "iva";
|
||||
};
|
||||
19
Documentation/devicetree/bindings/arm/omap/l3-noc.txt
Normal file
19
Documentation/devicetree/bindings/arm/omap/l3-noc.txt
Normal file
|
|
@ -0,0 +1,19 @@
|
|||
* TI - L3 Network On Chip (NoC)
|
||||
|
||||
This version is an implementation of the generic NoC IP
|
||||
provided by Arteris.
|
||||
|
||||
Required properties:
|
||||
- compatible : Should be "ti,omap3-l3-smx" for OMAP3 family
|
||||
Should be "ti,omap4-l3-noc" for OMAP4 family
|
||||
- ti,hwmods: "l3_main_1", ... One hwmod for each noc domain.
|
||||
|
||||
Examples:
|
||||
|
||||
ocp {
|
||||
compatible = "ti,omap4-l3-noc", "simple-bus";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
ranges;
|
||||
ti,hwmods = "l3_main_1", "l3_main_2", "l3_main_3";
|
||||
};
|
||||
27
Documentation/devicetree/bindings/arm/omap/mpu.txt
Normal file
27
Documentation/devicetree/bindings/arm/omap/mpu.txt
Normal file
|
|
@ -0,0 +1,27 @@
|
|||
* TI - MPU (Main Processor Unit) subsystem
|
||||
|
||||
The MPU subsystem contain one or several ARM cores
|
||||
depending of the version.
|
||||
The MPU contain CPUs, GIC, L2 cache and a local PRCM.
|
||||
|
||||
Required properties:
|
||||
- compatible : Should be "ti,omap3-mpu" for OMAP3
|
||||
Should be "ti,omap4-mpu" for OMAP4
|
||||
- ti,hwmods: "mpu"
|
||||
|
||||
Examples:
|
||||
|
||||
- For an OMAP4 SMP system:
|
||||
|
||||
mpu {
|
||||
compatible = "ti,omap4-mpu";
|
||||
ti,hwmods = "mpu";
|
||||
};
|
||||
|
||||
|
||||
- For an OMAP3 monocore system:
|
||||
|
||||
mpu {
|
||||
compatible = "ti,omap3-mpu";
|
||||
ti,hwmods = "mpu";
|
||||
};
|
||||
43
Documentation/devicetree/bindings/arm/omap/omap.txt
Normal file
43
Documentation/devicetree/bindings/arm/omap/omap.txt
Normal file
|
|
@ -0,0 +1,43 @@
|
|||
* Texas Instruments OMAP
|
||||
|
||||
OMAP is currently using a static file per SoC family to describe the
|
||||
IPs present in the SoC.
|
||||
On top of that an omap_device is created to extend the platform_device
|
||||
capabilities and to allow binding with one or several hwmods.
|
||||
The hwmods will contain all the information to build the device:
|
||||
adresse range, irq lines, dma lines, interconnect, PRCM register,
|
||||
clock domain, input clocks.
|
||||
For the moment just point to the existing hwmod, the next step will be
|
||||
to move data from hwmod to device-tree representation.
|
||||
|
||||
|
||||
Required properties:
|
||||
- compatible: Every devices present in OMAP SoC should be in the
|
||||
form: "ti,XXX"
|
||||
- ti,hwmods: list of hwmod names (ascii strings), that comes from the OMAP
|
||||
HW documentation, attached to a device. Must contain at least
|
||||
one hwmod.
|
||||
|
||||
Optional properties:
|
||||
- ti,no_idle_on_suspend: When present, it prevents the PM to idle the module
|
||||
during suspend.
|
||||
|
||||
|
||||
Example:
|
||||
|
||||
spinlock@1 {
|
||||
compatible = "ti,omap4-spinlock";
|
||||
ti,hwmods = "spinlock";
|
||||
};
|
||||
|
||||
|
||||
Boards:
|
||||
|
||||
- OMAP3 BeagleBoard : Low cost community board
|
||||
compatible = "ti,omap3-beagle", "ti,omap3"
|
||||
|
||||
- OMAP4 SDP : Software Developement Board
|
||||
compatible = "ti,omap4-sdp", "ti,omap4430"
|
||||
|
||||
- OMAP4 PandaBoard : Low cost community board
|
||||
compatible = "ti,omap4-panda", "ti,omap4430"
|
||||
24
Documentation/devicetree/bindings/arm/picoxcell.txt
Normal file
24
Documentation/devicetree/bindings/arm/picoxcell.txt
Normal file
|
|
@ -0,0 +1,24 @@
|
|||
Picochip picoXcell device tree bindings.
|
||||
========================================
|
||||
|
||||
Required root node properties:
|
||||
- compatible:
|
||||
- "picochip,pc7302-pc3x3" : PC7302 development board with PC3X3 device.
|
||||
- "picochip,pc7302-pc3x2" : PC7302 development board with PC3X2 device.
|
||||
- "picochip,pc3x3" : picoXcell PC3X3 device based board.
|
||||
- "picochip,pc3x2" : picoXcell PC3X2 device based board.
|
||||
|
||||
Timers required properties:
|
||||
- compatible = "picochip,pc3x2-timer"
|
||||
- interrupts : The single IRQ line for the timer.
|
||||
- clock-freq : The frequency in HZ of the timer.
|
||||
- reg : The register bank for the timer.
|
||||
|
||||
Note: two timers are required - one for the scheduler clock and one for the
|
||||
event tick/NOHZ.
|
||||
|
||||
VIC required properties:
|
||||
- compatible = "arm,pl192-vic".
|
||||
- interrupt-controller.
|
||||
- reg : The register bank for the device.
|
||||
- #interrupt-cells : Must be 1.
|
||||
|
|
@ -6,7 +6,9 @@ driver matching.
|
|||
|
||||
Required properties:
|
||||
|
||||
- compatible : should be a specific value for peripheral and "arm,primecell"
|
||||
- compatible : should be a specific name for the peripheral and
|
||||
"arm,primecell". The specific name will match the ARM
|
||||
engineering name for the logic block in the form: "arm,pl???"
|
||||
|
||||
Optional properties:
|
||||
|
||||
|
|
|
|||
17
Documentation/devicetree/bindings/ata/calxeda-sata.txt
Normal file
17
Documentation/devicetree/bindings/ata/calxeda-sata.txt
Normal file
|
|
@ -0,0 +1,17 @@
|
|||
* Calxeda 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 "calxeda,hb-ahci"
|
||||
- interrupts : <interrupt mapping for SATA IRQ>
|
||||
- reg : <registers mapping>
|
||||
|
||||
Example:
|
||||
sata@ffe08000 {
|
||||
compatible = "calxeda,hb-ahci";
|
||||
reg = <0xffe08000 0x1000>;
|
||||
interrupts = <115>;
|
||||
};
|
||||
|
||||
23
Documentation/devicetree/bindings/crypto/picochip-spacc.txt
Normal file
23
Documentation/devicetree/bindings/crypto/picochip-spacc.txt
Normal file
|
|
@ -0,0 +1,23 @@
|
|||
Picochip picoXcell SPAcc (Security Protocol Accelerator) bindings
|
||||
|
||||
Picochip picoXcell devices contain crypto offload engines that may be used for
|
||||
IPSEC and femtocell layer 2 ciphering.
|
||||
|
||||
Required properties:
|
||||
- compatible : "picochip,spacc-ipsec" for the IPSEC offload engine
|
||||
"picochip,spacc-l2" for the femtocell layer 2 ciphering engine.
|
||||
- reg : Offset and length of the register set for this device
|
||||
- interrupt-parent : The interrupt controller that controls the SPAcc
|
||||
interrupt.
|
||||
- interrupts : The interrupt line from the SPAcc.
|
||||
- ref-clock : The input clock that drives the SPAcc.
|
||||
|
||||
Example SPAcc node:
|
||||
|
||||
spacc@10000 {
|
||||
compatible = "picochip,spacc-ipsec";
|
||||
reg = <0x100000 0x10000>;
|
||||
interrupt-parent = <&vic0>;
|
||||
interrupts = <24>;
|
||||
ref-clock = <&ipsec_clk>, "ref";
|
||||
};
|
||||
|
|
@ -8,7 +8,7 @@ node's name represents the name of the corresponding LED.
|
|||
|
||||
LED sub-node properties:
|
||||
- gpios : Should specify the LED's GPIO, see "Specifying GPIO information
|
||||
for devices" in Documentation/powerpc/booting-without-of.txt. Active
|
||||
for devices" in Documentation/devicetree/booting-without-of.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).
|
||||
|
|
|
|||
10
Documentation/devicetree/bindings/gpio/pl061-gpio.txt
Normal file
10
Documentation/devicetree/bindings/gpio/pl061-gpio.txt
Normal file
|
|
@ -0,0 +1,10 @@
|
|||
ARM PL061 GPIO controller
|
||||
|
||||
Required properties:
|
||||
- compatible : "arm,pl061", "arm,primecell"
|
||||
- #gpio-cells : Should be two. The first cell is the pin number and the
|
||||
second cell is used to specify optional parameters:
|
||||
- bit 0 specifies polarity (0 for normal, 1 for inverted)
|
||||
- gpio-controller : Marks the device node as a GPIO controller.
|
||||
- interrupts : Interrupt mapping for GPIO IRQ.
|
||||
|
||||
25
Documentation/devicetree/bindings/i2c/fsl-imx-i2c.txt
Normal file
25
Documentation/devicetree/bindings/i2c/fsl-imx-i2c.txt
Normal file
|
|
@ -0,0 +1,25 @@
|
|||
* Freescale Inter IC (I2C) and High Speed Inter IC (HS-I2C) for i.MX
|
||||
|
||||
Required properties:
|
||||
- compatible : Should be "fsl,<chip>-i2c"
|
||||
- reg : Should contain I2C/HS-I2C registers location and length
|
||||
- interrupts : Should contain I2C/HS-I2C interrupt
|
||||
|
||||
Optional properties:
|
||||
- clock-frequency : Constains desired I2C/HS-I2C bus clock frequency in Hz.
|
||||
The absence of the propoerty indicates the default frequency 100 kHz.
|
||||
|
||||
Examples:
|
||||
|
||||
i2c@83fc4000 { /* I2C2 on i.MX51 */
|
||||
compatible = "fsl,imx51-i2c", "fsl,imx1-i2c";
|
||||
reg = <0x83fc4000 0x4000>;
|
||||
interrupts = <63>;
|
||||
};
|
||||
|
||||
i2c@70038000 { /* HS-I2C on i.MX51 */
|
||||
compatible = "fsl,imx51-i2c", "fsl,imx1-i2c";
|
||||
reg = <0x70038000 0x4000>;
|
||||
interrupts = <64>;
|
||||
clock-frequency = <400000>;
|
||||
};
|
||||
39
Documentation/devicetree/bindings/i2c/samsung-i2c.txt
Normal file
39
Documentation/devicetree/bindings/i2c/samsung-i2c.txt
Normal file
|
|
@ -0,0 +1,39 @@
|
|||
* Samsung's I2C controller
|
||||
|
||||
The Samsung's I2C controller is used to interface with I2C devices.
|
||||
|
||||
Required properties:
|
||||
- compatible: value should be either of the following.
|
||||
(a) "samsung, s3c2410-i2c", for i2c compatible with s3c2410 i2c.
|
||||
(b) "samsung, s3c2440-i2c", for i2c compatible with s3c2440 i2c.
|
||||
- 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.
|
||||
- gpios: The order of the gpios should be the following: <SDA, SCL>.
|
||||
The gpio specifier depends on the gpio controller.
|
||||
|
||||
Optional properties:
|
||||
- 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
|
||||
specified, the default value in Hz is 100000.
|
||||
|
||||
Example:
|
||||
|
||||
i2c@13870000 {
|
||||
compatible = "samsung,s3c2440-i2c";
|
||||
reg = <0x13870000 0x100>;
|
||||
interrupts = <345>;
|
||||
samsung,i2c-sda-delay = <100>;
|
||||
samsung,i2c-max-bus-freq = <100000>;
|
||||
gpios = <&gpd1 2 0 /* SDA */
|
||||
&gpd1 3 0 /* SCL */>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
wm8994@1a {
|
||||
compatible = "wlf,wm8994";
|
||||
reg = <0x1a>;
|
||||
};
|
||||
};
|
||||
27
Documentation/devicetree/bindings/mmc/nvidia-sdhci.txt
Normal file
27
Documentation/devicetree/bindings/mmc/nvidia-sdhci.txt
Normal file
|
|
@ -0,0 +1,27 @@
|
|||
* NVIDIA Tegra Secure Digital Host Controller
|
||||
|
||||
This controller on Tegra family SoCs provides an interface for MMC, SD,
|
||||
and SDIO types of memory cards.
|
||||
|
||||
Required properties:
|
||||
- compatible : Should be "nvidia,<chip>-sdhci"
|
||||
- reg : Should contain SD/MMC registers location and length
|
||||
- interrupts : Should contain SD/MMC interrupt
|
||||
|
||||
Optional properties:
|
||||
- cd-gpios : Specify GPIOs for card detection
|
||||
- wp-gpios : Specify GPIOs for write protection
|
||||
- power-gpios : Specify GPIOs for power control
|
||||
- support-8bit : Boolean, indicates if 8-bit mode should be used.
|
||||
|
||||
Example:
|
||||
|
||||
sdhci@c8000200 {
|
||||
compatible = "nvidia,tegra20-sdhci";
|
||||
reg = <0xc8000200 0x200>;
|
||||
interrupts = <47>;
|
||||
cd-gpios = <&gpio 69 0>; /* gpio PI5 */
|
||||
wp-gpios = <&gpio 57 0>; /* gpio PH1 */
|
||||
power-gpios = <&gpio 155 0>; /* gpio PT3 */
|
||||
support-8bit;
|
||||
};
|
||||
14
Documentation/devicetree/bindings/mtd/atmel-dataflash.txt
Normal file
14
Documentation/devicetree/bindings/mtd/atmel-dataflash.txt
Normal file
|
|
@ -0,0 +1,14 @@
|
|||
* Atmel Data Flash
|
||||
|
||||
Required properties:
|
||||
- compatible : "atmel,<model>", "atmel,<series>", "atmel,dataflash".
|
||||
|
||||
Example:
|
||||
|
||||
flash@1 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
compatible = "atmel,at45db321d", "atmel,at45", "atmel,dataflash";
|
||||
spi-max-frequency = <25000000>;
|
||||
reg = <1>;
|
||||
};
|
||||
|
|
@ -1,61 +1,24 @@
|
|||
CAN Device Tree Bindings
|
||||
------------------------
|
||||
2011 Freescale Semiconductor, Inc.
|
||||
Flexcan CAN contoller on Freescale's ARM and PowerPC system-on-a-chip (SOC).
|
||||
|
||||
fsl,flexcan-v1.0 nodes
|
||||
-----------------------
|
||||
In addition to the required compatible-, reg- and interrupt-properties, you can
|
||||
also specify which clock source shall be used for the controller.
|
||||
Required properties:
|
||||
|
||||
CPI Clock- Can Protocol Interface Clock
|
||||
This CLK_SRC bit of CTRL(control register) selects the clock source to
|
||||
the CAN Protocol Interface(CPI) to be either the peripheral clock
|
||||
(driven by the PLL) or the crystal oscillator clock. The selected clock
|
||||
is the one fed to the prescaler to generate the Serial Clock (Sclock).
|
||||
The PRESDIV field of CTRL(control register) controls a prescaler that
|
||||
generates the Serial Clock (Sclock), whose period defines the
|
||||
time quantum used to compose the CAN waveform.
|
||||
- compatible : Should be "fsl,<processor>-flexcan"
|
||||
|
||||
Can Engine Clock Source
|
||||
There are two sources for CAN clock
|
||||
- Platform Clock It represents the bus clock
|
||||
- Oscillator Clock
|
||||
An implementation should also claim any of the following compatibles
|
||||
that it is fully backwards compatible with:
|
||||
|
||||
Peripheral Clock (PLL)
|
||||
--------------
|
||||
|
|
||||
--------- -------------
|
||||
| |CPI Clock | Prescaler | Sclock
|
||||
| |---------------->| (1.. 256) |------------>
|
||||
--------- -------------
|
||||
| |
|
||||
-------------- ---------------------CLK_SRC
|
||||
Oscillator Clock
|
||||
- fsl,p1010-flexcan
|
||||
|
||||
- fsl,flexcan-clock-source : CAN Engine Clock Source.This property selects
|
||||
the peripheral clock. PLL clock is fed to the
|
||||
prescaler to generate the Serial Clock (Sclock).
|
||||
Valid values are "oscillator" and "platform"
|
||||
"oscillator": CAN engine clock source is oscillator clock.
|
||||
"platform" The CAN engine clock source is the bus clock
|
||||
(platform clock).
|
||||
- reg : Offset and length of the register set for this device
|
||||
- interrupts : Interrupt tuple for this device
|
||||
- clock-frequency : The oscillator frequency driving the flexcan device
|
||||
|
||||
- fsl,flexcan-clock-divider : for the reference and system clock, an additional
|
||||
clock divider can be specified.
|
||||
- clock-frequency: frequency required to calculate the bitrate for FlexCAN.
|
||||
Example:
|
||||
|
||||
Note:
|
||||
- v1.0 of flexcan-v1.0 represent the IP block version for P1010 SOC.
|
||||
- P1010 does not have oscillator as the Clock Source.So the default
|
||||
Clock Source is platform clock.
|
||||
Examples:
|
||||
|
||||
can0@1c000 {
|
||||
compatible = "fsl,flexcan-v1.0";
|
||||
can@1c000 {
|
||||
compatible = "fsl,p1010-flexcan";
|
||||
reg = <0x1c000 0x1000>;
|
||||
interrupts = <48 0x2>;
|
||||
interrupt-parent = <&mpic>;
|
||||
fsl,flexcan-clock-source = "platform";
|
||||
fsl,flexcan-clock-divider = <2>;
|
||||
clock-frequency = <fixed by u-boot>;
|
||||
clock-frequency = <200000000>; // filled in by bootloader
|
||||
};
|
||||
|
|
|
|||
38
Documentation/devicetree/bindings/net/smsc911x.txt
Normal file
38
Documentation/devicetree/bindings/net/smsc911x.txt
Normal file
|
|
@ -0,0 +1,38 @@
|
|||
* Smart Mixed-Signal Connectivity (SMSC) LAN911x/912x Controller
|
||||
|
||||
Required properties:
|
||||
- compatible : Should be "smsc,lan<model>", "smsc,lan9115"
|
||||
- reg : Address and length of the io space for SMSC LAN
|
||||
- interrupts : Should contain SMSC LAN interrupt line
|
||||
- interrupt-parent : Should be the phandle for the interrupt controller
|
||||
that services interrupts for this device
|
||||
- phy-mode : String, operation mode of the PHY interface.
|
||||
Supported values are: "mii", "gmii", "sgmii", "tbi", "rmii",
|
||||
"rgmii", "rgmii-id", "rgmii-rxid", "rgmii-txid", "rtbi", "smii".
|
||||
|
||||
Optional properties:
|
||||
- reg-shift : Specify the quantity to shift the register offsets by
|
||||
- reg-io-width : Specify the size (in bytes) of the IO accesses that
|
||||
should be performed on the device. Valid value for SMSC LAN is
|
||||
2 or 4. If it's omitted or invalid, the size would be 2.
|
||||
- smsc,irq-active-high : Indicates the IRQ polarity is active-high
|
||||
- smsc,irq-push-pull : Indicates the IRQ type is push-pull
|
||||
- smsc,force-internal-phy : Forces SMSC LAN controller to use
|
||||
internal PHY
|
||||
- smsc,force-external-phy : Forces SMSC LAN controller to use
|
||||
external PHY
|
||||
- smsc,save-mac-address : Indicates that mac address needs to be saved
|
||||
before resetting the controller
|
||||
- local-mac-address : 6 bytes, mac address
|
||||
|
||||
Examples:
|
||||
|
||||
lan9220@f4000000 {
|
||||
compatible = "smsc,lan9220", "smsc,lan9115";
|
||||
reg = <0xf4000000 0x2000000>;
|
||||
phy-mode = "mii";
|
||||
interrupt-parent = <&gpio1>;
|
||||
interrupts = <31>;
|
||||
reg-io-width = <4>;
|
||||
smsc,irq-push-pull;
|
||||
};
|
||||
|
|
@ -0,0 +1,5 @@
|
|||
NVIDIA Tegra 2 pinmux controller
|
||||
|
||||
Required properties:
|
||||
- compatible : "nvidia,tegra20-pinmux"
|
||||
|
||||
|
|
@ -1,3 +1,8 @@
|
|||
Freescale Reference Board Bindings
|
||||
|
||||
This document describes device tree bindings for various devices that
|
||||
exist on some Freescale reference boards.
|
||||
|
||||
* Board Control and Status (BCSR)
|
||||
|
||||
Required properties:
|
||||
|
|
@ -12,25 +17,26 @@ Example:
|
|||
reg = <f8000000 8000>;
|
||||
};
|
||||
|
||||
* Freescale on board FPGA
|
||||
* Freescale on-board FPGA
|
||||
|
||||
This is the memory-mapped registers for on board FPGA.
|
||||
|
||||
Required properities:
|
||||
- compatible : should be "fsl,fpga-pixis".
|
||||
- reg : should contain the address and the length of the FPPGA register
|
||||
set.
|
||||
- compatible: should be a board-specific string followed by a string
|
||||
indicating the type of FPGA. Example:
|
||||
"fsl,<board>-fpga", "fsl,fpga-pixis"
|
||||
- reg: should contain the address and the length of the FPGA register set.
|
||||
- interrupt-parent: should specify phandle for the interrupt controller.
|
||||
- interrupts : should specify event (wakeup) IRQ.
|
||||
- interrupts: should specify event (wakeup) IRQ.
|
||||
|
||||
Example (MPC8610HPCD):
|
||||
Example (P1022DS):
|
||||
|
||||
board-control@e8000000 {
|
||||
compatible = "fsl,fpga-pixis";
|
||||
reg = <0xe8000000 32>;
|
||||
interrupt-parent = <&mpic>;
|
||||
interrupts = <8 8>;
|
||||
};
|
||||
board-control@3,0 {
|
||||
compatible = "fsl,p1022ds-fpga", "fsl,fpga-ngpixis";
|
||||
reg = <3 0 0x30>;
|
||||
interrupt-parent = <&mpic>;
|
||||
interrupts = <8 8 0 0>;
|
||||
};
|
||||
|
||||
* Freescale BCSR GPIO banks
|
||||
|
||||
|
|
|
|||
395
Documentation/devicetree/bindings/powerpc/fsl/dcsr.txt
Normal file
395
Documentation/devicetree/bindings/powerpc/fsl/dcsr.txt
Normal file
|
|
@ -0,0 +1,395 @@
|
|||
===================================================================
|
||||
Debug Control and Status Register (DCSR) Binding
|
||||
Copyright 2011 Freescale Semiconductor Inc.
|
||||
|
||||
NOTE: The bindings described in this document are preliminary and subject
|
||||
to change. Some of the compatible strings that contain only generic names
|
||||
may turn out to be inappropriate, or need additional properties to describe
|
||||
the integration of the block with the rest of the chip.
|
||||
|
||||
=====================================================================
|
||||
Debug Control and Status Register Memory Map
|
||||
|
||||
Description
|
||||
|
||||
This node defines the base address and range for the
|
||||
defined DCSR Memory Map. Child nodes will describe the individual
|
||||
debug blocks defined within this memory space.
|
||||
|
||||
PROPERTIES
|
||||
|
||||
- compatible
|
||||
Usage: required
|
||||
Value type: <string>
|
||||
Definition: Must include "fsl,dcsr" and "simple-bus".
|
||||
The DCSR space exists in the memory-mapped bus.
|
||||
|
||||
- #address-cells
|
||||
Usage: required
|
||||
Value type: <u32>
|
||||
Definition: A standard property. Defines the number of cells
|
||||
or representing physical addresses in child nodes.
|
||||
|
||||
- #size-cells
|
||||
Usage: required
|
||||
Value type: <u32>
|
||||
Definition: A standard property. Defines the number of cells
|
||||
or representing the size of physical addresses in
|
||||
child nodes.
|
||||
|
||||
- ranges
|
||||
Usage: required
|
||||
Value type: <prop-encoded-array>
|
||||
Definition: A standard property. Specifies the physical address
|
||||
range of the DCSR space.
|
||||
|
||||
EXAMPLE
|
||||
dcsr: dcsr@f00000000 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
compatible = "fsl,dcsr", "simple-bus";
|
||||
ranges = <0x00000000 0xf 0x00000000 0x01008000>;
|
||||
};
|
||||
|
||||
=====================================================================
|
||||
Event Processing Unit
|
||||
|
||||
This node represents the region of DCSR space allocated to the EPU
|
||||
|
||||
PROPERTIES
|
||||
|
||||
- compatible
|
||||
Usage: required
|
||||
Value type: <string>
|
||||
Definition: Must include "fsl,dcsr-epu"
|
||||
|
||||
- interrupts
|
||||
Usage: required
|
||||
Value type: <prop_encoded-array>
|
||||
Definition: Specifies the interrupts generated by the EPU.
|
||||
The value of the interrupts property consists of three
|
||||
interrupt specifiers. The format of the specifier is defined
|
||||
by the binding document describing the node's interrupt parent.
|
||||
|
||||
The EPU counters can be configured to assert the performance
|
||||
monitor interrupt signal based on either counter overflow or value
|
||||
match. Which counter asserted the interrupt is captured in an EPU
|
||||
Counter Interrupt Status Register (EPCPUISR).
|
||||
|
||||
The EPU unit can also be configured to assert either or both of
|
||||
two interrupt signals based on debug event sources within the SoC.
|
||||
The interrupt signals are epu_xt_int0 and epu_xt_int1.
|
||||
Which event source asserted the interrupt is captured in an EPU
|
||||
Interrupt Status Register (EPISR0,EPISR1).
|
||||
|
||||
Interrupt numbers are lised in order (perfmon, event0, event1).
|
||||
|
||||
- interrupt-parent
|
||||
Usage: required
|
||||
Value type: <phandle>
|
||||
Definition: A single <phandle> value that points
|
||||
to the interrupt parent to which the child domain
|
||||
is being mapped. Value must be "&mpic"
|
||||
|
||||
- reg
|
||||
Usage: required
|
||||
Value type: <prop-encoded-array>
|
||||
Definition: A standard property. Specifies the physical address
|
||||
offset and length of the DCSR space registers of the device
|
||||
configuration block.
|
||||
|
||||
EXAMPLE
|
||||
dcsr-epu@0 {
|
||||
compatible = "fsl,dcsr-epu";
|
||||
interrupts = <52 2 0 0
|
||||
84 2 0 0
|
||||
85 2 0 0>;
|
||||
interrupt-parent = <&mpic>;
|
||||
reg = <0x0 0x1000>;
|
||||
};
|
||||
|
||||
=======================================================================
|
||||
Nexus Port Controller
|
||||
|
||||
This node represents the region of DCSR space allocated to the NPC
|
||||
|
||||
PROPERTIES
|
||||
|
||||
- compatible
|
||||
Usage: required
|
||||
Value type: <string>
|
||||
Definition: Must include "fsl,dcsr-npc"
|
||||
|
||||
- reg
|
||||
Usage: required
|
||||
Value type: <prop-encoded-array>
|
||||
Definition: A standard property. Specifies the physical address
|
||||
offset and length of the DCSR space registers of the device
|
||||
configuration block.
|
||||
The Nexus Port controller occupies two regions in the DCSR space
|
||||
with distinct functionality.
|
||||
|
||||
The first register range describes the Nexus Port Controller
|
||||
control and status registers.
|
||||
|
||||
The second register range describes the Nexus Port Controller
|
||||
internal trace buffer. The NPC trace buffer is a small memory buffer
|
||||
which stages the nexus trace data for transmission via the Aurora port
|
||||
or to a DDR based trace buffer. In some configurations the NPC trace
|
||||
buffer can be the only trace buffer used.
|
||||
|
||||
|
||||
EXAMPLE
|
||||
dcsr-npc {
|
||||
compatible = "fsl,dcsr-npc";
|
||||
reg = <0x1000 0x1000 0x1000000 0x8000>;
|
||||
};
|
||||
|
||||
=======================================================================
|
||||
Nexus Concentrator
|
||||
|
||||
This node represents the region of DCSR space allocated to the NXC
|
||||
|
||||
PROPERTIES
|
||||
|
||||
- compatible
|
||||
Usage: required
|
||||
Value type: <string>
|
||||
Definition: Must include "fsl,dcsr-nxc"
|
||||
|
||||
- reg
|
||||
Usage: required
|
||||
Value type: <prop-encoded-array>
|
||||
Definition: A standard property. Specifies the physical address
|
||||
offset and length of the DCSR space registers of the device
|
||||
configuration block.
|
||||
|
||||
EXAMPLE
|
||||
dcsr-nxc@2000 {
|
||||
compatible = "fsl,dcsr-nxc";
|
||||
reg = <0x2000 0x1000>;
|
||||
};
|
||||
=======================================================================
|
||||
CoreNet Debug Controller
|
||||
|
||||
This node represents the region of DCSR space allocated to
|
||||
the CoreNet Debug controller.
|
||||
|
||||
PROPERTIES
|
||||
|
||||
- compatible
|
||||
Usage: required
|
||||
Value type: <string>
|
||||
Definition: Must include "fsl,dcsr-corenet"
|
||||
|
||||
- reg
|
||||
Usage: required
|
||||
Value type: <prop-encoded-array>
|
||||
Definition: A standard property. Specifies the physical address
|
||||
offset and length of the DCSR space registers of the device
|
||||
configuration block.
|
||||
The CoreNet Debug controller occupies two regions in the DCSR space
|
||||
with distinct functionality.
|
||||
|
||||
The first register range describes the CoreNet Debug Controller
|
||||
functionalty to perform transaction and transaction attribute matches.
|
||||
|
||||
The second register range describes the CoreNet Debug Controller
|
||||
functionalty to trigger event notifications and debug traces.
|
||||
|
||||
EXAMPLE
|
||||
dcsr-corenet {
|
||||
compatible = "fsl,dcsr-corenet";
|
||||
reg = <0x8000 0x1000 0xB0000 0x1000>;
|
||||
};
|
||||
|
||||
=======================================================================
|
||||
Data Path Debug controller
|
||||
|
||||
This node represents the region of DCSR space allocated to
|
||||
the DPAA Debug Controller. This controller controls debug configuration
|
||||
for the QMAN and FMAN blocks.
|
||||
|
||||
PROPERTIES
|
||||
|
||||
- compatible
|
||||
Usage: required
|
||||
Value type: <string>
|
||||
Definition: Must include both an identifier specific to the SoC
|
||||
or Debug IP of the form "fsl,<soc>-dcsr-dpaa" in addition to the
|
||||
generic compatible string "fsl,dcsr-dpaa".
|
||||
|
||||
- reg
|
||||
Usage: required
|
||||
Value type: <prop-encoded-array>
|
||||
Definition: A standard property. Specifies the physical address
|
||||
offset and length of the DCSR space registers of the device
|
||||
configuration block.
|
||||
|
||||
EXAMPLE
|
||||
dcsr-dpaa@9000 {
|
||||
compatible = "fsl,p4080-dcsr-dpaa", "fsl,dcsr-dpaa";
|
||||
reg = <0x9000 0x1000>;
|
||||
};
|
||||
|
||||
=======================================================================
|
||||
OCeaN Debug controller
|
||||
|
||||
This node represents the region of DCSR space allocated to
|
||||
the OCN Debug Controller.
|
||||
|
||||
PROPERTIES
|
||||
|
||||
- compatible
|
||||
Usage: required
|
||||
Value type: <string>
|
||||
Definition: Must include both an identifier specific to the SoC
|
||||
or Debug IP of the form "fsl,<soc>-dcsr-ocn" in addition to the
|
||||
generic compatible string "fsl,dcsr-ocn".
|
||||
|
||||
- reg
|
||||
Usage: required
|
||||
Value type: <prop-encoded-array>
|
||||
Definition: A standard property. Specifies the physical address
|
||||
offset and length of the DCSR space registers of the device
|
||||
configuration block.
|
||||
|
||||
EXAMPLE
|
||||
dcsr-ocn@11000 {
|
||||
compatible = "fsl,p4080-dcsr-ocn", "fsl,dcsr-ocn";
|
||||
reg = <0x11000 0x1000>;
|
||||
};
|
||||
|
||||
=======================================================================
|
||||
DDR Controller Debug controller
|
||||
|
||||
This node represents the region of DCSR space allocated to
|
||||
the OCN Debug Controller.
|
||||
|
||||
PROPERTIES
|
||||
|
||||
- compatible
|
||||
Usage: required
|
||||
Value type: <string>
|
||||
Definition: Must include "fsl,dcsr-ddr"
|
||||
|
||||
- dev-handle
|
||||
Usage: required
|
||||
Definition: A phandle to associate this debug node with its
|
||||
component controller.
|
||||
|
||||
- reg
|
||||
Usage: required
|
||||
Value type: <prop-encoded-array>
|
||||
Definition: A standard property. Specifies the physical address
|
||||
offset and length of the DCSR space registers of the device
|
||||
configuration block.
|
||||
|
||||
EXAMPLE
|
||||
dcsr-ddr@12000 {
|
||||
compatible = "fsl,dcsr-ddr";
|
||||
dev-handle = <&ddr1>;
|
||||
reg = <0x12000 0x1000>;
|
||||
};
|
||||
|
||||
=======================================================================
|
||||
Nexus Aurora Link Controller
|
||||
|
||||
This node represents the region of DCSR space allocated to
|
||||
the NAL Controller.
|
||||
|
||||
PROPERTIES
|
||||
|
||||
- compatible
|
||||
Usage: required
|
||||
Value type: <string>
|
||||
Definition: Must include both an identifier specific to the SoC
|
||||
or Debug IP of the form "fsl,<soc>-dcsr-nal" in addition to the
|
||||
generic compatible string "fsl,dcsr-nal".
|
||||
|
||||
- reg
|
||||
Usage: required
|
||||
Value type: <prop-encoded-array>
|
||||
Definition: A standard property. Specifies the physical address
|
||||
offset and length of the DCSR space registers of the device
|
||||
configuration block.
|
||||
|
||||
EXAMPLE
|
||||
dcsr-nal@18000 {
|
||||
compatible = "fsl,p4080-dcsr-nal", "fsl,dcsr-nal";
|
||||
reg = <0x18000 0x1000>;
|
||||
};
|
||||
|
||||
|
||||
=======================================================================
|
||||
Run Control and Power Management
|
||||
|
||||
This node represents the region of DCSR space allocated to
|
||||
the RCPM Debug Controller. This functionlity is limited to the
|
||||
control the debug operations of the SoC and cores.
|
||||
|
||||
PROPERTIES
|
||||
|
||||
- compatible
|
||||
Usage: required
|
||||
Value type: <string>
|
||||
Definition: Must include both an identifier specific to the SoC
|
||||
or Debug IP of the form "fsl,<soc>-dcsr-rcpm" in addition to the
|
||||
generic compatible string "fsl,dcsr-rcpm".
|
||||
|
||||
- reg
|
||||
Usage: required
|
||||
Value type: <prop-encoded-array>
|
||||
Definition: A standard property. Specifies the physical address
|
||||
offset and length of the DCSR space registers of the device
|
||||
configuration block.
|
||||
|
||||
EXAMPLE
|
||||
dcsr-rcpm@22000 {
|
||||
compatible = "fsl,p4080-dcsr-rcpm", "fsl,dcsr-rcpm";
|
||||
reg = <0x22000 0x1000>;
|
||||
};
|
||||
|
||||
=======================================================================
|
||||
Core Service Bridge Proxy
|
||||
|
||||
This node represents the region of DCSR space allocated to
|
||||
the Core Service Bridge Proxies.
|
||||
There is one Core Service Bridge Proxy device for each CPU in the system.
|
||||
This functionlity provides access to the debug operations of the CPU.
|
||||
|
||||
PROPERTIES
|
||||
|
||||
- compatible
|
||||
Usage: required
|
||||
Value type: <string>
|
||||
Definition: Must include both an identifier specific to the cpu
|
||||
of the form "fsl,dcsr-<cpu>-sb-proxy" in addition to the
|
||||
generic compatible string "fsl,dcsr-cpu-sb-proxy".
|
||||
|
||||
- cpu-handle
|
||||
Usage: required
|
||||
Definition: A phandle to associate this debug node with its cpu.
|
||||
|
||||
- reg
|
||||
Usage: required
|
||||
Value type: <prop-encoded-array>
|
||||
Definition: A standard property. Specifies the physical address
|
||||
offset and length of the DCSR space registers of the device
|
||||
configuration block.
|
||||
|
||||
EXAMPLE
|
||||
dcsr-cpu-sb-proxy@40000 {
|
||||
compatible = "fsl,dcsr-e500mc-sb-proxy",
|
||||
"fsl,dcsr-cpu-sb-proxy";
|
||||
cpu-handle = <&cpu0>;
|
||||
reg = <0x40000 0x1000>;
|
||||
};
|
||||
dcsr-cpu-sb-proxy@41000 {
|
||||
compatible = "fsl,dcsr-e500mc-sb-proxy",
|
||||
"fsl,dcsr-cpu-sb-proxy";
|
||||
cpu-handle = <&cpu1>;
|
||||
reg = <0x41000 0x1000>;
|
||||
};
|
||||
|
||||
=======================================================================
|
||||
|
|
@ -25,6 +25,16 @@ Required properties:
|
|||
are routed to IPIC, and for 85xx/86xx cpu the interrupts are routed
|
||||
to MPIC.
|
||||
|
||||
Optional properties:
|
||||
- msi-address-64: 64-bit PCI address of the MSIIR register. The MSIIR register
|
||||
is used for MSI messaging. The address of MSIIR in PCI address space is
|
||||
the MSI message address.
|
||||
|
||||
This property may be used in virtualized environments where the hypervisor
|
||||
has created an alternate mapping for the MSIR block. See below for an
|
||||
explanation.
|
||||
|
||||
|
||||
Example:
|
||||
msi@41600 {
|
||||
compatible = "fsl,mpc8610-msi", "fsl,mpic-msi";
|
||||
|
|
@ -41,3 +51,35 @@ Example:
|
|||
0xe7 0>;
|
||||
interrupt-parent = <&mpic>;
|
||||
};
|
||||
|
||||
The Freescale hypervisor and msi-address-64
|
||||
-------------------------------------------
|
||||
Normally, PCI devices have access to all of CCSR via an ATMU mapping. The
|
||||
Freescale MSI driver calculates the address of MSIIR (in the MSI register
|
||||
block) and sets that address as the MSI message address.
|
||||
|
||||
In a virtualized environment, the hypervisor may need to create an IOMMU
|
||||
mapping for MSIIR. The Freescale ePAPR hypervisor has this requirement
|
||||
because of hardware limitations of the Peripheral Access Management Unit
|
||||
(PAMU), which is currently the only IOMMU that the hypervisor supports.
|
||||
The ATMU is programmed with the guest physical address, and the PAMU
|
||||
intercepts transactions and reroutes them to the true physical address.
|
||||
|
||||
In the PAMU, each PCI controller is given only one primary window. The
|
||||
PAMU restricts DMA operations so that they can only occur within a window.
|
||||
Because PCI devices must be able to DMA to memory, the primary window must
|
||||
be used to cover all of the guest's memory space.
|
||||
|
||||
PAMU primary windows can be divided into 256 subwindows, and each
|
||||
subwindow can have its own address mapping ("guest physical" to "true
|
||||
physical"). However, each subwindow has to have the same alignment, which
|
||||
means they cannot be located at just any address. Because of these
|
||||
restrictions, it is usually impossible to create a 4KB subwindow that
|
||||
covers MSIIR where it's normally located.
|
||||
|
||||
Therefore, the hypervisor has to create a subwindow inside the same
|
||||
primary window used for memory, but mapped to the MSIR block (where MSIIR
|
||||
lives). The first subwindow after the end of guest memory is used for
|
||||
this. The address specified in the msi-address-64 property is the PCI
|
||||
address of MSIIR. The hypervisor configures the PAMU to map that address to
|
||||
the true physical address of MSIIR.
|
||||
|
|
|
|||
31
Documentation/devicetree/bindings/serial/rs485.txt
Normal file
31
Documentation/devicetree/bindings/serial/rs485.txt
Normal file
|
|
@ -0,0 +1,31 @@
|
|||
* RS485 serial communications
|
||||
|
||||
The RTS signal is capable of automatically controlling line direction for
|
||||
the built-in half-duplex mode.
|
||||
The properties described hereafter shall be given to a half-duplex capable
|
||||
UART node.
|
||||
|
||||
Required properties:
|
||||
- rs485-rts-delay: prop-encoded-array <a b> where:
|
||||
* a is the delay beteween rts signal and beginning of data sent in milliseconds.
|
||||
it corresponds to the delay before sending data.
|
||||
* b is the delay between end of data sent and rts signal in milliseconds
|
||||
it corresponds to the delay after sending data and actual release of the line.
|
||||
|
||||
Optional properties:
|
||||
- linux,rs485-enabled-at-boot-time: empty property telling to enable the rs485
|
||||
feature at boot time. It can be disabled later with proper ioctl.
|
||||
- rs485-rx-during-tx: empty property that enables the receiving of data even
|
||||
whilst sending data.
|
||||
|
||||
RS485 example for Atmel USART:
|
||||
usart0: serial@fff8c000 {
|
||||
compatible = "atmel,at91sam9260-usart";
|
||||
reg = <0xfff8c000 0x4000>;
|
||||
interrupts = <7>;
|
||||
atmel,use-dma-rx;
|
||||
atmel,use-dma-tx;
|
||||
linux,rs485-enabled-at-boot-time;
|
||||
rs485-rts-delay = <0 200>; // in milliseconds
|
||||
};
|
||||
|
||||
|
|
@ -0,0 +1,11 @@
|
|||
* Freescale SGTL5000 Stereo Codec
|
||||
|
||||
Required properties:
|
||||
- compatible : "fsl,sgtl5000".
|
||||
|
||||
Example:
|
||||
|
||||
codec: sgtl5000@0a {
|
||||
compatible = "fsl,sgtl5000";
|
||||
reg = <0x0a>;
|
||||
};
|
||||
18
Documentation/devicetree/bindings/sound/wm8510.txt
Normal file
18
Documentation/devicetree/bindings/sound/wm8510.txt
Normal file
|
|
@ -0,0 +1,18 @@
|
|||
WM8510 audio CODEC
|
||||
|
||||
This device supports both I2C and SPI (configured with pin strapping
|
||||
on the board).
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : "wlf,wm8510"
|
||||
|
||||
- reg : the I2C address of the device for I2C, the chip select
|
||||
number for SPI.
|
||||
|
||||
Example:
|
||||
|
||||
codec: wm8510@1a {
|
||||
compatible = "wlf,wm8510";
|
||||
reg = <0x1a>;
|
||||
};
|
||||
16
Documentation/devicetree/bindings/sound/wm8523.txt
Normal file
16
Documentation/devicetree/bindings/sound/wm8523.txt
Normal file
|
|
@ -0,0 +1,16 @@
|
|||
WM8523 audio CODEC
|
||||
|
||||
This device supports I2C only.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : "wlf,wm8523"
|
||||
|
||||
- reg : the I2C address of the device.
|
||||
|
||||
Example:
|
||||
|
||||
codec: wm8523@1a {
|
||||
compatible = "wlf,wm8523";
|
||||
reg = <0x1a>;
|
||||
};
|
||||
16
Documentation/devicetree/bindings/sound/wm8580.txt
Normal file
16
Documentation/devicetree/bindings/sound/wm8580.txt
Normal file
|
|
@ -0,0 +1,16 @@
|
|||
WM8580 audio CODEC
|
||||
|
||||
This device supports I2C only.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : "wlf,wm8580"
|
||||
|
||||
- reg : the I2C address of the device.
|
||||
|
||||
Example:
|
||||
|
||||
codec: wm8580@1a {
|
||||
compatible = "wlf,wm8580";
|
||||
reg = <0x1a>;
|
||||
};
|
||||
18
Documentation/devicetree/bindings/sound/wm8711.txt
Normal file
18
Documentation/devicetree/bindings/sound/wm8711.txt
Normal file
|
|
@ -0,0 +1,18 @@
|
|||
WM8711 audio CODEC
|
||||
|
||||
This device supports both I2C and SPI (configured with pin strapping
|
||||
on the board).
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : "wlf,wm8711"
|
||||
|
||||
- reg : the I2C address of the device for I2C, the chip select
|
||||
number for SPI.
|
||||
|
||||
Example:
|
||||
|
||||
codec: wm8711@1a {
|
||||
compatible = "wlf,wm8711";
|
||||
reg = <0x1a>;
|
||||
};
|
||||
18
Documentation/devicetree/bindings/sound/wm8728.txt
Normal file
18
Documentation/devicetree/bindings/sound/wm8728.txt
Normal file
|
|
@ -0,0 +1,18 @@
|
|||
WM8728 audio CODEC
|
||||
|
||||
This device supports both I2C and SPI (configured with pin strapping
|
||||
on the board).
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : "wlf,wm8728"
|
||||
|
||||
- reg : the I2C address of the device for I2C, the chip select
|
||||
number for SPI.
|
||||
|
||||
Example:
|
||||
|
||||
codec: wm8728@1a {
|
||||
compatible = "wlf,wm8728";
|
||||
reg = <0x1a>;
|
||||
};
|
||||
18
Documentation/devicetree/bindings/sound/wm8731.txt
Normal file
18
Documentation/devicetree/bindings/sound/wm8731.txt
Normal file
|
|
@ -0,0 +1,18 @@
|
|||
WM8731 audio CODEC
|
||||
|
||||
This device supports both I2C and SPI (configured with pin strapping
|
||||
on the board).
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : "wlf,wm8731"
|
||||
|
||||
- reg : the I2C address of the device for I2C, the chip select
|
||||
number for SPI.
|
||||
|
||||
Example:
|
||||
|
||||
codec: wm8731@1a {
|
||||
compatible = "wlf,wm8731";
|
||||
reg = <0x1a>;
|
||||
};
|
||||
18
Documentation/devicetree/bindings/sound/wm8737.txt
Normal file
18
Documentation/devicetree/bindings/sound/wm8737.txt
Normal file
|
|
@ -0,0 +1,18 @@
|
|||
WM8737 audio CODEC
|
||||
|
||||
This device supports both I2C and SPI (configured with pin strapping
|
||||
on the board).
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : "wlf,wm8737"
|
||||
|
||||
- reg : the I2C address of the device for I2C, the chip select
|
||||
number for SPI.
|
||||
|
||||
Example:
|
||||
|
||||
codec: wm8737@1a {
|
||||
compatible = "wlf,wm8737";
|
||||
reg = <0x1a>;
|
||||
};
|
||||
18
Documentation/devicetree/bindings/sound/wm8741.txt
Normal file
18
Documentation/devicetree/bindings/sound/wm8741.txt
Normal file
|
|
@ -0,0 +1,18 @@
|
|||
WM8741 audio CODEC
|
||||
|
||||
This device supports both I2C and SPI (configured with pin strapping
|
||||
on the board).
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : "wlf,wm8741"
|
||||
|
||||
- reg : the I2C address of the device for I2C, the chip select
|
||||
number for SPI.
|
||||
|
||||
Example:
|
||||
|
||||
codec: wm8741@1a {
|
||||
compatible = "wlf,wm8741";
|
||||
reg = <0x1a>;
|
||||
};
|
||||
18
Documentation/devicetree/bindings/sound/wm8750.txt
Normal file
18
Documentation/devicetree/bindings/sound/wm8750.txt
Normal file
|
|
@ -0,0 +1,18 @@
|
|||
WM8750 and WM8987 audio CODECs
|
||||
|
||||
These devices support both I2C and SPI (configured with pin strapping
|
||||
on the board).
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : "wlf,wm8750" or "wlf,wm8987"
|
||||
|
||||
- reg : the I2C address of the device for I2C, the chip select
|
||||
number for SPI.
|
||||
|
||||
Example:
|
||||
|
||||
codec: wm8750@1a {
|
||||
compatible = "wlf,wm8750";
|
||||
reg = <0x1a>;
|
||||
};
|
||||
18
Documentation/devicetree/bindings/sound/wm8753.txt
Normal file
18
Documentation/devicetree/bindings/sound/wm8753.txt
Normal file
|
|
@ -0,0 +1,18 @@
|
|||
WM8753 audio CODEC
|
||||
|
||||
This device supports both I2C and SPI (configured with pin strapping
|
||||
on the board).
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : "wlf,wm8753"
|
||||
|
||||
- reg : the I2C address of the device for I2C, the chip select
|
||||
number for SPI.
|
||||
|
||||
Example:
|
||||
|
||||
codec: wm8737@1a {
|
||||
compatible = "wlf,wm8753";
|
||||
reg = <0x1a>;
|
||||
};
|
||||
16
Documentation/devicetree/bindings/sound/wm8770.txt
Normal file
16
Documentation/devicetree/bindings/sound/wm8770.txt
Normal file
|
|
@ -0,0 +1,16 @@
|
|||
WM8770 audio CODEC
|
||||
|
||||
This device supports SPI.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : "wlf,wm8770"
|
||||
|
||||
- reg : the chip select number.
|
||||
|
||||
Example:
|
||||
|
||||
codec: wm8770@1 {
|
||||
compatible = "wlf,wm8770";
|
||||
reg = <1>;
|
||||
};
|
||||
18
Documentation/devicetree/bindings/sound/wm8776.txt
Normal file
18
Documentation/devicetree/bindings/sound/wm8776.txt
Normal file
|
|
@ -0,0 +1,18 @@
|
|||
WM8776 audio CODEC
|
||||
|
||||
This device supports both I2C and SPI (configured with pin strapping
|
||||
on the board).
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : "wlf,wm8776"
|
||||
|
||||
- reg : the I2C address of the device for I2C, the chip select
|
||||
number for SPI.
|
||||
|
||||
Example:
|
||||
|
||||
codec: wm8776@1a {
|
||||
compatible = "wlf,wm8776";
|
||||
reg = <0x1a>;
|
||||
};
|
||||
18
Documentation/devicetree/bindings/sound/wm8804.txt
Normal file
18
Documentation/devicetree/bindings/sound/wm8804.txt
Normal file
|
|
@ -0,0 +1,18 @@
|
|||
WM8804 audio CODEC
|
||||
|
||||
This device supports both I2C and SPI (configured with pin strapping
|
||||
on the board).
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : "wlf,wm8804"
|
||||
|
||||
- reg : the I2C address of the device for I2C, the chip select
|
||||
number for SPI.
|
||||
|
||||
Example:
|
||||
|
||||
codec: wm8804@1a {
|
||||
compatible = "wlf,wm8804";
|
||||
reg = <0x1a>;
|
||||
};
|
||||
12
Documentation/devicetree/bindings/spi/spi_pl022.txt
Normal file
12
Documentation/devicetree/bindings/spi/spi_pl022.txt
Normal file
|
|
@ -0,0 +1,12 @@
|
|||
ARM PL022 SPI controller
|
||||
|
||||
Required properties:
|
||||
- compatible : "arm,pl022", "arm,primecell"
|
||||
- reg : Offset and length of the register set for the device
|
||||
- interrupts : Should contain SPI controller interrupt
|
||||
|
||||
Optional properties:
|
||||
- cs-gpios : should specify GPIOs used for chipselects.
|
||||
The gpios will be referred to as reg = <index> in the SPI child nodes.
|
||||
If unspecified, a single SPI device without a chip select can be used.
|
||||
|
||||
27
Documentation/devicetree/bindings/tty/serial/atmel-usart.txt
Normal file
27
Documentation/devicetree/bindings/tty/serial/atmel-usart.txt
Normal file
|
|
@ -0,0 +1,27 @@
|
|||
* Atmel Universal Synchronous Asynchronous Receiver/Transmitter (USART)
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "atmel,<chip>-usart"
|
||||
The compatible <chip> indicated will be the first SoC to support an
|
||||
additional mode or an USART new feature.
|
||||
- reg: Should contain registers location and length
|
||||
- interrupts: Should contain interrupt
|
||||
|
||||
Optional properties:
|
||||
- atmel,use-dma-rx: use of PDC or DMA for receiving data
|
||||
- atmel,use-dma-tx: use of PDC or DMA for transmitting data
|
||||
|
||||
<chip> compatible description:
|
||||
- at91rm9200: legacy USART support
|
||||
- at91sam9260: generic USART implementation for SAM9 SoCs
|
||||
|
||||
Example:
|
||||
|
||||
usart0: serial@fff8c000 {
|
||||
compatible = "atmel,at91sam9260-usart";
|
||||
reg = <0xfff8c000 0x4000>;
|
||||
interrupts = <7>;
|
||||
atmel,use-dma-rx;
|
||||
atmel,use-dma-tx;
|
||||
};
|
||||
|
||||
27
Documentation/devicetree/bindings/tty/serial/msm_serial.txt
Normal file
27
Documentation/devicetree/bindings/tty/serial/msm_serial.txt
Normal file
|
|
@ -0,0 +1,27 @@
|
|||
* Qualcomm MSM UART
|
||||
|
||||
Required properties:
|
||||
- compatible :
|
||||
- "qcom,msm-uart", and one of "qcom,msm-hsuart" or
|
||||
"qcom,msm-lsuart".
|
||||
- reg : offset and length of the register set for the device
|
||||
for the hsuart operating in compatible mode, there should be a
|
||||
second pair describing the gsbi registers.
|
||||
- interrupts : should contain the uart interrupt.
|
||||
|
||||
There are two different UART blocks used in MSM devices,
|
||||
"qcom,msm-hsuart" and "qcom,msm-lsuart". The msm-serial driver is
|
||||
able to handle both of these, and matches against the "qcom,msm-uart"
|
||||
as the compatibility.
|
||||
|
||||
The registers for the "qcom,msm-hsuart" device need to specify both
|
||||
register blocks, even for the common driver.
|
||||
|
||||
Example:
|
||||
|
||||
uart@19c400000 {
|
||||
compatible = "qcom,msm-hsuart", "qcom,msm-uart";
|
||||
reg = <0x19c40000 0x1000>,
|
||||
<0x19c00000 0x1000>;
|
||||
interrupts = <195>;
|
||||
};
|
||||
Some files were not shown because too many files have changed in this diff Show more
Loading…
Add table
Reference in a new issue