Skip to content

Commit

Permalink
---
Browse files Browse the repository at this point in the history
yaml
---
r: 367913
b: refs/heads/master
c: 5f56886
h: refs/heads/master
i:
  367911: 027922b
v: v3
  • Loading branch information
Linus Torvalds committed May 1, 2013
1 parent 0455b4e commit 5db33d9
Show file tree
Hide file tree
Showing 507 changed files with 29,219 additions and 8,782 deletions.
2 changes: 1 addition & 1 deletion [refs]
Original file line number Diff line number Diff line change
@@ -1,2 +1,2 @@
---
refs/heads/master: e2a8b0a779787314eca1061308a8182e6c5bfabd
refs/heads/master: 5f56886521d6ddd3648777fae44d82382dd8c87f
44 changes: 44 additions & 0 deletions trunk/Documentation/ABI/testing/sysfs-devices-lpss_ltr
Original file line number Diff line number Diff line change
@@ -0,0 +1,44 @@
What: /sys/devices/.../lpss_ltr/
Date: March 2013
Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Description:
The /sys/devices/.../lpss_ltr/ directory is only present for
devices included into the Intel Lynxpoint Low Power Subsystem
(LPSS). If present, it contains attributes containing the LTR
mode and the values of LTR registers of the device.

What: /sys/devices/.../lpss_ltr/ltr_mode
Date: March 2013
Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Description:
The /sys/devices/.../lpss_ltr/ltr_mode attribute contains an
integer number (0 or 1) indicating whether or not the devices'
LTR functionality is working in the software mode (1).

This attribute is read-only. If the device's runtime PM status
is not "active", attempts to read from this attribute cause
-EAGAIN to be returned.

What: /sys/devices/.../lpss_ltr/auto_ltr
Date: March 2013
Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Description:
The /sys/devices/.../lpss_ltr/auto_ltr attribute contains the
current value of the device's AUTO_LTR register (raw)
represented as an 8-digit hexadecimal number.

This attribute is read-only. If the device's runtime PM status
is not "active", attempts to read from this attribute cause
-EAGAIN to be returned.

What: /sys/devices/.../lpss_ltr/sw_ltr
Date: March 2013
Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Description:
The /sys/devices/.../lpss_ltr/auto_ltr attribute contains the
current value of the device's SW_LTR register (raw) represented
as an 8-digit hexadecimal number.

This attribute is read-only. If the device's runtime PM status
is not "active", attempts to read from this attribute cause
-EAGAIN to be returned.
Original file line number Diff line number Diff line change
@@ -0,0 +1,13 @@
What: /sys/devices/.../power_resources_wakeup/
Date: April 2013
Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Description:
The /sys/devices/.../power_resources_wakeup/ directory is only
present for device objects representing ACPI device nodes that
require ACPI power resources for wakeup signaling.

If present, it contains symbolic links to device directories
representing ACPI power resources that need to be turned on for
the given device node to be able to signal wakeup. The names of
the links are the same as the names of the directories they
point to.
26 changes: 26 additions & 0 deletions trunk/Documentation/ABI/testing/sysfs-firmware-acpi
Original file line number Diff line number Diff line change
Expand Up @@ -18,6 +18,32 @@ Description:
yoffset: The number of pixels between the top of the screen
and the top edge of the image.

What: /sys/firmware/acpi/hotplug/
Date: February 2013
Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Description:
There are separate hotplug profiles for different classes of
devices supported by ACPI, such as containers, memory modules,
processors, PCI root bridges etc. A hotplug profile for a given
class of devices is a collection of settings defining the way
that class of devices will be handled by the ACPI core hotplug
code. Those profiles are represented in sysfs as subdirectories
of /sys/firmware/acpi/hotplug/.

The following setting is available to user space for each
hotplug profile:

enabled: If set, the ACPI core will handle notifications of
hotplug events associated with the given class of
devices and will allow those devices to be ejected with
the help of the _EJ0 control method. Unsetting it
effectively disables hotplug for the correspoinding
class of devices.

The value of the above attribute is an integer number: 1 (set)
or 0 (unset). Attempts to write any other values to it will
cause -EINVAL to be returned.

