You've already forked linux-apfs
mirror of
https://github.com/linux-apfs/linux-apfs.git
synced 2026-05-01 15:00:59 -07:00
Merge tag 'v3.17-rc4' into next
Merge Linux 3.17-rc4 here so we have all the latest fixes on next too. This also cleans up a few conflicts when applying patches. Signed-off-by: Felipe Balbi <balbi@ti.com> Conflicts: drivers/usb/gadget/Makefile drivers/usb/gadget/function/Makefile drivers/usb/gadget/legacy/Makefile drivers/usb/phy/phy-samsung-usb.h
This commit is contained in:
Felipe Balbi
@@ -794,6 +794,7 @@ Greg Kroah-Hartman, "How to piss off a kernel subsystem maintainer".
|
||||
<http://www.kroah.com/log/linux/maintainer-03.html>
|
||||
<http://www.kroah.com/log/linux/maintainer-04.html>
|
||||
<http://www.kroah.com/log/linux/maintainer-05.html>
|
||||
<http://www.kroah.com/log/linux/maintainer-06.html>
|
||||
|
||||
NO!!!! No more huge patch bombs to linux-kernel@vger.kernel.org people!
|
||||
<https://lkml.org/lkml/2005/7/11/336>
|
||||
|
||||
@@ -15,6 +15,17 @@ Optional properties for main touchpad device:
|
||||
keycode generated by each GPIO. Linux keycodes are defined in
|
||||
<dt-bindings/input/input.h>.
|
||||
|
||||
- linux,gpio-keymap: When enabled, the SPT_GPIOPWN_T19 object sends messages
|
||||
on GPIO bit changes. An array of up to 8 entries can be provided
|
||||
indicating the Linux keycode mapped to each bit of the status byte,
|
||||
starting at the LSB. Linux keycodes are defined in
|
||||
<dt-bindings/input/input.h>.
|
||||
|
||||
Note: the numbering of the GPIOs and the bit they start at varies between
|
||||
maXTouch devices. You must either refer to the documentation, or
|
||||
experiment to determine which bit corresponds to which input. Use
|
||||
KEY_RESERVED for unused padding values.
|
||||
|
||||
Example:
|
||||
|
||||
touch@4b {
|
||||
|
||||
@@ -4,11 +4,13 @@ Specifying interrupt information for devices
|
||||
1) Interrupt client nodes
|
||||
-------------------------
|
||||
|
||||
Nodes that describe devices which generate interrupts must contain an either an
|
||||
"interrupts" property or an "interrupts-extended" property. These properties
|
||||
contain a list of interrupt specifiers, one per output interrupt. The format of
|
||||
the interrupt specifier is determined by the interrupt controller to which the
|
||||
interrupts are routed; see section 2 below for details.
|
||||
Nodes that describe devices which generate interrupts must contain an
|
||||
"interrupts" property, an "interrupts-extended" property, or both. If both are
|
||||
present, the latter should take precedence; the former may be provided simply
|
||||
for compatibility with software that does not recognize the latter. These
|
||||
properties contain a list of interrupt specifiers, one per output interrupt. The
|
||||
format of the interrupt specifier is determined by the interrupt controller to
|
||||
which the interrupts are routed; see section 2 below for details.
|
||||
|
||||
Example:
|
||||
interrupt-parent = <&intc1>;
|
||||
|
||||
@@ -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>;
|
||||
};
|
||||
};
|
||||
@@ -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
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
|
||||
Required properties:
|
||||
- compatible: should contain "snps,dw-pcie" to identify the core.
|
||||
- reg: Should contain the configuration address space.
|
||||
- reg-names: Must be "config" for the PCIe configuration space.
|
||||
(The old way of getting the configuration address space from "ranges"
|
||||
is deprecated and should be avoided.)
|
||||
- #address-cells: set to <3>
|
||||
- #size-cells: set to <2>
|
||||
- device_type: set to "pci"
|
||||
|
||||
@@ -0,0 +1,59 @@
|
||||
TI PCI Controllers
|
||||
|
||||
PCIe Designware Controller
|
||||
- compatible: Should be "ti,dra7-pcie""
|
||||
- reg : Two register ranges as listed in the reg-names property
|
||||
- reg-names : The first entry must be "ti-conf" for the TI specific registers
|
||||
The second entry must be "rc-dbics" for the designware pcie
|
||||
registers
|
||||
The third entry must be "config" for the PCIe configuration space
|
||||
- phys : list of PHY specifiers (used by generic PHY framework)
|
||||
- phy-names : must be "pcie-phy0", "pcie-phy1", "pcie-phyN".. based on the
|
||||
number of PHYs as specified in *phys* property.
|
||||
- ti,hwmods : Name of the hwmod associated to the pcie, "pcie<X>",
|
||||
where <X> is the instance number of the pcie from the HW spec.
|
||||
- interrupts : Two interrupt entries must be specified. The first one is for
|
||||
main interrupt line and the second for MSI interrupt line.
|
||||
- #address-cells,
|
||||
#size-cells,
|
||||
#interrupt-cells,
|
||||
device_type,
|
||||
ranges,
|
||||
num-lanes,
|
||||
interrupt-map-mask,
|
||||
interrupt-map : as specified in ../designware-pcie.txt
|
||||
|
||||
Example:
|
||||
axi {
|
||||
compatible = "simple-bus";
|
||||
#size-cells = <1>;
|
||||
#address-cells = <1>;
|
||||
ranges = <0x51000000 0x51000000 0x3000
|
||||
0x0 0x20000000 0x10000000>;
|
||||
pcie@51000000 {
|
||||
compatible = "ti,dra7-pcie";
|
||||
reg = <0x51000000 0x2000>, <0x51002000 0x14c>, <0x1000 0x2000>;
|
||||
reg-names = "rc_dbics", "ti_conf", "config";
|
||||
interrupts = <0 232 0x4>, <0 233 0x4>;
|
||||
#address-cells = <3>;
|
||||
#size-cells = <2>;
|
||||
device_type = "pci";
|
||||
ranges = <0x81000000 0 0 0x03000 0 0x00010000
|
||||
0x82000000 0 0x20013000 0x13000 0 0xffed000>;
|
||||
#interrupt-cells = <1>;
|
||||
num-lanes = <1>;
|
||||
ti,hwmods = "pcie1";
|
||||
phys = <&pcie1_phy>;
|
||||
phy-names = "pcie-phy0";
|
||||
interrupt-map-mask = <0 0 0 7>;
|
||||
interrupt-map = <0 0 0 1 &pcie_intc 1>,
|
||||
<0 0 0 2 &pcie_intc 2>,
|
||||
<0 0 0 3 &pcie_intc 3>,
|
||||
<0 0 0 4 &pcie_intc 4>;
|
||||
pcie_intc: interrupt-controller {
|
||||
interrupt-controller;
|
||||
#address-cells = <0>;
|
||||
#interrupt-cells = <1>;
|
||||
};
|
||||
};
|
||||
};
|
||||
@@ -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>;
|
||||
|
||||
@@ -45,8 +45,8 @@ Example:
|
||||
infet5-supply = <&some_reg>;
|
||||
infet6-supply = <&some_reg>;
|
||||
infet7-supply = <&some_reg>;
|
||||
vsys_l1-supply = <&some_reg>;
|
||||
vsys_l2-supply = <&some_reg>;
|
||||
vsys-l1-supply = <&some_reg>;
|
||||
vsys-l2-supply = <&some_reg>;
|
||||
|
||||
regulators {
|
||||
dcdc1 {
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
ADI AXI-SPDIF controller
|
||||
|
||||
Required properties:
|
||||
- compatible : Must be "adi,axi-spdif-1.00.a"
|
||||
- compatible : Must be "adi,axi-spdif-tx-1.00.a"
|
||||
- reg : Must contain SPDIF core's registers location and length
|
||||
- clocks : Pairs of phandle and specifier referencing the controller's clocks.
|
||||
The controller expects two clocks, the clock used for the AXI interface and
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -138,9 +138,9 @@ Installation
|
||||
- Build, install, reboot
|
||||
|
||||
The NFS/RDMA code will be enabled automatically if NFS and RDMA
|
||||
are turned on. The NFS/RDMA client and server are configured via the hidden
|
||||
SUNRPC_XPRT_RDMA config option that depends on SUNRPC and INFINIBAND. The
|
||||
value of SUNRPC_XPRT_RDMA will be:
|
||||
are turned on. The NFS/RDMA client and server are configured via the
|
||||
SUNRPC_XPRT_RDMA_CLIENT and SUNRPC_XPRT_RDMA_SERVER config options that both
|
||||
depend on SUNRPC and INFINIBAND. The default value of both options will be:
|
||||
|
||||
- N if either SUNRPC or INFINIBAND are N, in this case the NFS/RDMA client
|
||||
and server will not be built
|
||||
@@ -235,8 +235,9 @@ NFS/RDMA Setup
|
||||
|
||||
- Start the NFS server
|
||||
|
||||
If the NFS/RDMA server was built as a module (CONFIG_SUNRPC_XPRT_RDMA=m in
|
||||
kernel config), load the RDMA transport module:
|
||||
If the NFS/RDMA server was built as a module
|
||||
(CONFIG_SUNRPC_XPRT_RDMA_SERVER=m in kernel config), load the RDMA
|
||||
transport module:
|
||||
|
||||
$ modprobe svcrdma
|
||||
|
||||
@@ -255,8 +256,9 @@ NFS/RDMA Setup
|
||||
|
||||
- On the client system
|
||||
|
||||
If the NFS/RDMA client was built as a module (CONFIG_SUNRPC_XPRT_RDMA=m in
|
||||
kernel config), load the RDMA client module:
|
||||
If the NFS/RDMA client was built as a module
|
||||
(CONFIG_SUNRPC_XPRT_RDMA_CLIENT=m in kernel config), load the RDMA client
|
||||
module:
|
||||
|
||||
$ modprobe xprtrdma.ko
|
||||
|
||||
|
||||
@@ -235,6 +235,39 @@ be used for more than one file, you can store an arbitrary pointer in the
|
||||
private field of the seq_file structure; that value can then be retrieved
|
||||
by the iterator functions.
|
||||
|
||||
There is also a wrapper function to seq_open() called seq_open_private(). It
|
||||
kmallocs a zero filled block of memory and stores a pointer to it in the
|
||||
private field of the seq_file structure, returning 0 on success. The
|
||||
block size is specified in a third parameter to the function, e.g.:
|
||||
|
||||
static int ct_open(struct inode *inode, struct file *file)
|
||||
{
|
||||
return seq_open_private(file, &ct_seq_ops,
|
||||
sizeof(struct mystruct));
|
||||
}
|
||||
|
||||
There is also a variant function, __seq_open_private(), which is functionally
|
||||
identical except that, if successful, it returns the pointer to the allocated
|
||||
memory block, allowing further initialisation e.g.:
|
||||
|
||||
static int ct_open(struct inode *inode, struct file *file)
|
||||
{
|
||||
struct mystruct *p =
|
||||
__seq_open_private(file, &ct_seq_ops, sizeof(*p));
|
||||
|
||||
if (!p)
|
||||
return -ENOMEM;
|
||||
|
||||
p->foo = bar; /* initialize my stuff */
|
||||
...
|
||||
p->baz = true;
|
||||
|
||||
return 0;
|
||||
}
|
||||
|
||||
A corresponding close function, seq_release_private() is available which
|
||||
frees the memory allocated in the corresponding open.
|
||||
|
||||
The other operations of interest - read(), llseek(), and release() - are
|
||||
all implemented by the seq_file code itself. So a virtual file's
|
||||
file_operations structure will look like:
|
||||
|
||||
@@ -53,7 +53,20 @@ with IS_ERR() (they will never return a NULL pointer). -ENOENT will be returned
|
||||
if and only if no GPIO has been assigned to the device/function/index triplet,
|
||||
other error codes are used for cases where a GPIO has been assigned but an error
|
||||
occurred while trying to acquire it. This is useful to discriminate between mere
|
||||
errors and an absence of GPIO for optional GPIO parameters.
|
||||
errors and an absence of GPIO for optional GPIO parameters. For the common
|
||||
pattern where a GPIO is optional, the gpiod_get_optional() and
|
||||
gpiod_get_index_optional() functions can be used. These functions return NULL
|
||||
instead of -ENOENT if no GPIO has been assigned to the requested function:
|
||||
|
||||
|
||||
struct gpio_desc *gpiod_get_optional(struct device *dev,
|
||||
const char *con_id,
|
||||
enum gpiod_flags flags)
|
||||
|
||||
struct gpio_desc *gpiod_get_index_optional(struct device *dev,
|
||||
const char *con_id,
|
||||
unsigned int index,
|
||||
enum gpiod_flags flags)
|
||||
|
||||
Device-managed variants of these functions are also defined:
|
||||
|
||||
@@ -65,6 +78,15 @@ Device-managed variants of these functions are also defined:
|
||||
unsigned int idx,
|
||||
enum gpiod_flags flags)
|
||||
|
||||
struct gpio_desc *devm_gpiod_get_optional(struct device *dev,
|
||||
const char *con_id,
|
||||
enum gpiod_flags flags)
|
||||
|
||||
struct gpio_desc * devm_gpiod_get_index_optional(struct device *dev,
|
||||
const char *con_id,
|
||||
unsigned int index,
|
||||
enum gpiod_flags flags)
|
||||
|
||||
A GPIO descriptor can be disposed of using the gpiod_put() function:
|
||||
|
||||
void gpiod_put(struct gpio_desc *desc)
|
||||
|
||||
@@ -57,12 +57,12 @@ Well, you are all set up now. You can now use SMBus commands or plain
|
||||
I2C to communicate with your device. SMBus commands are preferred if
|
||||
the device supports them. Both are illustrated below.
|
||||
|
||||
__u8 register = 0x10; /* Device register to access */
|
||||
__u8 reg = 0x10; /* Device register to access */
|
||||
__s32 res;
|
||||
char buf[10];
|
||||
|
||||
/* Using SMBus commands */
|
||||
res = i2c_smbus_read_word_data(file, register);
|
||||
res = i2c_smbus_read_word_data(file, reg);
|
||||
if (res < 0) {
|
||||
/* ERROR HANDLING: i2c transaction failed */
|
||||
} else {
|
||||
@@ -70,11 +70,11 @@ the device supports them. Both are illustrated below.
|
||||
}
|
||||
|
||||
/* Using I2C Write, equivalent of
|
||||
i2c_smbus_write_word_data(file, register, 0x6543) */
|
||||
buf[0] = register;
|
||||
i2c_smbus_write_word_data(file, reg, 0x6543) */
|
||||
buf[0] = reg;
|
||||
buf[1] = 0x43;
|
||||
buf[2] = 0x65;
|
||||
if (write(file, buf, 3) ! =3) {
|
||||
if (write(file, buf, 3) != 3) {
|
||||
/* ERROR HANDLING: i2c transaction failed */
|
||||
}
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -59,7 +59,7 @@ acts similar to /dev/rtc and reacts on free-fall interrupts received
|
||||
from the device. It supports blocking operations, poll/select and
|
||||
fasync operation modes. You must read 1 bytes from the device. The
|
||||
result is number of free-fall interrupts since the last successful
|
||||
read (or 255 if number of interrupts would not fit). See the hpfall.c
|
||||
read (or 255 if number of interrupts would not fit). See the freefall.c
|
||||
file for an example on using the device.
|
||||
|
||||
|
||||
|
||||
@@ -143,8 +143,9 @@ This will cause the core to recalculate the total load on the regulator (based
|
||||
on all its consumers) and change operating mode (if necessary and permitted)
|
||||
to best match the current operating load.
|
||||
|
||||
The load_uA value can be determined from the consumers datasheet. e.g.most
|
||||
datasheets have tables showing the max current consumed in certain situations.
|
||||
The load_uA value can be determined from the consumer's datasheet. e.g. most
|
||||
datasheets have tables showing the maximum current consumed in certain
|
||||
situations.
|
||||
|
||||
Most consumers will use indirect operating mode control since they have no
|
||||
knowledge of the regulator or whether the regulator is shared with other
|
||||
@@ -173,7 +174,7 @@ Consumers can register interest in regulator events by calling :-
|
||||
int regulator_register_notifier(struct regulator *regulator,
|
||||
struct notifier_block *nb);
|
||||
|
||||
Consumers can uregister interest by calling :-
|
||||
Consumers can unregister interest by calling :-
|
||||
|
||||
int regulator_unregister_notifier(struct regulator *regulator,
|
||||
struct notifier_block *nb);
|
||||
|
||||
@@ -9,14 +9,14 @@ Safety
|
||||
|
||||
- Errors in regulator configuration can have very serious consequences
|
||||
for the system, potentially including lasting hardware damage.
|
||||
- It is not possible to automatically determine the power confugration
|
||||
- It is not possible to automatically determine the power configuration
|
||||
of the system - software-equivalent variants of the same chip may
|
||||
have different power requirments, and not all components with power
|
||||
have different power requirements, and not all components with power
|
||||
requirements are visible to software.
|
||||
|
||||
=> The API should make no changes to the hardware state unless it has
|
||||
specific knowledge that these changes are safe to do perform on
|
||||
this particular system.
|
||||
specific knowledge that these changes are safe to perform on this
|
||||
particular system.
|
||||
|
||||
Consumer use cases
|
||||
------------------
|
||||
|
||||
@@ -11,7 +11,7 @@ Consider the following machine :-
|
||||
+-> [Consumer B @ 3.3V]
|
||||
|
||||
The drivers for consumers A & B must be mapped to the correct regulator in
|
||||
order to control their power supply. This mapping can be achieved in machine
|
||||
order to control their power supplies. This mapping can be achieved in machine
|
||||
initialisation code by creating a struct regulator_consumer_supply for
|
||||
each regulator.
|
||||
|
||||
@@ -39,7 +39,7 @@ to the 'Vcc' supply for Consumer A.
|
||||
|
||||
Constraints can now be registered by defining a struct regulator_init_data
|
||||
for each regulator power domain. This structure also maps the consumers
|
||||
to their supply regulator :-
|
||||
to their supply regulators :-
|
||||
|
||||
static struct regulator_init_data regulator1_data = {
|
||||
.constraints = {
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user