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:
Greg Kroah-Hartman 2014-01-27 05:44:53 -08:00
commit cc11f372e9
6772 changed files with 296525 additions and 138040 deletions
Documentation
ABI/testing
DocBook
HOWTOIRQ-domain.txt
PCI
RCU
acpi
arm
Marvell
Samsung-S3C24XX
block
blockdev
cgroups
circular-buffers.txtclk.txt
cpu-freq
cpu-hotplug.txt
device-mapper
devices.txt
devicetree/bindings

View 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.

View 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

View 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

View 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.

View File

@ -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

View File

@ -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:

View File

@ -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>

View File

@ -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

View 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.

View 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

View 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

View File

@ -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.

View 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

View 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.

View 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".

View File

@ -10,5 +10,6 @@
*.out
*.png
*.gif
*.svg
media-indices.tmpl
media-entities.tmpl

View File

@ -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 ***"; \

View File

@ -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

View File

@ -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

View File

@ -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

View File

@ -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

View File

@ -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().

View File

@ -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)

View File

@ -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

View File

@ -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

View File

@ -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.

View File

@ -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.

View File

@ -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
---------------

View File

@ -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
-----------

View 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.

View File

@ -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"
------------------

View File

@ -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
=============

View File

@ -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:

View File

@ -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

View File

@ -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

View File

@ -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.
===============

View File

@ -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.

View File

@ -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

View 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

View File

@ -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,
};

View File

@ -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
-------

View File

@ -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
--------

View File

@ -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>

View File

@ -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

View 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.

View File

@ -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>;

View File

@ -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.

View File

@ -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.

View File

@ -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>;
};
};

View File

@ -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"

View File

@ -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>;
};

View File

@ -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

View 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";
...
}

View 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"

View File

@ -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:

View File

@ -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>;
};

View File

@ -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.

View File

@ -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).

View File

@ -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.

View File

@ -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.

View 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>;
};

View 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>;
};

View File

@ -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.

View File

@ -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.

View 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>;
};
};

View File

@ -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]

View File

@ -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>;
};

View File

@ -19,6 +19,6 @@ Example:
compatible = "fixed-factor-clock";
clocks = <&parentclk>;
#clock-cells = <0>;
div = <2>;
mult = <1>;
clock-div = <2>;
clock-mult = <1>;
};

View 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>.

View 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";
};

View File

@ -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";
};

View File

@ -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:

View 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>;
};

View File

@ -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 {

View File

@ -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>;
};
};

View File

@ -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 {

View File

@ -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 {

View 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>;
};

View 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>;
};

View File

@ -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";
};

View File

@ -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
>;
};

View File

@ -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";
};

View 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>;
};

View File

@ -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

View File

@ -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

View File

@ -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 {

View 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";
};

View 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";
};

View File

@ -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:

View File

@ -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>;
};

View File

@ -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

View 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>;
};

View 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";
};
};

View File

@ -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:

View 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>;
};

View File

@ -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

View File

@ -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";
};
};

View File

@ -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";

View 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>;
};
};
};

View File

@ -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