Skip to content

Commit

Permalink
Merge branch 'for-joerg/arm-smmu/fixes' of git://git.kernel.org/pub/s…
Browse files Browse the repository at this point in the history
…cm/linux/kernel/git/will/linux into iommu/fixes
  • Loading branch information
Joerg Roedel committed Sep 3, 2014
2 parents c0df975 + 4d09d99 commit 61bf5ff
Showing 340 changed files with 2,778 additions and 1,785 deletions.
107 changes: 107 additions & 0 deletions Documentation/devicetree/bindings/mfd/tc3589x.txt
Original file line number Diff line number Diff line change
@@ -0,0 +1,107 @@
* Toshiba TC3589x multi-purpose expander

The Toshiba TC3589x series are I2C-based MFD devices which may expose the
following built-in devices: gpio, keypad, rotator (vibrator), PWM (for
e.g. LEDs or vibrators) The included models are:

- TC35890
- TC35892
- TC35893
- TC35894
- TC35895
- TC35896

Required properties:
- compatible : must be "toshiba,tc35890", "toshiba,tc35892", "toshiba,tc35893",
"toshiba,tc35894", "toshiba,tc35895" or "toshiba,tc35896"
- reg : I2C address of the device
- interrupt-parent : specifies which IRQ controller we're connected to
- interrupts : the interrupt on the parent the controller is connected to
- interrupt-controller : marks the device node as an interrupt controller
- #interrupt-cells : should be <1>, the first cell is the IRQ offset on this
TC3589x interrupt controller.

Optional nodes:

- GPIO
This GPIO module inside the TC3589x has 24 (TC35890, TC35892) or 20
(other models) GPIO lines.
- compatible : must be "toshiba,tc3589x-gpio"
- interrupts : interrupt on the parent, which must be the tc3589x MFD device
- interrupt-controller : marks the device node as an interrupt controller
- #interrupt-cells : should be <2>, the first cell is the IRQ offset on this
TC3589x GPIO interrupt controller, the second cell is the interrupt flags
in accordance with <dt-bindings/interrupt-controller/irq.h>. The following
flags are valid:
- IRQ_TYPE_LEVEL_LOW
- IRQ_TYPE_LEVEL_HIGH
- IRQ_TYPE_EDGE_RISING
- IRQ_TYPE_EDGE_FALLING
- IRQ_TYPE_EDGE_BOTH
- gpio-controller : marks the device node as a GPIO controller
- #gpio-cells : should be <2>, the first cell is the GPIO offset on this
GPIO controller, the second cell is the flags.

- Keypad
This keypad is the same on all variants, supporting up to 96 different
keys. The linux-specific properties are modeled on those already existing
in other input drivers.
- compatible : must be "toshiba,tc3589x-keypad"
- debounce-delay-ms : debounce interval in milliseconds
- keypad,num-rows : number of rows in the matrix, see
bindings/input/matrix-keymap.txt
- keypad,num-columns : number of columns in the matrix, see
bindings/input/matrix-keymap.txt
- linux,keymap: the definition can be found in
bindings/input/matrix-keymap.txt
- linux,no-autorepeat: do no enable autorepeat feature.
- linux,wakeup: use any event on keypad as wakeup event.

Example:

tc35893@44 {
compatible = "toshiba,tc35893";
reg = <0x44>;
interrupt-parent = <&gpio6>;
interrupts = <26 IRQ_TYPE_EDGE_RISING>;

interrupt-controller;
#interrupt-cells = <1>;

tc3589x_gpio {
compatible = "toshiba,tc3589x-gpio";
interrupts = <0>;

interrupt-controller;
#interrupt-cells = <2>;
gpio-controller;
#gpio-cells = <2>;
};
tc3589x_keypad {
compatible = "toshiba,tc3589x-keypad";
interrupts = <6>;
debounce-delay-ms = <4>;
keypad,num-columns = <8>;
keypad,num-rows = <8>;
linux,no-autorepeat;
linux,wakeup;
linux,keymap = <0x0301006b
0x04010066
0x06040072
0x040200d7
0x0303006a
0x0205000e
0x0607008b
0x0500001c
0x0403000b
0x03040034
0x05020067
0x0305006c
0x040500e7
0x0005009e
0x06020073
0x01030039
0x07060069
0x050500d9>;
};
};
2 changes: 1 addition & 1 deletion Documentation/devicetree/bindings/mtd/gpmc-nand.txt
Original file line number Diff line number Diff line change
@@ -22,7 +22,7 @@ Optional properties:
width of 8 is assumed.

- ti,nand-ecc-opt: A string setting the ECC layout to use. One of:
"sw" <deprecated> use "ham1" instead
"sw" 1-bit Hamming ecc code via software
"hw" <deprecated> use "ham1" instead
"hw-romcode" <deprecated> use "ham1" instead
"ham1" 1-bit Hamming ecc code
Original file line number Diff line number Diff line change
@@ -62,7 +62,7 @@ Example:
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
interrupts = <0 32 0x4>;
interrupts = <0 16 0x4>;

