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 branch 'linus' into perf/urgent
Merge dependencies to apply a fix. Signed-off-by: Ingo Molnar <mingo@kernel.org>
This commit is contained in:
Ingo Molnar
@@ -2576,7 +2576,7 @@ S: Toronto, Ontario
|
||||
S: Canada
|
||||
|
||||
N: Zwane Mwaikambo
|
||||
E: zwane@arm.linux.org.uk
|
||||
E: zwanem@gmail.com
|
||||
D: Various driver hacking
|
||||
D: Lowlevel x86 kernel hacking
|
||||
D: General debugging
|
||||
@@ -2895,6 +2895,11 @@ S: Framewood Road
|
||||
S: Wexham SL3 6PJ
|
||||
S: United Kingdom
|
||||
|
||||
N: Richard Purdie
|
||||
E: rpurdie@rpsys.net
|
||||
D: Backlight subsystem maintainer
|
||||
S: United Kingdom
|
||||
|
||||
N: Daniel Quinlan
|
||||
E: quinlan@pathname.com
|
||||
W: http://www.pathname.com/~quinlan/
|
||||
@@ -3152,6 +3157,11 @@ N: Dipankar Sarma
|
||||
E: dipankar@in.ibm.com
|
||||
D: RCU
|
||||
|
||||
N: Yoshinori Sato
|
||||
E: ysato@users.sourceforge.jp
|
||||
D: uClinux for Renesas H8/300 (H8300)
|
||||
D: http://uclinux-h8.sourceforge.jp/
|
||||
|
||||
N: Hannu Savolainen
|
||||
E: hannu@opensound.com
|
||||
D: Maintainer of the sound drivers until 2.1.x days.
|
||||
|
||||
@@ -72,3 +72,16 @@ kernel tree without going through the obsolete state first.
|
||||
|
||||
It's up to the developer to place their interfaces in the category they
|
||||
wish for it to start out in.
|
||||
|
||||
|
||||
Notable bits of non-ABI, which should not under any circumstances be considered
|
||||
stable:
|
||||
|
||||
- Kconfig. Userspace should not rely on the presence or absence of any
|
||||
particular Kconfig symbol, in /proc/config.gz, in the copy of .config
|
||||
commonly installed to /boot, or in any invocation of the kernel build
|
||||
process.
|
||||
|
||||
- Kernel-internal symbols. Do not rely on the presence, absence, location, or
|
||||
type of any kernel symbol, either in System.map files or the kernel binary
|
||||
itself. See Documentation/stable_api_nonsense.txt.
|
||||
|
||||
@@ -104,7 +104,7 @@ Description:
|
||||
One of the following ASCII strings, representing the device
|
||||
type:
|
||||
|
||||
absent, ram, rom, nor, nand, dataflash, ubi, unknown
|
||||
absent, ram, rom, nor, nand, mlc-nand, dataflash, ubi, unknown
|
||||
|
||||
What: /sys/class/mtd/mtdX/writesize
|
||||
Date: April 2009
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
|
||||
What: /sys/class/net/<iface>/batman-adv/iface_status
|
||||
Date: May 2010
|
||||
Contact: Marek Lindner <lindner_marek@yahoo.de>
|
||||
Contact: Marek Lindner <mareklindner@neomailbox.ch>
|
||||
Description:
|
||||
Indicates the status of <iface> as it is seen by batman.
|
||||
|
||||
What: /sys/class/net/<iface>/batman-adv/mesh_iface
|
||||
Date: May 2010
|
||||
Contact: Marek Lindner <lindner_marek@yahoo.de>
|
||||
Contact: Marek Lindner <mareklindner@neomailbox.ch>
|
||||
Description:
|
||||
The /sys/class/net/<iface>/batman-adv/mesh_iface file
|
||||
displays the batman mesh interface this <iface>
|
||||
|
||||
@@ -1,22 +1,23 @@
|
||||
|
||||
What: /sys/class/net/<mesh_iface>/mesh/aggregated_ogms
|
||||
Date: May 2010
|
||||
Contact: Marek Lindner <lindner_marek@yahoo.de>
|
||||
Contact: Marek Lindner <mareklindner@neomailbox.ch>
|
||||
Description:
|
||||
Indicates whether the batman protocol messages of the
|
||||
mesh <mesh_iface> shall be aggregated or not.
|
||||
|
||||
What: /sys/class/net/<mesh_iface>/mesh/ap_isolation
|
||||
What: /sys/class/net/<mesh_iface>/mesh/<vlan_subdir>/ap_isolation
|
||||
Date: May 2011
|
||||
Contact: Antonio Quartulli <ordex@autistici.org>
|
||||
Contact: Antonio Quartulli <antonio@meshcoding.com>
|
||||
Description:
|
||||
Indicates whether the data traffic going from a
|
||||
wireless client to another wireless client will be
|
||||
silently dropped.
|
||||
silently dropped. <vlan_subdir> is empty when referring
|
||||
to the untagged lan.
|
||||
|
||||
What: /sys/class/net/<mesh_iface>/mesh/bonding
|
||||
Date: June 2010
|
||||
Contact: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
|
||||
Contact: Simon Wunderlich <sw@simonwunderlich.de>
|
||||
Description:
|
||||
Indicates whether the data traffic going through the
|
||||
mesh will be sent using multiple interfaces at the
|
||||
@@ -24,7 +25,7 @@ Description:
|
||||
|
||||
What: /sys/class/net/<mesh_iface>/mesh/bridge_loop_avoidance
|
||||
Date: November 2011
|
||||
Contact: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
|
||||
Contact: Simon Wunderlich <sw@simonwunderlich.de>
|
||||
Description:
|
||||
Indicates whether the bridge loop avoidance feature
|
||||
is enabled. This feature detects and avoids loops
|
||||
@@ -41,21 +42,21 @@ Description:
|
||||
|
||||
What: /sys/class/net/<mesh_iface>/mesh/gw_bandwidth
|
||||
Date: October 2010
|
||||
Contact: Marek Lindner <lindner_marek@yahoo.de>
|
||||
Contact: Marek Lindner <mareklindner@neomailbox.ch>
|
||||
Description:
|
||||
Defines the bandwidth which is propagated by this
|
||||
node if gw_mode was set to 'server'.
|
||||
|
||||
What: /sys/class/net/<mesh_iface>/mesh/gw_mode
|
||||
Date: October 2010
|
||||
Contact: Marek Lindner <lindner_marek@yahoo.de>
|
||||
Contact: Marek Lindner <mareklindner@neomailbox.ch>
|
||||
Description:
|
||||
Defines the state of the gateway features. Can be
|
||||
either 'off', 'client' or 'server'.
|
||||
|
||||
What: /sys/class/net/<mesh_iface>/mesh/gw_sel_class
|
||||
Date: October 2010
|
||||
Contact: Marek Lindner <lindner_marek@yahoo.de>
|
||||
Contact: Marek Lindner <mareklindner@neomailbox.ch>
|
||||
Description:
|
||||
Defines the selection criteria this node will use
|
||||
to choose a gateway if gw_mode was set to 'client'.
|
||||
@@ -77,25 +78,14 @@ Description:
|
||||
|
||||
What: /sys/class/net/<mesh_iface>/mesh/orig_interval
|
||||
Date: May 2010
|
||||
Contact: Marek Lindner <lindner_marek@yahoo.de>
|
||||
Contact: Marek Lindner <mareklindner@neomailbox.ch>
|
||||
Description:
|
||||
Defines the interval in milliseconds in which batman
|
||||
sends its protocol messages.
|
||||
|
||||
What: /sys/class/net/<mesh_iface>/mesh/routing_algo
|
||||
Date: Dec 2011
|
||||
Contact: Marek Lindner <lindner_marek@yahoo.de>
|
||||
Contact: Marek Lindner <mareklindner@neomailbox.ch>
|
||||
Description:
|
||||
Defines the routing procotol this mesh instance
|
||||
uses to find the optimal paths through the mesh.
|
||||
|
||||
What: /sys/class/net/<mesh_iface>/mesh/vis_mode
|
||||
Date: May 2010
|
||||
Contact: Marek Lindner <lindner_marek@yahoo.de>
|
||||
Description:
|
||||
Each batman node only maintains information about its
|
||||
own local neighborhood, therefore generating graphs
|
||||
showing the topology of the entire mesh is not easily
|
||||
feasible without having a central instance to collect
|
||||
the local topologies from all nodes. This file allows
|
||||
to activate the collecting (server) mode.
|
||||
|
||||
@@ -0,0 +1,152 @@
|
||||
What: /sys/class/powercap/
|
||||
Date: September 2013
|
||||
KernelVersion: 3.13
|
||||
Contact: linux-pm@vger.kernel.org
|
||||
Description:
|
||||
The powercap/ class sub directory belongs to the power cap
|
||||
subsystem. Refer to
|
||||
Documentation/power/powercap/powercap.txt for details.
|
||||
|
||||
What: /sys/class/powercap/<control type>
|
||||
Date: September 2013
|
||||
KernelVersion: 3.13
|
||||
Contact: linux-pm@vger.kernel.org
|
||||
Description:
|
||||
A <control type> is a unique name under /sys/class/powercap.
|
||||
Here <control type> determines how the power is going to be
|
||||
controlled. A <control type> can contain multiple power zones.
|
||||
|
||||
What: /sys/class/powercap/<control type>/enabled
|
||||
Date: September 2013
|
||||
KernelVersion: 3.13
|
||||
Contact: linux-pm@vger.kernel.org
|
||||
Description:
|
||||
This allows to enable/disable power capping for a "control type".
|
||||
This status affects every power zone using this "control_type.
|
||||
|
||||
What: /sys/class/powercap/<control type>/<power zone>
|
||||
Date: September 2013
|
||||
KernelVersion: 3.13
|
||||
Contact: linux-pm@vger.kernel.org
|
||||
Description:
|
||||
A power zone is a single or a collection of devices, which can
|
||||
be independently monitored and controlled. A power zone sysfs
|
||||
entry is qualified with the name of the <control type>.
|
||||
E.g. intel-rapl:0:1:1.
|
||||
|
||||
What: /sys/class/powercap/<control type>/<power zone>/<child power zone>
|
||||
Date: September 2013
|
||||
KernelVersion: 3.13
|
||||
Contact: linux-pm@vger.kernel.org
|
||||
Description:
|
||||
Power zones may be organized in a hierarchy in which child
|
||||
power zones provide monitoring and control for a subset of
|
||||
devices under the parent. For example, if there is a parent
|
||||
power zone for a whole CPU package, each CPU core in it can
|
||||
be a child power zone.
|
||||
|
||||
What: /sys/class/powercap/.../<power zone>/name
|
||||
Date: September 2013
|
||||
KernelVersion: 3.13
|
||||
Contact: linux-pm@vger.kernel.org
|
||||
Description:
|
||||
Specifies the name of this power zone.
|
||||
|
||||
What: /sys/class/powercap/.../<power zone>/energy_uj
|
||||
Date: September 2013
|
||||
KernelVersion: 3.13
|
||||
Contact: linux-pm@vger.kernel.org
|
||||
Description:
|
||||
Current energy counter in micro-joules. Write "0" to reset.
|
||||
If the counter can not be reset, then this attribute is
|
||||
read-only.
|
||||
|
||||
What: /sys/class/powercap/.../<power zone>/max_energy_range_uj
|
||||
Date: September 2013
|
||||
KernelVersion: 3.13
|
||||
Contact: linux-pm@vger.kernel.org
|
||||
Description:
|
||||
Range of the above energy counter in micro-joules.
|
||||
|
||||
|
||||
What: /sys/class/powercap/.../<power zone>/power_uw
|
||||
Date: September 2013
|
||||
KernelVersion: 3.13
|
||||
Contact: linux-pm@vger.kernel.org
|
||||
Description:
|
||||
Current power in micro-watts.
|
||||
|
||||
What: /sys/class/powercap/.../<power zone>/max_power_range_uw
|
||||
Date: September 2013
|
||||
KernelVersion: 3.13
|
||||
Contact: linux-pm@vger.kernel.org
|
||||
Description:
|
||||
Range of the above power value in micro-watts.
|
||||
|
||||
What: /sys/class/powercap/.../<power zone>/constraint_X_name
|
||||
Date: September 2013
|
||||
KernelVersion: 3.13
|
||||
Contact: linux-pm@vger.kernel.org
|
||||
Description:
|
||||
Each power zone can define one or more constraints. Each
|
||||
constraint can have an optional name. Here "X" can have values
|
||||
from 0 to max integer.
|
||||
|
||||
What: /sys/class/powercap/.../<power zone>/constraint_X_power_limit_uw
|
||||
Date: September 2013
|
||||
KernelVersion: 3.13
|
||||
Contact: linux-pm@vger.kernel.org
|
||||
Description:
|
||||
Power limit in micro-watts should be applicable for
|
||||
the time window specified by "constraint_X_time_window_us".
|
||||
Here "X" can have values from 0 to max integer.
|
||||
|
||||
What: /sys/class/powercap/.../<power zone>/constraint_X_time_window_us
|
||||
Date: September 2013
|
||||
KernelVersion: 3.13
|
||||
Contact: linux-pm@vger.kernel.org
|
||||
Description:
|
||||
Time window in micro seconds. This is used along with
|
||||
constraint_X_power_limit_uw to define a power constraint.
|
||||
Here "X" can have values from 0 to max integer.
|
||||
|
||||
|
||||
What: /sys/class/powercap/<control type>/.../constraint_X_max_power_uw
|
||||
Date: September 2013
|
||||
KernelVersion: 3.13
|
||||
Contact: linux-pm@vger.kernel.org
|
||||
Description:
|
||||
Maximum allowed power in micro watts for this constraint.
|
||||
Here "X" can have values from 0 to max integer.
|
||||
|
||||
What: /sys/class/powercap/<control type>/.../constraint_X_min_power_uw
|
||||
Date: September 2013
|
||||
KernelVersion: 3.13
|
||||
Contact: linux-pm@vger.kernel.org
|
||||
Description:
|
||||
Minimum allowed power in micro watts for this constraint.
|
||||
Here "X" can have values from 0 to max integer.
|
||||
|
||||
What: /sys/class/powercap/.../<power zone>/constraint_X_max_time_window_us
|
||||
Date: September 2013
|
||||
KernelVersion: 3.13
|
||||
Contact: linux-pm@vger.kernel.org
|
||||
Description:
|
||||
Maximum allowed time window in micro seconds for this
|
||||
constraint. Here "X" can have values from 0 to max integer.
|
||||
|
||||
What: /sys/class/powercap/.../<power zone>/constraint_X_min_time_window_us
|
||||
Date: September 2013
|
||||
KernelVersion: 3.13
|
||||
Contact: linux-pm@vger.kernel.org
|
||||
Description:
|
||||
Minimum allowed time window in micro seconds for this
|
||||
constraint. Here "X" can have values from 0 to max integer.
|
||||
|
||||
What: /sys/class/powercap/.../<power zone>/enabled
|
||||
Date: September 2013
|
||||
KernelVersion: 3.13
|
||||
Contact: linux-pm@vger.kernel.org
|
||||
Description
|
||||
This allows to enable/disable power capping at power zone level.
|
||||
This applies to current power zone and its children.
|
||||
@@ -101,14 +101,23 @@ style to do this even if your device holds the default setting,
|
||||
because this shows that you did think about these issues wrt. your
|
||||
device.
|
||||
|
||||
The query is performed via a call to dma_set_mask():
|
||||
The query is performed via a call to dma_set_mask_and_coherent():
|
||||
|
||||
int dma_set_mask(struct device *dev, u64 mask);
|
||||
int dma_set_mask_and_coherent(struct device *dev, u64 mask);
|
||||
|
||||
The query for consistent allocations is performed via a call to
|
||||
dma_set_coherent_mask():
|
||||
which will query the mask for both streaming and coherent APIs together.
|
||||
If you have some special requirements, then the following two separate
|
||||
queries can be used instead:
|
||||
|
||||
int dma_set_coherent_mask(struct device *dev, u64 mask);
|
||||
The query for streaming mappings is performed via a call to
|
||||
dma_set_mask():
|
||||
|
||||
int dma_set_mask(struct device *dev, u64 mask);
|
||||
|
||||
The query for consistent allocations is performed via a call
|
||||
to dma_set_coherent_mask():
|
||||
|
||||
int dma_set_coherent_mask(struct device *dev, u64 mask);
|
||||
|
||||
Here, dev is a pointer to the device struct of your device, and mask
|
||||
is a bit mask describing which bits of an address your device
|
||||
@@ -137,7 +146,7 @@ exactly why.
|
||||
|
||||
The standard 32-bit addressing device would do something like this:
|
||||
|
||||
if (dma_set_mask(dev, DMA_BIT_MASK(32))) {
|
||||
if (dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32))) {
|
||||
printk(KERN_WARNING
|
||||
"mydev: No suitable DMA available.\n");
|
||||
goto ignore_this_device;
|
||||
@@ -171,22 +180,20 @@ the case would look like this:
|
||||
|
||||
int using_dac, consistent_using_dac;
|
||||
|
||||
if (!dma_set_mask(dev, DMA_BIT_MASK(64))) {
|
||||
if (!dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64))) {
|
||||
using_dac = 1;
|
||||
consistent_using_dac = 1;
|
||||
dma_set_coherent_mask(dev, DMA_BIT_MASK(64));
|
||||
} else if (!dma_set_mask(dev, DMA_BIT_MASK(32))) {
|
||||
} else if (!dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32))) {
|
||||
using_dac = 0;
|
||||
consistent_using_dac = 0;
|
||||
dma_set_coherent_mask(dev, DMA_BIT_MASK(32));
|
||||
} else {
|
||||
printk(KERN_WARNING
|
||||
"mydev: No suitable DMA available.\n");
|
||||
goto ignore_this_device;
|
||||
}
|
||||
|
||||
dma_set_coherent_mask() will always be able to set the same or a
|
||||
smaller mask as dma_set_mask(). However for the rare case that a
|
||||
The coherent coherent mask will always be able to set the same or a
|
||||
smaller mask as the streaming mask. However for the rare case that a
|
||||
device driver only uses consistent allocations, one would have to
|
||||
check the return value from dma_set_coherent_mask().
|
||||
|
||||
@@ -199,9 +206,9 @@ address you might do something like:
|
||||
goto ignore_this_device;
|
||||
}
|
||||
|
||||
When dma_set_mask() is successful, and returns zero, the kernel saves
|
||||
away this mask you have provided. The kernel will use this
|
||||
information later when you make DMA mappings.
|
||||
When dma_set_mask() or dma_set_mask_and_coherent() is successful, and
|
||||
returns zero, the kernel saves away this mask you have provided. The
|
||||
kernel will use this information later when you make DMA mappings.
|
||||
|
||||
There is a case which we are aware of at this time, which is worth
|
||||
mentioning in this documentation. If your device supports multiple
|
||||
|
||||
@@ -141,6 +141,14 @@ won't change the current mask settings. It is more intended as an
|
||||
internal API for use by the platform than an external API for use by
|
||||
driver writers.
|
||||
|
||||
int
|
||||
dma_set_mask_and_coherent(struct device *dev, u64 mask)
|
||||
|
||||
Checks to see if the mask is possible and updates the device
|
||||
streaming and coherent DMA mask parameters if it is.
|
||||
|
||||
Returns: 0 if successful and a negative error if not.
|
||||
|
||||
int
|
||||
dma_set_mask(struct device *dev, u64 mask)
|
||||
|
||||
|
||||
@@ -152,8 +152,8 @@
|
||||
!Finclude/net/cfg80211.h cfg80211_scan_request
|
||||
!Finclude/net/cfg80211.h cfg80211_scan_done
|
||||
!Finclude/net/cfg80211.h cfg80211_bss
|
||||
!Finclude/net/cfg80211.h cfg80211_inform_bss_frame
|
||||
!Finclude/net/cfg80211.h cfg80211_inform_bss
|
||||
!Finclude/net/cfg80211.h cfg80211_inform_bss_width_frame
|
||||
!Finclude/net/cfg80211.h cfg80211_inform_bss_width
|
||||
!Finclude/net/cfg80211.h cfg80211_unlink_bss
|
||||
!Finclude/net/cfg80211.h cfg80211_find_ie
|
||||
!Finclude/net/cfg80211.h ieee80211_bss_get_ie
|
||||
|
||||
@@ -1222,8 +1222,6 @@ in this page</entry>
|
||||
#define NAND_BBT_VERSION 0x00000100
|
||||
/* Create a bbt if none axists */
|
||||
#define NAND_BBT_CREATE 0x00000200
|
||||
/* Search good / bad pattern through all pages of a block */
|
||||
#define NAND_BBT_SCANALLPAGES 0x00000400
|
||||
/* Write bbt if neccecary */
|
||||
#define NAND_BBT_WRITE 0x00001000
|
||||
/* Read and write back block contents when writing bbt */
|
||||
|
||||
@@ -525,8 +525,9 @@ corresponding register block for you.
|
||||
6. Other interesting functions
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
pci_find_slot() Find pci_dev corresponding to given bus and
|
||||
slot numbers.
|
||||
pci_get_domain_bus_and_slot() Find pci_dev corresponding to given domain,
|
||||
bus and slot and number. If the device is
|
||||
found, its reference count is increased.
|
||||
pci_set_power_state() Set PCI Power Management state (0=D0 ... 3=D3)
|
||||
pci_find_capability() Find specified capability in device's capability
|
||||
list.
|
||||
@@ -582,7 +583,8 @@ having sane locking.
|
||||
|
||||
pci_find_device() Superseded by pci_get_device()
|
||||
pci_find_subsys() Superseded by pci_get_subsys()
|
||||
pci_find_slot() Superseded by pci_get_slot()
|
||||
pci_find_slot() Superseded by pci_get_domain_bus_and_slot()
|
||||
pci_get_slot() Superseded by pci_get_domain_bus_and_slot()
|
||||
|
||||
|
||||
The alternative is the traditional PCI device driver that walks PCI
|
||||
|
||||
@@ -295,10 +295,6 @@ 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.
|
||||
|
||||
The driver can do this by including <linux/acpi_gpio.h> and then calling
|
||||
acpi_get_gpio(path, gpio). This will return the Linux GPIO number or
|
||||
negative errno if there was no translation found.
|
||||
|
||||
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
|
||||
@@ -322,3 +318,25 @@ 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:
|
||||
|
||||
#include <linux/gpio/consumer.h>
|
||||
...
|
||||
|
||||
struct gpio_desc *irq_desc, *power_desc;
|
||||
|
||||
irq_desc = gpiod_get_index(dev, NULL, 1);
|
||||
if (IS_ERR(irq_desc))
|
||||
/* handle error */
|
||||
|
||||
power_desc = gpiod_get_index(dev, NULL, 0);
|
||||
if (IS_ERR(power_desc))
|
||||
/* handle error */
|
||||
|
||||
/* Now we can use the GPIO descriptors */
|
||||
|
||||
See also Documentation/gpio.txt.
|
||||
|
||||
@@ -4,7 +4,8 @@ Kernel driver lp855x
|
||||
Backlight driver for LP855x ICs
|
||||
|
||||
Supported chips:
|
||||
Texas Instruments LP8550, LP8551, LP8552, LP8553, LP8556 and LP8557
|
||||
Texas Instruments LP8550, LP8551, LP8552, LP8553, LP8555, LP8556 and
|
||||
LP8557
|
||||
|
||||
Author: Milo(Woogyom) Kim <milo.kim@ti.com>
|
||||
|
||||
@@ -24,7 +25,7 @@ Value : pwm based or register based
|
||||
|
||||
2) chip_id
|
||||
The lp855x chip id.
|
||||
Value : lp8550/lp8551/lp8552/lp8553/lp8556/lp8557
|
||||
Value : lp8550/lp8551/lp8552/lp8553/lp8555/lp8556/lp8557
|
||||
|
||||
Platform data for lp855x
|
||||
------------------------
|
||||
|
||||
@@ -39,15 +39,15 @@ Module configuration options
|
||||
============================
|
||||
|
||||
If you use the floppy driver as a module, use the following syntax:
|
||||
modprobe floppy <options>
|
||||
modprobe floppy floppy="<options>"
|
||||
|
||||
Example:
|
||||
modprobe floppy omnibook messages
|
||||
modprobe floppy floppy="omnibook messages"
|
||||
|
||||
If you need certain options enabled every time you load the floppy driver,
|
||||
you can put:
|
||||
|
||||
options floppy omnibook messages
|
||||
options floppy floppy="omnibook messages"
|
||||
|
||||
in a configuration file in /etc/modprobe.d/.
|
||||
|
||||
|
||||
@@ -573,15 +573,19 @@ an memcg since the pages are allowed to be allocated from any physical
|
||||
node. One of the use cases is evaluating application performance by
|
||||
combining this information with the application's CPU allocation.
|
||||
|
||||
We export "total", "file", "anon" and "unevictable" pages per-node for
|
||||
each memcg. The ouput format of memory.numa_stat is:
|
||||
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:
|
||||
|
||||
total=<total pages> N0=<node 0 pages> N1=<node 1 pages> ...
|
||||
file=<total file pages> N0=<node 0 pages> N1=<node 1 pages> ...
|
||||
anon=<total anon pages> N0=<node 0 pages> N1=<node 1 pages> ...
|
||||
unevictable=<total anon pages> N0=<node 0 pages> N1=<node 1 pages> ...
|
||||
hierarchical_<counter>=<counter pages> N0=<node 0 pages> N1=<node 1 pages> ...
|
||||
|
||||
And we have total = file + anon + unevictable.
|
||||
The "total" count is sum of file + anon + unevictable.
|
||||
|
||||
6. Hierarchy support
|
||||
|
||||
|
||||
@@ -23,8 +23,8 @@ Contents:
|
||||
1.1 Initialization
|
||||
1.2 Per-CPU Initialization
|
||||
1.3 verify
|
||||
1.4 target or setpolicy?
|
||||
1.5 target
|
||||
1.4 target/target_index or setpolicy?
|
||||
1.5 target/target_index
|
||||
1.6 setpolicy
|
||||
2. Frequency Table Helpers
|
||||
|
||||
@@ -56,7 +56,8 @@ cpufreq_driver.init - A pointer to the per-CPU initialization
|
||||
cpufreq_driver.verify - A pointer to a "verification" function.
|
||||
|
||||
cpufreq_driver.setpolicy _or_
|
||||
cpufreq_driver.target - See below on the differences.
|
||||
cpufreq_driver.target/
|
||||
target_index - See below on the differences.
|
||||
|
||||
And optionally
|
||||
|
||||
@@ -66,7 +67,7 @@ cpufreq_driver.resume - A pointer to a per-CPU resume function
|
||||
which is called with interrupts disabled
|
||||
and _before_ the pre-suspend frequency
|
||||
and/or policy is restored by a call to
|
||||
->target or ->setpolicy.
|
||||
->target/target_index or ->setpolicy.
|
||||
|
||||
cpufreq_driver.attr - A pointer to a NULL-terminated list of
|
||||
"struct freq_attr" which allow to
|
||||
@@ -103,8 +104,8 @@ policy->governor must contain the "default policy" for
|
||||
this CPU. A few moments later,
|
||||
cpufreq_driver.verify and either
|
||||
cpufreq_driver.setpolicy or
|
||||
cpufreq_driver.target is called with
|
||||
these values.
|
||||
cpufreq_driver.target/target_index is called
|
||||
with these values.
|
||||
|
||||
For setting some of these values (cpuinfo.min[max]_freq, policy->min[max]), the
|
||||
frequency table helpers might be helpful. See the section 2 for more information
|
||||
@@ -133,20 +134,28 @@ range) is within policy->min and policy->max. If necessary, increase
|
||||
policy->max first, and only if this is no solution, decrease policy->min.
|
||||
|
||||
|
||||
1.4 target or setpolicy?
|
||||
1.4 target/target_index or setpolicy?
|
||||
----------------------------
|
||||
|
||||
Most cpufreq drivers or even most cpu frequency scaling algorithms
|
||||
only allow the CPU to be set to one frequency. For these, you use the
|
||||
->target call.
|
||||
->target/target_index call.
|
||||
|
||||
Some cpufreq-capable processors switch the frequency between certain
|
||||
limits on their own. These shall use the ->setpolicy call
|
||||
|
||||
|
||||
1.4. target
|
||||
1.4. target/target_index
|
||||
-------------
|
||||
|
||||
The target_index call has two arguments: struct cpufreq_policy *policy,
|
||||
and unsigned int index (into the exposed frequency table).
|
||||
|
||||
The CPUfreq driver must set the new frequency when called here. The
|
||||
actual frequency must be determined by freq_table[index].frequency.
|
||||
|
||||
Deprecated:
|
||||
----------
|
||||
The target call has three arguments: struct cpufreq_policy *policy,
|
||||
unsigned int target_frequency, unsigned int relation.
|
||||
|
||||
|
||||
@@ -40,7 +40,7 @@ Most cpufreq drivers (in fact, all except one, longrun) or even most
|
||||
cpu frequency scaling algorithms only offer the CPU to be set to one
|
||||
frequency. In order to offer dynamic frequency scaling, the cpufreq
|
||||
core must be able to tell these drivers of a "target frequency". So
|
||||
these specific drivers will be transformed to offer a "->target"
|
||||
these specific drivers will be transformed to offer a "->target/target_index"
|
||||
call instead of the existing "->setpolicy" call. For "longrun", all
|
||||
stays the same, though.
|
||||
|
||||
@@ -71,7 +71,7 @@ CPU can be set to switch independently | CPU can only be set
|
||||
/ the limits of policy->{min,max}
|
||||
/ \
|
||||
/ \
|
||||
Using the ->setpolicy call, Using the ->target call,
|
||||
Using the ->setpolicy call, Using the ->target/target_index call,
|
||||
the limits and the the frequency closest
|
||||
"policy" is set. to target_freq is set.
|
||||
It is assured that it
|
||||
|
||||
@@ -5,7 +5,7 @@
|
||||
Rusty Russell <rusty@rustcorp.com.au>
|
||||
Srivatsa Vaddagiri <vatsa@in.ibm.com>
|
||||
i386:
|
||||
Zwane Mwaikambo <zwane@arm.linux.org.uk>
|
||||
Zwane Mwaikambo <zwanem@gmail.com>
|
||||
ppc64:
|
||||
Nathan Lynch <nathanl@austin.ibm.com>
|
||||
Joel Schopp <jschopp@austin.ibm.com>
|
||||
|
||||
@@ -25,5 +25,4 @@ kernel configuration and platform will be selected by cpuidle.
|
||||
|
||||
Interfaces:
|
||||
extern int cpuidle_register_governor(struct cpuidle_governor *gov);
|
||||
extern void cpuidle_unregister_governor(struct cpuidle_governor *gov);
|
||||
struct cpuidle_governor
|
||||
|
||||
@@ -30,8 +30,10 @@ multiqueue
|
||||
|
||||
This policy is the default.
|
||||
|
||||
The multiqueue policy has two sets of 16 queues: one set for entries
|
||||
waiting for the cache and another one for those in the cache.
|
||||
The multiqueue policy has three sets of 16 queues: one set for entries
|
||||
waiting for the cache and another two for those in the cache (a set for
|
||||
clean entries and a set for dirty entries).
|
||||
|
||||
Cache entries in the queues are aged based on logical time. Entry into
|
||||
the cache is based on variable thresholds and queue selection is based
|
||||
on hit count on entry. The policy aims to take different cache miss
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user