forked from Minki/linux
Merge branch 'master' into staging-next
We need the network changes in staging-next in order to be able to fix up the rtl8821ae driver to build properly. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This commit is contained in:
commit
cc11f372e9
Documentation
ABI/testing
configfs-usb-gadget-ffsconfigfs-usb-gadget-loopbackconfigfs-usb-gadget-sourcesinkdebugfs-driver-genwqesysfs-bus-pcisysfs-bus-usbsysfs-class-net-meshsysfs-devices-system-cpusysfs-driver-genwqesysfs-firmware-efisysfs-firmware-efi-runtime-mapsysfs-fs-f2fssysfs-kernel-boot_paramssysfs-kernel-vmcoreinfosysfs-platform-tahvo-usb
DocBook
HOWTOIRQ-domain.txtPCI
RCU
acpi
arm
block
blockdev
cgroups
circular-buffers.txtclk.txtcpu-freq
cpu-hotplug.txtdevice-mapper
devices.txtdevicetree/bindings
ABI.txt
arm
arm-boardsatmel-aic.txtatmel-at91.txt
firmware
gic.txthisilicon
l2cc.txtmarvell,berlin.txtmoxart.txtomap
samsung
tegra.txttegra
versatile-fpga-irq.txtata
clock
at91-clock.txtclk-exynos-audss.txtclock-bindings.txtemev2-clock.txtexynos5250-clock.txtfixed-clock.txtfixed-factor-clock.txthi3620-clock.txtimx35-clock.txtimx5-clock.txtkeystone-pll.txtmaxim,max77686.txtnvidia,tegra114-car.txtnvidia,tegra124-car.txtnvidia,tegra20-car.txtnvidia,tegra30-car.txtqcom,gcc.txtqcom,mmcc.txtrenesas,cpg-div6-clocks.txtrenesas,cpg-mstp-clocks.txtrenesas,rcar-gen2-cpg-clocks.txtsilabs,si570.txtsunxi.txtzynq-7000.txt
cpufreq
crypto
dma
extcon
gpio
gpu
i2c
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
|
||||
KenelVersion: 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
|
||||
KenelVersion: 3.13
|
||||
Description:
|
||||
The attributes:
|
||||
|
||||
qlen - depth of loopback queue
|
||||
bulk_buflen - buffer length
|
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
|
||||
KenelVersion: 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
|
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.
|
@ -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
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
@ -82,93 +82,111 @@ Most of the hard work is done for the driver in the PCI layer. It simply
|
||||
has to request that the PCI layer set up the MSI capability for this
|
||||
device.
|
||||
|
||||
4.2.1 pci_enable_msi
|
||||
4.2.1 pci_enable_msi_range
|
||||
|
||||
int pci_enable_msi(struct pci_dev *dev)
|
||||
int pci_enable_msi_range(struct pci_dev *dev, int minvec, int maxvec)
|
||||
|
||||
A successful call allocates ONE interrupt to the device, regardless
|
||||
of how many MSIs the device supports. The device is switched from
|
||||
pin-based interrupt mode to MSI mode. The dev->irq number is changed
|
||||
to a new number which represents the message signaled interrupt;
|
||||
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.
|
||||
This function allows a device driver to request any number of MSI
|
||||
interrupts within specified range from 'minvec' to 'maxvec'.
|
||||
|
||||
4.2.2 pci_enable_msi_block
|
||||
|
||||
int pci_enable_msi_block(struct pci_dev *dev, int count)
|
||||
|
||||
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).
|
||||
|
||||
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.
|
||||
|
||||
4.2.4 pci_disable_msi
|
||||
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);
|
||||
}
|
||||
|
||||
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);
|
||||
}
|
||||
|
||||
4.2.2 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.3 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 +206,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 +241,103 @@ 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 pci_enable_msi_range(adapter->pdev, adapter->msix_entries,
|
||||
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-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_msi_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_msi_range(adapter->pdev, adapter->msix_entries,
|
||||
nvec, nvec);
|
||||
}
|
||||
|
||||
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 -ENOSPC;
|
||||
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_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 +353,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 +493,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)
|
||||
|
||||
|
@ -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.
|
||||
|
@ -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
|
||||
-----------
|
||||
|
72
Documentation/block/null_blk.txt
Normal file
72
Documentation/block/null_blk.txt
Normal file
@ -0,0 +1,72 @@
|
||||
Null block device driver
|
||||
================================================================================
|
||||
|
||||
I. Overview
|
||||
|
||||
The null block device (/dev/nullb*) is used for benchmarking the various
|
||||
block-layer implementations. It emulates a block device of X gigabytes in size.
|
||||
The following instances are possible:
|
||||
|
||||
Single-queue block-layer
|
||||
- Request-based.
|
||||
- Single submission queue per device.
|
||||
- Implements IO scheduling algorithms (CFQ, Deadline, noop).
|
||||
Multi-queue block-layer
|
||||
- Request-based.
|
||||
- Configurable submission queues per device.
|
||||
No block-layer (Known as bio-based)
|
||||
- Bio-based. IO requests are submitted directly to the device driver.
|
||||
- Directly accepts bio data structure and returns them.
|
||||
|
||||
All of them have a completion queue for each core in the system.
|
||||
|
||||
II. Module parameters applicable for all instances:
|
||||
|
||||
queue_mode=[0-2]: Default: 2-Multi-queue
|
||||
Selects which block-layer the module should instantiate with.
|
||||
|
||||
0: Bio-based.
|
||||
1: Single-queue.
|
||||
2: Multi-queue.
|
||||
|
||||
home_node=[0--nr_nodes]: Default: NUMA_NO_NODE
|
||||
Selects what CPU node the data structures are allocated from.
|
||||
|
||||
gb=[Size in GB]: Default: 250GB
|
||||
The size of the device reported to the system.
|
||||
|
||||
bs=[Block size (in bytes)]: Default: 512 bytes
|
||||
The block size reported to the system.
|
||||
|
||||
nr_devices=[Number of devices]: Default: 2
|
||||
Number of block devices instantiated. They are instantiated as /dev/nullb0,
|
||||
etc.
|
||||
|
||||
irq_mode=[0-2]: Default: 1-Soft-irq
|
||||
The completion mode used for completing IOs to the block-layer.
|
||||
|
||||
0: None.
|
||||
1: Soft-irq. Uses IPI to complete IOs across CPU nodes. Simulates the overhead
|
||||
when IOs are issued from another CPU node than the home the device is
|
||||
connected to.
|
||||
2: Timer: Waits a specific period (completion_nsec) for each IO before
|
||||
completion.
|
||||
|
||||
completion_nsec=[ns]: Default: 10.000ns
|
||||
Combined with irq_mode=2 (timer). The time each completion event must wait.
|
||||
|
||||
submit_queues=[0..nr_cpus]:
|
||||
The number of submission queues attached to the device driver. If unset, it
|
||||
defaults to 1 on single-queue and bio-based instances. For multi-queue,
|
||||
it is ignored when use_per_node_hctx module parameter is 1.
|
||||
|
||||
hw_queue_depth=[0..qdepth]: Default: 64
|
||||
The hardware queue depth of the device.
|
||||
|
||||
III: Multi-queue specific parameters
|
||||
|
||||
use_per_node_hctx=[0/1]: Default: 0
|
||||
0: The number of submit queues are set to the value of the submit_queues
|
||||
parameter.
|
||||
1: The multi-queue block layer is instantiated with a hardware dispatch
|
||||
queue for each CPU node in the system.
|
@ -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"
|
||||
------------------
|
||||
|
@ -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
|
||||
|
@ -97,8 +97,8 @@ to work with it.
|
||||
(struct res_counter *rc, struct res_counter *top,
|
||||
unsinged 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,
|
||||
};
|
||||
|
@ -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
|
||||
-------
|
||||
|
||||
|
@ -217,36 +217,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
|
||||
--------
|
||||
|
@ -235,6 +235,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.
|
||||
|
||||
@ -276,6 +278,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
|
||||
|
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.
|
||||
|
@ -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:
|
||||
|
||||
|
@ -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.
|
||||
|
@ -9,6 +9,7 @@ Required properties:
|
||||
- compatible : Should contain "nvidia,tegra<chip>-pmc".
|
||||
- reg : Offset and length of the register set for the device
|
||||
- clocks : Must contain an entry for each entry in clock-names.
|
||||
See ../clocks/clock-bindings.txt for details.
|
||||
- clock-names : Must include the following entries:
|
||||
"pclk" (The Tegra clock of that name),
|
||||
"clk32k_in" (The 32KHz clock input to Tegra).
|
||||
|
@ -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>;
|
||||
};
|
@ -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.
|
||||
|
||||
|
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>;
|
||||
};
|
||||
};
|
@ -62,6 +62,7 @@ clock which they consume.
|
||||
div_i2s1 157
|
||||
div_i2s2 158
|
||||
sclk_hdmiphy 159
|
||||
div_pcm0 160
|
||||
|
||||
|
||||
[Peripheral Clock Gates]
|
||||
@ -159,6 +160,8 @@ clock which they consume.
|
||||
mixer 343
|
||||
hdmi 344
|
||||
g2d 345
|
||||
mdma0 346
|
||||
smmu_mdma0 347
|
||||
|
||||
|
||||
[Clock Muxes]
|
||||
|
@ -10,6 +10,8 @@ Required properties:
|
||||
- clock-frequency : frequency of clock in Hz. Should be a single cell.
|
||||
|
||||
Optional properties:
|
||||
- clock-accuracy : accuracy of clock in ppb (parts per billion).
|
||||
Should be a single cell.
|
||||
- gpios : From common gpio binding; gpio connection to clock enable pin.
|
||||
- clock-output-names : From common clock binding.
|
||||
|
||||
@ -18,4 +20,5 @@ Example:
|
||||
compatible = "fixed-clock";
|
||||
#clock-cells = <0>;
|
||||
clock-frequency = <1000000000>;
|
||||
clock-accuracy = <100>;
|
||||
};
|
||||
|
@ -19,6 +19,6 @@ Example:
|
||||
compatible = "fixed-factor-clock";
|
||||
clocks = <&parentclk>;
|
||||
#clock-cells = <0>;
|
||||
div = <2>;
|
||||
mult = <1>;
|
||||
clock-div = <2>;
|
||||
clock-mult = <1>;
|
||||
};
|
||||
|
19
Documentation/devicetree/bindings/clock/hi3620-clock.txt
Normal file
19
Documentation/devicetree/bindings/clock/hi3620-clock.txt
Normal file
@ -0,0 +1,19 @@
|
||||
* Hisilicon Hi3620 Clock Controller
|
||||
|
||||
The Hi3620 clock controller generates and supplies clock to various
|
||||
controllers within the Hi3620 SoC.
|
||||
|
||||
Required Properties:
|
||||
|
||||
- compatible: should be one of the following.
|
||||
- "hisilicon,hi3620-clock" - controller compatible with Hi3620 SoC.
|
||||
|
||||
- reg: physical base address of the controller and length of memory mapped
|
||||
region.
|
||||
|
||||
- #clock-cells: should be 1.
|
||||
|
||||
Each clock is assigned an identifier and client nodes use this identifier
|
||||
to specify the clock which they consume.
|
||||
|
||||
All these identifier could be found in <dt-bindings/clock/hi3620-clock.h>.
|
113
Documentation/devicetree/bindings/clock/imx35-clock.txt
Normal file
113
Documentation/devicetree/bindings/clock/imx35-clock.txt
Normal file
@ -0,0 +1,113 @@
|
||||
* Clock bindings for Freescale i.MX35
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "fsl,imx35-ccm"
|
||||
- reg: Address and length of the register set
|
||||
- interrupts: Should contain CCM interrupt
|
||||
- #clock-cells: Should be <1>
|
||||
|
||||
The clock consumer should specify the desired clock by having the clock
|
||||
ID in its "clocks" phandle cell. The following is a full list of i.MX35
|
||||
clocks and IDs.
|
||||
|
||||
Clock ID
|
||||
---------------------------
|
||||
ckih 0
|
||||
mpll 1
|
||||
ppll 2
|
||||
mpll_075 3
|
||||
arm 4
|
||||
hsp 5
|
||||
hsp_div 6
|
||||
hsp_sel 7
|
||||
ahb 8
|
||||
ipg 9
|
||||
arm_per_div 10
|
||||
ahb_per_div 11
|
||||
ipg_per 12
|
||||
uart_sel 13
|
||||
uart_div 14
|
||||
esdhc_sel 15
|
||||
esdhc1_div 16
|
||||
esdhc2_div 17
|
||||
esdhc3_div 18
|
||||
spdif_sel 19
|
||||
spdif_div_pre 20
|
||||
spdif_div_post 21
|
||||
ssi_sel 22
|
||||
ssi1_div_pre 23
|
||||
ssi1_div_post 24
|
||||
ssi2_div_pre 25
|
||||
ssi2_div_post 26
|
||||
usb_sel 27
|
||||
usb_div 28
|
||||
nfc_div 29
|
||||
asrc_gate 30
|
||||
pata_gate 31
|
||||
audmux_gate 32
|
||||
can1_gate 33
|
||||
can2_gate 34
|
||||
cspi1_gate 35
|
||||
cspi2_gate 36
|
||||
ect_gate 37
|
||||
edio_gate 38
|
||||
emi_gate 39
|
||||
epit1_gate 40
|
||||
epit2_gate 41
|
||||
esai_gate 42
|
||||
esdhc1_gate 43
|
||||
esdhc2_gate 44
|
||||
esdhc3_gate 45
|
||||
fec_gate 46
|
||||
gpio1_gate 47
|
||||
gpio2_gate 48
|
||||
gpio3_gate 49
|
||||
gpt_gate 50
|
||||
i2c1_gate 51
|
||||
i2c2_gate 52
|
||||
i2c3_gate 53
|
||||
iomuxc_gate 54
|
||||
ipu_gate 55
|
||||
kpp_gate 56
|
||||
mlb_gate 57
|
||||
mshc_gate 58
|
||||
owire_gate 59
|
||||
pwm_gate 60
|
||||
rngc_gate 61
|
||||
rtc_gate 62
|
||||
rtic_gate 63
|
||||
scc_gate 64
|
||||
sdma_gate 65
|
||||
spba_gate 66
|
||||
spdif_gate 67
|
||||
ssi1_gate 68
|
||||
ssi2_gate 69
|
||||
uart1_gate 70
|
||||
uart2_gate 71
|
||||
uart3_gate 72
|
||||
usbotg_gate 73
|
||||
wdog_gate 74
|
||||
max_gate 75
|
||||
admux_gate 76
|
||||
csi_gate 77
|
||||
csi_div 78
|
||||
csi_sel 79
|
||||
iim_gate 80
|
||||
gpu2d_gate 81
|
||||
|
||||
Examples:
|
||||
|
||||
clks: ccm@53f80000 {
|
||||
compatible = "fsl,imx35-ccm";
|
||||
reg = <0x53f80000 0x4000>;
|
||||
interrupts = <31>;
|
||||
#clock-cells = <1>;
|
||||
};
|
||||
|
||||
esdhc1: esdhc@53fb4000 {
|
||||
compatible = "fsl,imx35-esdhc";
|
||||
reg = <0x53fb4000 0x4000>;
|
||||
interrupts = <7>;
|
||||
clocks = <&clks 9>, <&clks 8>, <&clks 43>;
|
||||
clock-names = "ipg", "ahb", "per";
|
||||
};
|
@ -7,197 +7,8 @@ Required properties:
|
||||
- #clock-cells: Should be <1>
|
||||
|
||||
The clock consumer should specify the desired clock by having the clock
|
||||
ID in its "clocks" phandle cell. The following is a full list of i.MX5
|
||||
clocks and IDs.
|
||||
|
||||
Clock ID
|
||||
---------------------------
|
||||
dummy 0
|
||||
ckil 1
|
||||
osc 2
|
||||
ckih1 3
|
||||
ckih2 4
|
||||
ahb 5
|
||||
ipg 6
|
||||
axi_a 7
|
||||
axi_b 8
|
||||
uart_pred 9
|
||||
uart_root 10
|
||||
esdhc_a_pred 11
|
||||
esdhc_b_pred 12
|
||||
esdhc_c_s 13
|
||||
esdhc_d_s 14
|
||||
emi_sel 15
|
||||
emi_slow_podf 16
|
||||
nfc_podf 17
|
||||
ecspi_pred 18
|
||||
ecspi_podf 19
|
||||
usboh3_pred 20
|
||||
usboh3_podf 21
|
||||
usb_phy_pred 22
|
||||
usb_phy_podf 23
|
||||
cpu_podf 24
|
||||
di_pred 25
|
||||
tve_s 27
|
||||
uart1_ipg_gate 28
|
||||
uart1_per_gate 29
|
||||
uart2_ipg_gate 30
|
||||
uart2_per_gate 31
|
||||
uart3_ipg_gate 32
|
||||
uart3_per_gate 33
|
||||
i2c1_gate 34
|
||||
i2c2_gate 35
|
||||
gpt_ipg_gate 36
|
||||
pwm1_ipg_gate 37
|
||||
pwm1_hf_gate 38
|
||||
pwm2_ipg_gate 39
|
||||
pwm2_hf_gate 40
|
||||
gpt_hf_gate 41
|
||||
fec_gate 42
|
||||
usboh3_per_gate 43
|
||||
esdhc1_ipg_gate 44
|
||||
esdhc2_ipg_gate 45
|
||||
esdhc3_ipg_gate 46
|
||||
esdhc4_ipg_gate 47
|
||||
ssi1_ipg_gate 48
|
||||
ssi2_ipg_gate 49
|
||||
ssi3_ipg_gate 50
|
||||
ecspi1_ipg_gate 51
|
||||
ecspi1_per_gate 52
|
||||
ecspi2_ipg_gate 53
|
||||
ecspi2_per_gate 54
|
||||
cspi_ipg_gate 55
|
||||
sdma_gate 56
|
||||
emi_slow_gate 57
|
||||
ipu_s 58
|
||||
ipu_gate 59
|
||||
nfc_gate 60
|
||||
ipu_di1_gate 61
|
||||
vpu_s 62
|
||||
vpu_gate 63
|
||||
vpu_reference_gate 64
|
||||
uart4_ipg_gate 65
|
||||
uart4_per_gate 66
|
||||
uart5_ipg_gate 67
|
||||
uart5_per_gate 68
|
||||
tve_gate 69
|
||||
tve_pred 70
|
||||
esdhc1_per_gate 71
|
||||
esdhc2_per_gate 72
|
||||
esdhc3_per_gate 73
|
||||
esdhc4_per_gate 74
|
||||
usb_phy_gate 75
|
||||
hsi2c_gate 76
|
||||
mipi_hsc1_gate 77
|
||||
mipi_hsc2_gate 78
|
||||
mipi_esc_gate 79
|
||||
mipi_hsp_gate 80
|
||||
ldb_di1_div_3_5 81
|
||||
ldb_di1_div 82
|
||||
ldb_di0_div_3_5 83
|
||||
ldb_di0_div 84
|
||||
ldb_di1_gate 85
|
||||
can2_serial_gate 86
|
||||
can2_ipg_gate 87
|
||||
i2c3_gate 88
|
||||
lp_apm 89
|
||||
periph_apm 90
|
||||
main_bus 91
|
||||
ahb_max 92
|
||||
aips_tz1 93
|
||||
aips_tz2 94
|
||||
tmax1 95
|
||||
tmax2 96
|
||||
tmax3 97
|
||||
spba 98
|
||||
uart_sel 99
|
||||
esdhc_a_sel 100
|
||||
esdhc_b_sel 101
|
||||
esdhc_a_podf 102
|
||||
esdhc_b_podf 103
|
||||
ecspi_sel 104
|
||||
usboh3_sel 105
|
||||
usb_phy_sel 106
|
||||
iim_gate 107
|
||||
usboh3_gate 108
|
||||
emi_fast_gate 109
|
||||
ipu_di0_gate 110
|
||||
gpc_dvfs 111
|
||||
pll1_sw 112
|
||||
pll2_sw 113
|
||||
pll3_sw 114
|
||||
ipu_di0_sel 115
|
||||
ipu_di1_sel 116
|
||||
tve_ext_sel 117
|
||||
mx51_mipi 118
|
||||
pll4_sw 119
|
||||
ldb_di1_sel 120
|
||||
di_pll4_podf 121
|
||||
ldb_di0_sel 122
|
||||
ldb_di0_gate 123
|
||||
usb_phy1_gate 124
|
||||
usb_phy2_gate 125
|
||||
per_lp_apm 126
|
||||
per_pred1 127
|
||||
per_pred2 128
|
||||
per_podf 129
|
||||
per_root 130
|
||||
ssi_apm 131
|
||||
ssi1_root_sel 132
|
||||
ssi2_root_sel 133
|
||||
ssi3_root_sel 134
|
||||
ssi_ext1_sel 135
|
||||
ssi_ext2_sel 136
|
||||
ssi_ext1_com_sel 137
|
||||
ssi_ext2_com_sel 138
|
||||
ssi1_root_pred 139
|
||||
ssi1_root_podf 140
|
||||
ssi2_root_pred 141
|
||||
ssi2_root_podf 142
|
||||
ssi_ext1_pred 143
|
||||
ssi_ext1_podf 144
|
||||
ssi_ext2_pred 145
|
||||
ssi_ext2_podf 146
|
||||
ssi1_root_gate 147
|
||||
ssi2_root_gate 148
|
||||
ssi3_root_gate 149
|
||||
ssi_ext1_gate 150
|
||||
ssi_ext2_gate 151
|
||||
epit1_ipg_gate 152
|
||||
epit1_hf_gate 153
|
||||
epit2_ipg_gate 154
|
||||
epit2_hf_gate 155
|
||||
can_sel 156
|
||||
can1_serial_gate 157
|
||||
can1_ipg_gate 158
|
||||
owire_gate 159
|
||||
gpu3d_s 160
|
||||
gpu2d_s 161
|
||||
gpu3d_gate 162
|
||||
gpu2d_gate 163
|
||||
garb_gate 164
|
||||
cko1_sel 165
|
||||
cko1_podf 166
|
||||
cko1 167
|
||||
cko2_sel 168
|
||||
cko2_podf 169
|
||||
cko2 170
|
||||
srtc_gate 171
|
||||
pata_gate 172
|
||||
sata_gate 173
|
||||
spdif_xtal_sel 174
|
||||
spdif0_sel 175
|
||||
spdif1_sel 176
|
||||
spdif0_pred 177
|
||||
spdif0_podf 178
|
||||
spdif1_pred 179
|
||||
spdif1_podf 180
|
||||
spdif0_com_sel 181
|
||||
spdif1_com_sel 182
|
||||
spdif0_gate 183
|
||||
spdif1_gate 184
|
||||
spdif_ipg_gate 185
|
||||
ocram 186
|
||||
ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx5-clock.h
|
||||
for the full list of i.MX5 clock IDs.
|
||||
|
||||
Examples (for mx53):
|
||||
|
||||
@ -212,7 +23,7 @@ can1: can@53fc8000 {
|
||||
compatible = "fsl,imx53-flexcan", "fsl,p1010-flexcan";
|
||||
reg = <0x53fc8000 0x4000>;
|
||||
interrupts = <82>;
|
||||
clocks = <&clks 158>, <&clks 157>;
|
||||
clocks = <&clks IMX5_CLK_CAN1_IPG_GATE>, <&clks IMX5_CLK_CAN1_SERIAL_GATE>;
|
||||
clock-names = "ipg", "per";
|
||||
status = "disabled";
|
||||
};
|
||||
|
@ -17,13 +17,14 @@ Required properties:
|
||||
- reg - pll control0 and pll multipler registers
|
||||
- reg-names : control and multiplier. The multiplier is applicable only for
|
||||
main pll clock
|
||||
- fixed-postdiv : fixed post divider value
|
||||
- fixed-postdiv : fixed post divider value. If absent, use clkod register bits
|
||||
for postdiv
|
||||
|
||||
Example:
|
||||
mainpllclk: mainpllclk@2310110 {
|
||||
#clock-cells = <0>;
|
||||
compatible = "ti,keystone,main-pll-clock";
|
||||
clocks = <&refclkmain>;
|
||||
clocks = <&refclksys>;
|
||||
reg = <0x02620350 4>, <0x02310110 4>;
|
||||
reg-names = "control", "multiplier";
|
||||
fixed-postdiv = <2>;
|
||||
@ -32,11 +33,10 @@ Example:
|
||||
papllclk: papllclk@2620358 {
|
||||
#clock-cells = <0>;
|
||||
compatible = "ti,keystone,pll-clock";
|
||||
clocks = <&refclkmain>;
|
||||
clocks = <&refclkpass>;
|
||||
clock-output-names = "pa-pll-clk";
|
||||
reg = <0x02620358 4>;
|
||||
reg-names = "control";
|
||||
fixed-postdiv = <6>;
|
||||
};
|
||||
|
||||
Required properties:
|
||||
|
38
Documentation/devicetree/bindings/clock/maxim,max77686.txt
Normal file
38
Documentation/devicetree/bindings/clock/maxim,max77686.txt
Normal file
@ -0,0 +1,38 @@
|
||||
Binding for Maxim MAX77686 32k clock generator block
|
||||
|
||||
This is a part of device tree bindings of MAX77686 multi-function device.
|
||||
More information can be found in bindings/mfd/max77686.txt file.
|
||||
|
||||
The MAX77686 contains three 32.768khz clock outputs that can be controlled
|
||||
(gated/ungated) over I2C.
|
||||
|
||||
Following properties should be presend in main device node of the MFD chip.
|
||||
|
||||
Required properties:
|
||||
- #clock-cells: simple one-cell clock specifier format is used, where the
|
||||
only cell is used as an index of the clock inside the provider. Following
|
||||
indices are allowed:
|
||||
- 0: 32khz_ap clock,
|
||||
- 1: 32khz_cp clock,
|
||||
- 2: 32khz_pmic clock.
|
||||
|
||||
Example: Node of the MFD chip
|
||||
|
||||
max77686: max77686@09 {
|
||||
compatible = "maxim,max77686";
|
||||
interrupt-parent = <&wakeup_eint>;
|
||||
interrupts = <26 0>;
|
||||
reg = <0x09>;
|
||||
#clock-cells = <1>;
|
||||
|
||||
/* ... */
|
||||
};
|
||||
|
||||
Example: Clock consumer node
|
||||
|
||||
foo@0 {
|
||||
compatible = "bar,foo";
|
||||
/* ... */
|
||||
clock-names = "my-clock";
|
||||
clocks = <&max77686 2>;
|
||||
};
|
@ -15,6 +15,9 @@ Required properties :
|
||||
In clock consumers, this cell represents the clock ID exposed by the
|
||||
CAR. The assignments may be found in header file
|
||||
<dt-bindings/clock/tegra114-car.h>.
|
||||
- #reset-cells : Should be 1.
|
||||
In clock consumers, this cell represents the bit number in the CAR's
|
||||
array of CLK_RST_CONTROLLER_RST_DEVICES_* registers.
|
||||
|
||||
Example SoC include file:
|
||||
|
||||
@ -23,6 +26,7 @@ Example SoC include file:
|
||||
compatible = "nvidia,tegra114-car";
|
||||
reg = <0x60006000 0x1000>;
|
||||
#clock-cells = <1>;
|
||||
#reset-cells = <1>;
|
||||
};
|
||||
|
||||
usb@c5004000 {
|
||||
|
@ -0,0 +1,63 @@
|
||||
NVIDIA Tegra124 Clock And Reset Controller
|
||||
|
||||
This binding uses the common clock binding:
|
||||
Documentation/devicetree/bindings/clock/clock-bindings.txt
|
||||
|
||||
The CAR (Clock And Reset) Controller on Tegra is the HW module responsible
|
||||
for muxing and gating Tegra's clocks, and setting their rates.
|
||||
|
||||
Required properties :
|
||||
- compatible : Should be "nvidia,tegra124-car"
|
||||
- reg : Should contain CAR registers location and length
|
||||
- clocks : Should contain phandle and clock specifiers for two clocks:
|
||||
the 32 KHz "32k_in", and the board-specific oscillator "osc".
|
||||
- #clock-cells : Should be 1.
|
||||
In clock consumers, this cell represents the clock ID exposed by the
|
||||
CAR. The assignments may be found in header file
|
||||
<dt-bindings/clock/tegra124-car.h>.
|
||||
- #reset-cells : Should be 1.
|
||||
In clock consumers, this cell represents the bit number in the CAR's
|
||||
array of CLK_RST_CONTROLLER_RST_DEVICES_* registers.
|
||||
|
||||
Example SoC include file:
|
||||
|
||||
/ {
|
||||
tegra_car: clock {
|
||||
compatible = "nvidia,tegra124-car";
|
||||
reg = <0x60006000 0x1000>;
|
||||
#clock-cells = <1>;
|
||||
#reset-cells = <1>;
|
||||
};
|
||||
|
||||
usb@c5004000 {
|
||||
clocks = <&tegra_car TEGRA124_CLK_USB2>;
|
||||
};
|
||||
};
|
||||
|
||||
Example board file:
|
||||
|
||||
/ {
|
||||
clocks {
|
||||
compatible = "simple-bus";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
osc: clock@0 {
|
||||
compatible = "fixed-clock";
|
||||
reg = <0>;
|
||||
#clock-cells = <0>;
|
||||
clock-frequency = <112400000>;
|
||||
};
|
||||
|
||||
clk_32k: clock@1 {
|
||||
compatible = "fixed-clock";
|
||||
reg = <1>;
|
||||
#clock-cells = <0>;
|
||||
clock-frequency = <32768>;
|
||||
};
|
||||
};
|
||||
|
||||
&tegra_car {
|
||||
clocks = <&clk_32k> <&osc>;
|
||||
};
|
||||
};
|
@ -15,6 +15,9 @@ Required properties :
|
||||
In clock consumers, this cell represents the clock ID exposed by the
|
||||
CAR. The assignments may be found in header file
|
||||
<dt-bindings/clock/tegra20-car.h>.
|
||||
- #reset-cells : Should be 1.
|
||||
In clock consumers, this cell represents the bit number in the CAR's
|
||||
array of CLK_RST_CONTROLLER_RST_DEVICES_* registers.
|
||||
|
||||
Example SoC include file:
|
||||
|
||||
@ -23,6 +26,7 @@ Example SoC include file:
|
||||
compatible = "nvidia,tegra20-car";
|
||||
reg = <0x60006000 0x1000>;
|
||||
#clock-cells = <1>;
|
||||
#reset-cells = <1>;
|
||||
};
|
||||
|
||||
usb@c5004000 {
|
||||
|
@ -15,6 +15,9 @@ Required properties :
|
||||
In clock consumers, this cell represents the clock ID exposed by the
|
||||
CAR. The assignments may be found in header file
|
||||
<dt-bindings/clock/tegra30-car.h>.
|
||||
- #reset-cells : Should be 1.
|
||||
In clock consumers, this cell represents the bit number in the CAR's
|
||||
array of CLK_RST_CONTROLLER_RST_DEVICES_* registers.
|
||||
|
||||
Example SoC include file:
|
||||
|
||||
@ -23,6 +26,7 @@ Example SoC include file:
|
||||
compatible = "nvidia,tegra30-car";
|
||||
reg = <0x60006000 0x1000>;
|
||||
#clock-cells = <1>;
|
||||
#reset-cells = <1>;
|
||||
};
|
||||
|
||||
usb@c5004000 {
|
||||
|
21
Documentation/devicetree/bindings/clock/qcom,gcc.txt
Normal file
21
Documentation/devicetree/bindings/clock/qcom,gcc.txt
Normal file
@ -0,0 +1,21 @@
|
||||
Qualcomm Global Clock & Reset Controller Binding
|
||||
------------------------------------------------
|
||||
|
||||
Required properties :
|
||||
- compatible : shall contain only one of the following:
|
||||
|
||||
"qcom,gcc-msm8660"
|
||||
"qcom,gcc-msm8960"
|
||||
"qcom,gcc-msm8974"
|
||||
|
||||
- reg : shall contain base register location and length
|
||||
- #clock-cells : shall contain 1
|
||||
- #reset-cells : shall contain 1
|
||||
|
||||
Example:
|
||||
clock-controller@900000 {
|
||||
compatible = "qcom,gcc-msm8960";
|
||||
reg = <0x900000 0x4000>;
|
||||
#clock-cells = <1>;
|
||||
#reset-cells = <1>;
|
||||
};
|
21
Documentation/devicetree/bindings/clock/qcom,mmcc.txt
Normal file
21
Documentation/devicetree/bindings/clock/qcom,mmcc.txt
Normal file
@ -0,0 +1,21 @@
|
||||
Qualcomm Multimedia Clock & Reset Controller Binding
|
||||
----------------------------------------------------
|
||||
|
||||
Required properties :
|
||||
- compatible : shall contain only one of the following:
|
||||
|
||||
"qcom,mmcc-msm8660"
|
||||
"qcom,mmcc-msm8960"
|
||||
"qcom,mmcc-msm8974"
|
||||
|
||||
- reg : shall contain base register location and length
|
||||
- #clock-cells : shall contain 1
|
||||
- #reset-cells : shall contain 1
|
||||
|
||||
Example:
|
||||
clock-controller@4000000 {
|
||||
compatible = "qcom,mmcc-msm8960";
|
||||
reg = <0x4000000 0x1000>;
|
||||
#clock-cells = <1>;
|
||||
#reset-cells = <1>;
|
||||
};
|
@ -0,0 +1,28 @@
|
||||
* Renesas CPG DIV6 Clock
|
||||
|
||||
The CPG DIV6 clocks are variable factor clocks provided by the Clock Pulse
|
||||
Generator (CPG). They clock input is divided by a configurable factor from 1
|
||||
to 64.
|
||||
|
||||
Required Properties:
|
||||
|
||||
- compatible: Must be one of the following
|
||||
- "renesas,r8a7790-div6-clock" for R8A7790 (R-Car H2) DIV6 clocks
|
||||
- "renesas,r8a7791-div6-clock" for R8A7791 (R-Car M2) DIV6 clocks
|
||||
- "renesas,cpg-div6-clock" for generic DIV6 clocks
|
||||
- reg: Base address and length of the memory resource used by the DIV6 clock
|
||||
- clocks: Reference to the parent clock
|
||||
- #clock-cells: Must be 0
|
||||
- clock-output-names: The name of the clock as a free-form string
|
||||
|
||||
|
||||
Example
|
||||
-------
|
||||
|
||||
sd2_clk: sd2_clk@e6150078 {
|
||||
compatible = "renesas,r8a7790-div6-clock", "renesas,cpg-div6-clock";
|
||||
reg = <0 0xe6150078 0 4>;
|
||||
clocks = <&pll1_div2_clk>;
|
||||
#clock-cells = <0>;
|
||||
clock-output-names = "sd2";
|
||||
};
|
@ -0,0 +1,51 @@
|
||||
* Renesas CPG Module Stop (MSTP) Clocks
|
||||
|
||||
The CPG can gate SoC device clocks. The gates are organized in groups of up to
|
||||
32 gates.
|
||||
|
||||
This device tree binding describes a single 32 gate clocks group per node.
|
||||
Clocks are referenced by user nodes by the MSTP node phandle and the clock
|
||||
index in the group, from 0 to 31.
|
||||
|
||||
Required Properties:
|
||||
|
||||
- compatible: Must be one of the following
|
||||
- "renesas,r8a7790-mstp-clocks" for R8A7790 (R-Car H2) MSTP gate clocks
|
||||
- "renesas,r8a7791-mstp-clocks" for R8A7791 (R-Car M2) MSTP gate clocks
|
||||
- "renesas,cpg-mstp-clock" for generic MSTP gate clocks
|
||||
- reg: Base address and length of the I/O mapped registers used by the MSTP
|
||||
clocks. The first register is the clock control register and is mandatory.
|
||||
The second register is the clock status register and is optional when not
|
||||
implemented in hardware.
|
||||
- clocks: Reference to the parent clocks, one per output clock. The parents
|
||||
must appear in the same order as the output clocks.
|
||||
- #clock-cells: Must be 1
|
||||
- clock-output-names: The name of the clocks as free-form strings
|
||||
- renesas,indices: Indices of the gate clocks into the group (0 to 31)
|
||||
|
||||
The clocks, clock-output-names and renesas,indices properties contain one
|
||||
entry per gate clock. The MSTP groups are sparsely populated. Unimplemented
|
||||
gate clocks must not be declared.
|
||||
|
||||
|
||||
Example
|
||||
-------
|
||||
|
||||
#include <dt-bindings/clock/r8a7790-clock.h>
|
||||
|
||||
mstp3_clks: mstp3_clks@e615013c {
|
||||
compatible = "renesas,r8a7790-mstp-clocks", "renesas,cpg-mstp-clocks";
|
||||
reg = <0 0xe615013c 0 4>, <0 0xe6150048 0 4>;
|
||||
clocks = <&cp_clk>, <&mmc1_clk>, <&sd3_clk>, <&sd2_clk>,
|
||||
<&cpg_clocks R8A7790_CLK_SD1>, <&cpg_clocks R8A7790_CLK_SD0>,
|
||||
<&mmc0_clk>;
|
||||
#clock-cells = <1>;
|
||||
clock-output-names =
|
||||
"tpu0", "mmcif1", "sdhi3", "sdhi2",
|
||||
"sdhi1", "sdhi0", "mmcif0";
|
||||
renesas,clock-indices = <
|
||||
R8A7790_CLK_TPU0 R8A7790_CLK_MMCIF1 R8A7790_CLK_SDHI3
|
||||
R8A7790_CLK_SDHI2 R8A7790_CLK_SDHI1 R8A7790_CLK_SDHI0
|
||||
R8A7790_CLK_MMCIF0
|
||||
>;
|
||||
};
|
@ -0,0 +1,32 @@
|
||||
* Renesas R-Car Gen2 Clock Pulse Generator (CPG)
|
||||
|
||||
The CPG generates core clocks for the R-Car Gen2 SoCs. It includes three PLLs
|
||||
and several fixed ratio dividers.
|
||||
|
||||
Required Properties:
|
||||
|
||||
- compatible: Must be one of
|
||||
- "renesas,r8a7790-cpg-clocks" for the r8a7790 CPG
|
||||
- "renesas,r8a7791-cpg-clocks" for the r8a7791 CPG
|
||||
- "renesas,rcar-gen2-cpg-clocks" for the generic R-Car Gen2 CPG
|
||||
|
||||
- reg: Base address and length of the memory resource used by the CPG
|
||||
|
||||
- clocks: Reference to the parent clock
|
||||
- #clock-cells: Must be 1
|
||||
- clock-output-names: The names of the clocks. Supported clocks are "main",
|
||||
"pll0", "pll1", "pll3", "lb", "qspi", "sdh", "sd0", "sd1" and "z"
|
||||
|
||||
|
||||
Example
|
||||
-------
|
||||
|
||||
cpg_clocks: cpg_clocks@e6150000 {
|
||||
compatible = "renesas,r8a7790-cpg-clocks",
|
||||
"renesas,rcar-gen2-cpg-clocks";
|
||||
reg = <0 0xe6150000 0 0x1000>;
|
||||
clocks = <&extal_clk>;
|
||||
#clock-cells = <1>;
|
||||
clock-output-names = "main", "pll0, "pll1", "pll3",
|
||||
"lb", "qspi", "sdh", "sd0", "sd1", "z";
|
||||
};
|
39
Documentation/devicetree/bindings/clock/silabs,si570.txt
Normal file
39
Documentation/devicetree/bindings/clock/silabs,si570.txt
Normal file
@ -0,0 +1,39 @@
|
||||
Binding for Silicon Labs 570, 571, 598 and 599 programmable
|
||||
I2C clock generators.
|
||||
|
||||
Reference
|
||||
This binding uses the common clock binding[1]. Details about the devices can be
|
||||
found in the data sheets[2][3].
|
||||
|
||||
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
|
||||
[2] Si570/571 Data Sheet
|
||||
http://www.silabs.com/Support%20Documents/TechnicalDocs/si570.pdf
|
||||
[3] Si598/599 Data Sheet
|
||||
http://www.silabs.com/Support%20Documents/TechnicalDocs/si598-99.pdf
|
||||
|
||||
Required properties:
|
||||
- compatible: Shall be one of "silabs,si570", "silabs,si571",
|
||||
"silabs,si598", "silabs,si599"
|
||||
- reg: I2C device address.
|
||||
- #clock-cells: From common clock bindings: Shall be 0.
|
||||
- factory-fout: Factory set default frequency. This frequency is part specific.
|
||||
The correct frequency for the part used has to be provided in
|
||||
order to generate the correct output frequencies. For more
|
||||
details, please refer to the data sheet.
|
||||
- temperature-stability: Temperature stability of the device in PPM. Should be
|
||||
one of: 7, 20, 50 or 100.
|
||||
|
||||
Optional properties:
|
||||
- clock-output-names: From common clock bindings. Recommended to be "si570".
|
||||
- clock-frequency: Output frequency to generate. This defines the output
|
||||
frequency set during boot. It can be reprogrammed during
|
||||
runtime through the common clock framework.
|
||||
|
||||
Example:
|
||||
si570: clock-generator@5d {
|
||||
#clock-cells = <0>;
|
||||
compatible = "silabs,si570";
|
||||
temperature-stability = <50>;
|
||||
reg = <0x5d>;
|
||||
factory-fout = <156250000>;
|
||||
};
|
@ -7,8 +7,10 @@ This binding uses the common clock binding[1].
|
||||
Required properties:
|
||||
- compatible : shall be one of the following:
|
||||
"allwinner,sun4i-osc-clk" - for a gatable oscillator
|
||||
"allwinner,sun4i-pll1-clk" - for the main PLL clock
|
||||
"allwinner,sun4i-pll1-clk" - for the main PLL clock and PLL4
|
||||
"allwinner,sun6i-a31-pll1-clk" - for the main PLL clock on A31
|
||||
"allwinner,sun4i-pll5-clk" - for the PLL5 clock
|
||||
"allwinner,sun4i-pll6-clk" - for the PLL6 clock
|
||||
"allwinner,sun4i-cpu-clk" - for the CPU multiplexer clock
|
||||
"allwinner,sun4i-axi-clk" - for the AXI clock
|
||||
"allwinner,sun4i-axi-gates-clk" - for the AXI gates
|
||||
@ -33,10 +35,14 @@ Required properties:
|
||||
"allwinner,sun7i-a20-apb1-gates-clk" - for the APB1 gates on A20
|
||||
"allwinner,sun6i-a31-apb2-div-clk" - for the APB2 gates on A31
|
||||
"allwinner,sun6i-a31-apb2-gates-clk" - for the APB2 gates on A31
|
||||
"allwinner,sun4i-mod0-clk" - for the module 0 family of clocks
|
||||
"allwinner,sun7i-a20-out-clk" - for the external output clocks
|
||||
|
||||
Required properties for all clocks:
|
||||
- reg : shall be the control register address for the clock.
|
||||
- clocks : shall be the input parent clock(s) phandle for the clock
|
||||
- clocks : shall be the input parent clock(s) phandle for the clock. For
|
||||
multiplexed clocks, the list order must match the hardware
|
||||
programming order.
|
||||
- #clock-cells : from common clock binding; shall be set to 0 except for
|
||||
"allwinner,*-gates-clk" where it shall be set to 1
|
||||
|
||||
|
@ -22,6 +22,10 @@ Required properties:
|
||||
Optional properties:
|
||||
- clocks : as described in the clock bindings
|
||||
- clock-names : as described in the clock bindings
|
||||
- fclk-enable : Bit mask to enable FCLKs statically at boot time.
|
||||
Bit [0..3] correspond to FCLK0..FCLK3. The corresponding
|
||||
FCLK will only be enabled if it is actually running at
|
||||
boot time.
|
||||
|
||||
Clock inputs:
|
||||
The following strings are optional parameters to the 'clock-names' property in
|
||||
|
@ -15,6 +15,10 @@ Optional properties:
|
||||
- clock-latency: Specify the possible maximum transition latency for clock,
|
||||
in unit of nanoseconds.
|
||||
- voltage-tolerance: Specify the CPU voltage tolerance in percentage.
|
||||
- #cooling-cells:
|
||||
- cooling-min-level:
|
||||
- cooling-max-level:
|
||||
Please refer to Documentation/devicetree/bindings/thermal/thermal.txt.
|
||||
|
||||
Examples:
|
||||
|
||||
@ -33,6 +37,9 @@ cpus {
|
||||
198000 850000
|
||||
>;
|
||||
clock-latency = <61036>; /* two CLK32 periods */
|
||||
#cooling-cells = <2>;
|
||||
cooling-min-level = <0>;
|
||||
cooling-max-level = <2>;
|
||||
};
|
||||
|
||||
cpu@1 {
|
||||
|
68
Documentation/devicetree/bindings/crypto/atmel-crypto.txt
Normal file
68
Documentation/devicetree/bindings/crypto/atmel-crypto.txt
Normal file
@ -0,0 +1,68 @@
|
||||
* Atmel HW cryptographic accelerators
|
||||
|
||||
These are the HW cryptographic accelerators found on some Atmel products.
|
||||
|
||||
* Advanced Encryption Standard (AES)
|
||||
|
||||
Required properties:
|
||||
- compatible : Should be "atmel,at91sam9g46-aes".
|
||||
- reg: Should contain AES registers location and length.
|
||||
- interrupts: Should contain the IRQ line for the AES.
|
||||
- dmas: List of two DMA specifiers as described in
|
||||
atmel-dma.txt and dma.txt files.
|
||||
- dma-names: Contains one identifier string for each DMA specifier
|
||||
in the dmas property.
|
||||
|
||||
Example:
|
||||
aes@f8038000 {
|
||||
compatible = "atmel,at91sam9g46-aes";
|
||||
reg = <0xf8038000 0x100>;
|
||||
interrupts = <43 4 0>;
|
||||
dmas = <&dma1 2 18>,
|
||||
<&dma1 2 19>;
|
||||
dma-names = "tx", "rx";
|
||||
|
||||
* Triple Data Encryption Standard (Triple DES)
|
||||
|
||||
Required properties:
|
||||
- compatible : Should be "atmel,at91sam9g46-tdes".
|
||||
- reg: Should contain TDES registers location and length.
|
||||
- interrupts: Should contain the IRQ line for the TDES.
|
||||
|
||||
Optional properties:
|
||||
- dmas: List of two DMA specifiers as described in
|
||||
atmel-dma.txt and dma.txt files.
|
||||
- dma-names: Contains one identifier string for each DMA specifier
|
||||
in the dmas property.
|
||||
|
||||
Example:
|
||||
tdes@f803c000 {
|
||||
compatible = "atmel,at91sam9g46-tdes";
|
||||
reg = <0xf803c000 0x100>;
|
||||
interrupts = <44 4 0>;
|
||||
dmas = <&dma1 2 20>,
|
||||
<&dma1 2 21>;
|
||||
dma-names = "tx", "rx";
|
||||
};
|
||||
|
||||
* Secure Hash Algorithm (SHA)
|
||||
|
||||
Required properties:
|
||||
- compatible : Should be "atmel,at91sam9g46-sha".
|
||||
- reg: Should contain SHA registers location and length.
|
||||
- interrupts: Should contain the IRQ line for the SHA.
|
||||
|
||||
Optional properties:
|
||||
- dmas: One DMA specifiers as described in
|
||||
atmel-dma.txt and dma.txt files.
|
||||
- dma-names: Contains one identifier string for each DMA specifier
|
||||
in the dmas property. Only one "tx" string needed.
|
||||
|
||||
Example:
|
||||
sha@f8034000 {
|
||||
compatible = "atmel,at91sam9g46-sha";
|
||||
reg = <0xf8034000 0x100>;
|
||||
interrupts = <42 4 0>;
|
||||
dmas = <&dma1 2 17>;
|
||||
dma-names = "tx";
|
||||
};
|
17
Documentation/devicetree/bindings/crypto/fsl-dcp.txt
Normal file
17
Documentation/devicetree/bindings/crypto/fsl-dcp.txt
Normal file
@ -0,0 +1,17 @@
|
||||
Freescale DCP (Data Co-Processor) found on i.MX23/i.MX28 .
|
||||
|
||||
Required properties:
|
||||
- compatible : Should be "fsl,<soc>-dcp"
|
||||
- reg : Should contain MXS DCP registers location and length
|
||||
- interrupts : Should contain MXS DCP interrupt numbers, VMI IRQ and DCP IRQ
|
||||
must be supplied, optionally Secure IRQ can be present, but
|
||||
is currently not implemented and not used.
|
||||
|
||||
Example:
|
||||
|
||||
dcp@80028000 {
|
||||
compatible = "fsl,imx28-dcp", "fsl,imx23-dcp";
|
||||
reg = <0x80028000 0x2000>;
|
||||
interrupts = <52 53>;
|
||||
status = "okay";
|
||||
};
|
@ -50,6 +50,9 @@ Each dmas request consists of 4 cells:
|
||||
0x00000008: Use fixed channel:
|
||||
Use automatic channel selection when unset
|
||||
Use DMA request line number when set
|
||||
0x00000010: Set channel as high priority:
|
||||
Normal priority when unset
|
||||
High priority when set
|
||||
|
||||
Example:
|
||||
|
||||
|
@ -5,6 +5,16 @@ Required properties:
|
||||
- reg: Should contain DMA registers location and length. This shuld include
|
||||
all of the per-channel registers.
|
||||
- interrupts: Should contain all of the per-channel DMA interrupts.
|
||||
- clocks: Must contain one entry, for the module clock.
|
||||
See ../clocks/clock-bindings.txt for details.
|
||||
- resets : Must contain an entry for each entry in reset-names.
|
||||
See ../reset/reset.txt for details.
|
||||
- reset-names : Must include the following entries:
|
||||
- dma
|
||||
- #dma-cells : Must be <1>. This dictates the length of DMA specifiers in
|
||||
client nodes' dmas properties. The specifier represents the DMA request
|
||||
select value for the peripheral. For more details, consult the Tegra TRM's
|
||||
documentation of the APB DMA channel control register REQ_SEL field.
|
||||
|
||||
Examples:
|
||||
|
||||
@ -27,4 +37,8 @@ apbdma: dma@6000a000 {
|
||||
0 149 0x04
|
||||
0 150 0x04
|
||||
0 151 0x04 >;
|
||||
clocks = <&tegra_car 34>;
|
||||
resets = <&tegra_car 34>;
|
||||
reset-names = "dma";
|
||||
#dma-cells = <1>;
|
||||
};
|
||||
|
@ -2,7 +2,11 @@ EXTCON FOR PALMAS/TWL CHIPS
|
||||
|
||||
PALMAS USB COMPARATOR
|
||||
Required Properties:
|
||||
- compatible : Should be "ti,palmas-usb" or "ti,twl6035-usb"
|
||||
- compatible: should contain one of:
|
||||
* "ti,palmas-usb-vid".
|
||||
* "ti,twl6035-usb-vid".
|
||||
* "ti,palmas-usb" (DEPRECATED - use "ti,palmas-usb-vid").
|
||||
* "ti,twl6035-usb" (DEPRECATED - use "ti,twl6035-usb-vid").
|
||||
|
||||
Optional Properties:
|
||||
- ti,wakeup : To enable the wakeup comparator in probe
|
||||
|
41
Documentation/devicetree/bindings/gpio/gpio-davinci.txt
Normal file
41
Documentation/devicetree/bindings/gpio/gpio-davinci.txt
Normal file
@ -0,0 +1,41 @@
|
||||
Davinci GPIO controller bindings
|
||||
|
||||
Required Properties:
|
||||
- compatible: should be "ti,dm6441-gpio"
|
||||
|
||||
- reg: Physical base address of the controller and the size of memory mapped
|
||||
registers.
|
||||
|
||||
- gpio-controller : Marks the device node as a gpio controller.
|
||||
|
||||
- interrupt-parent: phandle of the parent interrupt controller.
|
||||
|
||||
- interrupts: Array of GPIO interrupt number. Only banked or unbanked IRQs are
|
||||
supported at a time.
|
||||
|
||||
- ti,ngpio: The number of GPIO pins supported.
|
||||
|
||||
- ti,davinci-gpio-unbanked: The number of GPIOs that have an individual interrupt
|
||||
line to processor.
|
||||
|
||||
The GPIO controller also acts as an interrupt controller. It uses the default
|
||||
two cells specifier as described in Documentation/devicetree/bindings/
|
||||
interrupt-controller/interrupts.txt.
|
||||
|
||||
Example:
|
||||
|
||||
gpio: gpio@1e26000 {
|
||||
compatible = "ti,dm6441-gpio";
|
||||
gpio-controller;
|
||||
reg = <0x226000 0x1000>;
|
||||
interrupt-parent = <&intc>;
|
||||
interrupts = <42 IRQ_TYPE_EDGE_BOTH 43 IRQ_TYPE_EDGE_BOTH
|
||||
44 IRQ_TYPE_EDGE_BOTH 45 IRQ_TYPE_EDGE_BOTH
|
||||
46 IRQ_TYPE_EDGE_BOTH 47 IRQ_TYPE_EDGE_BOTH
|
||||
48 IRQ_TYPE_EDGE_BOTH 49 IRQ_TYPE_EDGE_BOTH
|
||||
50 IRQ_TYPE_EDGE_BOTH>;
|
||||
ti,ngpio = <144>;
|
||||
ti,davinci-gpio-unbanked = <0>;
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <2>;
|
||||
};
|
37
Documentation/devicetree/bindings/gpio/gpio-lp3943.txt
Normal file
37
Documentation/devicetree/bindings/gpio/gpio-lp3943.txt
Normal file
@ -0,0 +1,37 @@
|
||||
TI/National Semiconductor LP3943 GPIO controller
|
||||
|
||||
Required properties:
|
||||
- compatible: "ti,lp3943-gpio"
|
||||
- gpio-controller: Marks the device node as a GPIO controller.
|
||||
- #gpio-cells: Should be 2. See gpio.txt in this directory for a
|
||||
description of the cells format.
|
||||
|
||||
Example:
|
||||
Simple LED controls with LP3943 GPIO controller
|
||||
|
||||
&i2c4 {
|
||||
lp3943@60 {
|
||||
compatible = "ti,lp3943";
|
||||
reg = <0x60>;
|
||||
|
||||
gpioex: gpio {
|
||||
compatible = "ti,lp3943-gpio";
|
||||
gpio-controller;
|
||||
#gpio-cells = <2>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
leds {
|
||||
compatible = "gpio-leds";
|
||||
indicator1 {
|
||||
label = "indi1";
|
||||
gpios = <&gpioex 9 GPIO_ACTIVE_LOW>;
|
||||
};
|
||||
|
||||
indicator2 {
|
||||
label = "indi2";
|
||||
gpios = <&gpioex 10 GPIO_ACTIVE_LOW>;
|
||||
default-state = "off";
|
||||
};
|
||||
};
|
@ -38,12 +38,38 @@ Required device specific properties (only for SPI chips):
|
||||
removed.
|
||||
- spi-max-frequency = The maximum frequency this chip is able to handle
|
||||
|
||||
Example I2C:
|
||||
Optional properties:
|
||||
- #interrupt-cells : Should be two.
|
||||
- first cell is the pin number
|
||||
- second cell is used to specify flags.
|
||||
- interrupt-controller: Marks the device node as a interrupt controller.
|
||||
NOTE: The interrupt functionality is only supported for i2c versions of the
|
||||
chips. The spi chips can also do the interrupts, but this is not supported by
|
||||
the linux driver yet.
|
||||
|
||||
Optional device specific properties:
|
||||
- microchip,irq-mirror: Sets the mirror flag in the IOCON register. Devices
|
||||
with two interrupt outputs (these are the devices ending with 17 and
|
||||
those that have 16 IOs) have two IO banks: IO 0-7 form bank 1 and
|
||||
IO 8-15 are bank 2. These chips have two different interrupt outputs:
|
||||
One for bank 1 and another for bank 2. If irq-mirror is set, both
|
||||
interrupts are generated regardless of the bank that an input change
|
||||
occured on. If it is not set, the interrupt are only generated for the
|
||||
bank they belong to.
|
||||
On devices with only one interrupt output this property is useless.
|
||||
|
||||
Example I2C (with interrupt):
|
||||
gpiom1: gpio@20 {
|
||||
compatible = "microchip,mcp23017";
|
||||
gpio-controller;
|
||||
#gpio-cells = <2>;
|
||||
reg = <0x20>;
|
||||
|
||||
interrupt-parent = <&gpio1>;
|
||||
interrupts = <17 IRQ_TYPE_LEVEL_LOW>;
|
||||
interrupt-controller;
|
||||
#interrupt-cells=<2>;
|
||||
microchip,irq-mirror;
|
||||
};
|
||||
|
||||
Example SPI:
|
||||
|
19
Documentation/devicetree/bindings/gpio/moxa,moxart-gpio.txt
Normal file
19
Documentation/devicetree/bindings/gpio/moxa,moxart-gpio.txt
Normal file
@ -0,0 +1,19 @@
|
||||
MOXA ART GPIO Controller
|
||||
|
||||
Required properties:
|
||||
|
||||
- #gpio-cells : Should be 2, The first cell is the pin number,
|
||||
the second cell is used to specify polarity:
|
||||
0 = active high
|
||||
1 = active low
|
||||
- compatible : Must be "moxa,moxart-gpio"
|
||||
- reg : Should contain registers location and length
|
||||
|
||||
Example:
|
||||
|
||||
gpio: gpio@98700000 {
|
||||
gpio-controller;
|
||||
#gpio-cells = <2>;
|
||||
compatible = "moxa,moxart-gpio";
|
||||
reg = <0x98700000 0xC>;
|
||||
};
|
@ -2,10 +2,11 @@
|
||||
|
||||
Required Properties:
|
||||
|
||||
- compatible: should be one of the following.
|
||||
- compatible: should contain one of the following.
|
||||
- "renesas,gpio-r8a7778": for R8A7778 (R-Mobile M1) compatible GPIO controller.
|
||||
- "renesas,gpio-r8a7779": for R8A7779 (R-Car H1) compatible GPIO controller.
|
||||
- "renesas,gpio-r8a7790": for R8A7790 (R-Car H2) compatible GPIO controller.
|
||||
- "renesas,gpio-r8a7791": for R8A7791 (R-Car M2) compatible GPIO controller.
|
||||
- "renesas,gpio-rcar": for generic R-Car GPIO controller.
|
||||
|
||||
- reg: Base address and length of each memory resource used by the GPIO
|
||||
|
@ -9,6 +9,12 @@ Required properties:
|
||||
- #size-cells: The number of cells used to represent the size of an address
|
||||
range in the host1x address space. Should be 1.
|
||||
- ranges: The mapping of the host1x address space to the CPU address space.
|
||||
- clocks: Must contain one entry, for the module clock.
|
||||
See ../clocks/clock-bindings.txt for details.
|
||||
- resets: Must contain an entry for each entry in reset-names.
|
||||
See ../reset/reset.txt for details.
|
||||
- reset-names: Must include the following entries:
|
||||
- host1x
|
||||
|
||||
The host1x top-level node defines a number of children, each representing one
|
||||
of the following host1x client modules:
|
||||
@ -19,6 +25,12 @@ of the following host1x client modules:
|
||||
- compatible: "nvidia,tegra<chip>-mpe"
|
||||
- reg: Physical base address and length of the controller's registers.
|
||||
- interrupts: The interrupt outputs from the controller.
|
||||
- clocks: Must contain one entry, for the module clock.
|
||||
See ../clocks/clock-bindings.txt for details.
|
||||
- resets: Must contain an entry for each entry in reset-names.
|
||||
See ../reset/reset.txt for details.
|
||||
- reset-names: Must include the following entries:
|
||||
- mpe
|
||||
|
||||
- vi: video input
|
||||
|
||||
@ -26,6 +38,12 @@ of the following host1x client modules:
|
||||
- compatible: "nvidia,tegra<chip>-vi"
|
||||
- reg: Physical base address and length of the controller's registers.
|
||||
- interrupts: The interrupt outputs from the controller.
|
||||
- clocks: Must contain one entry, for the module clock.
|
||||
See ../clocks/clock-bindings.txt for details.
|
||||
- resets: Must contain an entry for each entry in reset-names.
|
||||
See ../reset/reset.txt for details.
|
||||
- reset-names: Must include the following entries:
|
||||
- vi
|
||||
|
||||
- epp: encoder pre-processor
|
||||
|
||||
@ -33,6 +51,12 @@ of the following host1x client modules:
|
||||
- compatible: "nvidia,tegra<chip>-epp"
|
||||
- reg: Physical base address and length of the controller's registers.
|
||||
- interrupts: The interrupt outputs from the controller.
|
||||
- clocks: Must contain one entry, for the module clock.
|
||||
See ../clocks/clock-bindings.txt for details.
|
||||
- resets: Must contain an entry for each entry in reset-names.
|
||||
See ../reset/reset.txt for details.
|
||||
- reset-names: Must include the following entries:
|
||||
- epp
|
||||
|
||||
- isp: image signal processor
|
||||
|
||||
@ -40,6 +64,12 @@ of the following host1x client modules:
|
||||
- compatible: "nvidia,tegra<chip>-isp"
|
||||
- reg: Physical base address and length of the controller's registers.
|
||||
- interrupts: The interrupt outputs from the controller.
|
||||
- clocks: Must contain one entry, for the module clock.
|
||||
See ../clocks/clock-bindings.txt for details.
|
||||
- resets: Must contain an entry for each entry in reset-names.
|
||||
See ../reset/reset.txt for details.
|
||||
- reset-names: Must include the following entries:
|
||||
- isp
|
||||
|
||||
- gr2d: 2D graphics engine
|
||||
|
||||
@ -47,12 +77,30 @@ of the following host1x client modules:
|
||||
- compatible: "nvidia,tegra<chip>-gr2d"
|
||||
- reg: Physical base address and length of the controller's registers.
|
||||
- interrupts: The interrupt outputs from the controller.
|
||||
- clocks: Must contain one entry, for the module clock.
|
||||
See ../clocks/clock-bindings.txt for details.
|
||||
- resets: Must contain an entry for each entry in reset-names.
|
||||
See ../reset/reset.txt for details.
|
||||
- reset-names: Must include the following entries:
|
||||
- 2d
|
||||
|
||||
- gr3d: 3D graphics engine
|
||||
|
||||
Required properties:
|
||||
- compatible: "nvidia,tegra<chip>-gr3d"
|
||||
- reg: Physical base address and length of the controller's registers.
|
||||
- clocks: Must contain an entry for each entry in clock-names.
|
||||
See ../clocks/clock-bindings.txt for details.
|
||||
- clock-names: Must include the following entries:
|
||||
(This property may be omitted if the only clock in the list is "3d")
|
||||
- 3d
|
||||
This MUST be the first entry.
|
||||
- 3d2 (Only required on SoCs with two 3D clocks)
|
||||
- resets: Must contain an entry for each entry in reset-names.
|
||||
See ../reset/reset.txt for details.
|
||||
- reset-names: Must include the following entries:
|
||||
- 3d
|
||||
- 3d2 (Only required on SoCs with two 3D clocks)
|
||||
|
||||
- dc: display controller
|
||||
|
||||
@ -60,6 +108,16 @@ of the following host1x client modules:
|
||||
- compatible: "nvidia,tegra<chip>-dc"
|
||||
- reg: Physical base address and length of the controller's registers.
|
||||
- interrupts: The interrupt outputs from the controller.
|
||||
- clocks: Must contain an entry for each entry in clock-names.
|
||||
See ../clocks/clock-bindings.txt for details.
|
||||
- clock-names: Must include the following entries:
|
||||
- dc
|
||||
This MUST be the first entry.
|
||||
- parent
|
||||
- resets: Must contain an entry for each entry in reset-names.
|
||||
See ../reset/reset.txt for details.
|
||||
- reset-names: Must include the following entries:
|
||||
- dc
|
||||
|
||||
Each display controller node has a child node, named "rgb", that represents
|
||||
the RGB output associated with the controller. It can take the following
|
||||
@ -76,6 +134,16 @@ of the following host1x client modules:
|
||||
- interrupts: The interrupt outputs from the controller.
|
||||
- vdd-supply: regulator for supply voltage
|
||||
- pll-supply: regulator for PLL
|
||||
- clocks: Must contain an entry for each entry in clock-names.
|
||||
See ../clocks/clock-bindings.txt for details.
|
||||
- clock-names: Must include the following entries:
|
||||
- hdmi
|
||||
This MUST be the first entry.
|
||||
- parent
|
||||
- resets: Must contain an entry for each entry in reset-names.
|
||||
See ../reset/reset.txt for details.
|
||||
- reset-names: Must include the following entries:
|
||||
- hdmi
|
||||
|
||||
Optional properties:
|
||||
- nvidia,ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
|
||||
@ -88,12 +156,24 @@ of the following host1x client modules:
|
||||
- compatible: "nvidia,tegra<chip>-tvo"
|
||||
- reg: Physical base address and length of the controller's registers.
|
||||
- interrupts: The interrupt outputs from the controller.
|
||||
- clocks: Must contain one entry, for the module clock.
|
||||
See ../clocks/clock-bindings.txt for details.
|
||||
|
||||
- dsi: display serial interface
|
||||
|
||||
Required properties:
|
||||
- compatible: "nvidia,tegra<chip>-dsi"
|
||||
- reg: Physical base address and length of the controller's registers.
|
||||
- clocks: Must contain an entry for each entry in clock-names.
|
||||
See ../clocks/clock-bindings.txt for details.
|
||||
- clock-names: Must include the following entries:
|
||||
- dsi
|
||||
This MUST be the first entry.
|
||||
- parent
|
||||
- resets: Must contain an entry for each entry in reset-names.
|
||||
See ../reset/reset.txt for details.
|
||||
- reset-names: Must include the following entries:
|
||||
- dsi
|
||||
|
||||
Example:
|
||||
|
||||
@ -105,6 +185,9 @@ Example:
|
||||
reg = <0x50000000 0x00024000>;
|
||||
interrupts = <0 65 0x04 /* mpcore syncpt */
|
||||
0 67 0x04>; /* mpcore general */
|
||||
clocks = <&tegra_car TEGRA20_CLK_HOST1X>;
|
||||
resets = <&tegra_car 28>;
|
||||
reset-names = "host1x";
|
||||
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
@ -115,41 +198,64 @@ Example:
|
||||
compatible = "nvidia,tegra20-mpe";
|
||||
reg = <0x54040000 0x00040000>;
|
||||
interrupts = <0 68 0x04>;
|
||||
clocks = <&tegra_car TEGRA20_CLK_MPE>;
|
||||
resets = <&tegra_car 60>;
|
||||
reset-names = "mpe";
|
||||
};
|
||||
|
||||
vi {
|
||||
compatible = "nvidia,tegra20-vi";
|
||||
reg = <0x54080000 0x00040000>;
|
||||
interrupts = <0 69 0x04>;
|
||||
clocks = <&tegra_car TEGRA20_CLK_VI>;
|
||||
resets = <&tegra_car 100>;
|
||||
reset-names = "vi";
|
||||
};
|
||||
|
||||
epp {
|
||||
compatible = "nvidia,tegra20-epp";
|
||||
reg = <0x540c0000 0x00040000>;
|
||||
interrupts = <0 70 0x04>;
|
||||
clocks = <&tegra_car TEGRA20_CLK_EPP>;
|
||||
resets = <&tegra_car 19>;
|
||||
reset-names = "epp";
|
||||
};
|
||||
|
||||
isp {
|
||||
compatible = "nvidia,tegra20-isp";
|
||||
reg = <0x54100000 0x00040000>;
|
||||
interrupts = <0 71 0x04>;
|
||||
clocks = <&tegra_car TEGRA20_CLK_ISP>;
|
||||
resets = <&tegra_car 23>;
|
||||
reset-names = "isp";
|
||||
};
|
||||
|
||||
gr2d {
|
||||
compatible = "nvidia,tegra20-gr2d";
|
||||
reg = <0x54140000 0x00040000>;
|
||||
interrupts = <0 72 0x04>;
|
||||
clocks = <&tegra_car TEGRA20_CLK_GR2D>;
|
||||
resets = <&tegra_car 21>;
|
||||
reset-names = "2d";
|
||||
};
|
||||
|
||||
gr3d {
|
||||
compatible = "nvidia,tegra20-gr3d";
|
||||
reg = <0x54180000 0x00040000>;
|
||||
clocks = <&tegra_car TEGRA20_CLK_GR3D>;
|
||||
resets = <&tegra_car 24>;
|
||||
reset-names = "3d";
|
||||
};
|
||||
|
||||
dc@54200000 {
|
||||
compatible = "nvidia,tegra20-dc";
|
||||
reg = <0x54200000 0x00040000>;
|
||||
interrupts = <0 73 0x04>;
|
||||
clocks = <&tegra_car TEGRA20_CLK_DISP1>,
|
||||
<&tegra_car TEGRA20_CLK_PLL_P>;
|
||||
clock-names = "disp1", "parent";
|
||||
resets = <&tegra_car 27>;
|
||||
reset-names = "dc";
|
||||
|
||||
rgb {
|
||||
status = "disabled";
|
||||
@ -160,6 +266,11 @@ Example:
|
||||
compatible = "nvidia,tegra20-dc";
|
||||
reg = <0x54240000 0x00040000>;
|
||||
interrupts = <0 74 0x04>;
|
||||
clocks = <&tegra_car TEGRA20_CLK_DISP2>,
|
||||
<&tegra_car TEGRA20_CLK_PLL_P>;
|
||||
clock-names = "disp2", "parent";
|
||||
resets = <&tegra_car 26>;
|
||||
reset-names = "dc";
|
||||
|
||||
rgb {
|
||||
status = "disabled";
|
||||
@ -170,6 +281,11 @@ Example:
|
||||
compatible = "nvidia,tegra20-hdmi";
|
||||
reg = <0x54280000 0x00040000>;
|
||||
interrupts = <0 75 0x04>;
|
||||
clocks = <&tegra_car TEGRA20_CLK_HDMI>,
|
||||
<&tegra_car TEGRA20_CLK_PLL_D_OUT0>;
|
||||
clock-names = "hdmi", "parent";
|
||||
resets = <&tegra_car 51>;
|
||||
reset-names = "hdmi";
|
||||
status = "disabled";
|
||||
};
|
||||
|
||||
@ -177,12 +293,18 @@ Example:
|
||||
compatible = "nvidia,tegra20-tvo";
|
||||
reg = <0x542c0000 0x00040000>;
|
||||
interrupts = <0 76 0x04>;
|
||||
clocks = <&tegra_car TEGRA20_CLK_TVO>;
|
||||
status = "disabled";
|
||||
};
|
||||
|
||||
dsi {
|
||||
compatible = "nvidia,tegra20-dsi";
|
||||
reg = <0x54300000 0x00040000>;
|
||||
clocks = <&tegra_car TEGRA20_CLK_DSI>,
|
||||
<&tegra_car TEGRA20_CLK_PLL_D_OUT0>;
|
||||
clock-names = "dsi", "parent";
|
||||
resets = <&tegra_car 48>;
|
||||
reset-names = "dsi";
|
||||
status = "disabled";
|
||||
};
|
||||
};
|
||||
|
@ -9,6 +9,7 @@ Required properties :
|
||||
- interrupts: interrupt number to the cpu.
|
||||
- #address-cells = <1>;
|
||||
- #size-cells = <0>;
|
||||
- clocks: phandles to input clocks.
|
||||
|
||||
Optional properties:
|
||||
- Child nodes conforming to i2c bus binding
|
||||
@ -21,6 +22,7 @@ i2c0: i2c@fff84000 {
|
||||
interrupts = <12 4 6>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
clocks = <&twi0_clk>;
|
||||
|
||||
24c512@50 {
|
||||
compatible = "24c512";
|
||||
|
50
Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt
Normal file
50
Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt
Normal file
@ -0,0 +1,50 @@
|
||||
* NXP PCA954x I2C bus switch
|
||||
|
||||
Required Properties:
|
||||
|
||||
- compatible: Must contain one of the following.
|
||||
"nxp,pca9540", "nxp,pca9542", "nxp,pca9543", "nxp,pca9544",
|
||||
"nxp,pca9545", "nxp,pca9546", "nxp,pca9547", "nxp,pca9548"
|
||||
|
||||
- reg: The I2C address of the device.
|
||||
|
||||
The following required properties are defined externally:
|
||||
|
||||
- Standard I2C mux properties. See i2c-mux.txt in this directory.
|
||||
- I2C child bus nodes. See i2c-mux.txt in this directory.
|
||||
|
||||
Optional Properties:
|
||||
|
||||
- reset-gpios: Reference to the GPIO connected to the reset input.
|
||||
|
||||
|
||||
Example:
|
||||
|
||||
i2c-switch@74 {
|
||||
compatible = "nxp,pca9548";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
reg = <0x74>;
|
||||
|
||||
i2c@2 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
reg = <2>;
|
||||
|
||||
eeprom@54 {
|
||||
compatible = "at,24c08";
|
||||
reg = <0x54>;
|
||||
};
|
||||
};
|
||||
|
||||
i2c@4 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
reg = <4>;
|
||||
|
||||
rtc@51 {
|
||||
compatible = "nxp,pcf8563";
|
||||
reg = <0x51>;
|
||||
};
|
||||
};
|
||||
};
|
@ -5,7 +5,11 @@ Required properties :
|
||||
|
||||
- reg : Offset and length of the register set for the device
|
||||
- compatible : Should be "marvell,mv64xxx-i2c" or "allwinner,sun4i-i2c"
|
||||
or "marvell,mv78230-i2c"
|
||||
or "marvell,mv78230-i2c" or "marvell,mv78230-a0-i2c"
|
||||
Note: Only use "marvell,mv78230-a0-i2c" for a very rare,
|
||||
initial version of the SoC which had broken offload
|
||||
support. Linux auto-detects this and sets it
|
||||
appropriately.
|
||||
- interrupts : The interrupt number
|
||||
|
||||
Optional properties :
|
||||
|
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue
Block a user