pinctrl-names = "default";
pinctrl-0 = <&gsbi5_uart_default>;
14 changes: 8 additions & 6 deletions Documentation/dma-buf-sharing.txt
Original file line number Diff line number Diff line change
@@ -56,10 +56,10 @@ The dma_buf buffer sharing API usage contains the following steps:
size_t size, int flags,
const char *exp_name)

If this succeeds, dma_buf_export allocates a dma_buf structure, and returns a
pointer to the same. It also associates an anonymous file with this buffer,
so it can be exported. On failure to allocate the dma_buf object, it returns
NULL.
If this succeeds, dma_buf_export_named allocates a dma_buf structure, and
returns a pointer to the same. It also associates an anonymous file with this
buffer, so it can be exported. On failure to allocate the dma_buf object,
it returns NULL.

'exp_name' is the name of exporter - to facilitate information while
debugging.
@@ -76,7 +76,7 @@ The dma_buf buffer sharing API usage contains the following steps:
drivers and/or processes.

Interface:
int dma_buf_fd(struct dma_buf *dmabuf)
int dma_buf_fd(struct dma_buf *dmabuf, int flags)

This API installs an fd for the anonymous file associated with this buffer;
returns either 'fd', or error.
@@ -157,7 +157,9 @@ to request use of buffer for allocation.
"dma_buf->ops->" indirection from the users of this interface.

In struct dma_buf_ops, unmap_dma_buf is defined as
void (*unmap_dma_buf)(struct dma_buf_attachment *, struct sg_table *);
void (*unmap_dma_buf)(struct dma_buf_attachment *,
struct sg_table *,
enum dma_data_direction);

unmap_dma_buf signifies the end-of-DMA for the attachment provided. Like
map_dma_buf, this API also must be implemented by the exporter.
36 changes: 33 additions & 3 deletions Documentation/kdump/kdump.txt
Original file line number Diff line number Diff line change
@@ -18,7 +18,7 @@ memory image to a dump file on the local disk, or across the network to
a remote system.

Kdump and kexec are currently supported on the x86, x86_64, ppc64, ia64,
and s390x architectures.
s390x and arm architectures.

When the system kernel boots, it reserves a small section of memory for
the dump-capture kernel. This ensures that ongoing Direct Memory Access
@@ -112,7 +112,7 @@ There are two possible methods of using Kdump.
2) Or use the system kernel binary itself as dump-capture kernel and there is
no need to build a separate dump-capture kernel. This is possible
only with the architectures which support a relocatable kernel. As
of today, i386, x86_64, ppc64 and ia64 architectures support relocatable
of today, i386, x86_64, ppc64, ia64 and arm architectures support relocatable
kernel.

Building a relocatable kernel is advantageous from the point of view that
@@ -241,6 +241,13 @@ Dump-capture kernel config options (Arch Dependent, ia64)
kernel will be aligned to 64Mb, so if the start address is not then
any space below the alignment point will be wasted.

Dump-capture kernel config options (Arch Dependent, arm)
----------------------------------------------------------

- To use a relocatable kernel,
Enable "AUTO_ZRELADDR" support under "Boot" options:

AUTO_ZRELADDR=y

Extended crashkernel syntax
===========================
@@ -256,6 +263,10 @@ The syntax is:
crashkernel=<range1>:<size1>[,<range2>:<size2>,...][@offset]
range=start-[end]

Please note, on arm, the offset is required.
crashkernel=<range1>:<size1>[,<range2>:<size2>,...]@offset
range=start-[end]

'start' is inclusive and 'end' is exclusive.

For example:
@@ -296,6 +307,12 @@ Boot into System Kernel
on the memory consumption of the kdump system. In general this is not
dependent on the memory size of the production system.

On arm, use "crashkernel=Y@X". Note that the start address of the kernel
will be aligned to 128MiB (0x08000000), so if the start address is not then
any space below the alignment point may be overwritten by the dump-capture kernel,
which means it is possible that the vmcore is not that precise as expected.


Load the Dump-capture Kernel
============================

@@ -315,7 +332,8 @@ For ia64:
- Use vmlinux or vmlinuz.gz
For s390x:
- Use image or bzImage

For arm:
- Use zImage

If you are using a uncompressed vmlinux image then use following command
to load dump-capture kernel.
@@ -331,6 +349,15 @@ to load dump-capture kernel.
--initrd=<initrd-for-dump-capture-kernel> \
--append="root=<root-dev> <arch-specific-options>"

If you are using a compressed zImage, then use following command
to load dump-capture kernel.

kexec --type zImage -p <dump-capture-kernel-bzImage> \
--initrd=<initrd-for-dump-capture-kernel> \
--dtb=<dtb-for-dump-capture-kernel> \
--append="root=<root-dev> <arch-specific-options>"


Please note, that --args-linux does not need to be specified for ia64.
It is planned to make this a no-op on that architecture, but for now
it should be omitted
@@ -347,6 +374,9 @@ For ppc64:
For s390x:
"1 maxcpus=1 cgroup_disable=memory"

For arm:
"1 maxcpus=1 reset_devices"

Notes on loading the dump-capture kernel:

* By default, the ELF headers are stored in ELF64 format to support
Loading

0 comments on commit 61bf5ff

Please sign in to comment.