What: /sys/firmware/acpi/interrupts/
Date: February 2008
Contact: Len Brown <lenb@kernel.org>
Expand Down
9 changes: 5 additions & 4 deletions trunk/Documentation/cpu-freq/cpu-drivers.txt
Original file line number Diff line number Diff line change
Expand Up @@ -108,8 +108,9 @@ policy->governor must contain the "default policy" for
cpufreq_driver.target is called with
these values.

For setting some of these values, the frequency table helpers might be
helpful. See the section 2 for more information on them.
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
on them.

SMP systems normally have same clock source for a group of cpus. For these the
.init() would be called only once for the first online cpu. Here the .init()
Expand Down Expand Up @@ -184,10 +185,10 @@ the reference implementation in drivers/cpufreq/longrun.c
As most cpufreq processors only allow for being set to a few specific
frequencies, a "frequency table" with some functions might assist in
some work of the processor driver. Such a "frequency table" consists
of an array of struct cpufreq_freq_table entries, with any value in
of an array of struct cpufreq_frequency_table entries, with any value in
"index" you want to use, and the corresponding frequency in
"frequency". At the end of the table, you need to add a
cpufreq_freq_table entry with frequency set to CPUFREQ_TABLE_END. And
cpufreq_frequency_table entry with frequency set to CPUFREQ_TABLE_END. And
if you want to skip one entry in the table, set the frequency to
CPUFREQ_ENTRY_INVALID. The entries don't need to be in ascending
order.
Expand Down
27 changes: 27 additions & 0 deletions trunk/Documentation/cpu-freq/governors.txt
Original file line number Diff line number Diff line change
Expand Up @@ -167,6 +167,27 @@ of load evaluation and helping the CPU stay at its top speed when truly
busy, rather than shifting back and forth in speed. This tunable has no
effect on behavior at lower speeds/lower CPU loads.

powersave_bias: this parameter takes a value between 0 to 1000. It
defines the percentage (times 10) value of the target frequency that
will be shaved off of the target. For example, when set to 100 -- 10%,
when ondemand governor would have targeted 1000 MHz, it will target
1000 MHz - (10% of 1000 MHz) = 900 MHz instead. This is set to 0
(disabled) by default.
When AMD frequency sensitivity powersave bias driver --
drivers/cpufreq/amd_freq_sensitivity.c is loaded, this parameter
defines the workload frequency sensitivity threshold in which a lower
frequency is chosen instead of ondemand governor's original target.
The frequency sensitivity is a hardware reported (on AMD Family 16h
Processors and above) value between 0 to 100% that tells software how
the performance of the workload running on a CPU will change when
frequency changes. A workload with sensitivity of 0% (memory/IO-bound)
will not perform any better on higher core frequency, whereas a
workload with sensitivity of 100% (CPU-bound) will perform better
higher the frequency. When the driver is loaded, this is set to 400
by default -- for CPUs running workloads with sensitivity value below
40%, a lower frequency is chosen. Unloading the driver or writing 0
will disable this feature.


2.5 Conservative
----------------
Expand All @@ -191,6 +212,12 @@ governor but for the opposite direction. For example when set to its
default value of '20' it means that if the CPU usage needs to be below
20% between samples to have the frequency decreased.

sampling_down_factor: similar functionality as in "ondemand" governor.
But in "conservative", it controls the rate at which the kernel makes
a decision on when to decrease the frequency while running in any
speed. Load for frequency increase is still evaluated every
sampling rate.

3. The Governor Interface in the CPUfreq Core
=============================================

Expand Down
6 changes: 6 additions & 0 deletions trunk/Documentation/cpuidle/driver.txt
Original file line number Diff line number Diff line change
Expand Up @@ -15,11 +15,17 @@ has mechanisms in place to support actual entry-exit into CPU idle states.
cpuidle driver initializes the cpuidle_device structure for each CPU device
and registers with cpuidle using cpuidle_register_device.

If all the idle states are the same, the wrapper function cpuidle_register
could be used instead.

