Linux 3.14-rc6
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAABAgAGBQJTHSaRAAoJEHm+PkMAQRiG7G8IAJHElwFDNSQE7Y9MmbicrAMG kfjhBtBpTaVrJKQXegCNUwDaLLyC4oLIxDheW84oPXbrEGDLqPtBov/hrcFkHVr4 lh/ZYk02nYtcfpN0JnL/Yj2oKHVmBWs0vFlM7StSFsJCj10DoCVQQdmAJ8XODTPo CXMapk+UikTX1TlIO8+B5toyl3R1OqPmW211UV1vQVLKy66hu+MKVN/V+/EyopL0 1jO81EDpaRaeIJh1/okcyUoIq9pqLkAWNpeQ7uyXZ+Sfivt9RXwLYKmAB3lP20Hc ZMIIoHSCyYRFjxLlQvt02bA9nY4wTY7YN5kZ2kk65y7TFfhcGsCw1Sc69iyCoKs= =CJcA -----END PGP SIGNATURE----- Merge tag 'v3.14-rc6' into drm-intel-next-queued Linux 3.14-rc6 I need the hdmi/dvi-dual link fixes in 3.14 to avoid ugly conflicts when merging Ville's new hdmi cloning support into my -next tree Conflicts: drivers/gpu/drm/i915/Makefile drivers/gpu/drm/i915/intel_dp.c Makefile cleanup conflicts with an acpi build fix, intel_dp.c is trivial. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This commit is contained in:
commit
e8e6e6012d
3
.gitignore
vendored
3
.gitignore
vendored
|
@ -92,3 +92,6 @@ extra_certificates
|
|||
signing_key.priv
|
||||
signing_key.x509
|
||||
x509.genkey
|
||||
|
||||
# Kconfig presets
|
||||
all.config
|
||||
|
|
4
CREDITS
4
CREDITS
|
@ -823,8 +823,8 @@ S: D-69231 Rauenberg
|
|||
S: Germany
|
||||
|
||||
N: Jean Delvare
|
||||
E: khali@linux-fr.org
|
||||
W: http://khali.linux-fr.org/
|
||||
E: jdelvare@suse.de
|
||||
W: http://jdelvare.nerim.net/
|
||||
D: Several hardware monitoring drivers
|
||||
S: France
|
||||
|
||||
|
|
|
@ -29,6 +29,8 @@ DMA-ISA-LPC.txt
|
|||
- How to do DMA with ISA (and LPC) devices.
|
||||
DMA-attributes.txt
|
||||
- listing of the various possible attributes a DMA region can have
|
||||
dmatest.txt
|
||||
- how to compile, configure and use the dmatest system.
|
||||
DocBook/
|
||||
- directory with DocBook templates etc. for kernel documentation.
|
||||
EDID/
|
||||
|
@ -77,6 +79,8 @@ arm/
|
|||
- directory with info about Linux on the ARM architecture.
|
||||
arm64/
|
||||
- directory with info about Linux on the 64 bit ARM architecture.
|
||||
assoc_array.txt
|
||||
- generic associative array intro.
|
||||
atomic_ops.txt
|
||||
- semantics and behavior of atomic and bitmask operations.
|
||||
auxdisplay/
|
||||
|
@ -87,6 +91,8 @@ bad_memory.txt
|
|||
- how to use kernel parameters to exclude bad RAM regions.
|
||||
basic_profiling.txt
|
||||
- basic instructions for those who wants to profile Linux kernel.
|
||||
bcache.txt
|
||||
- Block-layer cache on fast SSDs to improve slow (raid) I/O performance.
|
||||
binfmt_misc.txt
|
||||
- info on the kernel support for extra binary formats.
|
||||
blackfin/
|
||||
|
@ -171,6 +177,8 @@ early-userspace/
|
|||
- info about initramfs, klibc, and userspace early during boot.
|
||||
edac.txt
|
||||
- information on EDAC - Error Detection And Correction
|
||||
efi-stub.txt
|
||||
- How to use the EFI boot stub to bypass GRUB or elilo on EFI systems.
|
||||
eisa.txt
|
||||
- info on EISA bus support.
|
||||
email-clients.txt
|
||||
|
@ -195,8 +203,8 @@ futex-requeue-pi.txt
|
|||
- info on requeueing of tasks from a non-PI futex to a PI futex
|
||||
gcov.txt
|
||||
- use of GCC's coverage testing tool "gcov" with the Linux kernel
|
||||
gpio.txt
|
||||
- overview of GPIO (General Purpose Input/Output) access conventions.
|
||||
gpio/
|
||||
- gpio related documentation
|
||||
hid/
|
||||
- directory with information on human interface devices
|
||||
highuid.txt
|
||||
|
@ -255,6 +263,8 @@ kernel-docs.txt
|
|||
- listing of various WWW + books that document kernel internals.
|
||||
kernel-parameters.txt
|
||||
- summary listing of command line / boot prompt args for the kernel.
|
||||
kernel-per-CPU-kthreads.txt
|
||||
- List of all per-CPU kthreads and how they introduce jitter.
|
||||
kmemcheck.txt
|
||||
- info on dynamic checker that detects uses of uninitialized memory.
|
||||
kmemleak.txt
|
||||
|
@ -299,8 +309,6 @@ memory-devices/
|
|||
- directory with info on parts like the Texas Instruments EMIF driver
|
||||
memory-hotplug.txt
|
||||
- Hotpluggable memory support, how to use and current status.
|
||||
memory.txt
|
||||
- info on typical Linux memory problems.
|
||||
metag/
|
||||
- directory with info about Linux on Meta architecture.
|
||||
mips/
|
||||
|
@ -311,6 +319,8 @@ mmc/
|
|||
- directory with info about the MMC subsystem
|
||||
mn10300/
|
||||
- directory with info about the mn10300 architecture port
|
||||
module-signing.txt
|
||||
- Kernel module signing for increased security when loading modules.
|
||||
mtd/
|
||||
- directory with info about memory technology devices (flash)
|
||||
mono.txt
|
||||
|
@ -343,6 +353,8 @@ pcmcia/
|
|||
- info on the Linux PCMCIA driver.
|
||||
percpu-rw-semaphore.txt
|
||||
- RCU based read-write semaphore optimized for locking for reading
|
||||
phy.txt
|
||||
- Description of the generic PHY framework.
|
||||
pi-futex.txt
|
||||
- documentation on lightweight priority inheritance futexes.
|
||||
pinctrl.txt
|
||||
|
@ -431,6 +443,8 @@ sysrq.txt
|
|||
- info on the magic SysRq key.
|
||||
target/
|
||||
- directory with info on generating TCM v4 fabric .ko modules
|
||||
this_cpu_ops.txt
|
||||
- List rationale behind and the way to use this_cpu operations.
|
||||
thermal/
|
||||
- directory with information on managing thermal issues (CPU/temp)
|
||||
trace/
|
||||
|
@ -469,6 +483,8 @@ wimax/
|
|||
- directory with info about Intel Wireless Wimax Connections
|
||||
workqueue.txt
|
||||
- information on the Concurrency Managed Workqueue implementation
|
||||
ww-mutex-design.txt
|
||||
- Intro to Mutex wait/would deadlock handling.s
|
||||
x86/x86_64/
|
||||
- directory with info on Linux support for AMD x86-64 (Hammer) machines.
|
||||
xtensa/
|
||||
|
|
|
@ -1,13 +1,13 @@
|
|||
What: /config/usb-gadget
|
||||
Date: Jun 2013
|
||||
KenelVersion: 3.11
|
||||
KernelVersion: 3.11
|
||||
Description:
|
||||
This group contains sub-groups corresponding to created
|
||||
USB gadgets.
|
||||
|
||||
What: /config/usb-gadget/gadget
|
||||
Date: Jun 2013
|
||||
KenelVersion: 3.11
|
||||
KernelVersion: 3.11
|
||||
Description:
|
||||
|
||||
The attributes of a gadget:
|
||||
|
@ -27,7 +27,7 @@ Description:
|
|||
|
||||
What: /config/usb-gadget/gadget/configs
|
||||
Date: Jun 2013
|
||||
KenelVersion: 3.11
|
||||
KernelVersion: 3.11
|
||||
Description:
|
||||
This group contains a USB gadget's configurations
|
||||
|
||||
|
@ -58,20 +58,20 @@ Description:
|
|||
|
||||
What: /config/usb-gadget/gadget/functions
|
||||
Date: Jun 2013
|
||||
KenelVersion: 3.11
|
||||
KernelVersion: 3.11
|
||||
Description:
|
||||
This group contains functions available to this USB gadget.
|
||||
|
||||
What: /config/usb-gadget/gadget/strings
|
||||
Date: Jun 2013
|
||||
KenelVersion: 3.11
|
||||
KernelVersion: 3.11
|
||||
Description:
|
||||
This group contains subdirectories for language-specific
|
||||
strings for this gadget.
|
||||
|
||||
What: /config/usb-gadget/gadget/strings/language
|
||||
Date: Jun 2013
|
||||
KenelVersion: 3.11
|
||||
KernelVersion: 3.11
|
||||
Description:
|
||||
The attributes:
|
||||
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
What: /config/usb-gadget/gadget/functions/acm.name
|
||||
Date: Jun 2013
|
||||
KenelVersion: 3.11
|
||||
KernelVersion: 3.11
|
||||
Description:
|
||||
|
||||
This item contains just one readonly attribute: port_num.
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
What: /config/usb-gadget/gadget/functions/ecm.name
|
||||
Date: Jun 2013
|
||||
KenelVersion: 3.11
|
||||
KernelVersion: 3.11
|
||||
Description:
|
||||
The attributes:
|
||||
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
What: /config/usb-gadget/gadget/functions/eem.name
|
||||
Date: Jun 2013
|
||||
KenelVersion: 3.11
|
||||
KernelVersion: 3.11
|
||||
Description:
|
||||
The attributes:
|
||||
|
||||
|
|
9
Documentation/ABI/testing/configfs-usb-gadget-ffs
Normal file
9
Documentation/ABI/testing/configfs-usb-gadget-ffs
Normal file
|
@ -0,0 +1,9 @@
|
|||
What: /config/usb-gadget/gadget/functions/ffs.name
|
||||
Date: Nov 2013
|
||||
KernelVersion: 3.13
|
||||
Description: The purpose of this directory is to create and remove it.
|
||||
|
||||
A corresponding USB function instance is created/removed.
|
||||
There are no attributes here.
|
||||
|
||||
All parameters are set through FunctionFS.
|
8
Documentation/ABI/testing/configfs-usb-gadget-loopback
Normal file
8
Documentation/ABI/testing/configfs-usb-gadget-loopback
Normal file
|
@ -0,0 +1,8 @@
|
|||
What: /config/usb-gadget/gadget/functions/Loopback.name
|
||||
Date: Nov 2013
|
||||
KernelVersion: 3.13
|
||||
Description:
|
||||
The attributes:
|
||||
|
||||
qlen - depth of loopback queue
|
||||
bulk_buflen - buffer length
|
|
@ -1,6 +1,6 @@
|
|||
What: /config/usb-gadget/gadget/functions/mass_storage.name
|
||||
Date: Oct 2013
|
||||
KenelVersion: 3.13
|
||||
KernelVersion: 3.13
|
||||
Description:
|
||||
The attributes:
|
||||
|
||||
|
@ -13,7 +13,7 @@ Description:
|
|||
|
||||
What: /config/usb-gadget/gadget/functions/mass_storage.name/lun.name
|
||||
Date: Oct 2013
|
||||
KenelVersion: 3.13
|
||||
KernelVersion: 3.13
|
||||
Description:
|
||||
The attributes:
|
||||
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
What: /config/usb-gadget/gadget/functions/ncm.name
|
||||
Date: Jun 2013
|
||||
KenelVersion: 3.11
|
||||
KernelVersion: 3.11
|
||||
Description:
|
||||
The attributes:
|
||||
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
What: /config/usb-gadget/gadget/functions/obex.name
|
||||
Date: Jun 2013
|
||||
KenelVersion: 3.11
|
||||
KernelVersion: 3.11
|
||||
Description:
|
||||
|
||||
This item contains just one readonly attribute: port_num.
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
What: /config/usb-gadget/gadget/functions/phonet.name
|
||||
Date: Jun 2013
|
||||
KenelVersion: 3.11
|
||||
KernelVersion: 3.11
|
||||
Description:
|
||||
|
||||
This item contains just one readonly attribute: ifname.
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
What: /config/usb-gadget/gadget/functions/rndis.name
|
||||
Date: Jun 2013
|
||||
KenelVersion: 3.11
|
||||
KernelVersion: 3.11
|
||||
Description:
|
||||
The attributes:
|
||||
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
What: /config/usb-gadget/gadget/functions/gser.name
|
||||
Date: Jun 2013
|
||||
KenelVersion: 3.11
|
||||
KernelVersion: 3.11
|
||||
Description:
|
||||
|
||||
This item contains just one readonly attribute: port_num.
|
||||
|
|
12
Documentation/ABI/testing/configfs-usb-gadget-sourcesink
Normal file
12
Documentation/ABI/testing/configfs-usb-gadget-sourcesink
Normal file
|
@ -0,0 +1,12 @@
|
|||
What: /config/usb-gadget/gadget/functions/SourceSink.name
|
||||
Date: Nov 2013
|
||||
KernelVersion: 3.13
|
||||
Description:
|
||||
The attributes:
|
||||
|
||||
pattern - 0 (all zeros), 1 (mod63), 2 (none)
|
||||
isoc_interval - 1..16
|
||||
isoc_maxpacket - 0 - 1023 (fs), 0 - 1024 (hs/ss)
|
||||
isoc_mult - 0..2 (hs/ss only)
|
||||
isoc_maxburst - 0..15 (ss only)
|
||||
qlen - buffer length
|
|
@ -1,6 +1,6 @@
|
|||
What: /config/usb-gadget/gadget/functions/geth.name
|
||||
Date: Jun 2013
|
||||
KenelVersion: 3.11
|
||||
KernelVersion: 3.11
|
||||
Description:
|
||||
The attributes:
|
||||
|
||||
|
|
91
Documentation/ABI/testing/debugfs-driver-genwqe
Normal file
91
Documentation/ABI/testing/debugfs-driver-genwqe
Normal file
|
@ -0,0 +1,91 @@
|
|||
What: /sys/kernel/debug/genwqe/genwqe<n>_card/ddcb_info
|
||||
Date: Oct 2013
|
||||
Contact: haver@linux.vnet.ibm.com
|
||||
Description: DDCB queue dump used for debugging queueing problems.
|
||||
|
||||
What: /sys/kernel/debug/genwqe/genwqe<n>_card/curr_regs
|
||||
Date: Oct 2013
|
||||
Contact: haver@linux.vnet.ibm.com
|
||||
Description: Dump of the current error registers.
|
||||
Only available for PF.
|
||||
|
||||
What: /sys/kernel/debug/genwqe/genwqe<n>_card/curr_dbg_uid0
|
||||
Date: Oct 2013
|
||||
Contact: haver@linux.vnet.ibm.com
|
||||
Description: Internal chip state of UID0 (unit id 0).
|
||||
Only available for PF.
|
||||
|
||||
What: /sys/kernel/debug/genwqe/genwqe<n>_card/curr_dbg_uid1
|
||||
Date: Oct 2013
|
||||
Contact: haver@linux.vnet.ibm.com
|
||||
Description: Internal chip state of UID1.
|
||||
Only available for PF.
|
||||
|
||||
What: /sys/kernel/debug/genwqe/genwqe<n>_card/curr_dbg_uid2
|
||||
Date: Oct 2013
|
||||
Contact: haver@linux.vnet.ibm.com
|
||||
Description: Internal chip state of UID2.
|
||||
Only available for PF.
|
||||
|
||||
What: /sys/kernel/debug/genwqe/genwqe<n>_card/prev_regs
|
||||
Date: Oct 2013
|
||||
Contact: haver@linux.vnet.ibm.com
|
||||
Description: Dump of the error registers before the last reset of
|
||||
the card occured.
|
||||
Only available for PF.
|
||||
|
||||
What: /sys/kernel/debug/genwqe/genwqe<n>_card/prev_dbg_uid0
|
||||
Date: Oct 2013
|
||||
Contact: haver@linux.vnet.ibm.com
|
||||
Description: Internal chip state of UID0 before card was reset.
|
||||
Only available for PF.
|
||||
|
||||
What: /sys/kernel/debug/genwqe/genwqe<n>_card/prev_dbg_uid1
|
||||
Date: Oct 2013
|
||||
Contact: haver@linux.vnet.ibm.com
|
||||
Description: Internal chip state of UID1 before card was reset.
|
||||
Only available for PF.
|
||||
|
||||
What: /sys/kernel/debug/genwqe/genwqe<n>_card/prev_dbg_uid2
|
||||
Date: Oct 2013
|
||||
Contact: haver@linux.vnet.ibm.com
|
||||
Description: Internal chip state of UID2 before card was reset.
|
||||
Only available for PF.
|
||||
|
||||
What: /sys/kernel/debug/genwqe/genwqe<n>_card/info
|
||||
Date: Oct 2013
|
||||
Contact: haver@linux.vnet.ibm.com
|
||||
Description: Comprehensive summary of bitstream version and software
|
||||
version. Used bitstream and bitstream clocking information.
|
||||
|
||||
What: /sys/kernel/debug/genwqe/genwqe<n>_card/err_inject
|
||||
Date: Oct 2013
|
||||
Contact: haver@linux.vnet.ibm.com
|
||||
Description: Possibility to inject error cases to ensure that the drivers
|
||||
error handling code works well.
|
||||
|
||||
What: /sys/kernel/debug/genwqe/genwqe<n>_card/vf<0..14>_jobtimeout_msec
|
||||
Date: Oct 2013
|
||||
Contact: haver@linux.vnet.ibm.com
|
||||
Description: Default VF timeout 250ms. Testing might require 1000ms.
|
||||
Using 0 will use the cards default value (whatever that is).
|
||||
|
||||
The timeout depends on the max number of available cards
|
||||
in the system and the maximum allowed queue size.
|
||||
|
||||
The driver ensures that the settings are done just before
|
||||
the VFs get enabled. Changing the timeouts in flight is not
|
||||
possible.
|
||||
Only available for PF.
|
||||
|
||||
What: /sys/kernel/debug/genwqe/genwqe<n>_card/jobtimer
|
||||
Date: Oct 2013
|
||||
Contact: haver@linux.vnet.ibm.com
|
||||
Description: Dump job timeout register values for PF and VFs.
|
||||
Only available for PF.
|
||||
|
||||
What: /sys/kernel/debug/genwqe/genwqe<n>_card/queue_working_time
|
||||
Date: Dec 2013
|
||||
Contact: haver@linux.vnet.ibm.com
|
||||
Description: Dump queue working time register values for PF and VFs.
|
||||
Only available for PF.
|
|
@ -197,6 +197,19 @@ Description:
|
|||
Raw pressure measurement from channel Y. Units after
|
||||
application of scale and offset are kilopascal.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_humidityrelative_raw
|
||||
KernelVersion: 3.14
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Raw humidity measurement of air. Units after application of
|
||||
scale and offset are milli percent.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_humidityrelative_input
|
||||
KernelVersion: 3.14
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Scaled humidity measurement in milli percent.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_accel_offset
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_accel_x_offset
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_accel_y_offset
|
||||
|
|
|
@ -70,18 +70,15 @@ Date: September, 2011
|
|||
Contact: Neil Horman <nhorman@tuxdriver.com>
|
||||
Description:
|
||||
The /sys/devices/.../msi_irqs directory contains a variable set
|
||||
of sub-directories, with each sub-directory being named after a
|
||||
corresponding msi irq vector allocated to that device. Each
|
||||
numbered sub-directory N contains attributes of that irq.
|
||||
Note that this directory is not created for device drivers which
|
||||
do not support msi irqs
|
||||
of files, with each file being named after a corresponding msi
|
||||
irq vector allocated to that device.
|
||||
|
||||
What: /sys/bus/pci/devices/.../msi_irqs/<N>/mode
|
||||
What: /sys/bus/pci/devices/.../msi_irqs/<N>
|
||||
Date: September 2011
|
||||
Contact: Neil Horman <nhorman@tuxdriver.com>
|
||||
Description:
|
||||
This attribute indicates the mode that the irq vector named by
|
||||
the parent directory is in (msi vs. msix)
|
||||
the file is in (msi vs. msix)
|
||||
|
||||
What: /sys/bus/pci/devices/.../remove
|
||||
Date: January 2009
|
||||
|
|
|
@ -18,6 +18,28 @@ Removal of a device:
|
|||
|
||||
$ echo <dev-id> > /sys/bus/rbd/remove
|
||||
|
||||
What: /sys/bus/rbd/add_single_major
|
||||
Date: December 2013
|
||||
KernelVersion: 3.14
|
||||
Contact: Sage Weil <sage@inktank.com>
|
||||
Description: Available only if rbd module is inserted with single_major
|
||||
parameter set to true.
|
||||
Usage is the same as for /sys/bus/rbd/add. If present,
|
||||
should be used instead of the latter: any attempts to use
|
||||
/sys/bus/rbd/add if /sys/bus/rbd/add_single_major is
|
||||
available will fail for backwards compatibility reasons.
|
||||
|
||||
What: /sys/bus/rbd/remove_single_major
|
||||
Date: December 2013
|
||||
KernelVersion: 3.14
|
||||
Contact: Sage Weil <sage@inktank.com>
|
||||
Description: Available only if rbd module is inserted with single_major
|
||||
parameter set to true.
|
||||
Usage is the same as for /sys/bus/rbd/remove. If present,
|
||||
should be used instead of the latter: any attempts to use
|
||||
/sys/bus/rbd/remove if /sys/bus/rbd/remove_single_major is
|
||||
available will fail for backwards compatibility reasons.
|
||||
|
||||
Entries under /sys/bus/rbd/devices/<dev-id>/
|
||||
--------------------------------------------
|
||||
|
||||
|
@ -33,6 +55,10 @@ major
|
|||
|
||||
The block device major number.
|
||||
|
||||
minor
|
||||
|
||||
The block device minor number. (December 2013, since 3.14.)
|
||||
|
||||
name
|
||||
|
||||
The name of the rbd image.
|
||||
|
|
|
@ -50,13 +50,19 @@ Description:
|
|||
This may allow the driver to support more hardware than
|
||||
was included in the driver's static device ID support
|
||||
table at compile time. The format for the device ID is:
|
||||
idVendor idProduct bInterfaceClass.
|
||||
idVendor idProduct bInterfaceClass RefIdVendor RefIdProduct
|
||||
The vendor ID and device ID fields are required, the
|
||||
interface class is optional.
|
||||
rest is optional. The Ref* tuple can be used to tell the
|
||||
driver to use the same driver_data for the new device as
|
||||
it is used for the reference device.
|
||||
Upon successfully adding an ID, the driver will probe
|
||||
for the device and attempt to bind to it. For example:
|
||||
# echo "8086 10f5" > /sys/bus/usb/drivers/foo/new_id
|
||||
|
||||
Here add a new device (0458:7045) using driver_data from
|
||||
an already supported device (0458:704c):
|
||||
# echo "0458 7045 0 0458 704c" > /sys/bus/usb/drivers/foo/new_id
|
||||
|
||||
Reading from this file will list all dynamically added
|
||||
device IDs in the same format, with one entry per
|
||||
line. For example:
|
||||
|
|
|
@ -68,6 +68,14 @@ Description:
|
|||
Defines the penalty which will be applied to an
|
||||
originator message's tq-field on every hop.
|
||||
|
||||
What: /sys/class/net/<mesh_iface>/mesh/isolation_mark
|
||||
Date: Nov 2013
|
||||
Contact: Antonio Quartulli <antonio@meshcoding.com>
|
||||
Description:
|
||||
Defines the isolation mark (and its bitmask) which
|
||||
is used to classify clients as "isolated" by the
|
||||
Extended Isolation feature.
|
||||
|
||||
What: /sys/class/net/<mesh_iface>/mesh/network_coding
|
||||
Date: Nov 2012
|
||||
Contact: Martin Hundeboll <martin@hundeboll.net>
|
||||
|
|
|
@ -200,3 +200,27 @@ Description: address and size of the percpu note.
|
|||
note of cpu#.
|
||||
|
||||
crash_notes_size: size of the note of cpu#.
|
||||
|
||||
|
||||
What: /sys/devices/system/cpu/intel_pstate/max_perf_pct
|
||||
/sys/devices/system/cpu/intel_pstate/min_perf_pct
|
||||
/sys/devices/system/cpu/intel_pstate/no_turbo
|
||||
Date: February 2013
|
||||
Contact: linux-pm@vger.kernel.org
|
||||
Description: Parameters for the Intel P-state driver
|
||||
|
||||
Logic for selecting the current P-state in Intel
|
||||
Sandybridge+ processors. The three knobs control
|
||||
limits for the P-state that will be requested by the
|
||||
driver.
|
||||
|
||||
max_perf_pct: limits the maximum P state that will be requested by
|
||||
the driver stated as a percentage of the available performance.
|
||||
|
||||
min_perf_pct: limits the minimum P state that will be requested by
|
||||
the driver stated as a percentage of the available performance.
|
||||
|
||||
no_turbo: limits the driver to selecting P states below the turbo
|
||||
frequency range.
|
||||
|
||||
More details can be found in Documentation/cpu-freq/intel-pstate.txt
|
||||
|
|
62
Documentation/ABI/testing/sysfs-driver-genwqe
Normal file
62
Documentation/ABI/testing/sysfs-driver-genwqe
Normal file
|
@ -0,0 +1,62 @@
|
|||
What: /sys/class/genwqe/genwqe<n>_card/version
|
||||
Date: Oct 2013
|
||||
Contact: haver@linux.vnet.ibm.com
|
||||
Description: Unique bitstream identification e.g.
|
||||
'0000000330336283.00000000475a4950'.
|
||||
|
||||
What: /sys/class/genwqe/genwqe<n>_card/appid
|
||||
Date: Oct 2013
|
||||
Contact: haver@linux.vnet.ibm.com
|
||||
Description: Identifies the currently active card application e.g. 'GZIP'
|
||||
for compression/decompression.
|
||||
|
||||
What: /sys/class/genwqe/genwqe<n>_card/type
|
||||
Date: Oct 2013
|
||||
Contact: haver@linux.vnet.ibm.com
|
||||
Description: Type of the card e.g. 'GenWQE5-A7'.
|
||||
|
||||
What: /sys/class/genwqe/genwqe<n>_card/curr_bitstream
|
||||
Date: Oct 2013
|
||||
Contact: haver@linux.vnet.ibm.com
|
||||
Description: Currently active bitstream. 1 is default, 0 is backup.
|
||||
|
||||
What: /sys/class/genwqe/genwqe<n>_card/next_bitstream
|
||||
Date: Oct 2013
|
||||
Contact: haver@linux.vnet.ibm.com
|
||||
Description: Interface to set the next bitstream to be used.
|
||||
|
||||
What: /sys/class/genwqe/genwqe<n>_card/tempsens
|
||||
Date: Oct 2013
|
||||
Contact: haver@linux.vnet.ibm.com
|
||||
Description: Interface to read the cards temperature sense register.
|
||||
|
||||
What: /sys/class/genwqe/genwqe<n>_card/freerunning_timer
|
||||
Date: Oct 2013
|
||||
Contact: haver@linux.vnet.ibm.com
|
||||
Description: Interface to read the cards free running timer.
|
||||
Used for performance and utilization measurements.
|
||||
|
||||
What: /sys/class/genwqe/genwqe<n>_card/queue_working_time
|
||||
Date: Oct 2013
|
||||
Contact: haver@linux.vnet.ibm.com
|
||||
Description: Interface to read queue working time.
|
||||
Used for performance and utilization measurements.
|
||||
|
||||
What: /sys/class/genwqe/genwqe<n>_card/state
|
||||
Date: Oct 2013
|
||||
Contact: haver@linux.vnet.ibm.com
|
||||
Description: State of the card: "unused", "used", "error".
|
||||
|
||||
What: /sys/class/genwqe/genwqe<n>_card/base_clock
|
||||
Date: Oct 2013
|
||||
Contact: haver@linux.vnet.ibm.com
|
||||
Description: Base clock frequency of the card.
|
||||
|
||||
What: /sys/class/genwqe/genwqe<n>_card/device/sriov_numvfs
|
||||
Date: Oct 2013
|
||||
Contact: haver@linux.vnet.ibm.com
|
||||
Description: Enable VFs (1..15):
|
||||
sudo sh -c 'echo 15 > \
|
||||
/sys/bus/pci/devices/0000\:1b\:00.0/sriov_numvfs'
|
||||
Disable VFs:
|
||||
Write a 0 into the same sysfs entry.
|
20
Documentation/ABI/testing/sysfs-firmware-efi
Normal file
20
Documentation/ABI/testing/sysfs-firmware-efi
Normal file
|
@ -0,0 +1,20 @@
|
|||
What: /sys/firmware/efi/fw_vendor
|
||||
Date: December 2013
|
||||
Contact: Dave Young <dyoung@redhat.com>
|
||||
Description: It shows the physical address of firmware vendor field in the
|
||||
EFI system table.
|
||||
Users: Kexec
|
||||
|
||||
What: /sys/firmware/efi/runtime
|
||||
Date: December 2013
|
||||
Contact: Dave Young <dyoung@redhat.com>
|
||||
Description: It shows the physical address of runtime service table entry in
|
||||
the EFI system table.
|
||||
Users: Kexec
|
||||
|
||||
What: /sys/firmware/efi/config_table
|
||||
Date: December 2013
|
||||
Contact: Dave Young <dyoung@redhat.com>
|
||||
Description: It shows the physical address of config table entry in the EFI
|
||||
system table.
|
||||
Users: Kexec
|
34
Documentation/ABI/testing/sysfs-firmware-efi-runtime-map
Normal file
34
Documentation/ABI/testing/sysfs-firmware-efi-runtime-map
Normal file
|
@ -0,0 +1,34 @@
|
|||
What: /sys/firmware/efi/runtime-map/
|
||||
Date: December 2013
|
||||
Contact: Dave Young <dyoung@redhat.com>
|
||||
Description: Switching efi runtime services to virtual mode requires
|
||||
that all efi memory ranges which have the runtime attribute
|
||||
bit set to be mapped to virtual addresses.
|
||||
|
||||
The efi runtime services can only be switched to virtual
|
||||
mode once without rebooting. The kexec kernel must maintain
|
||||
the same physical to virtual address mappings as the first
|
||||
kernel. The mappings are exported to sysfs so userspace tools
|
||||
can reassemble them and pass them into the kexec kernel.
|
||||
|
||||
/sys/firmware/efi/runtime-map/ is the directory the kernel
|
||||
exports that information in.
|
||||
|
||||
subdirectories are named with the number of the memory range:
|
||||
|
||||
/sys/firmware/efi/runtime-map/0
|
||||
/sys/firmware/efi/runtime-map/1
|
||||
/sys/firmware/efi/runtime-map/2
|
||||
/sys/firmware/efi/runtime-map/3
|
||||
...
|
||||
|
||||
Each subdirectory contains five files:
|
||||
|
||||
attribute : The attributes of the memory range.
|
||||
num_pages : The size of the memory range in pages.
|
||||
phys_addr : The physical address of the memory range.
|
||||
type : The type of the memory range.
|
||||
virt_addr : The virtual address of the memory range.
|
||||
|
||||
Above values are all hexadecimal numbers with the '0x' prefix.
|
||||
Users: Kexec
|
|
@ -24,3 +24,34 @@ Date: July 2013
|
|||
Contact: "Namjae Jeon" <namjae.jeon@samsung.com>
|
||||
Description:
|
||||
Controls the victim selection policy for garbage collection.
|
||||
|
||||
What: /sys/fs/f2fs/<disk>/reclaim_segments
|
||||
Date: October 2013
|
||||
Contact: "Jaegeuk Kim" <jaegeuk.kim@samsung.com>
|
||||
Description:
|
||||
Controls the issue rate of segment discard commands.
|
||||
|
||||
What: /sys/fs/f2fs/<disk>/ipu_policy
|
||||
Date: November 2013
|
||||
Contact: "Jaegeuk Kim" <jaegeuk.kim@samsung.com>
|
||||
Description:
|
||||
Controls the in-place-update policy.
|
||||
|
||||
What: /sys/fs/f2fs/<disk>/min_ipu_util
|
||||
Date: November 2013
|
||||
Contact: "Jaegeuk Kim" <jaegeuk.kim@samsung.com>
|
||||
Description:
|
||||
Controls the FS utilization condition for the in-place-update
|
||||
policies.
|
||||
|
||||
What: /sys/fs/f2fs/<disk>/max_small_discards
|
||||
Date: November 2013
|
||||
Contact: "Jaegeuk Kim" <jaegeuk.kim@samsung.com>
|
||||
Description:
|
||||
Controls the issue rate of small discard commands.
|
||||
|
||||
What: /sys/fs/f2fs/<disk>/max_victim_search
|
||||
Date: January 2014
|
||||
Contact: "Jaegeuk Kim" <jaegeuk.kim@samsung.com>
|
||||
Description:
|
||||
Controls the number of trials to find a victim segment.
|
||||
|
|
38
Documentation/ABI/testing/sysfs-kernel-boot_params
Normal file
38
Documentation/ABI/testing/sysfs-kernel-boot_params
Normal file
|
@ -0,0 +1,38 @@
|
|||
What: /sys/kernel/boot_params
|
||||
Date: December 2013
|
||||
Contact: Dave Young <dyoung@redhat.com>
|
||||
Description: The /sys/kernel/boot_params directory contains two
|
||||
files: "data" and "version" and one subdirectory "setup_data".
|
||||
It is used to export the kernel boot parameters of an x86
|
||||
platform to userspace for kexec and debugging purpose.
|
||||
|
||||
If there's no setup_data in boot_params the subdirectory will
|
||||
not be created.
|
||||
|
||||
"data" file is the binary representation of struct boot_params.
|
||||
|
||||
"version" file is the string representation of boot
|
||||
protocol version.
|
||||
|
||||
"setup_data" subdirectory contains the setup_data data
|
||||
structure in boot_params. setup_data is maintained in kernel
|
||||
as a link list. In "setup_data" subdirectory there's one
|
||||
subdirectory for each link list node named with the number
|
||||
of the list nodes. The list node subdirectory contains two
|
||||
files "type" and "data". "type" file is the string
|
||||
representation of setup_data type. "data" file is the binary
|
||||
representation of setup_data payload.
|
||||
|
||||
The whole boot_params directory structure is like below:
|
||||
/sys/kernel/boot_params
|
||||
|__ data
|
||||
|__ setup_data
|
||||
| |__ 0
|
||||
| | |__ data
|
||||
| | |__ type
|
||||
| |__ 1
|
||||
| |__ data
|
||||
| |__ type
|
||||
|__ version
|
||||
|
||||
Users: Kexec
|
14
Documentation/ABI/testing/sysfs-kernel-vmcoreinfo
Normal file
14
Documentation/ABI/testing/sysfs-kernel-vmcoreinfo
Normal file
|
@ -0,0 +1,14 @@
|
|||
What: /sys/kernel/vmcoreinfo
|
||||
Date: October 2007
|
||||
KernelVersion: 2.6.24
|
||||
Contact: Ken'ichi Ohmichi <oomichi@mxs.nes.nec.co.jp>
|
||||
Kexec Mailing List <kexec@lists.infradead.org>
|
||||
Vivek Goyal <vgoyal@redhat.com>
|
||||
Description
|
||||
Shows physical address and size of vmcoreinfo ELF note.
|
||||
First value contains physical address of note in hex and
|
||||
second value contains the size of note in hex. This ELF
|
||||
note info is parsed by second kernel and exported to user
|
||||
space as part of ELF note in /proc/vmcore file. This note
|
||||
contains various information like struct size, symbol
|
||||
values, page size etc.
|
16
Documentation/ABI/testing/sysfs-platform-tahvo-usb
Normal file
16
Documentation/ABI/testing/sysfs-platform-tahvo-usb
Normal file
|
@ -0,0 +1,16 @@
|
|||
What: /sys/bus/platform/devices/tahvo-usb/otg_mode
|
||||
Date: December 2013
|
||||
Contact: Aaro Koskinen <aaro.koskinen@iki.fi>
|
||||
Description:
|
||||
Set or read the current OTG mode. Valid values are "host" and
|
||||
"peripheral".
|
||||
|
||||
Reading: returns the current mode.
|
||||
|
||||
What: /sys/bus/platform/devices/tahvo-usb/vbus
|
||||
Date: December 2013
|
||||
Contact: Aaro Koskinen <aaro.koskinen@iki.fi>
|
||||
Description:
|
||||
Read the current VBUS state.
|
||||
|
||||
Reading: returns "on" or "off".
|
1
Documentation/DocBook/.gitignore
vendored
1
Documentation/DocBook/.gitignore
vendored
|
@ -10,5 +10,6 @@
|
|||
*.out
|
||||
*.png
|
||||
*.gif
|
||||
*.svg
|
||||
media-indices.tmpl
|
||||
media-entities.tmpl
|
||||
|
|
|
@ -54,6 +54,7 @@ htmldocs: $(HTML)
|
|||
|
||||
MAN := $(patsubst %.xml, %.9, $(BOOKS))
|
||||
mandocs: $(MAN)
|
||||
$(if $(wildcard $(obj)/man/*.9),gzip -f $(obj)/man/*.9)
|
||||
|
||||
installmandocs: mandocs
|
||||
mkdir -p /usr/local/man/man9/
|
||||
|
@ -145,7 +146,7 @@ build_main_index = rm -rf $(main_idx); \
|
|||
cat $(HTML) >> $(main_idx)
|
||||
|
||||
quiet_cmd_db2html = HTML $@
|
||||
cmd_db2html = xmlto xhtml $(XMLTOFLAGS) -o $(patsubst %.html,%,$@) $< && \
|
||||
cmd_db2html = xmlto html $(XMLTOFLAGS) -o $(patsubst %.html,%,$@) $< && \
|
||||
echo '<a HREF="$(patsubst %.html,%,$(notdir $@))/index.html"> \
|
||||
$(patsubst %.html,%,$(notdir $@))</a><p>' > $@
|
||||
|
||||
|
@ -159,7 +160,7 @@ quiet_cmd_db2html = HTML $@
|
|||
cp $(PNG-$(basename $(notdir $@))) $(patsubst %.html,%,$@); fi
|
||||
|
||||
quiet_cmd_db2man = MAN $@
|
||||
cmd_db2man = if grep -q refentry $<; then xmlto man $(XMLTOFLAGS) -o $(obj)/man $< ; gzip -f $(obj)/man/*.9; fi
|
||||
cmd_db2man = if grep -q refentry $<; then xmlto man $(XMLTOFLAGS) -o $(obj)/man $< ; fi
|
||||
%.9 : %.xml
|
||||
@(which xmlto > /dev/null 2>&1) || \
|
||||
(echo "*** You need to install xmlto ***"; \
|
||||
|
|
|
@ -109,6 +109,7 @@ X!Ilib/string.c
|
|||
<sect1><title>The Slab Cache</title>
|
||||
!Iinclude/linux/slab.h
|
||||
!Emm/slab.c
|
||||
!Emm/util.c
|
||||
</sect1>
|
||||
<sect1><title>User Space Memory Access</title>
|
||||
!Iarch/x86/include/asm/uaccess_32.h
|
||||
|
|
|
@ -2523,6 +2523,18 @@ that used it. It was originally scheduled for removal in 2.6.35.
|
|||
</orderedlist>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>V4L2 in Linux 3.14</title>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para> In struct <structname>v4l2_rect</structname>, the type
|
||||
of <structfield>width</structfield> and <structfield>height</structfield>
|
||||
fields changed from _s32 to _u32.
|
||||
</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</section>
|
||||
|
||||
<section id="other">
|
||||
<title>Relation of V4L2 to other Linux multimedia APIs</title>
|
||||
|
||||
|
|
|
@ -3161,6 +3161,47 @@ V4L2_CID_MPEG_VIDEO_VPX_GOLDEN_FRAME_REF_PERIOD as a golden frame.</entry>
|
|||
</entrytbl>
|
||||
</row>
|
||||
|
||||
<row><entry></entry></row>
|
||||
<row>
|
||||
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_VPX_MIN_QP</constant></entry>
|
||||
<entry>integer</entry>
|
||||
</row>
|
||||
<row><entry spanname="descr">Minimum quantization parameter for VP8.</entry>
|
||||
</row>
|
||||
|
||||
<row><entry></entry></row>
|
||||
<row>
|
||||
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_VPX_MAX_QP</constant></entry>
|
||||
<entry>integer</entry>
|
||||
</row>
|
||||
<row><entry spanname="descr">Maximum quantization parameter for VP8.</entry>
|
||||
</row>
|
||||
|
||||
<row><entry></entry></row>
|
||||
<row>
|
||||
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_VPX_I_FRAME_QP</constant> </entry>
|
||||
<entry>integer</entry>
|
||||
</row>
|
||||
<row><entry spanname="descr">Quantization parameter for an I frame for VP8.</entry>
|
||||
</row>
|
||||
|
||||
<row><entry></entry></row>
|
||||
<row>
|
||||
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_VPX_P_FRAME_QP</constant> </entry>
|
||||
<entry>integer</entry>
|
||||
</row>
|
||||
<row><entry spanname="descr">Quantization parameter for a P frame for VP8.</entry>
|
||||
</row>
|
||||
|
||||
<row><entry></entry></row>
|
||||
<row>
|
||||
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_VPX_PROFILE</constant> </entry>
|
||||
<entry>integer</entry>
|
||||
</row>
|
||||
<row><entry spanname="descr">Select the desired profile for VPx encoder.
|
||||
Acceptable values are 0, 1, 2 and 3 corresponding to encoder profiles 0, 1, 2 and 3.</entry>
|
||||
</row>
|
||||
|
||||
<row><entry></entry></row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
|
|
|
@ -346,17 +346,14 @@ rectangle, in pixels.</entry>
|
|||
rectangle, in pixels. Offsets increase to the right and down.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__s32</entry>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>width</structfield></entry>
|
||||
<entry>Width of the rectangle, in pixels.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__s32</entry>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>height</structfield></entry>
|
||||
<entry>Height of the rectangle, in pixels. Width and
|
||||
height cannot be negative, the fields are signed for hysterical
|
||||
reasons. <!-- video4linux-list@redhat.com on 22 Oct 2002 subject
|
||||
"Re:[V4L][patches!] Re:v4l2/kernel-2.5" --></entry>
|
||||
<entry>Height of the rectangle, in pixels.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
|
|
|
@ -134,6 +134,15 @@
|
|||
<entry>Output pad, relative to the entity. Output pads source data
|
||||
and are origins of links.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>MEDIA_PAD_FL_MUST_CONNECT</constant></entry>
|
||||
<entry>If this flag is set and the pad is linked to any other
|
||||
pad, then at least one of those links must be enabled for the
|
||||
entity to be able to stream. There could be temporary reasons
|
||||
(e.g. device configuration dependent) for the pad to need
|
||||
enabled links even when this flag isn't set; the absence of the
|
||||
flag doesn't imply there is none.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
|
|
|
@ -89,7 +89,7 @@
|
|||
<constant>V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE</constant>.
|
||||
</para>
|
||||
|
||||
<para>The following tables list existing packet RGB formats.</para>
|
||||
<para>The following tables list existing packed RGB formats.</para>
|
||||
|
||||
<table pgwide="0" frame="none" id="v4l2-mbus-pixelcode-rgb">
|
||||
<title>RGB formats</title>
|
||||
|
@ -615,7 +615,7 @@
|
|||
</mediaobject>
|
||||
</figure>
|
||||
|
||||
<para>The following table lists existing packet Bayer formats. The data
|
||||
<para>The following table lists existing packed Bayer formats. The data
|
||||
organization is given as an example for the first pixel only.</para>
|
||||
|
||||
<table pgwide="0" frame="none" id="v4l2-mbus-pixelcode-bayer">
|
||||
|
@ -1178,7 +1178,7 @@
|
|||
U, Y, V, Y order will be named <constant>V4L2_MBUS_FMT_UYVY8_2X8</constant>.
|
||||
</para>
|
||||
|
||||
<para><xref linkend="v4l2-mbus-pixelcode-yuv8"/> list existing packet YUV
|
||||
<para><xref linkend="v4l2-mbus-pixelcode-yuv8"/> lists existing packed YUV
|
||||
formats and describes the organization of each pixel data in each sample.
|
||||
When a format pattern is split across multiple samples each of the samples
|
||||
in the pattern is described.</para>
|
||||
|
@ -2491,6 +2491,163 @@
|
|||
</table>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>HSV/HSL Formats</title>
|
||||
|
||||
<para>Those formats transfer pixel data as RGB values in a cylindrical-coordinate
|
||||
system using Hue-Saturation-Value or Hue-Saturation-Lightness components. The
|
||||
format code is made of the following information.
|
||||
<itemizedlist>
|
||||
<listitem><para>The hue, saturation, value or lightness and optional alpha
|
||||
components order code, as encoded in a pixel sample. The only currently
|
||||
supported value is AHSV.
|
||||
</para></listitem>
|
||||
<listitem><para>The number of bits per component, for each component. The values
|
||||
can be different for all components. The only currently supported value is 8888.
|
||||
</para></listitem>
|
||||
<listitem><para>The number of bus samples per pixel. Pixels that are wider than
|
||||
the bus width must be transferred in multiple samples. The only currently
|
||||
supported value is 1.</para></listitem>
|
||||
<listitem><para>The bus width.</para></listitem>
|
||||
<listitem><para>For formats where the total number of bits per pixel is smaller
|
||||
than the number of bus samples per pixel times the bus width, a padding
|
||||
value stating if the bytes are padded in their most high order bits
|
||||
(PADHI) or low order bits (PADLO).</para></listitem>
|
||||
<listitem><para>For formats where the number of bus samples per pixel is larger
|
||||
than 1, an endianness value stating if the pixel is transferred MSB first
|
||||
(BE) or LSB first (LE).</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
|
||||
<para>The following table lists existing HSV/HSL formats.</para>
|
||||
|
||||
<table pgwide="0" frame="none" id="v4l2-mbus-pixelcode-hsv">
|
||||
<title>HSV/HSL formats</title>
|
||||
<tgroup cols="27">
|
||||
<colspec colname="id" align="left" />
|
||||
<colspec colname="code" align="center"/>
|
||||
<colspec colname="bit" />
|
||||
<colspec colnum="4" colname="b31" align="center" />
|
||||
<colspec colnum="5" colname="b20" align="center" />
|
||||
<colspec colnum="6" colname="b29" align="center" />
|
||||
<colspec colnum="7" colname="b28" align="center" />
|
||||
<colspec colnum="8" colname="b27" align="center" />
|
||||
<colspec colnum="9" colname="b26" align="center" />
|
||||
<colspec colnum="10" colname="b25" align="center" />
|
||||
<colspec colnum="11" colname="b24" align="center" />
|
||||
<colspec colnum="12" colname="b23" align="center" />
|
||||
<colspec colnum="13" colname="b22" align="center" />
|
||||
<colspec colnum="14" colname="b21" align="center" />
|
||||
<colspec colnum="15" colname="b20" align="center" />
|
||||
<colspec colnum="16" colname="b19" align="center" />
|
||||
<colspec colnum="17" colname="b18" align="center" />
|
||||
<colspec colnum="18" colname="b17" align="center" />
|
||||
<colspec colnum="19" colname="b16" align="center" />
|
||||
<colspec colnum="20" colname="b15" align="center" />
|
||||
<colspec colnum="21" colname="b14" align="center" />
|
||||
<colspec colnum="22" colname="b13" align="center" />
|
||||
<colspec colnum="23" colname="b12" align="center" />
|
||||
<colspec colnum="24" colname="b11" align="center" />
|
||||
<colspec colnum="25" colname="b10" align="center" />
|
||||
<colspec colnum="26" colname="b09" align="center" />
|
||||
<colspec colnum="27" colname="b08" align="center" />
|
||||
<colspec colnum="28" colname="b07" align="center" />
|
||||
<colspec colnum="29" colname="b06" align="center" />
|
||||
<colspec colnum="30" colname="b05" align="center" />
|
||||
<colspec colnum="31" colname="b04" align="center" />
|
||||
<colspec colnum="32" colname="b03" align="center" />
|
||||
<colspec colnum="33" colname="b02" align="center" />
|
||||
<colspec colnum="34" colname="b01" align="center" />
|
||||
<colspec colnum="35" colname="b00" align="center" />
|
||||
<spanspec namest="b31" nameend="b00" spanname="b0" />
|
||||
<thead>
|
||||
<row>
|
||||
<entry>Identifier</entry>
|
||||
<entry>Code</entry>
|
||||
<entry></entry>
|
||||
<entry spanname="b0">Data organization</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry>Bit</entry>
|
||||
<entry>31</entry>
|
||||
<entry>30</entry>
|
||||
<entry>29</entry>
|
||||
<entry>28</entry>
|
||||
<entry>27</entry>
|
||||
<entry>26</entry>
|
||||
<entry>25</entry>
|
||||
<entry>24</entry>
|
||||
<entry>23</entry>
|
||||
<entry>22</entry>
|
||||
<entry>21</entry>
|
||||
<entry>20</entry>
|
||||
<entry>19</entry>
|
||||
<entry>18</entry>
|
||||
<entry>17</entry>
|
||||
<entry>16</entry>
|
||||
<entry>15</entry>
|
||||
<entry>14</entry>
|
||||
<entry>13</entry>
|
||||
<entry>12</entry>
|
||||
<entry>11</entry>
|
||||
<entry>10</entry>
|
||||
<entry>9</entry>
|
||||
<entry>8</entry>
|
||||
<entry>7</entry>
|
||||
<entry>6</entry>
|
||||
<entry>5</entry>
|
||||
<entry>4</entry>
|
||||
<entry>3</entry>
|
||||
<entry>2</entry>
|
||||
<entry>1</entry>
|
||||
<entry>0</entry>
|
||||
</row>
|
||||
</thead>
|
||||
<tbody valign="top">
|
||||
<row id="V4L2-MBUS-FMT-AHSV8888-1X32">
|
||||
<entry>V4L2_MBUS_FMT_AHSV8888_1X32</entry>
|
||||
<entry>0x6001</entry>
|
||||
<entry></entry>
|
||||
<entry>a<subscript>7</subscript></entry>
|
||||
<entry>a<subscript>6</subscript></entry>
|
||||
<entry>a<subscript>5</subscript></entry>
|
||||
<entry>a<subscript>4</subscript></entry>
|
||||
<entry>a<subscript>3</subscript></entry>
|
||||
<entry>a<subscript>2</subscript></entry>
|
||||
<entry>a<subscript>1</subscript></entry>
|
||||
<entry>a<subscript>0</subscript></entry>
|
||||
<entry>h<subscript>7</subscript></entry>
|
||||
<entry>h<subscript>6</subscript></entry>
|
||||
<entry>h<subscript>5</subscript></entry>
|
||||
<entry>h<subscript>4</subscript></entry>
|
||||
<entry>h<subscript>3</subscript></entry>
|
||||
<entry>h<subscript>2</subscript></entry>
|
||||
<entry>h<subscript>1</subscript></entry>
|
||||
<entry>h<subscript>0</subscript></entry>
|
||||
<entry>s<subscript>7</subscript></entry>
|
||||
<entry>s<subscript>6</subscript></entry>
|
||||
<entry>s<subscript>5</subscript></entry>
|
||||
<entry>s<subscript>4</subscript></entry>
|
||||
<entry>s<subscript>3</subscript></entry>
|
||||
<entry>s<subscript>2</subscript></entry>
|
||||
<entry>s<subscript>1</subscript></entry>
|
||||
<entry>s<subscript>0</subscript></entry>
|
||||
<entry>v<subscript>7</subscript></entry>
|
||||
<entry>v<subscript>6</subscript></entry>
|
||||
<entry>v<subscript>5</subscript></entry>
|
||||
<entry>v<subscript>4</subscript></entry>
|
||||
<entry>v<subscript>3</subscript></entry>
|
||||
<entry>v<subscript>2</subscript></entry>
|
||||
<entry>v<subscript>1</subscript></entry>
|
||||
<entry>v<subscript>0</subscript></entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>JPEG Compressed Formats</title>
|
||||
|
||||
|
|
|
@ -140,6 +140,14 @@ 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.14</revnumber>
|
||||
<date>2013-11-25</date>
|
||||
<authorinitials>rr</authorinitials>
|
||||
<revremark>Set width and height as unsigned on v4l2_rect.
|
||||
</revremark>
|
||||
</revision>
|
||||
|
||||
<revision>
|
||||
<revnumber>3.11</revnumber>
|
||||
<date>2013-05-26</date>
|
||||
|
@ -501,7 +509,7 @@ and discussions on the V4L mailing list.</revremark>
|
|||
</partinfo>
|
||||
|
||||
<title>Video for Linux Two API Specification</title>
|
||||
<subtitle>Revision 3.11</subtitle>
|
||||
<subtitle>Revision 3.14</subtitle>
|
||||
|
||||
<chapter id="common">
|
||||
&sub-common;
|
||||
|
|
|
@ -133,18 +133,14 @@ rectangle, in pixels.</entry>
|
|||
rectangle, in pixels.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__s32</entry>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>width</structfield></entry>
|
||||
<entry>Width of the rectangle, in pixels.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__s32</entry>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>height</structfield></entry>
|
||||
<entry>Height of the rectangle, in pixels. Width
|
||||
and height cannot be negative, the fields are signed for
|
||||
hysterical reasons. <!-- video4linux-list@redhat.com
|
||||
on 22 Oct 2002 subject "Re:[V4L][patches!] Re:v4l2/kernel-2.5" -->
|
||||
</entry>
|
||||
<entry>Height of the rectangle, in pixels.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
|
|
|
@ -59,7 +59,7 @@ buffers are filled (if there are any empty buffers in the incoming
|
|||
queue) until <constant>VIDIOC_STREAMON</constant> has been called.
|
||||
Accordingly the output hardware is disabled, no video signal is
|
||||
produced until <constant>VIDIOC_STREAMON</constant> has been called.
|
||||
The ioctl will succeed only when at least one output buffer is in the
|
||||
The ioctl will succeed when at least one output buffer is in the
|
||||
incoming queue.</para>
|
||||
|
||||
<para>The <constant>VIDIOC_STREAMOFF</constant> ioctl, apart of
|
||||
|
|
|
@ -112,7 +112,7 @@ required reading:
|
|||
|
||||
Other excellent descriptions of how to create patches properly are:
|
||||
"The Perfect Patch"
|
||||
http://kerneltrap.org/node/3737
|
||||
http://www.ozlabs.org/~akpm/stuff/tpp.txt
|
||||
"Linux kernel patch submission format"
|
||||
http://linux.yyz.us/patch-format.html
|
||||
|
||||
|
@ -579,7 +579,7 @@ all time. It should describe the patch completely, containing:
|
|||
For more details on what this should all look like, please see the
|
||||
ChangeLog section of the document:
|
||||
"The Perfect Patch"
|
||||
http://userweb.kernel.org/~akpm/stuff/tpp.txt
|
||||
http://www.ozlabs.org/~akpm/stuff/tpp.txt
|
||||
|
||||
|
||||
|
||||
|
|
|
@ -141,7 +141,7 @@ will use a legacy domain only if an IRQ range is supplied by the
|
|||
system and will otherwise use a linear domain mapping. The semantics
|
||||
of this call are such that if an IRQ range is specified then
|
||||
descriptors will be allocated on-the-fly for it, and if no range is
|
||||
specified it will fall through to irq_domain_add_linear() which meand
|
||||
specified it will fall through to irq_domain_add_linear() which means
|
||||
*no* irq descriptors will be allocated.
|
||||
|
||||
A typical use case for simple domains is where an irqchip provider
|
||||
|
|
|
@ -2,12 +2,12 @@
|
|||
- this file
|
||||
MSI-HOWTO.txt
|
||||
- the Message Signaled Interrupts (MSI) Driver Guide HOWTO and FAQ.
|
||||
PCI-DMA-mapping.txt
|
||||
- info for PCI drivers using DMA portably across all platforms
|
||||
PCIEBUS-HOWTO.txt
|
||||
- a guide describing the PCI Express Port Bus driver
|
||||
pci-error-recovery.txt
|
||||
- info on PCI error recovery
|
||||
pci-iov-howto.txt
|
||||
- the PCI Express I/O Virtualization HOWTO
|
||||
pci.txt
|
||||
- info on the PCI subsystem for device driver authors
|
||||
pcieaer-howto.txt
|
||||
|
|
|
@ -94,81 +94,136 @@ consequently, this function should be called before the driver calls
|
|||
request_irq(), because an MSI is delivered via a vector that is
|
||||
different from the vector of a pin-based interrupt.
|
||||
|
||||
4.2.2 pci_enable_msi_block
|
||||
4.2.2 pci_enable_msi_range
|
||||
|
||||
int pci_enable_msi_block(struct pci_dev *dev, int count)
|
||||
int pci_enable_msi_range(struct pci_dev *dev, int minvec, int maxvec)
|
||||
|
||||
This variation on the above call allows a device driver to request multiple
|
||||
MSIs. The MSI specification only allows interrupts to be allocated in
|
||||
powers of two, up to a maximum of 2^5 (32).
|
||||
This function allows a device driver to request any number of MSI
|
||||
interrupts within specified range from 'minvec' to 'maxvec'.
|
||||
|
||||
If this function returns 0, it has succeeded in allocating at least as many
|
||||
interrupts as the driver requested (it may have allocated more in order
|
||||
to satisfy the power-of-two requirement). In this case, the function
|
||||
enables MSI on this device and updates dev->irq to be the lowest of
|
||||
the new interrupts assigned to it. The other interrupts assigned to
|
||||
the device are in the range dev->irq to dev->irq + count - 1.
|
||||
|
||||
If this function returns a negative number, it indicates an error and
|
||||
the driver should not attempt to request any more MSI interrupts for
|
||||
this device. If this function returns a positive number, it is
|
||||
less than 'count' and indicates the number of interrupts that could have
|
||||
been allocated. In neither case is the irq value updated or the device
|
||||
switched into MSI mode.
|
||||
|
||||
The device driver must decide what action to take if
|
||||
pci_enable_msi_block() returns a value less than the number requested.
|
||||
For instance, the driver could still make use of fewer interrupts;
|
||||
in this case the driver should call pci_enable_msi_block()
|
||||
again. Note that it is not guaranteed to succeed, even when the
|
||||
'count' has been reduced to the value returned from a previous call to
|
||||
pci_enable_msi_block(). This is because there are multiple constraints
|
||||
on the number of vectors that can be allocated; pci_enable_msi_block()
|
||||
returns as soon as it finds any constraint that doesn't allow the
|
||||
call to succeed.
|
||||
|
||||
4.2.3 pci_enable_msi_block_auto
|
||||
|
||||
int pci_enable_msi_block_auto(struct pci_dev *dev, unsigned int *count)
|
||||
|
||||
This variation on pci_enable_msi() call allows a device driver to request
|
||||
the maximum possible number of MSIs. The MSI specification only allows
|
||||
interrupts to be allocated in powers of two, up to a maximum of 2^5 (32).
|
||||
|
||||
If this function returns a positive number, it indicates that it has
|
||||
succeeded and the returned value is the number of allocated interrupts. In
|
||||
this case, the function enables MSI on this device and updates dev->irq to
|
||||
be the lowest of the new interrupts assigned to it. The other interrupts
|
||||
assigned to the device are in the range dev->irq to dev->irq + returned
|
||||
value - 1.
|
||||
If this function returns a positive number it indicates the number of
|
||||
MSI interrupts that have been successfully allocated. In this case
|
||||
the device is switched from pin-based interrupt mode to MSI mode and
|
||||
updates dev->irq to be the lowest of the new interrupts assigned to it.
|
||||
The other interrupts assigned to the device are in the range dev->irq
|
||||
to dev->irq + returned value - 1. Device driver can use the returned
|
||||
number of successfully allocated MSI interrupts to further allocate
|
||||
and initialize device resources.
|
||||
|
||||
If this function returns a negative number, it indicates an error and
|
||||
the driver should not attempt to request any more MSI interrupts for
|
||||
this device.
|
||||
|
||||
If the device driver needs to know the number of interrupts the device
|
||||
supports it can pass the pointer count where that number is stored. The
|
||||
device driver must decide what action to take if pci_enable_msi_block_auto()
|
||||
succeeds, but returns a value less than the number of interrupts supported.
|
||||
If the device driver does not need to know the number of interrupts
|
||||
supported, it can set the pointer count to NULL.
|
||||
This function should be called before the driver calls request_irq(),
|
||||
because MSI interrupts are delivered via vectors that are different
|
||||
from the vector of a pin-based interrupt.
|
||||
|
||||
It is ideal if drivers can cope with a variable number of MSI interrupts;
|
||||
there are many reasons why the platform may not be able to provide the
|
||||
exact number that a driver asks for.
|
||||
|
||||
There could be devices that can not operate with just any number of MSI
|
||||
interrupts within a range. See chapter 4.3.1.3 to get the idea how to
|
||||
handle such devices for MSI-X - the same logic applies to MSI.
|
||||
|
||||
4.2.1.1 Maximum possible number of MSI interrupts
|
||||
|
||||
The typical usage of MSI interrupts is to allocate as many vectors as
|
||||
possible, likely up to the limit returned by pci_msi_vec_count() function:
|
||||
|
||||
static int foo_driver_enable_msi(struct pci_dev *pdev, int nvec)
|
||||
{
|
||||
return pci_enable_msi_range(pdev, 1, nvec);
|
||||
}
|
||||
|
||||
Note the value of 'minvec' parameter is 1. As 'minvec' is inclusive,
|
||||
the value of 0 would be meaningless and could result in error.
|
||||
|
||||
Some devices have a minimal limit on number of MSI interrupts.
|
||||
In this case the function could look like this:
|
||||
|
||||
static int foo_driver_enable_msi(struct pci_dev *pdev, int nvec)
|
||||
{
|
||||
return pci_enable_msi_range(pdev, FOO_DRIVER_MINIMUM_NVEC, nvec);
|
||||
}
|
||||
|
||||
4.2.1.2 Exact number of MSI interrupts
|
||||
|
||||
If a driver is unable or unwilling to deal with a variable number of MSI
|
||||
interrupts it could request a particular number of interrupts by passing
|
||||
that number to pci_enable_msi_range() function as both 'minvec' and 'maxvec'
|
||||
parameters:
|
||||
|
||||
static int foo_driver_enable_msi(struct pci_dev *pdev, int nvec)
|
||||
{
|
||||
return pci_enable_msi_range(pdev, nvec, nvec);
|
||||
}
|
||||
|
||||
Note, unlike pci_enable_msi_exact() function, which could be also used to
|
||||
enable a particular number of MSI-X interrupts, pci_enable_msi_range()
|
||||
returns either a negative errno or 'nvec' (not negative errno or 0 - as
|
||||
pci_enable_msi_exact() does).
|
||||
|
||||
4.2.1.3 Single MSI mode
|
||||
|
||||
The most notorious example of the request type described above is
|
||||
enabling the single MSI mode for a device. It could be done by passing
|
||||
two 1s as 'minvec' and 'maxvec':
|
||||
|
||||
static int foo_driver_enable_single_msi(struct pci_dev *pdev)
|
||||
{
|
||||
return pci_enable_msi_range(pdev, 1, 1);
|
||||
}
|
||||
|
||||
Note, unlike pci_enable_msi() function, which could be also used to
|
||||
enable the single MSI mode, pci_enable_msi_range() returns either a
|
||||
negative errno or 1 (not negative errno or 0 - as pci_enable_msi()
|
||||
does).
|
||||
|
||||
4.2.3 pci_enable_msi_exact
|
||||
|
||||
int pci_enable_msi_exact(struct pci_dev *dev, int nvec)
|
||||
|
||||
This variation on pci_enable_msi_range() call allows a device driver to
|
||||
request exactly 'nvec' MSIs.
|
||||
|
||||
If this function returns a negative number, it indicates an error and
|
||||
the driver should not attempt to request any more MSI interrupts for
|
||||
this device.
|
||||
|
||||
By contrast with pci_enable_msi_range() function, pci_enable_msi_exact()
|
||||
returns zero in case of success, which indicates MSI interrupts have been
|
||||
successfully allocated.
|
||||
|
||||
4.2.4 pci_disable_msi
|
||||
|
||||
void pci_disable_msi(struct pci_dev *dev)
|
||||
|
||||
This function should be used to undo the effect of pci_enable_msi() or
|
||||
pci_enable_msi_block() or pci_enable_msi_block_auto(). Calling it restores
|
||||
dev->irq to the pin-based interrupt number and frees the previously
|
||||
allocated message signaled interrupt(s). The interrupt may subsequently be
|
||||
assigned to another device, so drivers should not cache the value of
|
||||
dev->irq.
|
||||
This function should be used to undo the effect of pci_enable_msi_range().
|
||||
Calling it restores dev->irq to the pin-based interrupt number and frees
|
||||
the previously allocated MSIs. The interrupts may subsequently be assigned
|
||||
to another device, so drivers should not cache the value of dev->irq.
|
||||
|
||||
Before calling this function, a device driver must always call free_irq()
|
||||
on any interrupt for which it previously called request_irq().
|
||||
Failure to do so results in a BUG_ON(), leaving the device with
|
||||
MSI enabled and thus leaking its vector.
|
||||
|
||||
4.2.4 pci_msi_vec_count
|
||||
|
||||
int pci_msi_vec_count(struct pci_dev *dev)
|
||||
|
||||
This function could be used to retrieve the number of MSI vectors the
|
||||
device requested (via the Multiple Message Capable register). The MSI
|
||||
specification only allows the returned value to be a power of two,
|
||||
up to a maximum of 2^5 (32).
|
||||
|
||||
If this function returns a negative number, it indicates the device is
|
||||
not capable of sending MSIs.
|
||||
|
||||
If this function returns a positive number, it indicates the maximum
|
||||
number of MSI interrupt vectors that could be allocated.
|
||||
|
||||
4.3 Using MSI-X
|
||||
|
||||
The MSI-X capability is much more flexible than the MSI capability.
|
||||
|
@ -188,26 +243,31 @@ in each element of the array to indicate for which entries the kernel
|
|||
should assign interrupts; it is invalid to fill in two entries with the
|
||||
same number.
|
||||
|
||||
4.3.1 pci_enable_msix
|
||||
4.3.1 pci_enable_msix_range
|
||||
|
||||
int pci_enable_msix(struct pci_dev *dev, struct msix_entry *entries, int nvec)
|
||||
int pci_enable_msix_range(struct pci_dev *dev, struct msix_entry *entries,
|
||||
int minvec, int maxvec)
|
||||
|
||||
Calling this function asks the PCI subsystem to allocate 'nvec' MSIs.
|
||||
Calling this function asks the PCI subsystem to allocate any number of
|
||||
MSI-X interrupts within specified range from 'minvec' to 'maxvec'.
|
||||
The 'entries' argument is a pointer to an array of msix_entry structs
|
||||
which should be at least 'nvec' entries in size. On success, the
|
||||
device is switched into MSI-X mode and the function returns 0.
|
||||
The 'vector' member in each entry is populated with the interrupt number;
|
||||
which should be at least 'maxvec' entries in size.
|
||||
|
||||
On success, the device is switched into MSI-X mode and the function
|
||||
returns the number of MSI-X interrupts that have been successfully
|
||||
allocated. In this case the 'vector' member in entries numbered from
|
||||
0 to the returned value - 1 is populated with the interrupt number;
|
||||
the driver should then call request_irq() for each 'vector' that it
|
||||
decides to use. The device driver is responsible for keeping track of the
|
||||
interrupts assigned to the MSI-X vectors so it can free them again later.
|
||||
Device driver can use the returned number of successfully allocated MSI-X
|
||||
interrupts to further allocate and initialize device resources.
|
||||
|
||||
If this function returns a negative number, it indicates an error and
|
||||
the driver should not attempt to allocate any more MSI-X interrupts for
|
||||
this device. If it returns a positive number, it indicates the maximum
|
||||
number of interrupt vectors that could have been allocated. See example
|
||||
below.
|
||||
this device.
|
||||
|
||||
This function, in contrast with pci_enable_msi(), does not adjust
|
||||
This function, in contrast with pci_enable_msi_range(), does not adjust
|
||||
dev->irq. The device will not generate interrupts for this interrupt
|
||||
number once MSI-X is enabled.
|
||||
|
||||
|
@ -218,28 +278,165 @@ It is ideal if drivers can cope with a variable number of MSI-X interrupts;
|
|||
there are many reasons why the platform may not be able to provide the
|
||||
exact number that a driver asks for.
|
||||
|
||||
A request loop to achieve that might look like:
|
||||
There could be devices that can not operate with just any number of MSI-X
|
||||
interrupts within a range. E.g., an network adapter might need let's say
|
||||
four vectors per each queue it provides. Therefore, a number of MSI-X
|
||||
interrupts allocated should be a multiple of four. In this case interface
|
||||
pci_enable_msix_range() can not be used alone to request MSI-X interrupts
|
||||
(since it can allocate any number within the range, without any notion of
|
||||
the multiple of four) and the device driver should master a custom logic
|
||||
to request the required number of MSI-X interrupts.
|
||||
|
||||
4.3.1.1 Maximum possible number of MSI-X interrupts
|
||||
|
||||
The typical usage of MSI-X interrupts is to allocate as many vectors as
|
||||
possible, likely up to the limit returned by pci_msix_vec_count() function:
|
||||
|
||||
static int foo_driver_enable_msix(struct foo_adapter *adapter, int nvec)
|
||||
{
|
||||
while (nvec >= FOO_DRIVER_MINIMUM_NVEC) {
|
||||
rc = pci_enable_msix(adapter->pdev,
|
||||
adapter->msix_entries, nvec);
|
||||
if (rc > 0)
|
||||
nvec = rc;
|
||||
else
|
||||
return rc;
|
||||
}
|
||||
|
||||
return -ENOSPC;
|
||||
return pci_enable_msix_range(adapter->pdev, adapter->msix_entries,
|
||||
1, nvec);
|
||||
}
|
||||
|
||||
4.3.2 pci_disable_msix
|
||||
Note the value of 'minvec' parameter is 1. As 'minvec' is inclusive,
|
||||
the value of 0 would be meaningless and could result in error.
|
||||
|
||||
Some devices have a minimal limit on number of MSI-X interrupts.
|
||||
In this case the function could look like this:
|
||||
|
||||
static int foo_driver_enable_msix(struct foo_adapter *adapter, int nvec)
|
||||
{
|
||||
return pci_enable_msix_range(adapter->pdev, adapter->msix_entries,
|
||||
FOO_DRIVER_MINIMUM_NVEC, nvec);
|
||||
}
|
||||
|
||||
4.3.1.2 Exact number of MSI-X interrupts
|
||||
|
||||
If a driver is unable or unwilling to deal with a variable number of MSI-X
|
||||
interrupts it could request a particular number of interrupts by passing
|
||||
that number to pci_enable_msix_range() function as both 'minvec' and 'maxvec'
|
||||
parameters:
|
||||
|
||||
static int foo_driver_enable_msix(struct foo_adapter *adapter, int nvec)
|
||||
{
|
||||
return pci_enable_msix_range(adapter->pdev, adapter->msix_entries,
|
||||
nvec, nvec);
|
||||
}
|
||||
|
||||
Note, unlike pci_enable_msix_exact() function, which could be also used to
|
||||
enable a particular number of MSI-X interrupts, pci_enable_msix_range()
|
||||
returns either a negative errno or 'nvec' (not negative errno or 0 - as
|
||||
pci_enable_msix_exact() does).
|
||||
|
||||
4.3.1.3 Specific requirements to the number of MSI-X interrupts
|
||||
|
||||
As noted above, there could be devices that can not operate with just any
|
||||
number of MSI-X interrupts within a range. E.g., let's assume a device that
|
||||
is only capable sending the number of MSI-X interrupts which is a power of
|
||||
two. A routine that enables MSI-X mode for such device might look like this:
|
||||
|
||||
/*
|
||||
* Assume 'minvec' and 'maxvec' are non-zero
|
||||
*/
|
||||
static int foo_driver_enable_msix(struct foo_adapter *adapter,
|
||||
int minvec, int maxvec)
|
||||
{
|
||||
int rc;
|
||||
|
||||
minvec = roundup_pow_of_two(minvec);
|
||||
maxvec = rounddown_pow_of_two(maxvec);
|
||||
|
||||
if (minvec > maxvec)
|
||||
return -ERANGE;
|
||||
|
||||
retry:
|
||||
rc = pci_enable_msix_range(adapter->pdev, adapter->msix_entries,
|
||||
maxvec, maxvec);
|
||||
/*
|
||||
* -ENOSPC is the only error code allowed to be analized
|
||||
*/
|
||||
if (rc == -ENOSPC) {
|
||||
if (maxvec == 1)
|
||||
return -ENOSPC;
|
||||
|
||||
maxvec /= 2;
|
||||
|
||||
if (minvec > maxvec)
|
||||
return -ENOSPC;
|
||||
|
||||
goto retry;
|
||||
}
|
||||
|
||||
return rc;
|
||||
}
|
||||
|
||||
Note how pci_enable_msix_range() return value is analized for a fallback -
|
||||
any error code other than -ENOSPC indicates a fatal error and should not
|
||||
be retried.
|
||||
|
||||
4.3.2 pci_enable_msix_exact
|
||||
|
||||
int pci_enable_msix_exact(struct pci_dev *dev,
|
||||
struct msix_entry *entries, int nvec)
|
||||
|
||||
This variation on pci_enable_msix_range() call allows a device driver to
|
||||
request exactly 'nvec' MSI-Xs.
|
||||
|
||||
If this function returns a negative number, it indicates an error and
|
||||
the driver should not attempt to allocate any more MSI-X interrupts for
|
||||
this device.
|
||||
|
||||
By contrast with pci_enable_msix_range() function, pci_enable_msix_exact()
|
||||
returns zero in case of success, which indicates MSI-X interrupts have been
|
||||
successfully allocated.
|
||||
|
||||
Another version of a routine that enables MSI-X mode for a device with
|
||||
specific requirements described in chapter 4.3.1.3 might look like this:
|
||||
|
||||
/*
|
||||
* Assume 'minvec' and 'maxvec' are non-zero
|
||||
*/
|
||||
static int foo_driver_enable_msix(struct foo_adapter *adapter,
|
||||
int minvec, int maxvec)
|
||||
{
|
||||
int rc;
|
||||
|
||||
minvec = roundup_pow_of_two(minvec);
|
||||
maxvec = rounddown_pow_of_two(maxvec);
|
||||
|
||||
if (minvec > maxvec)
|
||||
return -ERANGE;
|
||||
|
||||
retry:
|
||||
rc = pci_enable_msix_exact(adapter->pdev,
|
||||
adapter->msix_entries, maxvec);
|
||||
|
||||
/*
|
||||
* -ENOSPC is the only error code allowed to be analyzed
|
||||
*/
|
||||
if (rc == -ENOSPC) {
|
||||
if (maxvec == 1)
|
||||
return -ENOSPC;
|
||||
|
||||
maxvec /= 2;
|
||||
|
||||
if (minvec > maxvec)
|
||||
return -ENOSPC;
|
||||
|
||||
goto retry;
|
||||
} else if (rc < 0) {
|
||||
return rc;
|
||||
}
|
||||
|
||||
return maxvec;
|
||||
}
|
||||
|
||||
4.3.3 pci_disable_msix
|
||||
|
||||
void pci_disable_msix(struct pci_dev *dev)
|
||||
|
||||
This function should be used to undo the effect of pci_enable_msix(). It frees
|
||||
the previously allocated message signaled interrupts. The interrupts may
|
||||
This function should be used to undo the effect of pci_enable_msix_range().
|
||||
It frees the previously allocated MSI-X interrupts. The interrupts may
|
||||
subsequently be assigned to another device, so drivers should not cache
|
||||
the value of the 'vector' elements over a call to pci_disable_msix().
|
||||
|
||||
|
@ -255,18 +452,32 @@ MSI-X Table. This address is mapped by the PCI subsystem, and should not
|
|||
be accessed directly by the device driver. If the driver wishes to
|
||||
mask or unmask an interrupt, it should call disable_irq() / enable_irq().
|
||||
|
||||
4.3.4 pci_msix_vec_count
|
||||
|
||||
int pci_msix_vec_count(struct pci_dev *dev)
|
||||
|
||||
This function could be used to retrieve number of entries in the device
|
||||
MSI-X table.
|
||||
|
||||
If this function returns a negative number, it indicates the device is
|
||||
not capable of sending MSI-Xs.
|
||||
|
||||
If this function returns a positive number, it indicates the maximum
|
||||
number of MSI-X interrupt vectors that could be allocated.
|
||||
|
||||
4.4 Handling devices implementing both MSI and MSI-X capabilities
|
||||
|
||||
If a device implements both MSI and MSI-X capabilities, it can
|
||||
run in either MSI mode or MSI-X mode, but not both simultaneously.
|
||||
This is a requirement of the PCI spec, and it is enforced by the
|
||||
PCI layer. Calling pci_enable_msi() when MSI-X is already enabled or
|
||||
pci_enable_msix() when MSI is already enabled results in an error.
|
||||
If a device driver wishes to switch between MSI and MSI-X at runtime,
|
||||
it must first quiesce the device, then switch it back to pin-interrupt
|
||||
mode, before calling pci_enable_msi() or pci_enable_msix() and resuming
|
||||
operation. This is not expected to be a common operation but may be
|
||||
useful for debugging or testing during development.
|
||||
PCI layer. Calling pci_enable_msi_range() when MSI-X is already
|
||||
enabled or pci_enable_msix_range() when MSI is already enabled
|
||||
results in an error. If a device driver wishes to switch between MSI
|
||||
and MSI-X at runtime, it must first quiesce the device, then switch
|
||||
it back to pin-interrupt mode, before calling pci_enable_msi_range()
|
||||
or pci_enable_msix_range() and resuming operation. This is not expected
|
||||
to be a common operation but may be useful for debugging or testing
|
||||
during development.
|
||||
|
||||
4.5 Considerations when using MSIs
|
||||
|
||||
|
@ -381,5 +592,5 @@ or disabled (0). If 0 is found in any of the msi_bus files belonging
|
|||
to bridges between the PCI root and the device, MSIs are disabled.
|
||||
|
||||
It is also worth checking the device driver to see whether it supports MSIs.
|
||||
For example, it may contain calls to pci_enable_msi(), pci_enable_msix() or
|
||||
pci_enable_msi_block().
|
||||
For example, it may contain calls to pci_enable_msi_range() or
|
||||
pci_enable_msix_range().
|
||||
|
|
|
@ -123,8 +123,10 @@ initialization with a pointer to a structure describing the driver
|
|||
|
||||
|
||||
The ID table is an array of struct pci_device_id entries ending with an
|
||||
all-zero entry; use of the macro DEFINE_PCI_DEVICE_TABLE is the preferred
|
||||
method of declaring the table. Each entry consists of:
|
||||
all-zero entry. Definitions with static const are generally preferred.
|
||||
Use of the deprecated macro DEFINE_PCI_DEVICE_TABLE should be avoided.
|
||||
|
||||
Each entry consists of:
|
||||
|
||||
vendor,device Vendor and device ID to match (or PCI_ANY_ID)
|
||||
|
||||
|
|
|
@ -8,6 +8,8 @@ listRCU.txt
|
|||
- Using RCU to Protect Read-Mostly Linked Lists
|
||||
lockdep.txt
|
||||
- RCU and lockdep checking
|
||||
lockdep-splat.txt
|
||||
- RCU Lockdep splats explained.
|
||||
NMI-RCU.txt
|
||||
- Using RCU to Protect Dynamic NMI Handlers
|
||||
rcubarrier.txt
|
||||
|
|
|
@ -396,14 +396,14 @@ o Each element of the form "3/3 ..>. 0:7 ^0" represents one rcu_node
|
|||
|
||||
The output of "cat rcu/rcu_sched/rcu_pending" looks as follows:
|
||||
|
||||
0!np=26111 qsp=29 rpq=5386 cbr=1 cng=570 gpc=3674 gps=577 nn=15903
|
||||
1!np=28913 qsp=35 rpq=6097 cbr=1 cng=448 gpc=3700 gps=554 nn=18113
|
||||
2!np=32740 qsp=37 rpq=6202 cbr=0 cng=476 gpc=4627 gps=546 nn=20889
|
||||
3 np=23679 qsp=22 rpq=5044 cbr=1 cng=415 gpc=3403 gps=347 nn=14469
|
||||
4!np=30714 qsp=4 rpq=5574 cbr=0 cng=528 gpc=3931 gps=639 nn=20042
|
||||
5 np=28910 qsp=2 rpq=5246 cbr=0 cng=428 gpc=4105 gps=709 nn=18422
|
||||
6!np=38648 qsp=5 rpq=7076 cbr=0 cng=840 gpc=4072 gps=961 nn=25699
|
||||
7 np=37275 qsp=2 rpq=6873 cbr=0 cng=868 gpc=3416 gps=971 nn=25147
|
||||
0!np=26111 qsp=29 rpq=5386 cbr=1 cng=570 gpc=3674 gps=577 nn=15903 ndw=0
|
||||
1!np=28913 qsp=35 rpq=6097 cbr=1 cng=448 gpc=3700 gps=554 nn=18113 ndw=0
|
||||
2!np=32740 qsp=37 rpq=6202 cbr=0 cng=476 gpc=4627 gps=546 nn=20889 ndw=0
|
||||
3 np=23679 qsp=22 rpq=5044 cbr=1 cng=415 gpc=3403 gps=347 nn=14469 ndw=0
|
||||
4!np=30714 qsp=4 rpq=5574 cbr=0 cng=528 gpc=3931 gps=639 nn=20042 ndw=0
|
||||
5 np=28910 qsp=2 rpq=5246 cbr=0 cng=428 gpc=4105 gps=709 nn=18422 ndw=0
|
||||
6!np=38648 qsp=5 rpq=7076 cbr=0 cng=840 gpc=4072 gps=961 nn=25699 ndw=0
|
||||
7 np=37275 qsp=2 rpq=6873 cbr=0 cng=868 gpc=3416 gps=971 nn=25147 ndw=0
|
||||
|
||||
The fields are as follows:
|
||||
|
||||
|
@ -432,6 +432,10 @@ o "gpc" is the number of times that an old grace period had
|
|||
o "gps" is the number of times that a new grace period had started,
|
||||
but this CPU was not yet aware of it.
|
||||
|
||||
o "ndw" is the number of times that a wakeup of an rcuo
|
||||
callback-offload kthread had to be deferred in order to avoid
|
||||
deadlock.
|
||||
|
||||
o "nn" is the number of times that this CPU needed nothing.
|
||||
|
||||
|
||||
|
@ -443,7 +447,7 @@ The output of "cat rcu/rcuboost" looks as follows:
|
|||
balk: nt=0 egt=6541 bt=0 nb=0 ny=126 nos=0
|
||||
|
||||
This information is output only for rcu_preempt. Each two-line entry
|
||||
corresponds to a leaf rcu_node strcuture. The fields are as follows:
|
||||
corresponds to a leaf rcu_node structure. The fields are as follows:
|
||||
|
||||
o "n:m" is the CPU-number range for the corresponding two-line
|
||||
entry. In the sample output above, the first entry covers
|
||||
|
|
|
@ -45,11 +45,22 @@ directory apei/einj. The following files are provided.
|
|||
injection. Before this, please specify all necessary error
|
||||
parameters.
|
||||
|
||||
- flags
|
||||
Present for kernel version 3.13 and above. Used to specify which
|
||||
of param{1..4} are valid and should be used by BIOS during injection.
|
||||
Value is a bitmask as specified in ACPI5.0 spec for the
|
||||
SET_ERROR_TYPE_WITH_ADDRESS data structure:
|
||||
Bit 0 - Processor APIC field valid (see param3 below)
|
||||
Bit 1 - Memory address and mask valid (param1 and param2)
|
||||
Bit 2 - PCIe (seg,bus,dev,fn) valid (param4 below)
|
||||
If set to zero, legacy behaviour is used where the type of injection
|
||||
specifies just one bit set, and param1 is multiplexed.
|
||||
|
||||
- param1
|
||||
This file is used to set the first error parameter value. Effect of
|
||||
parameter depends on error_type specified. For example, if error
|
||||
type is memory related type, the param1 should be a valid physical
|
||||
memory address.
|
||||
memory address. [Unless "flag" is set - see above]
|
||||
|
||||
- param2
|
||||
This file is used to set the second error parameter value. Effect of
|
||||
|
@ -58,6 +69,12 @@ directory apei/einj. The following files are provided.
|
|||
address mask. Linux requires page or narrower granularity, say,
|
||||
0xfffffffffffff000.
|
||||
|
||||
- param3
|
||||
Used when the 0x1 bit is set in "flag" to specify the APIC id
|
||||
|
||||
- param4
|
||||
Used when the 0x4 bit is set in "flag" to specify target PCIe device
|
||||
|
||||
- notrigger
|
||||
The EINJ mechanism is a two step process. First inject the error, then
|
||||
perform some actions to trigger it. Setting "notrigger" to 1 skips the
|
||||
|
|
|
@ -293,36 +293,13 @@ the device to the driver. For example:
|
|||
|
||||
These GPIO numbers are controller relative and path "\\_SB.PCI0.GPI0"
|
||||
specifies the path to the controller. In order to use these GPIOs in Linux
|
||||
we need to translate them to the Linux GPIO numbers.
|
||||
we need to translate them to the corresponding Linux GPIO descriptors.
|
||||
|
||||
In a simple case of just getting the Linux GPIO number from device
|
||||
resources one can use acpi_get_gpio_by_index() helper function. It takes
|
||||
pointer to the device and index of the GpioIo/GpioInt descriptor in the
|
||||
device resources list. For example:
|
||||
There is a standard GPIO API for that and is documented in
|
||||
Documentation/gpio.txt.
|
||||
|
||||
int gpio_irq, gpio_power;
|
||||
int ret;
|
||||
|
||||
gpio_irq = acpi_get_gpio_by_index(dev, 1, NULL);
|
||||
if (gpio_irq < 0)
|
||||
/* handle error */
|
||||
|
||||
gpio_power = acpi_get_gpio_by_index(dev, 0, NULL);
|
||||
if (gpio_power < 0)
|
||||
/* handle error */
|
||||
|
||||
/* Now we can use the GPIO numbers */
|
||||
|
||||
Other GpioIo parameters must be converted first by the driver to be
|
||||
suitable to the gpiolib before passing them.
|
||||
|
||||
In case of GpioInt resource an additional call to gpio_to_irq() must be
|
||||
done before calling request_irq().
|
||||
|
||||
Note that the above API is ACPI specific and not recommended for drivers
|
||||
that need to support non-ACPI systems. The recommended way is to use
|
||||
the descriptor based GPIO interfaces. The above example looks like this
|
||||
when converted to the GPIO desc:
|
||||
In the above example we can get the corresponding two GPIO descriptors with
|
||||
a code like this:
|
||||
|
||||
#include <linux/gpio/consumer.h>
|
||||
...
|
||||
|
@ -339,4 +316,5 @@ when converted to the GPIO desc:
|
|||
|
||||
/* Now we can use the GPIO descriptors */
|
||||
|
||||
See also Documentation/gpio.txt.
|
||||
There are also devm_* versions of these functions which release the
|
||||
descriptors once the device is released.
|
||||
|
|
|
@ -235,10 +235,6 @@ Wysocki <rafael.j.wysocki@intel.com>.
|
|||
named object's type in the second column). In that case the object's
|
||||
directory in sysfs will contain the 'path' attribute whose value is
|
||||
the full path to the node from the namespace root.
|
||||
struct acpi_device objects are created for the ACPI namespace nodes
|
||||
whose _STA control methods return PRESENT or FUNCTIONING. The power
|
||||
resource nodes or nodes without _STA are assumed to be both PRESENT
|
||||
and FUNCTIONING.
|
||||
F:
|
||||
The struct acpi_device object is created for a fixed hardware
|
||||
feature (as indicated by the fixed feature flag's name in the second
|
||||
|
@ -340,7 +336,7 @@ Wysocki <rafael.j.wysocki@intel.com>.
|
|||
| +-------------+-------+----------------+
|
||||
| |
|
||||
| | +- - - - - - - +- - - - - - +- - - - - - - -+
|
||||
| +-| * PNP0C0D:00 | \_SB_.LID0 | acpi:PNP0C0D: |
|
||||
| +-| PNP0C0D:00 | \_SB_.LID0 | acpi:PNP0C0D: |
|
||||
| | +- - - - - - - +- - - - - - +- - - - - - - -+
|
||||
| |
|
||||
| | +------------+------------+-----------------------+
|
||||
|
@ -390,6 +386,3 @@ Wysocki <rafael.j.wysocki@intel.com>.
|
|||
attribute (as described earlier in this document).
|
||||
NOTE: N/A indicates the device object does not have the 'path' or the
|
||||
'modalias' attribute.
|
||||
NOTE: The PNP0C0D device listed above is highlighted (marked by "*")
|
||||
to indicate it will be created only when its _STA methods return
|
||||
PRESENT or FUNCTIONING.
|
||||
|
|
|
@ -4,6 +4,8 @@ Booting
|
|||
- requirements for booting
|
||||
Interrupts
|
||||
- ARM Interrupt subsystem documentation
|
||||
IXP4xx
|
||||
- Intel IXP4xx Network processor.
|
||||
msm
|
||||
- MSM specific documentation
|
||||
Netwinder
|
||||
|
@ -24,8 +26,16 @@ SPEAr
|
|||
- ST SPEAr platform Linux Overview
|
||||
VFP/
|
||||
- Release notes for Linux Kernel Vector Floating Point support code
|
||||
cluster-pm-race-avoidance.txt
|
||||
- Algorithm for CPU and Cluster setup/teardown
|
||||
empeg/
|
||||
- Ltd's Empeg MP3 Car Audio Player
|
||||
firmware.txt
|
||||
- Secure firmware registration and calling.
|
||||
kernel_mode_neon.txt
|
||||
- How to use NEON instructions in kernel mode
|
||||
kernel_user_helpers.txt
|
||||
- Helper functions in kernel space made available for userspace.
|
||||
mem_alignment
|
||||
- alignment abort handler documentation
|
||||
memory.txt
|
||||
|
@ -34,3 +44,7 @@ nwfpe/
|
|||
- NWFPE floating point emulator documentation
|
||||
swp_emulation
|
||||
- SWP/SWPB emulation handler/logging description
|
||||
tcm.txt
|
||||
- ARM Tightly Coupled Memory
|
||||
vlocks.txt
|
||||
- Voting locks, low-level mechanism relying on memory system atomic writes.
|
||||
|
|
|
@ -211,6 +211,30 @@ MMP/MMP2 family (communication processor)
|
|||
Linux kernel mach directory: arch/arm/mach-mmp
|
||||
Linux kernel plat directory: arch/arm/plat-pxa
|
||||
|
||||
Berlin family (Digital Entertainment)
|
||||
-------------------------------------
|
||||
|
||||
Flavors:
|
||||
88DE3005, Armada 1500-mini
|
||||
Design name: BG2CD
|
||||
Core: ARM Cortex-A9, PL310 L2CC
|
||||
Homepage: http://www.marvell.com/digital-entertainment/armada-1500-mini/
|
||||
88DE3100, Armada 1500
|
||||
Design name: BG2
|
||||
Core: Marvell PJ4B (ARMv7), Tauros3 L2CC
|
||||
Homepage: http://www.marvell.com/digital-entertainment/armada-1500/
|
||||
Product Brief: http://www.marvell.com/digital-entertainment/armada-1500/assets/Marvell-ARMADA-1500-Product-Brief.pdf
|
||||
88DE????
|
||||
Design name: BG3
|
||||
Core: ARM Cortex-A15, CA15 integrated L2CC
|
||||
|
||||
Homepage: http://www.marvell.com/digital-entertainment/
|
||||
Directory: arch/arm/mach-berlin
|
||||
|
||||
Comments:
|
||||
* This line of SoCs is based on Marvell Sheeva or ARM Cortex CPUs
|
||||
with Synopsys DesignWare (IRQ, GPIO, Timers, ...) and PXA IP (SDHCI, USB, ETH, ...).
|
||||
|
||||
Long-term plans
|
||||
---------------
|
||||
|
||||
|
|
|
@ -85,21 +85,10 @@ between the calls.
|
|||
Headers
|
||||
-------
|
||||
|
||||
See arch/arm/mach-s3c2410/include/mach/regs-gpio.h for the list
|
||||
See arch/arm/mach-s3c24xx/include/mach/regs-gpio.h for the list
|
||||
of GPIO pins, and the configuration values for them. This
|
||||
is included by using #include <mach/regs-gpio.h>
|
||||
|
||||
The GPIO management functions are defined in the hardware
|
||||
header arch/arm/mach-s3c2410/include/mach/hardware.h which can be
|
||||
included by #include <mach/hardware.h>
|
||||
|
||||
A useful amount of documentation can be found in the hardware
|
||||
header on how the GPIO functions (and others) work.
|
||||
|
||||
Whilst a number of these functions do make some checks on what
|
||||
is passed to them, for speed of use, they may not always ensure
|
||||
that the user supplied data to them is correct.
|
||||
|
||||
|
||||
PIN Numbers
|
||||
-----------
|
||||
|
|
|
@ -1,8 +1,10 @@
|
|||
00-INDEX
|
||||
- This file
|
||||
|
||||
Makefile
|
||||
- Makefile for gptimers example file.
|
||||
bfin-gpio-notes.txt
|
||||
- Notes in developing/using bfin-gpio driver.
|
||||
|
||||
bfin-spi-notes.txt
|
||||
- Notes for using bfin spi bus driver.
|
||||
gptimers-example.c
|
||||
- gptimers example
|
||||
|
|
|
@ -14,6 +14,8 @@ deadline-iosched.txt
|
|||
- Deadline IO scheduler tunables
|
||||
ioprio.txt
|
||||
- Block io priorities (in CFQ scheduler)
|
||||
null_blk.txt
|
||||
- Null block for block-layer benchmarking.
|
||||
queue-sysfs.txt
|
||||
- Queue's sysfs entries
|
||||
request.txt
|
||||
|
|
|
@ -447,14 +447,13 @@ struct bio_vec {
|
|||
* main unit of I/O for the block layer and lower layers (ie drivers)
|
||||
*/
|
||||
struct bio {
|
||||
sector_t bi_sector;
|
||||
struct bio *bi_next; /* request queue link */
|
||||
struct block_device *bi_bdev; /* target device */
|
||||
unsigned long bi_flags; /* status, command, etc */
|
||||
unsigned long bi_rw; /* low bits: r/w, high: priority */
|
||||
|
||||
unsigned int bi_vcnt; /* how may bio_vec's */
|
||||
unsigned int bi_idx; /* current index into bio_vec array */
|
||||
struct bvec_iter bi_iter; /* current index into bio_vec array */
|
||||
|
||||
unsigned int bi_size; /* total size in bytes */
|
||||
unsigned short bi_phys_segments; /* segments after physaddr coalesce*/
|
||||
|
@ -480,7 +479,7 @@ With this multipage bio design:
|
|||
- Code that traverses the req list can find all the segments of a bio
|
||||
by using rq_for_each_segment. This handles the fact that a request
|
||||
has multiple bios, each of which can have multiple segments.
|
||||
- Drivers which can't process a large bio in one shot can use the bi_idx
|
||||
- Drivers which can't process a large bio in one shot can use the bi_iter
|
||||
field to keep track of the next bio_vec entry to process.
|
||||
(e.g a 1MB bio_vec needs to be handled in max 128kB chunks for IDE)
|
||||
[TBD: Should preferably also have a bi_voffset and bi_vlen to avoid modifying
|
||||
|
@ -589,7 +588,7 @@ driver should not modify these values. The block layer sets up the
|
|||
nr_sectors and current_nr_sectors fields (based on the corresponding
|
||||
hard_xxx values and the number of bytes transferred) and updates it on
|
||||
every transfer that invokes end_that_request_first. It does the same for the
|
||||
buffer, bio, bio->bi_idx fields too.
|
||||
buffer, bio, bio->bi_iter fields too.
|
||||
|
||||
The buffer field is just a virtual address mapping of the current segment
|
||||
of the i/o buffer in cases where the buffer resides in low-memory. For high
|
||||
|
|
111
Documentation/block/biovecs.txt
Normal file
111
Documentation/block/biovecs.txt
Normal file
|
@ -0,0 +1,111 @@
|
|||
|
||||
Immutable biovecs and biovec iterators:
|
||||
=======================================
|
||||
|
||||
Kent Overstreet <kmo@daterainc.com>
|
||||
|
||||
As of 3.13, biovecs should never be modified after a bio has been submitted.
|
||||
Instead, we have a new struct bvec_iter which represents a range of a biovec -
|
||||
the iterator will be modified as the bio is completed, not the biovec.
|
||||
|
||||
More specifically, old code that needed to partially complete a bio would
|
||||
update bi_sector and bi_size, and advance bi_idx to the next biovec. If it
|
||||
ended up partway through a biovec, it would increment bv_offset and decrement
|
||||
bv_len by the number of bytes completed in that biovec.
|
||||
|
||||
In the new scheme of things, everything that must be mutated in order to
|
||||
partially complete a bio is segregated into struct bvec_iter: bi_sector,
|
||||
bi_size and bi_idx have been moved there; and instead of modifying bv_offset
|
||||
and bv_len, struct bvec_iter has bi_bvec_done, which represents the number of
|
||||
bytes completed in the current bvec.
|
||||
|
||||
There are a bunch of new helper macros for hiding the gory details - in
|
||||
particular, presenting the illusion of partially completed biovecs so that
|
||||
normal code doesn't have to deal with bi_bvec_done.
|
||||
|
||||
* Driver code should no longer refer to biovecs directly; we now have
|
||||
bio_iovec() and bio_iovec_iter() macros that return literal struct biovecs,
|
||||
constructed from the raw biovecs but taking into account bi_bvec_done and
|
||||
bi_size.
|
||||
|
||||
bio_for_each_segment() has been updated to take a bvec_iter argument
|
||||
instead of an integer (that corresponded to bi_idx); for a lot of code the
|
||||
conversion just required changing the types of the arguments to
|
||||
bio_for_each_segment().
|
||||
|
||||
* Advancing a bvec_iter is done with bio_advance_iter(); bio_advance() is a
|
||||
wrapper around bio_advance_iter() that operates on bio->bi_iter, and also
|
||||
advances the bio integrity's iter if present.
|
||||
|
||||
There is a lower level advance function - bvec_iter_advance() - which takes
|
||||
a pointer to a biovec, not a bio; this is used by the bio integrity code.
|
||||
|
||||
What's all this get us?
|
||||
=======================
|
||||
|
||||
Having a real iterator, and making biovecs immutable, has a number of
|
||||
advantages:
|
||||
|
||||
* Before, iterating over bios was very awkward when you weren't processing
|
||||
exactly one bvec at a time - for example, bio_copy_data() in fs/bio.c,
|
||||
which copies the contents of one bio into another. Because the biovecs
|
||||
wouldn't necessarily be the same size, the old code was tricky convoluted -
|
||||
it had to walk two different bios at the same time, keeping both bi_idx and
|
||||
and offset into the current biovec for each.
|
||||
|
||||
The new code is much more straightforward - have a look. This sort of
|
||||
pattern comes up in a lot of places; a lot of drivers were essentially open
|
||||
coding bvec iterators before, and having common implementation considerably
|
||||
simplifies a lot of code.
|
||||
|
||||
* Before, any code that might need to use the biovec after the bio had been
|
||||
completed (perhaps to copy the data somewhere else, or perhaps to resubmit
|
||||
it somewhere else if there was an error) had to save the entire bvec array
|
||||
- again, this was being done in a fair number of places.
|
||||
|
||||
* Biovecs can be shared between multiple bios - a bvec iter can represent an
|
||||
arbitrary range of an existing biovec, both starting and ending midway
|
||||
through biovecs. This is what enables efficient splitting of arbitrary
|
||||
bios. Note that this means we _only_ use bi_size to determine when we've
|
||||
reached the end of a bio, not bi_vcnt - and the bio_iovec() macro takes
|
||||
bi_size into account when constructing biovecs.
|
||||
|
||||
* Splitting bios is now much simpler. The old bio_split() didn't even work on
|
||||
bios with more than a single bvec! Now, we can efficiently split arbitrary
|
||||
size bios - because the new bio can share the old bio's biovec.
|
||||
|
||||
Care must be taken to ensure the biovec isn't freed while the split bio is
|
||||
still using it, in case the original bio completes first, though. Using
|
||||
bio_chain() when splitting bios helps with this.
|
||||
|
||||
* Submitting partially completed bios is now perfectly fine - this comes up
|
||||
occasionally in stacking block drivers and various code (e.g. md and
|
||||
bcache) had some ugly workarounds for this.
|
||||
|
||||
It used to be the case that submitting a partially completed bio would work
|
||||
fine to _most_ devices, but since accessing the raw bvec array was the
|
||||
norm, not all drivers would respect bi_idx and those would break. Now,
|
||||
since all drivers _must_ go through the bvec iterator - and have been
|
||||
audited to make sure they are - submitting partially completed bios is
|
||||
perfectly fine.
|
||||
|
||||
Other implications:
|
||||
===================
|
||||
|
||||
* Almost all usage of bi_idx is now incorrect and has been removed; instead,
|
||||
where previously you would have used bi_idx you'd now use a bvec_iter,
|
||||
probably passing it to one of the helper macros.
|
||||
|
||||
I.e. instead of using bio_iovec_idx() (or bio->bi_iovec[bio->bi_idx]), you
|
||||
now use bio_iter_iovec(), which takes a bvec_iter and returns a
|
||||
literal struct bio_vec - constructed on the fly from the raw biovec but
|
||||
taking into account bi_bvec_done (and bi_size).
|
||||
|
||||
* bi_vcnt can't be trusted or relied upon by driver code - i.e. anything that
|
||||
doesn't actually own the bio. The reason is twofold: firstly, it's not
|
||||
actually needed for iterating over the bio anymore - we only use bi_size.
|
||||
Secondly, when cloning a bio and reusing (a portion of) the original bio's
|
||||
biovec, in order to calculate bi_vcnt for the new bio we'd have to iterate
|
||||
over all the biovecs in the new bio - which is silly as it's not needed.
|
||||
|
||||
So, don't use bi_vcnt anymore.
|
|
@ -36,21 +36,30 @@ allowing one to squeeze more programs onto an average installation or
|
|||
rescue floppy disk.
|
||||
|
||||
|
||||
2) Kernel Command Line Parameters
|
||||
2) Parameters
|
||||
---------------------------------
|
||||
|
||||
2a) Kernel Command Line Parameters
|
||||
|
||||
ramdisk_size=N
|
||||
==============
|
||||
|
||||
This parameter tells the RAM disk driver to set up RAM disks of N k size. The
|
||||
default is 4096 (4 MB) (8192 (8 MB) on S390).
|
||||
default is 4096 (4 MB).
|
||||
|
||||
ramdisk_blocksize=N
|
||||
===================
|
||||
2b) Module parameters
|
||||
|
||||
This parameter tells the RAM disk driver how many bytes to use per block. The
|
||||
default is 1024 (BLOCK_SIZE).
|
||||
rd_nr
|
||||
=====
|
||||
/dev/ramX devices created.
|
||||
|
||||
max_part
|
||||
========
|
||||
Maximum partition number.
|
||||
|
||||
rd_size
|
||||
=======
|
||||
See ramdisk_size.
|
||||
|
||||
3) Using "rdev -r"
|
||||
------------------
|
||||
|
|
|
@ -1,8 +1,6 @@
|
|||
zram: Compressed RAM based block devices
|
||||
----------------------------------------
|
||||
|
||||
Project home: http://compcache.googlecode.com/
|
||||
|
||||
* Introduction
|
||||
|
||||
The zram module creates RAM based block devices named /dev/zram<id>
|
||||
|
@ -69,9 +67,5 @@ Following shows a typical sequence of steps for using zram.
|
|||
resets the disksize to zero. You must set the disksize again
|
||||
before reusing the device.
|
||||
|
||||
Please report any problems at:
|
||||
- Mailing list: linux-mm-cc at laptop dot org
|
||||
- Issue tracker: http://code.google.com/p/compcache/issues/list
|
||||
|
||||
Nitin Gupta
|
||||
ngupta@vflare.org
|
|
@ -24,7 +24,6 @@ CONTENTS:
|
|||
2.1 Basic Usage
|
||||
2.2 Attaching processes
|
||||
2.3 Mounting hierarchies by name
|
||||
2.4 Notification API
|
||||
3. Kernel API
|
||||
3.1 Overview
|
||||
3.2 Synchronization
|
||||
|
@ -472,25 +471,6 @@ you give a subsystem a name.
|
|||
The name of the subsystem appears as part of the hierarchy description
|
||||
in /proc/mounts and /proc/<pid>/cgroups.
|
||||
|
||||
2.4 Notification API
|
||||
--------------------
|
||||
|
||||
There is mechanism which allows to get notifications about changing
|
||||
status of a cgroup.
|
||||
|
||||
To register a new notification handler you need to:
|
||||
- create a file descriptor for event notification using eventfd(2);
|
||||
- open a control file to be monitored (e.g. memory.usage_in_bytes);
|
||||
- write "<event_fd> <control_fd> <args>" to cgroup.event_control.
|
||||
Interpretation of args is defined by control file implementation;
|
||||
|
||||
eventfd will be woken up by control file implementation or when the
|
||||
cgroup is removed.
|
||||
|
||||
To unregister a notification handler just close eventfd.
|
||||
|
||||
NOTE: Support of notifications should be implemented for the control
|
||||
file. See documentation for the subsystem.
|
||||
|
||||
3. Kernel API
|
||||
=============
|
||||
|
|
|
@ -577,7 +577,7 @@ Each memcg's numa_stat file includes "total", "file", "anon" and "unevictable"
|
|||
per-node page counts including "hierarchical_<counter>" which sums up all
|
||||
hierarchical children's values in addition to the memcg's own value.
|
||||
|
||||
The ouput format of memory.numa_stat is:
|
||||
The output format of memory.numa_stat is:
|
||||
|
||||
total=<total pages> N0=<node 0 pages> N1=<node 1 pages> ...
|
||||
file=<total file pages> N0=<node 0 pages> N1=<node 1 pages> ...
|
||||
|
@ -670,7 +670,7 @@ page tables.
|
|||
|
||||
8.1 Interface
|
||||
|
||||
This feature is disabled by default. It can be enabledi (and disabled again) by
|
||||
This feature is disabled by default. It can be enabled (and disabled again) by
|
||||
writing to memory.move_charge_at_immigrate of the destination cgroup.
|
||||
|
||||
If you want to enable it:
|
||||
|
|
|
@ -6,6 +6,8 @@ tag network packets with a class identifier (classid).
|
|||
|
||||
The Traffic Controller (tc) can be used to assign
|
||||
different priorities to packets from different cgroups.
|
||||
Also, Netfilter (iptables) can use this tag to perform
|
||||
actions on such packets.
|
||||
|
||||
Creating a net_cls cgroups instance creates a net_cls.classid file.
|
||||
This net_cls.classid value is initialized to 0.
|
||||
|
@ -32,3 +34,6 @@ tc class add dev eth0 parent 10: classid 10:1 htb rate 40mbit
|
|||
- creating traffic class 10:1
|
||||
|
||||
tc filter add dev eth0 parent 10: protocol ip prio 10 handle 1: cgroup
|
||||
|
||||
configuring iptables, basic example:
|
||||
iptables -A OUTPUT -m cgroup ! --cgroup 0x100001 -j DROP
|
||||
|
|
|
@ -95,10 +95,10 @@ to work with it.
|
|||
|
||||
f. u64 res_counter_uncharge_until
|
||||
(struct res_counter *rc, struct res_counter *top,
|
||||
unsinged long val)
|
||||
unsigned long val)
|
||||
|
||||
Almost same as res_cunter_uncharge() but propagation of uncharge
|
||||
stops when rc == top. This is useful when kill a res_coutner in
|
||||
Almost same as res_counter_uncharge() but propagation of uncharge
|
||||
stops when rc == top. This is useful when kill a res_counter in
|
||||
child cgroup.
|
||||
|
||||
2.1 Other accounting routines
|
||||
|
|
|
@ -160,6 +160,7 @@ The producer will look something like this:
|
|||
spin_lock(&producer_lock);
|
||||
|
||||
unsigned long head = buffer->head;
|
||||
/* The spin_unlock() and next spin_lock() provide needed ordering. */
|
||||
unsigned long tail = ACCESS_ONCE(buffer->tail);
|
||||
|
||||
if (CIRC_SPACE(head, tail, buffer->size) >= 1) {
|
||||
|
@ -168,9 +169,8 @@ The producer will look something like this:
|
|||
|
||||
produce_item(item);
|
||||
|
||||
smp_wmb(); /* commit the item before incrementing the head */
|
||||
|
||||
buffer->head = (head + 1) & (buffer->size - 1);
|
||||
smp_store_release(buffer->head,
|
||||
(head + 1) & (buffer->size - 1));
|
||||
|
||||
/* wake_up() will make sure that the head is committed before
|
||||
* waking anyone up */
|
||||
|
@ -183,9 +183,14 @@ This will instruct the CPU that the contents of the new item must be written
|
|||
before the head index makes it available to the consumer and then instructs the
|
||||
CPU that the revised head index must be written before the consumer is woken.
|
||||
|
||||
Note that wake_up() doesn't have to be the exact mechanism used, but whatever
|
||||
is used must guarantee a (write) memory barrier between the update of the head
|
||||
index and the change of state of the consumer, if a change of state occurs.
|
||||
Note that wake_up() does not guarantee any sort of barrier unless something
|
||||
is actually awakened. We therefore cannot rely on it for ordering. However,
|
||||
there is always one element of the array left empty. Therefore, the
|
||||
producer must produce two elements before it could possibly corrupt the
|
||||
element currently being read by the consumer. Therefore, the unlock-lock
|
||||
pair between consecutive invocations of the consumer provides the necessary
|
||||
ordering between the read of the index indicating that the consumer has
|
||||
vacated a given element and the write by the producer to that same element.
|
||||
|
||||
|
||||
THE CONSUMER
|
||||
|
@ -195,21 +200,20 @@ The consumer will look something like this:
|
|||
|
||||
spin_lock(&consumer_lock);
|
||||
|
||||
unsigned long head = ACCESS_ONCE(buffer->head);
|
||||
/* Read index before reading contents at that index. */
|
||||
unsigned long head = smp_load_acquire(buffer->head);
|
||||
unsigned long tail = buffer->tail;
|
||||
|
||||
if (CIRC_CNT(head, tail, buffer->size) >= 1) {
|
||||
/* read index before reading contents at that index */
|
||||
smp_read_barrier_depends();
|
||||
|
||||
/* extract one item from the buffer */
|
||||
struct item *item = buffer[tail];
|
||||
|
||||
consume_item(item);
|
||||
|
||||
smp_mb(); /* finish reading descriptor before incrementing tail */
|
||||
|
||||
buffer->tail = (tail + 1) & (buffer->size - 1);
|
||||
/* Finish reading descriptor before incrementing tail. */
|
||||
smp_store_release(buffer->tail,
|
||||
(tail + 1) & (buffer->size - 1));
|
||||
}
|
||||
|
||||
spin_unlock(&consumer_lock);
|
||||
|
@ -218,12 +222,17 @@ This will instruct the CPU to make sure the index is up to date before reading
|
|||
the new item, and then it shall make sure the CPU has finished reading the item
|
||||
before it writes the new tail pointer, which will erase the item.
|
||||
|
||||
|
||||
Note the use of ACCESS_ONCE() in both algorithms to read the opposition index.
|
||||
This prevents the compiler from discarding and reloading its cached value -
|
||||
which some compilers will do across smp_read_barrier_depends(). This isn't
|
||||
strictly needed if you can be sure that the opposition index will _only_ be
|
||||
used the once.
|
||||
Note the use of ACCESS_ONCE() and smp_load_acquire() to read the
|
||||
opposition index. This prevents the compiler from discarding and
|
||||
reloading its cached value - which some compilers will do across
|
||||
smp_read_barrier_depends(). This isn't strictly needed if you can
|
||||
be sure that the opposition index will _only_ be used the once.
|
||||
The smp_load_acquire() additionally forces the CPU to order against
|
||||
subsequent memory references. Similarly, smp_store_release() is used
|
||||
in both algorithms to write the thread's index. This documents the
|
||||
fact that we are writing to something that can be read concurrently,
|
||||
prevents the compiler from tearing the store, and enforces ordering
|
||||
against previous accesses.
|
||||
|
||||
|
||||
===============
|
||||
|
|
|
@ -77,6 +77,11 @@ the operations defined in clk.h:
|
|||
int (*set_parent)(struct clk_hw *hw, u8 index);
|
||||
u8 (*get_parent)(struct clk_hw *hw);
|
||||
int (*set_rate)(struct clk_hw *hw, unsigned long);
|
||||
int (*set_rate_and_parent)(struct clk_hw *hw,
|
||||
unsigned long rate,
|
||||
unsigned long parent_rate, u8 index);
|
||||
unsigned long (*recalc_accuracy)(struct clk_hw *hw,
|
||||
unsigned long parent_accuracy);
|
||||
void (*init)(struct clk_hw *hw);
|
||||
};
|
||||
|
||||
|
@ -202,6 +207,8 @@ optional or must be evaluated on a case-by-case basis.
|
|||
.set_parent | | | n | y | n |
|
||||
.get_parent | | | n | y | n |
|
||||
| | | | | |
|
||||
.recalc_accuracy| | | | | |
|
||||
| | | | | |
|
||||
.init | | | | | |
|
||||
-----------------------------------------------------------
|
||||
[1] either one of round_rate or determine_rate is required.
|
||||
|
|
|
@ -17,8 +17,8 @@ Introduction
|
|||
Some CPUs support a functionality to raise the operating frequency of
|
||||
some cores in a multi-core package if certain conditions apply, mostly
|
||||
if the whole chip is not fully utilized and below it's intended thermal
|
||||
budget. This is done without operating system control by a combination
|
||||
of hardware and firmware.
|
||||
budget. The decision about boost disable/enable is made either at hardware
|
||||
(e.g. x86) or software (e.g ARM).
|
||||
On Intel CPUs this is called "Turbo Boost", AMD calls it "Turbo-Core",
|
||||
in technical documentation "Core performance boost". In Linux we use
|
||||
the term "boost" for convenience.
|
||||
|
@ -48,24 +48,24 @@ be desirable:
|
|||
User controlled switch
|
||||
----------------------
|
||||
|
||||
To allow the user to toggle the boosting functionality, the acpi-cpufreq
|
||||
driver exports a sysfs knob to disable it. There is a file:
|
||||
To allow the user to toggle the boosting functionality, the cpufreq core
|
||||
driver exports a sysfs knob to enable or disable it. There is a file:
|
||||
/sys/devices/system/cpu/cpufreq/boost
|
||||
which can either read "0" (boosting disabled) or "1" (boosting enabled).
|
||||
Reading the file is always supported, even if the processor does not
|
||||
support boosting. In this case the file will be read-only and always
|
||||
reads as "0". Explicitly changing the permissions and writing to that
|
||||
file anyway will return EINVAL.
|
||||
The file is exported only when cpufreq driver supports boosting.
|
||||
Explicitly changing the permissions and writing to that file anyway will
|
||||
return EINVAL.
|
||||
|
||||
On supported CPUs one can write either a "0" or a "1" into this file.
|
||||
This will either disable the boost functionality on all cores in the
|
||||
whole system (0) or will allow the hardware to boost at will (1).
|
||||
whole system (0) or will allow the software or hardware to boost at will
|
||||
(1).
|
||||
|
||||
Writing a "1" does not explicitly boost the system, but just allows the
|
||||
CPU (and the firmware) to boost at their discretion. Some implementations
|
||||
take external factors like the chip's temperature into account, so
|
||||
boosting once does not necessarily mean that it will occur every time
|
||||
even using the exact same software setup.
|
||||
CPU to boost at their discretion. Some implementations take external
|
||||
factors like the chip's temperature into account, so boosting once does
|
||||
not necessarily mean that it will occur every time even using the exact
|
||||
same software setup.
|
||||
|
||||
|
||||
AMD legacy cpb switch
|
||||
|
|
40
Documentation/cpu-freq/intel-pstate.txt
Normal file
40
Documentation/cpu-freq/intel-pstate.txt
Normal file
|
@ -0,0 +1,40 @@
|
|||
Intel P-state driver
|
||||
--------------------
|
||||
|
||||
This driver implements a scaling driver with an internal governor for
|
||||
Intel Core processors. The driver follows the same model as the
|
||||
Transmeta scaling driver (longrun.c) and implements the setpolicy()
|
||||
instead of target(). Scaling drivers that implement setpolicy() are
|
||||
assumed to implement internal governors by the cpufreq core. All the
|
||||
logic for selecting the current P state is contained within the
|
||||
driver; no external governor is used by the cpufreq core.
|
||||
|
||||
Intel SandyBridge+ processors are supported.
|
||||
|
||||
New sysfs files for controlling P state selection have been added to
|
||||
/sys/devices/system/cpu/intel_pstate/
|
||||
|
||||
max_perf_pct: limits the maximum P state that will be requested by
|
||||
the driver stated as a percentage of the available performance.
|
||||
|
||||
min_perf_pct: limits the minimum P state that will be requested by
|
||||
the driver stated as a percentage of the available performance.
|
||||
|
||||
no_turbo: limits the driver to selecting P states below the turbo
|
||||
frequency range.
|
||||
|
||||
For contemporary Intel processors, the frequency is controlled by the
|
||||
processor itself and the P-states exposed to software are related to
|
||||
performance levels. The idea that frequency can be set to a single
|
||||
frequency is fiction for Intel Core processors. Even if the scaling
|
||||
driver selects a single P state the actual frequency the processor
|
||||
will run at is selected by the processor itself.
|
||||
|
||||
New debugfs files have also been added to /sys/kernel/debug/pstate_snb/
|
||||
|
||||
deadband
|
||||
d_gain_pct
|
||||
i_gain_pct
|
||||
p_gain_pct
|
||||
sample_rate_ms
|
||||
setpoint
|
|
@ -285,7 +285,7 @@ A: This is what you would need in your kernel code to receive notifications.
|
|||
return NOTIFY_OK;
|
||||
}
|
||||
|
||||
static struct notifier_block foobar_cpu_notifer =
|
||||
static struct notifier_block foobar_cpu_notifier =
|
||||
{
|
||||
.notifier_call = foobar_cpu_callback,
|
||||
};
|
||||
|
|
|
@ -22,10 +22,12 @@ locations such as buffers like the printk buffer or the process table.
|
|||
Retrieving a full system memory dump is also possible over the FireWire,
|
||||
using data transfer rates in the order of 10MB/s or more.
|
||||
|
||||
Memory access is currently limited to the low 4G of physical address
|
||||
space which can be a problem on IA64 machines where memory is located
|
||||
mostly above that limit, but it is rarely a problem on more common
|
||||
hardware such as hardware based on x86, x86-64 and PowerPC.
|
||||
With most FireWire controllers, memory access is limited to the low 4 GB
|
||||
of physical address space. This can be a problem on IA64 machines where
|
||||
memory is located mostly above that limit, but it is rarely a problem on
|
||||
more common hardware such as x86, x86-64 and PowerPC. However, at least
|
||||
Agere/LSI FW643e and FW643e2 controllers are known to support access to
|
||||
physical addresses above 4 GB.
|
||||
|
||||
Together with a early initialization of the OHCI-1394 controller for debugging,
|
||||
this facility proved most useful for examining long debugs logs in the printk
|
||||
|
@ -36,17 +38,11 @@ available (notebooks) or too slow for extensive debug information (like ACPI).
|
|||
Drivers
|
||||
-------
|
||||
|
||||
The ohci1394 driver in drivers/ieee1394 initializes the OHCI-1394 controllers
|
||||
to a working state and enables physical DMA by default for all remote nodes.
|
||||
This can be turned off by ohci1394's module parameter phys_dma=0.
|
||||
|
||||
The alternative firewire-ohci driver in drivers/firewire uses filtered physical
|
||||
The firewire-ohci driver in drivers/firewire uses filtered physical
|
||||
DMA by default, which is more secure but not suitable for remote debugging.
|
||||
Compile the driver with CONFIG_FIREWIRE_OHCI_REMOTE_DMA (Kernel hacking menu:
|
||||
Remote debugging over FireWire with firewire-ohci) to get unfiltered physical
|
||||
DMA.
|
||||
Pass the remote_dma=1 parameter to the driver to get unfiltered physical DMA.
|
||||
|
||||
Because ohci1394 and firewire-ohci depend on the PCI enumeration to be
|
||||
Because the firewire-ohci driver depends on the PCI enumeration to be
|
||||
completed, an initialization routine which runs pretty early has been
|
||||
implemented for x86. This routine runs long before console_init() can be
|
||||
called, i.e. before the printk buffer appears on the console.
|
||||
|
@ -64,7 +60,7 @@ be used to view the printk buffer of a remote machine, even with live update.
|
|||
|
||||
Bernhard Kaindl enhanced firescope to support accessing 64-bit machines
|
||||
from 32-bit firescope and vice versa:
|
||||
- http://halobates.de/firewire/firescope-0.2.2.tar.bz2
|
||||
- http://v3.sk/~lkundrak/firescope/
|
||||
|
||||
and he implemented fast system dump (alpha version - read README.txt):
|
||||
- http://halobates.de/firewire/firedump-0.1.tar.bz2
|
||||
|
@ -92,11 +88,11 @@ Step-by-step instructions for using firescope with early OHCI initialization:
|
|||
|
||||
1) Verify that your hardware is supported:
|
||||
|
||||
Load the ohci1394 or the fw-ohci module and check your kernel logs.
|
||||
Load the firewire-ohci module and check your kernel logs.
|
||||
You should see a line similar to
|
||||
|
||||
ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[18] MMIO=[fe9ff800-fe9fffff]
|
||||
... Max Packet=[2048] IR/IT contexts=[4/8]
|
||||
firewire_ohci 0000:15:00.1: added OHCI v1.0 device as card 2, 4 IR + 4 IT
|
||||
... contexts, quirks 0x11
|
||||
|
||||
when loading the driver. If you have no supported controller, many PCI,
|
||||
CardBus and even some Express cards which are fully compliant to OHCI-1394
|
||||
|
@ -105,6 +101,9 @@ Step-by-step instructions for using firescope with early OHCI initialization:
|
|||
compliant, they are based on TI PCILynx chips and require drivers for Win-
|
||||
dows operating systems.
|
||||
|
||||
The mentioned kernel log message contains ">4 GB phys DMA" in case of
|
||||
OHCI-1394 controllers which support accesses above this limit.
|
||||
|
||||
2) Establish a working FireWire cable connection:
|
||||
|
||||
Any FireWire cable, as long at it provides electrically and mechanically
|
||||
|
@ -113,20 +112,18 @@ Step-by-step instructions for using firescope with early OHCI initialization:
|
|||
|
||||
If an driver is running on both machines you should see a line like
|
||||
|
||||
ieee1394: Node added: ID:BUS[0-01:1023] GUID[0090270001b84bba]
|
||||
firewire_core 0000:15:00.1: created device fw1: GUID 00061b0020105917, S400
|
||||
|
||||
on both machines in the kernel log when the cable is plugged in
|
||||
and connects the two machines.
|
||||
|
||||
3) Test physical DMA using firescope:
|
||||
|
||||
On the debug host,
|
||||
- load the raw1394 module,
|
||||
- make sure that /dev/raw1394 is accessible,
|
||||
On the debug host, make sure that /dev/fw* is accessible,
|
||||
then start firescope:
|
||||
|
||||
$ firescope
|
||||
Port 0 (ohci1394) opened, 2 nodes detected
|
||||
Port 0 (/dev/fw1) opened, 2 nodes detected
|
||||
|
||||
FireScope
|
||||
---------
|
||||
|
|
|
@ -40,8 +40,11 @@ on hit count on entry. The policy aims to take different cache miss
|
|||
costs into account and to adjust to varying load patterns automatically.
|
||||
|
||||
Message and constructor argument pairs are:
|
||||
'sequential_threshold <#nr_sequential_ios>' and
|
||||
'random_threshold <#nr_random_ios>'.
|
||||
'sequential_threshold <#nr_sequential_ios>'
|
||||
'random_threshold <#nr_random_ios>'
|
||||
'read_promote_adjustment <value>'
|
||||
'write_promote_adjustment <value>'
|
||||
'discard_promote_adjustment <value>'
|
||||
|
||||
The sequential threshold indicates the number of contiguous I/Os
|
||||
required before a stream is treated as sequential. The random threshold
|
||||
|
@ -55,6 +58,15 @@ since spindles tend to have good bandwidth. The io_tracker counts
|
|||
contiguous I/Os to try to spot when the io is in one of these sequential
|
||||
modes.
|
||||
|
||||
Internally the mq policy maintains a promotion threshold variable. If
|
||||
the hit count of a block not in the cache goes above this threshold it
|
||||
gets promoted to the cache. The read, write and discard promote adjustment
|
||||
tunables allow you to tweak the promotion threshold by adding a small
|
||||
value based on the io type. They default to 4, 8 and 1 respectively.
|
||||
If you're trying to quickly warm a new cache device you may wish to
|
||||
reduce these to encourage promotion. Remember to switch them back to
|
||||
their defaults after the cache fills though.
|
||||
|
||||
cleaner
|
||||
-------
|
||||
|
||||
|
|
|
@ -124,12 +124,11 @@ the default being 204800 sectors (or 100MB).
|
|||
Updating on-disk metadata
|
||||
-------------------------
|
||||
|
||||
On-disk metadata is committed every time a REQ_SYNC or REQ_FUA bio is
|
||||
written. If no such requests are made then commits will occur every
|
||||
second. This means the cache behaves like a physical disk that has a
|
||||
write cache (the same is true of the thin-provisioning target). If
|
||||
power is lost you may lose some recent writes. The metadata should
|
||||
always be consistent in spite of any crash.
|
||||
On-disk metadata is committed every time a FLUSH or FUA bio is written.
|
||||
If no such requests are made then commits will occur every second. This
|
||||
means the cache behaves like a physical disk that has a volatile write
|
||||
cache. If power is lost you may lose some recent writes. The metadata
|
||||
should always be consistent in spite of any crash.
|
||||
|
||||
The 'dirty' state for a cache block changes far too frequently for us
|
||||
to keep updating it on the fly. So we treat it as a hint. In normal
|
||||
|
@ -217,36 +216,43 @@ the characteristics of a specific policy, always request it by name.
|
|||
Status
|
||||
------
|
||||
|
||||
<#used metadata blocks>/<#total metadata blocks> <#read hits> <#read misses>
|
||||
<#write hits> <#write misses> <#demotions> <#promotions> <#blocks in cache>
|
||||
<#dirty> <#features> <features>* <#core args> <core args>* <#policy args>
|
||||
<policy args>*
|
||||
<metadata block size> <#used metadata blocks>/<#total metadata blocks>
|
||||
<cache block size> <#used cache blocks>/<#total cache blocks>
|
||||
<#read hits> <#read misses> <#write hits> <#write misses>
|
||||
<#demotions> <#promotions> <#dirty> <#features> <features>*
|
||||
<#core args> <core args>* <policy name> <#policy args> <policy args>*
|
||||
|
||||
#used metadata blocks : Number of metadata blocks used
|
||||
#total metadata blocks : Total number of metadata blocks
|
||||
#read hits : Number of times a READ bio has been mapped
|
||||
metadata block size : Fixed block size for each metadata block in
|
||||
sectors
|
||||
#used metadata blocks : Number of metadata blocks used
|
||||
#total metadata blocks : Total number of metadata blocks
|
||||
cache block size : Configurable block size for the cache device
|
||||
in sectors
|
||||
#used cache blocks : Number of blocks resident in the cache
|
||||
#total cache blocks : Total number of cache blocks
|
||||
#read hits : Number of times a READ bio has been mapped
|
||||
to the cache
|
||||
#read misses : Number of times a READ bio has been mapped
|
||||
#read misses : Number of times a READ bio has been mapped
|
||||
to the origin
|
||||
#write hits : Number of times a WRITE bio has been mapped
|
||||
#write hits : Number of times a WRITE bio has been mapped
|
||||
to the cache
|
||||
#write misses : Number of times a WRITE bio has been
|
||||
#write misses : Number of times a WRITE bio has been
|
||||
mapped to the origin
|
||||
#demotions : Number of times a block has been removed
|
||||
#demotions : Number of times a block has been removed
|
||||
from the cache
|
||||
#promotions : Number of times a block has been moved to
|
||||
#promotions : Number of times a block has been moved to
|
||||
the cache
|
||||
#blocks in cache : Number of blocks resident in the cache
|
||||
#dirty : Number of blocks in the cache that differ
|
||||
#dirty : Number of blocks in the cache that differ
|
||||
from the origin
|
||||
#feature args : Number of feature args to follow
|
||||
feature args : 'writethrough' (optional)
|
||||
#core args : Number of core arguments (must be even)
|
||||
core args : Key/value pairs for tuning the core
|
||||
#feature args : Number of feature args to follow
|
||||
feature args : 'writethrough' (optional)
|
||||
#core args : Number of core arguments (must be even)
|
||||
core args : Key/value pairs for tuning the core
|
||||
e.g. migration_threshold
|
||||
#policy args : Number of policy arguments to follow (must be even)
|
||||
policy args : Key/value pairs
|
||||
e.g. 'sequential_threshold 1024
|
||||
policy name : Name of the policy
|
||||
#policy args : Number of policy arguments to follow (must be even)
|
||||
policy args : Key/value pairs
|
||||
e.g. sequential_threshold
|
||||
|
||||
Messages
|
||||
--------
|
||||
|
|
|
@ -116,6 +116,35 @@ 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.
|
||||
|
||||
A low water mark for the metadata device is maintained in the kernel and
|
||||
will trigger a dm event if free space on the metadata device drops below
|
||||
it.
|
||||
|
||||
Updating on-disk metadata
|
||||
-------------------------
|
||||
|
||||
On-disk metadata is committed every time a FLUSH or FUA bio is written.
|
||||
If no such requests are made then commits will occur every second. This
|
||||
means the thin-provisioning target behaves like a physical disk that has
|
||||
a volatile write cache. If power is lost you may lose some recent
|
||||
writes. The metadata should always be consistent in spite of any crash.
|
||||
|
||||
If data space is exhausted the pool will either error or queue IO
|
||||
according to the configuration (see: error_if_no_space). If metadata
|
||||
space is exhausted or a metadata operation fails: the pool will error IO
|
||||
until the pool is taken offline and repair is performed to 1) fix any
|
||||
potential inconsistencies and 2) clear the flag that imposes repair.
|
||||
Once the pool's metadata device is repaired it may be resized, which
|
||||
will allow the pool to return to normal operation. Note that if a pool
|
||||
is flagged as needing repair, the pool's data and metadata devices
|
||||
cannot be resized until repair is performed. It should also be noted
|
||||
that when the pool's metadata space is exhausted the current metadata
|
||||
transaction is aborted. Given that the pool will cache IO whose
|
||||
completion may have already been acknowledged to upper IO layers
|
||||
(e.g. filesystem) it is strongly suggested that consistency checks
|
||||
(e.g. fsck) be performed on those layers when repair of the pool is
|
||||
required.
|
||||
|
||||
Thin provisioning
|
||||
-----------------
|
||||
|
||||
|
@ -235,6 +264,8 @@ i) Constructor
|
|||
read_only: Don't allow any changes to be made to the pool
|
||||
metadata.
|
||||
|
||||
error_if_no_space: Error IOs, instead of queueing, if no space.
|
||||
|
||||
Data block size must be between 64KB (128 sectors) and 1GB
|
||||
(2097152 sectors) inclusive.
|
||||
|
||||
|
@ -256,10 +287,9 @@ ii) Status
|
|||
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
|
||||
The location, in blocks, 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.
|
||||
held root.
|
||||
|
||||
discard_passdown|no_discard_passdown
|
||||
Whether or not discards are actually being passed down to the
|
||||
|
@ -276,6 +306,11 @@ ii) Status
|
|||
contain the string 'Fail'. The userspace recovery tools
|
||||
should then be used.
|
||||
|
||||
error_if_no_space|queue_if_no_space
|
||||
If the pool runs out of data or metadata space, the pool will
|
||||
either queue or error the IO destined to the data device. The
|
||||
default is to queue the IO until more space is added.
|
||||
|
||||
iii) Messages
|
||||
|
||||
create_thin <dev id>
|
||||
|
|
|
@ -409,6 +409,7 @@ Your cooperation is appreciated.
|
|||
193 = /dev/d7s SPARC 7-segment display
|
||||
194 = /dev/zkshim Zero-Knowledge network shim control
|
||||
195 = /dev/elographics/e2201 Elographics touchscreen E271-2201
|
||||
196 = /dev/vfio/vfio VFIO userspace driver interface
|
||||
198 = /dev/sexec Signed executable interface
|
||||
199 = /dev/scanners/cuecat :CueCat barcode scanner
|
||||
200 = /dev/net/tun TAP/TUN network device
|
||||
|
|
|
@ -8,3 +8,5 @@ https://lists.ozlabs.org/listinfo/devicetree-discuss
|
|||
- this file
|
||||
booting-without-of.txt
|
||||
- Booting Linux without Open Firmware, describes history and format of device trees.
|
||||
usage-model.txt
|
||||
- How Linux uses DT and what DT aims to solve.
|
39
Documentation/devicetree/bindings/ABI.txt
Normal file
39
Documentation/devicetree/bindings/ABI.txt
Normal file
|
@ -0,0 +1,39 @@
|
|||
|
||||
Devicetree (DT) ABI
|
||||
|
||||
I. Regarding stable bindings/ABI, we quote from the 2013 ARM mini-summit
|
||||
summary document:
|
||||
|
||||
"That still leaves the question of, what does a stable binding look
|
||||
like? Certainly a stable binding means that a newer kernel will not
|
||||
break on an older device tree, but that doesn't mean the binding is
|
||||
frozen for all time. Grant said there are ways to change bindings that
|
||||
don't result in breakage. For instance, if a new property is added,
|
||||
then default to the previous behaviour if it is missing. If a binding
|
||||
truly needs an incompatible change, then change the compatible string
|
||||
at the same time. The driver can bind against both the old and the
|
||||
new. These guidelines aren't new, but they desperately need to be
|
||||
documented."
|
||||
|
||||
II. General binding rules
|
||||
|
||||
1) Maintainers, don't let perfect be the enemy of good. Don't hold up a
|
||||
binding because it isn't perfect.
|
||||
|
||||
2) Use specific compatible strings so that if we need to add a feature (DMA)
|
||||
in the future, we can create a new compatible string. See I.
|
||||
|
||||
3) Bindings can be augmented, but the driver shouldn't break when given
|
||||
the old binding. ie. add additional properties, but don't change the
|
||||
meaning of an existing property. For drivers, default to the original
|
||||
behaviour when a newly added property is missing.
|
||||
|
||||
4) Don't submit bindings for staging or unstable. That will be decided by
|
||||
the devicetree maintainers *after* discussion on the mailinglist.
|
||||
|
||||
III. Notes
|
||||
|
||||
1) This document is intended as a general familiarization with the process as
|
||||
decided at the 2013 Kernel Summit. When in doubt, the current word of the
|
||||
devicetree maintainers overrules this document. In that situation, a patch
|
||||
updating this document would be appreciated.
|
|
@ -14,6 +14,9 @@ Required nodes:
|
|||
- core-module: the root node to the Integrator platforms must have
|
||||
a core-module with regs and the compatible string
|
||||
"arm,core-module-integrator"
|
||||
- external-bus-interface: the root node to the Integrator platforms
|
||||
must have an external bus interface with regs and the
|
||||
compatible-string "arm,external-bus-interface"
|
||||
|
||||
Required properties for the core module:
|
||||
- regs: the location and size of the core module registers, one
|
||||
|
@ -48,6 +51,11 @@ Required nodes:
|
|||
reg = <0x10000000 0x200>;
|
||||
};
|
||||
|
||||
ebi@12000000 {
|
||||
compatible = "arm,external-bus-interface";
|
||||
reg = <0x12000000 0x100>;
|
||||
};
|
||||
|
||||
syscon {
|
||||
compatible = "arm,integrator-ap-syscon";
|
||||
reg = <0x11000000 0x100>;
|
||||
|
|
|
@ -2,6 +2,7 @@
|
|||
|
||||
Required properties:
|
||||
- compatible: Should be "atmel,<chip>-aic"
|
||||
<chip> can be "at91rm9200" or "sama5d3"
|
||||
- interrupt-controller: Identifies the node as an interrupt controller.
|
||||
- interrupt-parent: For single AIC system, it is an empty property.
|
||||
- #interrupt-cells: The number of cells to define the interrupts. It should be 3.
|
||||
|
|
|
@ -20,6 +20,10 @@ TC/TCLIB Timer required properties:
|
|||
- interrupts: Should contain all interrupts for the TC block
|
||||
Note that you can specify several interrupt cells if the TC
|
||||
block has one interrupt per channel.
|
||||
- clock-names: tuple listing input clock names.
|
||||
Required elements: "t0_clk"
|
||||
Optional elements: "t1_clk", "t2_clk"
|
||||
- clocks: phandles to input clocks.
|
||||
|
||||
Examples:
|
||||
|
||||
|
@ -28,6 +32,8 @@ One interrupt per TC block:
|
|||
compatible = "atmel,at91rm9200-tcb";
|
||||
reg = <0xfff7c000 0x100>;
|
||||
interrupts = <18 4>;
|
||||
clocks = <&tcb0_clk>;
|
||||
clock-names = "t0_clk";
|
||||
};
|
||||
|
||||
One interrupt per TC channel in a TC block:
|
||||
|
@ -35,6 +41,8 @@ One interrupt per TC channel in a TC block:
|
|||
compatible = "atmel,at91rm9200-tcb";
|
||||
reg = <0xfffdc000 0x100>;
|
||||
interrupts = <26 4 27 4 28 4>;
|
||||
clocks = <&tcb1_clk>;
|
||||
clock-names = "t0_clk";
|
||||
};
|
||||
|
||||
RSTC Reset Controller required properties:
|
||||
|
@ -50,7 +58,8 @@ Example:
|
|||
};
|
||||
|
||||
RAMC SDRAM/DDR Controller required properties:
|
||||
- compatible: Should be "atmel,at91sam9260-sdramc",
|
||||
- compatible: Should be "atmel,at91rm9200-sdramc",
|
||||
"atmel,at91sam9260-sdramc",
|
||||
"atmel,at91sam9g45-ddramc",
|
||||
- reg: Should contain registers location and length
|
||||
For at91sam9263 and at91sam9g45 you must specify 2 entries.
|
||||
|
|
|
@ -8,13 +8,18 @@ Required properties:
|
|||
- DEPRECATED: compatible : "bcm,kona-timer"
|
||||
- reg : Register range for the timer
|
||||
- interrupts : interrupt for the timer
|
||||
- clocks: phandle + clock specifier pair of the external clock
|
||||
- clock-frequency: frequency that the clock operates
|
||||
|
||||
Only one of clocks or clock-frequency should be specified.
|
||||
|
||||
Refer to clocks/clock-bindings.txt for generic clock consumer properties.
|
||||
|
||||
Example:
|
||||
timer@35006000 {
|
||||
compatible = "brcm,kona-timer";
|
||||
reg = <0x35006000 0x1000>;
|
||||
interrupts = <0x0 7 0x4>;
|
||||
clock-frequency = <32768>;
|
||||
clocks = <&hub_timer_clk>;
|
||||
};
|
||||
|
||||
|
|
|
@ -1,46 +0,0 @@
|
|||
* Texas Instruments Davinci NAND
|
||||
|
||||
This file provides information, what the device node for the
|
||||
davinci nand interface contain.
|
||||
|
||||
Required properties:
|
||||
- compatible: "ti,davinci-nand";
|
||||
- reg : contain 2 offset/length values:
|
||||
- offset and length for the access window
|
||||
- offset and length for accessing the aemif control registers
|
||||
- ti,davinci-chipselect: Indicates on the davinci_nand driver which
|
||||
chipselect is used for accessing the nand.
|
||||
|
||||
Recommended properties :
|
||||
- ti,davinci-mask-ale: mask for ale
|
||||
- ti,davinci-mask-cle: mask for cle
|
||||
- ti,davinci-mask-chipsel: mask for chipselect
|
||||
- ti,davinci-ecc-mode: ECC mode valid values for davinci driver:
|
||||
- "none"
|
||||
- "soft"
|
||||
- "hw"
|
||||
- ti,davinci-ecc-bits: used ECC bits, currently supported 1 or 4.
|
||||
- ti,davinci-nand-buswidth: buswidth 8 or 16
|
||||
- ti,davinci-nand-use-bbt: use flash based bad block table support.
|
||||
|
||||
nand device bindings may contain additional sub-nodes describing
|
||||
partitions of the address space. See partition.txt for more detail.
|
||||
|
||||
Example(da850 EVM ):
|
||||
nand_cs3@62000000 {
|
||||
compatible = "ti,davinci-nand";
|
||||
reg = <0x62000000 0x807ff
|
||||
0x68000000 0x8000>;
|
||||
ti,davinci-chipselect = <1>;
|
||||
ti,davinci-mask-ale = <0>;
|
||||
ti,davinci-mask-cle = <0>;
|
||||
ti,davinci-mask-chipsel = <0>;
|
||||
ti,davinci-ecc-mode = "hw";
|
||||
ti,davinci-ecc-bits = <4>;
|
||||
ti,davinci-nand-use-bbt;
|
||||
|
||||
partition@180000 {
|
||||
label = "ubifs";
|
||||
reg = <0x180000 0x7e80000>;
|
||||
};
|
||||
};
|
|
@ -0,0 +1,20 @@
|
|||
Trusted Foundations
|
||||
-------------------
|
||||
|
||||
Boards that use the Trusted Foundations secure monitor can signal its
|
||||
presence by declaring a node compatible with "tlm,trusted-foundations"
|
||||
under the /firmware/ node
|
||||
|
||||
Required properties:
|
||||
- compatible: "tlm,trusted-foundations"
|
||||
- tlm,version-major: major version number of Trusted Foundations firmware
|
||||
- tlm,version-minor: minor version number of Trusted Foundations firmware
|
||||
|
||||
Example:
|
||||
firmware {
|
||||
trusted-foundations {
|
||||
compatible = "tlm,trusted-foundations";
|
||||
tlm,version-major = <2>;
|
||||
tlm,version-minor = <8>;
|
||||
};
|
||||
};
|
|
@ -11,6 +11,7 @@ have PPIs or SGIs.
|
|||
Main node required properties:
|
||||
|
||||
- compatible : should be one of:
|
||||
"arm,gic-400"
|
||||
"arm,cortex-a15-gic"
|
||||
"arm,cortex-a9-gic"
|
||||
"arm,cortex-a7-gic"
|
||||
|
|
|
@ -0,0 +1,32 @@
|
|||
Hisilicon Platforms Device Tree Bindings
|
||||
----------------------------------------------------
|
||||
|
||||
Hi4511 Board
|
||||
Required root node properties:
|
||||
- compatible = "hisilicon,hi3620-hi4511";
|
||||
|
||||
Hisilicon system controller
|
||||
|
||||
Required properties:
|
||||
- compatible : "hisilicon,sysctrl"
|
||||
- reg : Register address and size
|
||||
|
||||
Optional properties:
|
||||
- smp-offset : offset in sysctrl for notifying slave cpu booting
|
||||
cpu 1, reg;
|
||||
cpu 2, reg + 0x4;
|
||||
cpu 3, reg + 0x8;
|
||||
If reg value is not zero, cpun exit wfi and go
|
||||
- resume-offset : offset in sysctrl for notifying cpu0 when resume
|
||||
- reboot-offset : offset in sysctrl for system reboot
|
||||
|
||||
Example:
|
||||
|
||||
/* for Hi3620 */
|
||||
sysctrl: system-controller@fc802000 {
|
||||
compatible = "hisilicon,sysctrl";
|
||||
reg = <0xfc802000 0x1000>;
|
||||
smp-offset = <0x31c>;
|
||||
resume-offset = <0x308>;
|
||||
reboot-offset = <0x4>;
|
||||
};
|
|
@ -7,20 +7,21 @@ 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"
|
||||
"marvell,aurora-system-cache": Marvell Controller designed to be
|
||||
"arm,pl310-cache"
|
||||
"arm,l220-cache"
|
||||
"arm,l210-cache"
|
||||
"bcm,bcm11351-a2-pl310-cache": DEPRECATED by "brcm,bcm11351-a2-pl310-cache"
|
||||
"brcm,bcm11351-a2-pl310-cache": For Broadcom bcm11351 chipset where an
|
||||
offset needs to be added to the address before passing down to the L2
|
||||
cache controller
|
||||
"marvell,aurora-system-cache": Marvell Controller designed to be
|
||||
compatible with the ARM one, with system cache mode (meaning
|
||||
maintenance operations on L1 are broadcasted to the L2 and L2
|
||||
performs the same operation).
|
||||
"marvell,"aurora-outer-cache: Marvell Controller designed to be
|
||||
compatible with the ARM one with outer cache mode.
|
||||
"brcm,bcm11351-a2-pl310-cache": For Broadcom bcm11351 chipset where an
|
||||
offset needs to be added to the address before passing down to the L2
|
||||
cache controller
|
||||
"bcm,bcm11351-a2-pl310-cache": DEPRECATED by
|
||||
"brcm,bcm11351-a2-pl310-cache"
|
||||
"marvell,aurora-outer-cache": Marvell Controller designed to be
|
||||
compatible with the ARM one with outer cache mode.
|
||||
"marvell,tauros3-cache": Marvell Tauros3 cache controller, compatible
|
||||
with arm,pl310-cache controller.
|
||||
- cache-unified : Specifies the cache is a unified cache.
|
||||
- cache-level : Should be set to 2 for a level 2 cache.
|
||||
- reg : Physical base address and size of cache controller's memory mapped
|
||||
|
|
24
Documentation/devicetree/bindings/arm/marvell,berlin.txt
Normal file
24
Documentation/devicetree/bindings/arm/marvell,berlin.txt
Normal file
|
@ -0,0 +1,24 @@
|
|||
Marvell Berlin SoC Family Device Tree Bindings
|
||||
---------------------------------------------------------------
|
||||
|
||||
Boards with a SoC of the Marvell Berlin family, e.g. Armada 1500
|
||||
shall have the following properties:
|
||||
|
||||
* Required root node properties:
|
||||
compatible: must contain "marvell,berlin"
|
||||
|
||||
In addition, the above compatible shall be extended with the specific
|
||||
SoC and board used. Currently known SoC compatibles are:
|
||||
"marvell,berlin2" for Marvell Armada 1500 (BG2, 88DE3100),
|
||||
"marvell,berlin2cd" for Marvell Armada 1500-mini (BG2CD, 88DE3005)
|
||||
"marvell,berlin2ct" for Marvell Armada ? (BG2CT, 88DE????)
|
||||
"marvell,berlin3" for Marvell Armada ? (BG3, 88DE????)
|
||||
|
||||
* Example:
|
||||
|
||||
/ {
|
||||
model = "Sony NSZ-GS7";
|
||||
compatible = "sony,nsz-gs7", "marvell,berlin2", "marvell,berlin";
|
||||
|
||||
...
|
||||
}
|
12
Documentation/devicetree/bindings/arm/moxart.txt
Normal file
12
Documentation/devicetree/bindings/arm/moxart.txt
Normal file
|
@ -0,0 +1,12 @@
|
|||
MOXA ART device tree bindings
|
||||
|
||||
Boards with the MOXA ART SoC shall have the following properties:
|
||||
|
||||
Required root node property:
|
||||
|
||||
compatible = "moxa,moxart";
|
||||
|
||||
Boards:
|
||||
|
||||
- UC-7112-LX: embedded computer
|
||||
compatible = "moxa,moxart-uc-7112-lx", "moxa,moxart"
|
|
@ -31,6 +31,59 @@ spinlock@1 {
|
|||
ti,hwmods = "spinlock";
|
||||
};
|
||||
|
||||
SoC Type (optional):
|
||||
|
||||
- General Purpose devices
|
||||
compatible = "ti,gp"
|
||||
- High Security devices
|
||||
compatible = "ti,hs"
|
||||
|
||||
SoC Families:
|
||||
|
||||
- OMAP2 generic - defaults to OMAP2420
|
||||
compatible = "ti,omap2"
|
||||
- OMAP3 generic - defaults to OMAP3430
|
||||
compatible = "ti,omap3"
|
||||
- OMAP4 generic - defaults to OMAP4430
|
||||
compatible = "ti,omap4"
|
||||
- OMAP5 generic - defaults to OMAP5430
|
||||
compatible = "ti,omap5"
|
||||
- DRA7 generic - defaults to DRA742
|
||||
compatible = "ti,dra7"
|
||||
- AM43x generic - defaults to AM4372
|
||||
compatible = "ti,am43"
|
||||
|
||||
SoCs:
|
||||
|
||||
- OMAP2420
|
||||
compatible = "ti,omap2420", "ti,omap2"
|
||||
- OMAP2430
|
||||
compatible = "ti,omap2430", "ti,omap2"
|
||||
|
||||
- OMAP3430
|
||||
compatible = "ti,omap3430", "ti,omap3"
|
||||
- AM3517
|
||||
compatible = "ti,am3517", "ti,omap3"
|
||||
- OMAP3630
|
||||
compatible = "ti,omap36xx", "ti,omap3"
|
||||
- AM33xx
|
||||
compatible = "ti,am33xx", "ti,omap3"
|
||||
|
||||
- OMAP4430
|
||||
compatible = "ti,omap4430", "ti,omap4"
|
||||
- OMAP4460
|
||||
compatible = "ti,omap4460", "ti,omap4"
|
||||
|
||||
- OMAP5430
|
||||
compatible = "ti,omap5430", "ti,omap5"
|
||||
- OMAP5432
|
||||
compatible = "ti,omap5432", "ti,omap5"
|
||||
|
||||
- DRA742
|
||||
compatible = "ti,dra7xx", "ti,dra7"
|
||||
|
||||
- AM4372
|
||||
compatible = "ti,am4372", "ti,am43"
|
||||
|
||||
Boards:
|
||||
|
||||
|
@ -38,7 +91,7 @@ Boards:
|
|||
compatible = "ti,omap3-beagle", "ti,omap3"
|
||||
|
||||
- OMAP3 Tobi with Overo : Commercial expansion board with daughter board
|
||||
compatible = "ti,omap3-tobi", "ti,omap3-overo", "ti,omap3"
|
||||
compatible = "gumstix,omap3-overo-tobi", "gumstix,omap3-overo", "ti,omap3"
|
||||
|
||||
- OMAP4 SDP : Software Development Board
|
||||
compatible = "ti,omap4-sdp", "ti,omap4430"
|
||||
|
|
|
@ -1,7 +1,12 @@
|
|||
SAMSUNG S5P/Exynos SoC series System Registers (SYSREG)
|
||||
|
||||
Properties:
|
||||
- name : should be 'sysreg';
|
||||
- compatible : should contain "samsung,<chip name>-sysreg", "syscon";
|
||||
For Exynos4 SoC series it should be "samsung,exynos4-sysreg", "syscon";
|
||||
- reg : offset and length of the register set.
|
||||
|
||||
Example:
|
||||
syscon@10010000 {
|
||||
compatible = "samsung,exynos4-sysreg", "syscon";
|
||||
reg = <0x10010000 0x400>;
|
||||
};
|
||||
|
|
|
@ -32,3 +32,8 @@ board-specific compatible values:
|
|||
nvidia,whistler
|
||||
toradex,colibri_t20-512
|
||||
toradex,iris
|
||||
|
||||
Trusted Foundations
|
||||
-------------------------------------------
|
||||
Tegra supports the Trusted Foundation secure monitor. See the
|
||||
"tlm,trusted-foundations" binding's documentation for more details.
|
||||
|
|
|
@ -29,3 +29,8 @@ pic: pic@14000000 {
|
|||
clear-mask = <0xffffffff>;
|
||||
valid-mask = <0x003fffff>;
|
||||
};
|
||||
|
||||
Optional properties:
|
||||
- interrupts: if the FPGA IRQ controller is cascaded, i.e. if its IRQ
|
||||
output is simply connected to the input of another IRQ controller,
|
||||
then the parent IRQ shall be specified in this property.
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
* Marvell Orion SATA
|
||||
|
||||
Required Properties:
|
||||
- compatibility : "marvell,orion-sata"
|
||||
- compatibility : "marvell,orion-sata" or "marvell,armada-370-sata"
|
||||
- reg : Address range of controller
|
||||
- interrupts : Interrupt controller is using
|
||||
- nr-ports : Number of SATA ports in use.
|
||||
|
|
18
Documentation/devicetree/bindings/ata/sata_rcar.txt
Normal file
18
Documentation/devicetree/bindings/ata/sata_rcar.txt
Normal file
|
@ -0,0 +1,18 @@
|
|||
* Renesas R-Car SATA
|
||||
|
||||
Required properties:
|
||||
- compatible : should contain one of the following:
|
||||
- "renesas,sata-r8a7779" for R-Car H1
|
||||
- "renesas,sata-r8a7790" for R-Car H2
|
||||
- "renesas,sata-r8a7791" for R-Car M2
|
||||
- reg : address and length of the SATA registers;
|
||||
- interrupts : must consist of one interrupt specifier.
|
||||
|
||||
Example:
|
||||
|
||||
sata: sata@fc600000 {
|
||||
compatible = "renesas,sata-r8a7779";
|
||||
reg = <0xfc600000 0x2000>;
|
||||
interrupt-parent = <&gic>;
|
||||
interrupts = <0 100 IRQ_TYPE_LEVEL_HIGH>;
|
||||
};
|
339
Documentation/devicetree/bindings/clock/at91-clock.txt
Normal file
339
Documentation/devicetree/bindings/clock/at91-clock.txt
Normal file
|
@ -0,0 +1,339 @@
|
|||
Device Tree Clock bindings for arch-at91
|
||||
|
||||
This binding uses the common clock binding[1].
|
||||
|
||||
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
|
||||
|
||||
Required properties:
|
||||
- compatible : shall be one of the following:
|
||||
"atmel,at91rm9200-pmc" or
|
||||
"atmel,at91sam9g45-pmc" or
|
||||
"atmel,at91sam9n12-pmc" or
|
||||
"atmel,at91sam9x5-pmc" or
|
||||
"atmel,sama5d3-pmc":
|
||||
at91 PMC (Power Management Controller)
|
||||
All at91 specific clocks (clocks defined below) must be child
|
||||
node of the PMC node.
|
||||
|
||||
"atmel,at91rm9200-clk-main":
|
||||
at91 main oscillator
|
||||
|
||||
"atmel,at91rm9200-clk-master" or
|
||||
"atmel,at91sam9x5-clk-master":
|
||||
at91 master clock
|
||||
|
||||
"atmel,at91sam9x5-clk-peripheral" or
|
||||
"atmel,at91rm9200-clk-peripheral":
|
||||
at91 peripheral clocks
|
||||
|
||||
"atmel,at91rm9200-clk-pll" or
|
||||
"atmel,at91sam9g45-clk-pll" or
|
||||
"atmel,at91sam9g20-clk-pllb" or
|
||||
"atmel,sama5d3-clk-pll":
|
||||
at91 pll clocks
|
||||
|
||||
"atmel,at91sam9x5-clk-plldiv":
|
||||
at91 plla divisor
|
||||
|
||||
"atmel,at91rm9200-clk-programmable" or
|
||||
"atmel,at91sam9g45-clk-programmable" or
|
||||
"atmel,at91sam9x5-clk-programmable":
|
||||
at91 programmable clocks
|
||||
|
||||
"atmel,at91sam9x5-clk-smd":
|
||||
at91 SMD (Soft Modem) clock
|
||||
|
||||
"atmel,at91rm9200-clk-system":
|
||||
at91 system clocks
|
||||
|
||||
"atmel,at91rm9200-clk-usb" or
|
||||
"atmel,at91sam9x5-clk-usb" or
|
||||
"atmel,at91sam9n12-clk-usb":
|
||||
at91 usb clock
|
||||
|
||||
"atmel,at91sam9x5-clk-utmi":
|
||||
at91 utmi clock
|
||||
|
||||
Required properties for PMC node:
|
||||
- reg : defines the IO memory reserved for the PMC.
|
||||
- #size-cells : shall be 0 (reg is used to encode clk id).
|
||||
- #address-cells : shall be 1 (reg is used to encode clk id).
|
||||
- interrupts : shall be set to PMC interrupt line.
|
||||
- interrupt-controller : tell that the PMC is an interrupt controller.
|
||||
- #interrupt-cells : must be set to 1. The first cell encodes the interrupt id,
|
||||
and reflect the bit position in the PMC_ER/DR/SR registers.
|
||||
You can use the dt macros defined in dt-bindings/clk/at91.h.
|
||||
0 (AT91_PMC_MOSCS) -> main oscillator ready
|
||||
1 (AT91_PMC_LOCKA) -> PLL A ready
|
||||
2 (AT91_PMC_LOCKB) -> PLL B ready
|
||||
3 (AT91_PMC_MCKRDY) -> master clock ready
|
||||
6 (AT91_PMC_LOCKU) -> UTMI PLL clock ready
|
||||
8 .. 15 (AT91_PMC_PCKRDY(id)) -> programmable clock ready
|
||||
16 (AT91_PMC_MOSCSELS) -> main oscillator selected
|
||||
17 (AT91_PMC_MOSCRCS) -> RC main oscillator stabilized
|
||||
18 (AT91_PMC_CFDEV) -> clock failure detected
|
||||
|
||||
For example:
|
||||
pmc: pmc@fffffc00 {
|
||||
compatible = "atmel,sama5d3-pmc";
|
||||
interrupts = <1 4 7>;
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <2>;
|
||||
#size-cells = <0>;
|
||||
#address-cells = <1>;
|
||||
|
||||
/* put at91 clocks here */
|
||||
};
|
||||
|
||||
Required properties for main clock:
|
||||
- interrupt-parent : must reference the PMC node.
|
||||
- interrupts : shall be set to "<0>".
|
||||
- #clock-cells : from common clock binding; shall be set to 0.
|
||||
- clocks (optional if clock-frequency is provided) : shall be the slow clock
|
||||
phandle. This clock is used to calculate the main clock rate if
|
||||
"clock-frequency" is not provided.
|
||||
- clock-frequency : the main oscillator frequency.Prefer the use of
|
||||
"clock-frequency" over automatic clock rate calculation.
|
||||
|
||||
For example:
|
||||
main: mainck {
|
||||
compatible = "atmel,at91rm9200-clk-main";
|
||||
interrupt-parent = <&pmc>;
|
||||
interrupts = <0>;
|
||||
#clock-cells = <0>;
|
||||
clocks = <&ck32k>;
|
||||
clock-frequency = <18432000>;
|
||||
};
|
||||
|
||||
Required properties for master clock:
|
||||
- interrupt-parent : must reference the PMC node.
|
||||
- interrupts : shall be set to "<3>".
|
||||
- #clock-cells : from common clock binding; shall be set to 0.
|
||||
- clocks : shall be the master clock sources (see atmel datasheet) phandles.
|
||||
e.g. "<&ck32k>, <&main>, <&plla>, <&pllb>".
|
||||
- atmel,clk-output-range : minimum and maximum clock frequency (two u32
|
||||
fields).
|
||||
e.g. output = <0 133000000>; <=> 0 to 133MHz.
|
||||
- atmel,clk-divisors : master clock divisors table (four u32 fields).
|
||||
0 <=> reserved value.
|
||||
e.g. divisors = <1 2 4 6>;
|
||||
- atmel,master-clk-have-div3-pres : some SoC use the reserved value 7 in the
|
||||
PRES field as CLOCK_DIV3 (e.g sam9x5).
|
||||
|
||||
For example:
|
||||
mck: mck {
|
||||
compatible = "atmel,at91rm9200-clk-master";
|
||||
interrupt-parent = <&pmc>;
|
||||
interrupts = <3>;
|
||||
#clock-cells = <0>;
|
||||
atmel,clk-output-range = <0 133000000>;
|
||||
atmel,clk-divisors = <1 2 4 0>;
|
||||
};
|
||||
|
||||
Required properties for peripheral clocks:
|
||||
- #size-cells : shall be 0 (reg is used to encode clk id).
|
||||
- #address-cells : shall be 1 (reg is used to encode clk id).
|
||||
- clocks : shall be the master clock phandle.
|
||||
e.g. clocks = <&mck>;
|
||||
- name: device tree node describing a specific system clock.
|
||||
* #clock-cells : from common clock binding; shall be set to 0.
|
||||
* reg: peripheral id. See Atmel's datasheets to get a full
|
||||
list of peripheral ids.
|
||||
* atmel,clk-output-range : minimum and maximum clock frequency
|
||||
(two u32 fields). Only valid on at91sam9x5-clk-peripheral
|
||||
compatible IPs.
|
||||
|
||||
For example:
|
||||
periph: periphck {
|
||||
compatible = "atmel,at91sam9x5-clk-peripheral";
|
||||
#size-cells = <0>;
|
||||
#address-cells = <1>;
|
||||
clocks = <&mck>;
|
||||
|
||||
ssc0_clk {
|
||||
#clock-cells = <0>;
|
||||
reg = <2>;
|
||||
atmel,clk-output-range = <0 133000000>;
|
||||
};
|
||||
|
||||
usart0_clk {
|
||||
#clock-cells = <0>;
|
||||
reg = <3>;
|
||||
atmel,clk-output-range = <0 66000000>;
|
||||
};
|
||||
};
|
||||
|
||||
|
||||
Required properties for pll clocks:
|
||||
- interrupt-parent : must reference the PMC node.
|
||||
- interrupts : shall be set to "<1>".
|
||||
- #clock-cells : from common clock binding; shall be set to 0.
|
||||
- clocks : shall be the main clock phandle.
|
||||
- reg : pll id.
|
||||
0 -> PLL A
|
||||
1 -> PLL B
|
||||
- atmel,clk-input-range : minimum and maximum source clock frequency (two u32
|
||||
fields).
|
||||
e.g. input = <1 32000000>; <=> 1 to 32MHz.
|
||||
- #atmel,pll-clk-output-range-cells : number of cells reserved for pll output
|
||||
range description. Sould be set to 2, 3
|
||||
or 4.
|
||||
* 1st and 2nd cells represent the frequency range (min-max).
|
||||
* 3rd cell is optional and represents the OUT field value for the given
|
||||
range.
|
||||
* 4th cell is optional and represents the ICPLL field (PLLICPR
|
||||
register)
|
||||
- atmel,pll-clk-output-ranges : pll output frequency ranges + optional parameter
|
||||
depending on #atmel,pll-output-range-cells
|
||||
property value.
|
||||
|
||||
For example:
|
||||
plla: pllack {
|
||||
compatible = "atmel,at91sam9g45-clk-pll";
|
||||
interrupt-parent = <&pmc>;
|
||||
interrupts = <1>;
|
||||
#clock-cells = <0>;
|
||||
clocks = <&main>;
|
||||
reg = <0>;
|
||||
atmel,clk-input-range = <2000000 32000000>;
|
||||
#atmel,pll-clk-output-range-cells = <4>;
|
||||
atmel,pll-clk-output-ranges = <74500000 800000000 0 0
|
||||
69500000 750000000 1 0
|
||||
64500000 700000000 2 0
|
||||
59500000 650000000 3 0
|
||||
54500000 600000000 0 1
|
||||
49500000 550000000 1 1
|
||||
44500000 500000000 2 1
|
||||
40000000 450000000 3 1>;
|
||||
};
|
||||
|
||||
Required properties for plldiv clocks (plldiv = pll / 2):
|
||||
- #clock-cells : from common clock binding; shall be set to 0.
|
||||
- clocks : shall be the plla clock phandle.
|
||||
|
||||
The pll divisor is equal to 2 and cannot be changed.
|
||||
|
||||
For example:
|
||||
plladiv: plladivck {
|
||||
compatible = "atmel,at91sam9x5-clk-plldiv";
|
||||
#clock-cells = <0>;
|
||||
clocks = <&plla>;
|
||||
};
|
||||
|
||||
Required properties for programmable clocks:
|
||||
- interrupt-parent : must reference the PMC node.
|
||||
- #size-cells : shall be 0 (reg is used to encode clk id).
|
||||
- #address-cells : shall be 1 (reg is used to encode clk id).
|
||||
- clocks : shall be the programmable clock source phandles.
|
||||
e.g. clocks = <&clk32k>, <&main>, <&plla>, <&pllb>;
|
||||
- name: device tree node describing a specific prog clock.
|
||||
* #clock-cells : from common clock binding; shall be set to 0.
|
||||
* reg : programmable clock id (register offset from PCKx
|
||||
register).
|
||||
* interrupts : shall be set to "<(8 + id)>".
|
||||
|
||||
For example:
|
||||
prog: progck {
|
||||
compatible = "atmel,at91sam9g45-clk-programmable";
|
||||
#size-cells = <0>;
|
||||
#address-cells = <1>;
|
||||
interrupt-parent = <&pmc>;
|
||||
clocks = <&clk32k>, <&main>, <&plladiv>, <&utmi>, <&mck>;
|
||||
|
||||
prog0 {
|
||||
#clock-cells = <0>;
|
||||
reg = <0>;
|
||||
interrupts = <8>;
|
||||
};
|
||||
|
||||
prog1 {
|
||||
#clock-cells = <0>;
|
||||
reg = <1>;
|
||||
interrupts = <9>;
|
||||
};
|
||||
};
|
||||
|
||||
|
||||
Required properties for smd clock:
|
||||
- #clock-cells : from common clock binding; shall be set to 0.
|
||||
- clocks : shall be the smd clock source phandles.
|
||||
e.g. clocks = <&plladiv>, <&utmi>;
|
||||
|
||||
For example:
|
||||
smd: smdck {
|
||||
compatible = "atmel,at91sam9x5-clk-smd";
|
||||
#clock-cells = <0>;
|
||||
clocks = <&plladiv>, <&utmi>;
|
||||
};
|
||||
|
||||
Required properties for system clocks:
|
||||
- #size-cells : shall be 0 (reg is used to encode clk id).
|
||||
- #address-cells : shall be 1 (reg is used to encode clk id).
|
||||
- name: device tree node describing a specific system clock.
|
||||
* #clock-cells : from common clock binding; shall be set to 0.
|
||||
* reg: system clock id (bit position in SCER/SCDR/SCSR registers).
|
||||
See Atmel's datasheet to get a full list of system clock ids.
|
||||
|
||||
For example:
|
||||
system: systemck {
|
||||
compatible = "atmel,at91rm9200-clk-system";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
ddrck {
|
||||
#clock-cells = <0>;
|
||||
reg = <2>;
|
||||
clocks = <&mck>;
|
||||
};
|
||||
|
||||
uhpck {
|
||||
#clock-cells = <0>;
|
||||
reg = <6>;
|
||||
clocks = <&usb>;
|
||||
};
|
||||
|
||||
udpck {
|
||||
#clock-cells = <0>;
|
||||
reg = <7>;
|
||||
clocks = <&usb>;
|
||||
};
|
||||
};
|
||||
|
||||
|
||||
Required properties for usb clock:
|
||||
- #clock-cells : from common clock binding; shall be set to 0.
|
||||
- clocks : shall be the smd clock source phandles.
|
||||
e.g. clocks = <&pllb>;
|
||||
- atmel,clk-divisors (only available for "atmel,at91rm9200-clk-usb"):
|
||||
usb clock divisor table.
|
||||
e.g. divisors = <1 2 4 0>;
|
||||
|
||||
For example:
|
||||
usb: usbck {
|
||||
compatible = "atmel,at91sam9x5-clk-usb";
|
||||
#clock-cells = <0>;
|
||||
clocks = <&plladiv>, <&utmi>;
|
||||
};
|
||||
|
||||
usb: usbck {
|
||||
compatible = "atmel,at91rm9200-clk-usb";
|
||||
#clock-cells = <0>;
|
||||
clocks = <&pllb>;
|
||||
atmel,clk-divisors = <1 2 4 0>;
|
||||
};
|
||||
|
||||
|
||||
Required properties for utmi clock:
|
||||
- interrupt-parent : must reference the PMC node.
|
||||
- interrupts : shall be set to "<AT91_PMC_LOCKU IRQ_TYPE_LEVEL_HIGH>".
|
||||
- #clock-cells : from common clock binding; shall be set to 0.
|
||||
- clocks : shall be the main clock source phandle.
|
||||
|
||||
For example:
|
||||
utmi: utmick {
|
||||
compatible = "atmel,at91sam9x5-clk-utmi";
|
||||
interrupt-parent = <&pmc>;
|
||||
interrupts = <AT91_PMC_LOCKU IRQ_TYPE_LEVEL_HIGH>;
|
||||
#clock-cells = <0>;
|
||||
clocks = <&main>;
|
||||
};
|
93
Documentation/devicetree/bindings/clock/bcm-kona-clock.txt
Normal file
93
Documentation/devicetree/bindings/clock/bcm-kona-clock.txt
Normal file
|
@ -0,0 +1,93 @@
|
|||
Broadcom Kona Family Clocks
|
||||
|
||||
This binding is associated with Broadcom SoCs having "Kona" style
|
||||
clock control units (CCUs). A CCU is a clock provider that manages
|
||||
a set of clock signals. Each CCU is represented by a node in the
|
||||
device tree.
|
||||
|
||||
This binding uses the common clock binding:
|
||||
Documentation/devicetree/bindings/clock/clock-bindings.txt
|
||||
|
||||
Required properties:
|
||||
- compatible
|
||||
Shall have one of the following values:
|
||||
- "brcm,bcm11351-root-ccu"
|
||||
- "brcm,bcm11351-aon-ccu"
|
||||
- "brcm,bcm11351-hub-ccu"
|
||||
- "brcm,bcm11351-master-ccu"
|
||||
- "brcm,bcm11351-slave-ccu"
|
||||
- reg
|
||||
Shall define the base and range of the address space
|
||||
containing clock control registers
|
||||
- #clock-cells
|
||||
Shall have value <1>. The permitted clock-specifier values
|
||||
are defined below.
|
||||
- clock-output-names
|
||||
Shall be an ordered list of strings defining the names of
|
||||
the clocks provided by the CCU.
|
||||
|
||||
|
||||
BCM281XX family SoCs use Kona CCUs. The following table defines
|
||||
the set of CCUs and clock specifiers for BCM281XX clocks. When
|
||||
a clock consumer references a clocks, its symbolic specifier
|
||||
(rather than its numeric index value) should be used. These
|
||||
specifiers are defined in "include/dt-bindings/clock/bcm281xx.h".
|
||||
|
||||
CCU Clock Type Index Specifier
|
||||
--- ----- ---- ----- ---------
|
||||
root frac_1m peri 0 BCM281XX_ROOT_CCU_FRAC_1M
|
||||
|
||||
aon hub_timer peri 0 BCM281XX_AON_CCU_HUB_TIMER
|
||||
aon pmu_bsc peri 1 BCM281XX_AON_CCU_PMU_BSC
|
||||
aon pmu_bsc_var peri 2 BCM281XX_AON_CCU_PMU_BSC_VAR
|
||||
|
||||
hub tmon_1m peri 0 BCM281XX_HUB_CCU_TMON_1M
|
||||
|
||||
master sdio1 peri 0 BCM281XX_MASTER_CCU_SDIO1
|
||||
master sdio2 peri 1 BCM281XX_MASTER_CCU_SDIO2
|
||||
master sdio3 peri 2 BCM281XX_MASTER_CCU_SDIO3
|
||||
master sdio4 peri 3 BCM281XX_MASTER_CCU_SDIO4
|
||||
master dmac peri 4 BCM281XX_MASTER_CCU_DMAC
|
||||
master usb_ic peri 5 BCM281XX_MASTER_CCU_USB_IC
|
||||
master hsic2_48m peri 6 BCM281XX_MASTER_CCU_HSIC_48M
|
||||
master hsic2_12m peri 7 BCM281XX_MASTER_CCU_HSIC_12M
|
||||
|
||||
slave uartb peri 0 BCM281XX_SLAVE_CCU_UARTB
|
||||
slave uartb2 peri 1 BCM281XX_SLAVE_CCU_UARTB2
|
||||
slave uartb3 peri 2 BCM281XX_SLAVE_CCU_UARTB3
|
||||
slave uartb4 peri 3 BCM281XX_SLAVE_CCU_UARTB4
|
||||
slave ssp0 peri 4 BCM281XX_SLAVE_CCU_SSP0
|
||||
slave ssp2 peri 5 BCM281XX_SLAVE_CCU_SSP2
|
||||
slave bsc1 peri 6 BCM281XX_SLAVE_CCU_BSC1
|
||||
slave bsc2 peri 7 BCM281XX_SLAVE_CCU_BSC2
|
||||
slave bsc3 peri 8 BCM281XX_SLAVE_CCU_BSC3
|
||||
slave pwm peri 9 BCM281XX_SLAVE_CCU_PWM
|
||||
|
||||
|
||||
Device tree example:
|
||||
|
||||
slave_ccu: slave_ccu {
|
||||
compatible = "brcm,bcm11351-slave-ccu";
|
||||
reg = <0x3e011000 0x0f00>;
|
||||
#clock-cells = <1>;
|
||||
clock-output-names = "uartb",
|
||||
"uartb2",
|
||||
"uartb3",
|
||||
"uartb4";
|
||||
};
|
||||
|
||||
ref_crystal_clk: ref_crystal {
|
||||
#clock-cells = <0>;
|
||||
compatible = "fixed-clock";
|
||||
clock-frequency = <26000000>;
|
||||
};
|
||||
|
||||
uart@3e002000 {
|
||||
compatible = "brcm,bcm11351-dw-apb-uart", "snps,dw-apb-uart";
|
||||
status = "disabled";
|
||||
reg = <0x3e002000 0x1000>;
|
||||
clocks = <&slave_ccu BCM281XX_SLAVE_CCU_UARTB3>;
|
||||
interrupts = <GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH>;
|
||||
reg-shift = <2>;
|
||||
reg-io-width = <4>;
|
||||
};
|
|
@ -8,12 +8,29 @@ Required Properties:
|
|||
|
||||
- compatible: should be one of the following:
|
||||
- "samsung,exynos4210-audss-clock" - controller compatible with all Exynos4 SoCs.
|
||||
- "samsung,exynos5250-audss-clock" - controller compatible with all Exynos5 SoCs.
|
||||
|
||||
- "samsung,exynos5250-audss-clock" - controller compatible with Exynos5250
|
||||
SoCs.
|
||||
- "samsung,exynos5420-audss-clock" - controller compatible with Exynos5420
|
||||
SoCs.
|
||||
- reg: physical base address and length of the controller's register set.
|
||||
|
||||
- #clock-cells: should be 1.
|
||||
|
||||
- clocks:
|
||||
- pll_ref: Fixed rate PLL reference clock, parent of mout_audss. "fin_pll"
|
||||
is used if not specified.
|
||||
- pll_in: Input PLL to the AudioSS block, parent of mout_audss. "fout_epll"
|
||||
is used if not specified.
|
||||
- cdclk: External i2s clock, parent of mout_i2s. "cdclk0" is used if not
|
||||
specified.
|
||||
- sclk_audio: Audio bus clock, parent of mout_i2s. "sclk_audio0" is used if
|
||||
not specified.
|
||||
- sclk_pcm_in: PCM clock, parent of sclk_pcm. "sclk_pcm0" is used if not
|
||||
specified.
|
||||
|
||||
- clock-names: Aliases for the above clocks. They should be "pll_ref",
|
||||
"pll_in", "cdclk", "sclk_audio", and "sclk_pcm_in" respectively.
|
||||
|
||||
The following is the list of clocks generated by the controller. Each clock is
|
||||
assigned an identifier and client nodes use this identifier to specify the
|
||||
clock which they consume. Some of the clocks are available only on a particular
|
||||
|
@ -34,8 +51,10 @@ i2s_bus 6
|
|||
sclk_i2s 7
|
||||
pcm_bus 8
|
||||
sclk_pcm 9
|
||||
adma 10 Exynos5420
|
||||
|
||||
Example 1: An example of a clock controller node is listed below.
|
||||
Example 1: An example of a clock controller node using the default input
|
||||
clock names is listed below.
|
||||
|
||||
clock_audss: audss-clock-controller@3810000 {
|
||||
compatible = "samsung,exynos5250-audss-clock";
|
||||
|
@ -43,7 +62,19 @@ clock_audss: audss-clock-controller@3810000 {
|
|||
#clock-cells = <1>;
|
||||
};
|
||||
|
||||
Example 2: I2S controller node that consumes the clock generated by the clock
|
||||
Example 2: An example of a clock controller node with the input clocks
|
||||
specified.
|
||||
|
||||
clock_audss: audss-clock-controller@3810000 {
|
||||
compatible = "samsung,exynos5250-audss-clock";
|
||||
reg = <0x03810000 0x0C>;
|
||||
#clock-cells = <1>;
|
||||
clocks = <&clock 1>, <&clock 7>, <&clock 138>, <&clock 160>,
|
||||
<&ext_i2s_clk>;
|
||||
clock-names = "pll_ref", "pll_in", "sclk_audio", "sclk_pcm_in", "cdclk";
|
||||
};
|
||||
|
||||
Example 3: I2S controller node that consumes the clock generated by the clock
|
||||
controller. Refer to the standard clock bindings for information
|
||||
about 'clocks' and 'clock-names' property.
|
||||
|
||||
|
|
|
@ -5,7 +5,7 @@ Sources of clock signal can be represented by any node in the device
|
|||
tree. Those nodes are designated as clock providers. Clock consumer
|
||||
nodes use a phandle and clock specifier pair to connect clock provider
|
||||
outputs to clock inputs. Similar to the gpio specifiers, a clock
|
||||
specifier is an array of one more more cells identifying the clock
|
||||
specifier is an array of zero, one or more cells identifying the clock
|
||||
output on a device. The length of a clock specifier is defined by the
|
||||
value of a #clock-cells property in the clock provider node.
|
||||
|
||||
|
|
134
Documentation/devicetree/bindings/clock/corenet-clock.txt
Normal file
134
Documentation/devicetree/bindings/clock/corenet-clock.txt
Normal file
|
@ -0,0 +1,134 @@
|
|||
* Clock Block on Freescale CoreNet Platforms
|
||||
|
||||
Freescale CoreNet chips take primary clocking input from the external
|
||||
SYSCLK signal. The SYSCLK input (frequency) is multiplied using
|
||||
multiple phase locked loops (PLL) to create a variety of frequencies
|
||||
which can then be passed to a variety of internal logic, including
|
||||
cores and peripheral IP blocks.
|
||||
Please refer to the Reference Manual for details.
|
||||
|
||||
1. Clock Block Binding
|
||||
|
||||
Required properties:
|
||||
- compatible: Should contain a specific clock block compatible string
|
||||
and a single chassis clock compatible string.
|
||||
Clock block strings include, but not limited to, one of the:
|
||||
* "fsl,p2041-clockgen"
|
||||
* "fsl,p3041-clockgen"
|
||||
* "fsl,p4080-clockgen"
|
||||
* "fsl,p5020-clockgen"
|
||||
* "fsl,p5040-clockgen"
|
||||
* "fsl,t4240-clockgen"
|
||||
* "fsl,b4420-clockgen"
|
||||
* "fsl,b4860-clockgen"
|
||||
Chassis clock strings include:
|
||||
* "fsl,qoriq-clockgen-1.0": for chassis 1.0 clocks
|
||||
* "fsl,qoriq-clockgen-2.0": for chassis 2.0 clocks
|
||||
- reg: Describes the address of the device's resources within the
|
||||
address space defined by its parent bus, and resource zero
|
||||
represents the clock register set
|
||||
- clock-frequency: Input system clock frequency
|
||||
|
||||
Recommended properties:
|
||||
- ranges: Allows valid translation between child's address space and
|
||||
parent's. Must be present if the device has sub-nodes.
|
||||
- #address-cells: Specifies the number of cells used to represent
|
||||
physical base addresses. Must be present if the device has
|
||||
sub-nodes and set to 1 if present
|
||||
- #size-cells: Specifies the number of cells used to represent
|
||||
the size of an address. Must be present if the device has
|
||||
sub-nodes and set to 1 if present
|
||||
|
||||
2. Clock Provider/Consumer Binding
|
||||
|
||||
Most of the bindings are from the common clock binding[1].
|
||||
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
|
||||
|
||||
Required properties:
|
||||
- compatible : Should include one of the following:
|
||||
* "fsl,qoriq-core-pll-1.0" for core PLL clocks (v1.0)
|
||||
* "fsl,qoriq-core-pll-2.0" for core PLL clocks (v2.0)
|
||||
* "fsl,qoriq-core-mux-1.0" for core mux clocks (v1.0)
|
||||
* "fsl,qoriq-core-mux-2.0" for core mux clocks (v2.0)
|
||||
* "fsl,qoriq-sysclk-1.0": for input system clock (v1.0).
|
||||
It takes parent's clock-frequency as its clock.
|
||||
* "fsl,qoriq-sysclk-2.0": for input system clock (v2.0).
|
||||
It takes parent's clock-frequency as its clock.
|
||||
- #clock-cells: From common clock binding. The number of cells in a
|
||||
clock-specifier. Should be <0> for "fsl,qoriq-sysclk-[1,2].0"
|
||||
clocks, or <1> for "fsl,qoriq-core-pll-[1,2].0" clocks.
|
||||
For "fsl,qoriq-core-pll-[1,2].0" clocks, the single
|
||||
clock-specifier cell may take the following values:
|
||||
* 0 - equal to the PLL frequency
|
||||
* 1 - equal to the PLL frequency divided by 2
|
||||
* 2 - equal to the PLL frequency divided by 4
|
||||
|
||||
Recommended properties:
|
||||
- clocks: Should be the phandle of input parent clock
|
||||
- clock-names: From common clock binding, indicates the clock name
|
||||
- clock-output-names: From common clock binding, indicates the names of
|
||||
output clocks
|
||||
- reg: Should be the offset and length of clock block base address.
|
||||
The length should be 4.
|
||||
|
||||
Example for clock block and clock provider:
|
||||
/ {
|
||||
clockgen: global-utilities@e1000 {
|
||||
compatible = "fsl,p5020-clockgen", "fsl,qoriq-clockgen-1.0";
|
||||
ranges = <0x0 0xe1000 0x1000>;
|
||||
clock-frequency = <133333333>;
|
||||
reg = <0xe1000 0x1000>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
|
||||
sysclk: sysclk {
|
||||
#clock-cells = <0>;
|
||||
compatible = "fsl,qoriq-sysclk-1.0";
|
||||
clock-output-names = "sysclk";
|
||||
}
|
||||
|
||||
pll0: pll0@800 {
|
||||
#clock-cells = <1>;
|
||||
reg = <0x800 0x4>;
|
||||
compatible = "fsl,qoriq-core-pll-1.0";
|
||||
clocks = <&sysclk>;
|
||||
clock-output-names = "pll0", "pll0-div2";
|
||||
};
|
||||
|
||||
pll1: pll1@820 {
|
||||
#clock-cells = <1>;
|
||||
reg = <0x820 0x4>;
|
||||
compatible = "fsl,qoriq-core-pll-1.0";
|
||||
clocks = <&sysclk>;
|
||||
clock-output-names = "pll1", "pll1-div2";
|
||||
};
|
||||
|
||||
mux0: mux0@0 {
|
||||
#clock-cells = <0>;
|
||||
reg = <0x0 0x4>;
|
||||
compatible = "fsl,qoriq-core-mux-1.0";
|
||||
clocks = <&pll0 0>, <&pll0 1>, <&pll1 0>, <&pll1 1>;
|
||||
clock-names = "pll0", "pll0-div2", "pll1", "pll1-div2";
|
||||
clock-output-names = "cmux0";
|
||||
};
|
||||
|
||||
mux1: mux1@20 {
|
||||
#clock-cells = <0>;
|
||||
reg = <0x20 0x4>;
|
||||
compatible = "fsl,qoriq-core-mux-1.0";
|
||||
clocks = <&pll0 0>, <&pll0 1>, <&pll1 0>, <&pll1 1>;
|
||||
clock-names = "pll0", "pll0-div2", "pll1", "pll1-div2";
|
||||
clock-output-names = "cmux1";
|
||||
};
|
||||
};
|
||||
}
|
||||
|
||||
Example for clock consumer:
|
||||
|
||||
/ {
|
||||
cpu0: PowerPC,e5500@0 {
|
||||
...
|
||||
clocks = <&mux0>;
|
||||
...
|
||||
};
|
||||
}
|
98
Documentation/devicetree/bindings/clock/emev2-clock.txt
Normal file
98
Documentation/devicetree/bindings/clock/emev2-clock.txt
Normal file
|
@ -0,0 +1,98 @@
|
|||
Device tree Clock bindings for Renesas EMMA Mobile EV2
|
||||
|
||||
This binding uses the common clock binding.
|
||||
|
||||
* SMU
|
||||
System Management Unit described in user's manual R19UH0037EJ1000_SMU.
|
||||
This is not a clock provider, but clocks under SMU depend on it.
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "renesas,emev2-smu"
|
||||
- reg: Address and Size of SMU registers
|
||||
|
||||
* SMU_CLKDIV
|
||||
Function block with an input mux and a divider, which corresponds to
|
||||
"Serial clock generator" in fig."Clock System Overview" of the manual,
|
||||
and "xxx frequency division setting register" (XXXCLKDIV) registers.
|
||||
This makes internal (neither input nor output) clock that is provided
|
||||
to input of xxxGCLK block.
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "renesas,emev2-smu-clkdiv"
|
||||
- reg: Byte offset from SMU base and Bit position in the register
|
||||
- clocks: Parent clocks. Input clocks as described in clock-bindings.txt
|
||||
- #clock-cells: Should be <0>
|
||||
|
||||
* SMU_GCLK
|
||||
Clock gating node shown as "Clock stop processing block" in the
|
||||
fig."Clock System Overview" of the manual.
|
||||
Registers are "xxx clock gate control register" (XXXGCLKCTRL).
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "renesas,emev2-smu-gclk"
|
||||
- reg: Byte offset from SMU base and Bit position in the register
|
||||
- clocks: Input clock as described in clock-bindings.txt
|
||||
- #clock-cells: Should be <0>
|
||||
|
||||
Example of provider:
|
||||
|
||||
usia_u0_sclkdiv: usia_u0_sclkdiv {
|
||||
compatible = "renesas,emev2-smu-clkdiv";
|
||||
reg = <0x610 0>;
|
||||
clocks = <&pll3_fo>, <&pll4_fo>, <&pll1_fo>, <&osc1_fo>;
|
||||
#clock-cells = <0>;
|
||||
};
|
||||
|
||||
usia_u0_sclk: usia_u0_sclk {
|
||||
compatible = "renesas,emev2-smu-gclk";
|
||||
reg = <0x4a0 1>;
|
||||
clocks = <&usia_u0_sclkdiv>;
|
||||
#clock-cells = <0>;
|
||||
};
|
||||
|
||||
Example of consumer:
|
||||
|
||||
uart@e1020000 {
|
||||
compatible = "renesas,em-uart";
|
||||
reg = <0xe1020000 0x38>;
|
||||
interrupts = <0 8 0>;
|
||||
clocks = <&usia_u0_sclk>;
|
||||
clock-names = "sclk";
|
||||
};
|
||||
|
||||
Example of clock-tree description:
|
||||
|
||||
This describes a clock path in the clock tree
|
||||
c32ki -> pll3_fo -> usia_u0_sclkdiv -> usia_u0_sclk
|
||||
|
||||
smu@e0110000 {
|
||||
compatible = "renesas,emev2-smu";
|
||||
reg = <0xe0110000 0x10000>;
|
||||
#address-cells = <2>;
|
||||
#size-cells = <0>;
|
||||
|
||||
c32ki: c32ki {
|
||||
compatible = "fixed-clock";
|
||||
clock-frequency = <32768>;
|
||||
#clock-cells = <0>;
|
||||
};
|
||||
pll3_fo: pll3_fo {
|
||||
compatible = "fixed-factor-clock";
|
||||
clocks = <&c32ki>;
|
||||
clock-div = <1>;
|
||||
clock-mult = <7000>;
|
||||
#clock-cells = <0>;
|
||||
};
|
||||
usia_u0_sclkdiv: usia_u0_sclkdiv {
|
||||
compatible = "renesas,emev2-smu-clkdiv";
|
||||
reg = <0x610 0>;
|
||||
clocks = <&pll3_fo>;
|
||||
#clock-cells = <0>;
|
||||
};
|
||||
usia_u0_sclk: usia_u0_sclk {
|
||||
compatible = "renesas,emev2-smu-gclk";
|
||||
reg = <0x4a0 1>;
|
||||
clocks = <&usia_u0_sclkdiv>;
|
||||
#clock-cells = <0>;
|
||||
};
|
||||
};
|
Some files were not shown because too many files have changed in this diff Show more
Loading…
Reference in a new issue