Merge branch 'for-joerg/arm-smmu/fixes' of...

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

	};

};

				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

		#gpio-cells = <2>;

		interrupt-controller;

		#interrupt-cells = <2>;

		interrupts = <0 32 0x4>;

		interrupts = <0 16 0x4>;

		pinctrl-names = "default";

		pinctrl-0 = <&gsbi5_uart_default>;

				     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.

   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.

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

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

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

  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

===========================

    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:

   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

============================

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

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

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