It can also support the dynamic changes (like battery <-> AC), by using
cpuidle_pause_and_lock, cpuidle_disable_device and cpuidle_enable_device,
cpuidle_resume_and_unlock.

Interfaces:
extern int cpuidle_register(struct cpuidle_driver *drv,
const struct cpumask *const coupled_cpus);
extern int cpuidle_unregister(struct cpuidle_driver *drv);
extern int cpuidle_register_driver(struct cpuidle_driver *drv);
extern void cpuidle_unregister_driver(struct cpuidle_driver *drv);
extern int cpuidle_register_device(struct cpuidle_device *dev);
Expand Down
84 changes: 67 additions & 17 deletions trunk/Documentation/device-mapper/dm-raid.txt
Original file line number Diff line number Diff line change
@@ -1,10 +1,13 @@
dm-raid
-------
=======

The device-mapper RAID (dm-raid) target provides a bridge from DM to MD.
It allows the MD RAID drivers to be accessed using a device-mapper
interface.


Mapping Table Interface
-----------------------
The target is named "raid" and it accepts the following parameters:

<raid_type> <#raid_params> <raid_params> \
Expand Down Expand Up @@ -47,7 +50,7 @@ The target is named "raid" and it accepts the following parameters:
followed by optional parameters (in any order):
[sync|nosync] Force or prevent RAID initialization.

[rebuild <idx>] Rebuild drive number idx (first drive is 0).
[rebuild <idx>] Rebuild drive number 'idx' (first drive is 0).

[daemon_sleep <ms>]
Interval between runs of the bitmap daemon that
Expand All @@ -56,9 +59,9 @@ The target is named "raid" and it accepts the following parameters:

[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[write_mostly <idx>] Drive index is write-mostly
[max_write_behind <sectors>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size (higher RAIDs only)
[write_mostly <idx>] Mark drive index 'idx' write-mostly.
[max_write_behind <sectors>] See '--write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size (RAID 4/5/6 only)
[region_size <sectors>]
The region_size multiplied by the number of regions is the
logical size of the array. The bitmap records the device
Expand Down Expand Up @@ -122,7 +125,7 @@ The target is named "raid" and it accepts the following parameters:
given for both the metadata and data drives for a given position.


Example tables
Example Tables
--------------
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# No metadata devices specified to hold superblock/bitmap info
Expand All @@ -141,26 +144,70 @@ Example tables
raid4 4 2048 sync min_recovery_rate 20 \
5 8:17 8:18 8:33 8:34 8:49 8:50 8:65 8:66 8:81 8:82


Status Output
-------------
'dmsetup table' displays the table used to construct the mapping.
The optional parameters are always printed in the order listed
above with "sync" or "nosync" always output ahead of the other
arguments, regardless of the order used when originally loading the table.
Arguments that can be repeated are ordered by value.

'dmsetup status' yields information on the state and health of the
array.
The output is as follows:

'dmsetup status' yields information on the state and health of the array.
The output is as follows (normally a single line, but expanded here for
clarity):
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
2: <raid_type> <#devices> <health_chars> \
3: <sync_ratio> <sync_action> <mismatch_cnt>

Line 1 is the standard output produced by device-mapper.
Line 2 is produced by the raid target, and best explained by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Line 2 & 3 are produced by the raid target and are best explained by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568 init 0
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Faulty or missing devices are marked 'D'. Devices that are out-of-sync
are marked 'a'.

which are 'A'live, and the array is 2/490221568 complete with its initial
recovery. Here is a fuller description of the individual fields:
<raid_type> Same as the <raid_type> used to create the array.
<health_chars> One char for each device, indicating: 'A' = alive and
in-sync, 'a' = alive but not in-sync, 'D' = dead/failed.
<sync_ratio> The ratio indicating how much of the array has undergone
the process described by 'sync_action'. If the
'sync_action' is "check" or "repair", then the process
of "resync" or "recover" can be considered complete.
<sync_action> One of the following possible states:
idle - No synchronization action is being performed.
frozen - The current action has been halted.
resync - Array is undergoing its initial synchronization
or is resynchronizing after an unclean shutdown
(possibly aided by a bitmap).
recover - A device in the array is being rebuilt or
replaced.
check - A user-initiated full check of the array is
being performed. All blocks are read and
checked for consistency. The number of
discrepancies found are recorded in
<mismatch_cnt>. No changes are made to the
array by this action.
repair - The same as "check", but discrepancies are
corrected.
reshape - The array is undergoing a reshape.
<mismatch_cnt> The number of discrepancies found between mirror copies
in RAID1/10 or wrong parity values found in RAID4/5/6.
This value is valid only after a "check" of the array
is performed. A healthy array has a 'mismatch_cnt' of 0.

Message Interface
-----------------
The dm-raid target will accept certain actions through the 'message' interface.
('man dmsetup' for more information on the message interface.) These actions
include:
"idle" - Halt the current sync action.
"frozen" - Freeze the current sync action.
"resync" - Initiate/continue a resync.
"recover"- Initiate/continue a recover process.
"check" - Initiate a check (i.e. a "scrub") of the array.
"repair" - Initiate a repair of the array.
"reshape"- Currently unsupported (-EINVAL).

Version History
---------------
Expand All @@ -171,4 +218,7 @@ Version History
1.3.1 Allow device replacement/rebuild for RAID 10
1.3.2 Fix/improve redundancy checking for RAID10
1.4.0 Non-functional change. Removes arg from mapping function.
1.4.1 Add RAID10 "far" and "offset" algorithm support.
1.4.1 RAID10 fix redundancy validation checks (commit 55ebbb5).
1.4.2 Add RAID10 "far" and "offset" algorithm support.
1.5.0 Add message interface to allow manipulation of the sync_action.
New status (STATUSTYPE_INFO) fields: sync_action and mismatch_cnt.
17 changes: 17 additions & 0 deletions trunk/Documentation/devicetree/bindings/ata/imx-pata.txt
Original file line number Diff line number Diff line change
@@ -0,0 +1,17 @@
* Freescale i.MX PATA Controller

Required properties:
- compatible: "fsl,imx27-pata"
- reg: Address range of the PATA Controller
- interrupts: The interrupt of the PATA Controller
- clocks: the clocks for the PATA Controller

Example:

pata: pata@83fe0000 {
compatible = "fsl,imx51-pata", "fsl,imx27-pata";
reg = <0x83fe0000 0x4000>;
interrupts = <70>;
clocks = <&clks 161>;
status = "disabled";
};
Original file line number Diff line number Diff line change
@@ -0,0 +1,65 @@
Generic ARM big LITTLE cpufreq driver's DT glue
-----------------------------------------------

This is DT specific glue layer for generic cpufreq driver for big LITTLE
systems.

Both required and optional properties listed below must be defined
under node /cpus/cpu@x. Where x is the first cpu inside a cluster.

FIXME: Cpus should boot in the order specified in DT and all cpus for a cluster
must be present contiguously. Generic DT driver will check only node 'x' for
cpu:x.

Required properties:
- operating-points: Refer to Documentation/devicetree/bindings/power/opp.txt
for details

Optional properties:
- clock-latency: Specify the possible maximum transition latency for clock,
in unit of nanoseconds.

Examples:

cpus {
#address-cells = <1>;
#size-cells = <0>;

cpu@0 {
compatible = "arm,cortex-a15";
reg = <0>;
next-level-cache = <&L2>;
operating-points = <
/* kHz uV */
792000 1100000
396000 950000
198000 850000
>;
clock-latency = <61036>; /* two CLK32 periods */
};

cpu@1 {
compatible = "arm,cortex-a15";
reg = <1>;
next-level-cache = <&L2>;
};

cpu@100 {
compatible = "arm,cortex-a7";
reg = <100>;
next-level-cache = <&L2>;
operating-points = <
/* kHz uV */
792000 950000
396000 750000
198000 450000
>;
clock-latency = <61036>; /* two CLK32 periods */
};

cpu@101 {
compatible = "arm,cortex-a7";
reg = <101>;
next-level-cache = <&L2>;
};
};
Loading

0 comments on commit 5db33d9

Please sign in to comment.