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.2-rc2' into staging/for_v3.3
* tag 'v3.2-rc2': (3068 commits) Linux 3.2-rc2 hfs: add sanity check for file name length fsl-rio: fix compile error blackfin: Fixup export.h includes Blackfin: add serial TX IRQ in individual platform resource virtio-pci: fix use after free ACPI / cpuidle: Remove acpi_idle_suspend (to fix suspend regression) drm/radeon/kms/combios: fix dynamic allocation of PM clock modes [CPUFREQ] db8500: fix build error due to undeclared i variable bma023: Add SFI translation for this device vrtc: change its year offset from 1960 to 1972 ce4100: fix a build error arm/imx: fix imx6q mmc error when mounting rootfs arm/imx: fix AUTO_ZRELADDR selection arm/imx: fix the references to ARCH_MX3 ARM: mx51/53: set pwm clock parent to ipg_perclk btrfs: rename the option to nospace_cache drm/radeon/kms/pm: switch to dynamically allocating clock mode array drm/radeon/kms: optimize r600_pm_profile_init drm/radeon/kms/pm: add a proper pm profile init function for fusion ... Conflicts: drivers/media/radio/Kconfig
This commit is contained in:
Mauro Carvalho Chehab
@@ -68,6 +68,7 @@ Juha Yrjola <juha.yrjola@solidboot.com>
|
||||
Kay Sievers <kay.sievers@vrfy.org>
|
||||
Kenneth W Chen <kenneth.w.chen@intel.com>
|
||||
Koushik <raghavendra.koushik@neterion.com>
|
||||
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
|
||||
Leonid I Ananiev <leonid.i.ananiev@intel.com>
|
||||
Linas Vepstas <linas@austin.ibm.com>
|
||||
Mark Brown <broonie@sirena.org.uk>
|
||||
@@ -111,3 +112,4 @@ Uwe Kleine-König <ukl@pengutronix.de>
|
||||
Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com>
|
||||
Valdis Kletnieks <Valdis.Kletnieks@vt.edu>
|
||||
Takashi YOSHII <takashi.yoshii.zj@renesas.com>
|
||||
Yusuke Goda <goda.yusuke@renesas.com>
|
||||
|
||||
@@ -0,0 +1,22 @@
|
||||
What: /sys/firmware/acpi/pm_profile
|
||||
Date: 03-Nov-2011
|
||||
KernelVersion: v3.2
|
||||
Contact: linux-acpi@vger.kernel.org
|
||||
Description: The ACPI pm_profile sysfs interface exports the platform
|
||||
power management (and performance) requirement expectations
|
||||
as provided by BIOS. The integer value is directly passed as
|
||||
retrieved from the FADT ACPI table.
|
||||
Values: For possible values see ACPI specification:
|
||||
5.2.9 Fixed ACPI Description Table (FADT)
|
||||
Field: Preferred_PM_Profile
|
||||
|
||||
Currently these values are defined by spec:
|
||||
0 Unspecified
|
||||
1 Desktop
|
||||
2 Mobile
|
||||
3 Workstation
|
||||
4 Enterprise Server
|
||||
5 SOHO Server
|
||||
6 Appliance PC
|
||||
7 Performance Server
|
||||
>7 Reserved
|
||||
@@ -0,0 +1,19 @@
|
||||
What: /sys/kernel/debug/ideapad/cfg
|
||||
Date: Sep 2011
|
||||
KernelVersion: 3.2
|
||||
Contact: Ike Panhc <ike.pan@canonical.com>
|
||||
Description:
|
||||
|
||||
cfg shows the return value of _CFG method in VPC2004 device. It tells machine
|
||||
capability and what graphic component within the machine.
|
||||
|
||||
|
||||
What: /sys/kernel/debug/ideapad/status
|
||||
Date: Sep 2011
|
||||
KernelVersion: 3.2
|
||||
Contact: Ike Panhc <ike.pan@canonical.com>
|
||||
Description:
|
||||
|
||||
status shows infos we can read and tells its meaning and value.
|
||||
|
||||
|
||||
@@ -71,3 +71,10 @@ Description: Value of 1 indicates the controller can honor the reset_devices
|
||||
a dump device, as kdump requires resetting the device in order
|
||||
to work reliably.
|
||||
|
||||
Where: /sys/bus/pci/devices/<dev>/ccissX/transport_mode
|
||||
Date: July 2011
|
||||
Kernel Version: 3.0
|
||||
Contact: iss_storagedev@hp.com
|
||||
Description: Value of "simple" indicates that the controller has been placed
|
||||
in "simple mode". Value of "performant" indicates that the
|
||||
controller has been placed in "performant mode".
|
||||
|
||||
@@ -5,19 +5,4 @@ Contact: "Ike Panhc <ike.pan@canonical.com>"
|
||||
Description:
|
||||
Control the power of camera module. 1 means on, 0 means off.
|
||||
|
||||
What: /sys/devices/platform/ideapad/cfg
|
||||
Date: Jun 2011
|
||||
KernelVersion: 3.1
|
||||
Contact: "Ike Panhc <ike.pan@canonical.com>"
|
||||
Description:
|
||||
Ideapad capability bits.
|
||||
Bit 8-10: 1 - Intel graphic only
|
||||
2 - ATI graphic only
|
||||
3 - Nvidia graphic only
|
||||
4 - Intel and ATI graphic
|
||||
5 - Intel and Nvidia graphic
|
||||
Bit 16: Bluetooth exist (1 for exist)
|
||||
Bit 17: 3G exist (1 for exist)
|
||||
Bit 18: Wifi exist (1 for exist)
|
||||
Bit 19: Camera exist (1 for exist)
|
||||
|
||||
|
||||
@@ -166,8 +166,8 @@ if (condition)
|
||||
else
|
||||
do_that();
|
||||
|
||||
This does not apply if one branch of a conditional statement is a single
|
||||
statement. Use braces in both branches.
|
||||
This does not apply if only one branch of a conditional statement is a single
|
||||
statement; in the latter case use braces in both branches:
|
||||
|
||||
if (condition) {
|
||||
do_this();
|
||||
|
||||
@@ -50,6 +50,13 @@ specify the GFP_ flags (see kmalloc) for the allocation (the
|
||||
implementation may choose to ignore flags that affect the location of
|
||||
the returned memory, like GFP_DMA).
|
||||
|
||||
void *
|
||||
dma_zalloc_coherent(struct device *dev, size_t size,
|
||||
dma_addr_t *dma_handle, gfp_t flag)
|
||||
|
||||
Wraps dma_alloc_coherent() and also zeroes the returned memory if the
|
||||
allocation attempt succeeded.
|
||||
|
||||
void
|
||||
dma_free_coherent(struct device *dev, size_t size, void *cpu_addr,
|
||||
dma_addr_t dma_handle)
|
||||
|
||||
+168
-140
File diff suppressed because it is too large
Load Diff
@@ -572,7 +572,7 @@ static void board_select_chip (struct mtd_info *mtd, int chip)
|
||||
</para>
|
||||
<para>
|
||||
The simplest way to activate the FLASH based bad block table support
|
||||
is to set the option NAND_USE_FLASH_BBT in the option field of
|
||||
is to set the option NAND_BBT_USE_FLASH in the bbt_option field of
|
||||
the nand chip structure before calling nand_scan(). For AG-AND
|
||||
chips is this done by default.
|
||||
This activates the default FLASH based bad block table functionality
|
||||
@@ -773,20 +773,6 @@ struct nand_oobinfo {
|
||||
done according to the default builtin scheme.
|
||||
</para>
|
||||
</sect2>
|
||||
<sect2 id="User_space_placement_selection">
|
||||
<title>User space placement selection</title>
|
||||
<para>
|
||||
All non ecc functions like mtd->read and mtd->write use an internal
|
||||
structure, which can be set by an ioctl. This structure is preset
|
||||
to the autoplacement default.
|
||||
<programlisting>
|
||||
ioctl (fd, MEMSETOOBSEL, oobsel);
|
||||
</programlisting>
|
||||
oobsel is a pointer to a user supplied structure of type
|
||||
nand_oobconfig. The contents of this structure must match the
|
||||
criteria of the filesystem, which will be used. See an example in utils/nandwrite.c.
|
||||
</para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
<sect1 id="Spare_area_autoplacement_default">
|
||||
<title>Spare area autoplacement default schemes</title>
|
||||
@@ -1158,9 +1144,6 @@ in this page</entry>
|
||||
These constants are defined in nand.h. They are ored together to describe
|
||||
the functionality.
|
||||
<programlisting>
|
||||
/* Use a flash based bad block table. This option is parsed by the
|
||||
* default bad block table function (nand_default_bbt). */
|
||||
#define NAND_USE_FLASH_BBT 0x00010000
|
||||
/* The hw ecc generator provides a syndrome instead a ecc value on read
|
||||
* This can only work if we have the ecc bytes directly behind the
|
||||
* data bytes. Applies for DOC and AG-AND Renesas HW Reed Solomon generators */
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
To choose IO schedulers at boot time, use the argument 'elevator=deadline'.
|
||||
'noop', 'as' and 'cfq' (the default) are also available. IO schedulers are
|
||||
assigned globally at boot time only presently.
|
||||
'noop' and 'cfq' (the default) are also available. IO schedulers are assigned
|
||||
globally at boot time only presently.
|
||||
|
||||
Each io queue has a set of io scheduler tunables associated with it. These
|
||||
tunables control how the io scheduler works. You can find these entries
|
||||
|
||||
@@ -78,6 +78,16 @@ The device naming scheme is:
|
||||
/dev/cciss/c1d1p2 Controller 1, disk 1, partition 2
|
||||
/dev/cciss/c1d1p3 Controller 1, disk 1, partition 3
|
||||
|
||||
CCISS simple mode support
|
||||
-------------------------
|
||||
|
||||
The "cciss_simple_mode=1" boot parameter may be used to prevent the driver
|
||||
from putting the controller into "performant" mode. The difference is that
|
||||
with simple mode, each command completion requires an interrupt, while with
|
||||
"performant mode" (the default, and ordinarily better performing) it is
|
||||
possible to have multiple command completions indicated by a single
|
||||
interrupt.
|
||||
|
||||
SCSI tape drive and medium changer support
|
||||
------------------------------------------
|
||||
|
||||
|
||||
@@ -454,8 +454,8 @@ mounted hierarchy, to remove a task from its current cgroup you must
|
||||
move it into a new cgroup (possibly the root cgroup) by writing to the
|
||||
new cgroup's tasks file.
|
||||
|
||||
Note: If the ns cgroup is active, moving a process to another cgroup can
|
||||
fail.
|
||||
Note: Due to some restrictions enforced by some cgroup subsystems, moving
|
||||
a process to another cgroup can fail.
|
||||
|
||||
2.3 Mounting hierarchies by name
|
||||
--------------------------------
|
||||
|
||||
@@ -33,9 +33,9 @@ demonstrate this problem using nested bash shells:
|
||||
|
||||
From a second, unrelated bash shell:
|
||||
$ kill -SIGSTOP 16690
|
||||
$ kill -SIGCONT 16990
|
||||
$ kill -SIGCONT 16690
|
||||
|
||||
<at this point 16990 exits and causes 16644 to exit too>
|
||||
<at this point 16690 exits and causes 16644 to exit too>
|
||||
|
||||
This happens because bash can observe both signals and choose how it
|
||||
responds to them.
|
||||
|
||||
@@ -418,7 +418,6 @@ total_unevictable - sum of all children's "unevictable"
|
||||
|
||||
# The following additional stats are dependent on CONFIG_DEBUG_VM.
|
||||
|
||||
inactive_ratio - VM internal parameter. (see mm/page_alloc.c)
|
||||
recent_rotated_anon - VM internal parameter. (see mm/vmscan.c)
|
||||
recent_rotated_file - VM internal parameter. (see mm/vmscan.c)
|
||||
recent_scanned_anon - VM internal parameter. (see mm/vmscan.c)
|
||||
|
||||
@@ -48,7 +48,7 @@ kernel and userspace, 'connector' is used as the interface for
|
||||
communication.
|
||||
|
||||
There are currently two userspace log implementations that leverage this
|
||||
framework - "clustered_disk" and "clustered_core". These implementations
|
||||
framework - "clustered-disk" and "clustered-core". These implementations
|
||||
provide a cluster-coherent log for shared-storage. Device-mapper mirroring
|
||||
can be used in a shared-storage environment when the cluster log implementations
|
||||
are employed.
|
||||
|
||||
@@ -0,0 +1,84 @@
|
||||
Introduction
|
||||
============
|
||||
|
||||
The more-sophisticated device-mapper targets require complex metadata
|
||||
that is managed in kernel. In late 2010 we were seeing that various
|
||||
different targets were rolling their own data strutures, for example:
|
||||
|
||||
- Mikulas Patocka's multisnap implementation
|
||||
- Heinz Mauelshagen's thin provisioning target
|
||||
- Another btree-based caching target posted to dm-devel
|
||||
- Another multi-snapshot target based on a design of Daniel Phillips
|
||||
|
||||
Maintaining these data structures takes a lot of work, so if possible
|
||||
we'd like to reduce the number.
|
||||
|
||||
The persistent-data library is an attempt to provide a re-usable
|
||||
framework for people who want to store metadata in device-mapper
|
||||
targets. It's currently used by the thin-provisioning target and an
|
||||
upcoming hierarchical storage target.
|
||||
|
||||
Overview
|
||||
========
|
||||
|
||||
The main documentation is in the header files which can all be found
|
||||
under drivers/md/persistent-data.
|
||||
|
||||
The block manager
|
||||
-----------------
|
||||
|
||||
dm-block-manager.[hc]
|
||||
|
||||
This provides access to the data on disk in fixed sized-blocks. There
|
||||
is a read/write locking interface to prevent concurrent accesses, and
|
||||
keep data that is being used in the cache.
|
||||
|
||||
Clients of persistent-data are unlikely to use this directly.
|
||||
|
||||
The transaction manager
|
||||
-----------------------
|
||||
|
||||
dm-transaction-manager.[hc]
|
||||
|
||||
This restricts access to blocks and enforces copy-on-write semantics.
|
||||
The only way you can get hold of a writable block through the
|
||||
transaction manager is by shadowing an existing block (ie. doing
|
||||
copy-on-write) or allocating a fresh one. Shadowing is elided within
|
||||
the same transaction so performance is reasonable. The commit method
|
||||
ensures that all data is flushed before it writes the superblock.
|
||||
On power failure your metadata will be as it was when last committed.
|
||||
|
||||
The Space Maps
|
||||
--------------
|
||||
|
||||
dm-space-map.h
|
||||
dm-space-map-metadata.[hc]
|
||||
dm-space-map-disk.[hc]
|
||||
|
||||
On-disk data structures that keep track of reference counts of blocks.
|
||||
Also acts as the allocator of new blocks. Currently two
|
||||
implementations: a simpler one for managing blocks on a different
|
||||
device (eg. thinly-provisioned data blocks); and one for managing
|
||||
the metadata space. The latter is complicated by the need to store
|
||||
its own data within the space it's managing.
|
||||
|
||||
The data structures
|
||||
-------------------
|
||||
|
||||
dm-btree.[hc]
|
||||
dm-btree-remove.c
|
||||
dm-btree-spine.c
|
||||
dm-btree-internal.h
|
||||
|
||||
Currently there is only one data structure, a hierarchical btree.
|
||||
There are plans to add more. For example, something with an
|
||||
array-like interface would see a lot of use.
|
||||
|
||||
The btree is 'hierarchical' in that you can define it to be composed
|
||||
of nested btrees, and take multiple keys. For example, the
|
||||
thin-provisioning target uses a btree with two levels of nesting.
|
||||
The first maps a device id to a mapping tree, and that in turn maps a
|
||||
virtual block to a physical block.
|
||||
|
||||
Values stored in the btrees can have arbitrary size. Keys are always
|
||||
64bits, although nesting allows you to use multiple keys.
|
||||
@@ -0,0 +1,285 @@
|
||||
Introduction
|
||||
============
|
||||
|
||||
This document descibes a collection of device-mapper targets that
|
||||
between them implement thin-provisioning and snapshots.
|
||||
|
||||
The main highlight of this implementation, compared to the previous
|
||||
implementation of snapshots, is that it allows many virtual devices to
|
||||
be stored on the same data volume. This simplifies administration and
|
||||
allows the sharing of data between volumes, thus reducing disk usage.
|
||||
|
||||
Another significant feature is support for an arbitrary depth of
|
||||
recursive snapshots (snapshots of snapshots of snapshots ...). The
|
||||
previous implementation of snapshots did this by chaining together
|
||||
lookup tables, and so performance was O(depth). This new
|
||||
implementation uses a single data structure to avoid this degradation
|
||||
with depth. Fragmentation may still be an issue, however, in some
|
||||
scenarios.
|
||||
|
||||
Metadata is stored on a separate device from data, giving the
|
||||
administrator some freedom, for example to:
|
||||
|
||||
- Improve metadata resilience by storing metadata on a mirrored volume
|
||||
but data on a non-mirrored one.
|
||||
|
||||
- Improve performance by storing the metadata on SSD.
|
||||
|
||||
Status
|
||||
======
|
||||
|
||||
These targets are very much still in the EXPERIMENTAL state. Please
|
||||
do not yet rely on them in production. But do experiment and offer us
|
||||
feedback. Different use cases will have different performance
|
||||
characteristics, for example due to fragmentation of the data volume.
|
||||
|
||||
If you find this software is not performing as expected please mail
|
||||
dm-devel@redhat.com with details and we'll try our best to improve
|
||||
things for you.
|
||||
|
||||
Userspace tools for checking and repairing the metadata are under
|
||||
development.
|
||||
|
||||
Cookbook
|
||||
========
|
||||
|
||||
This section describes some quick recipes for using thin provisioning.
|
||||
They use the dmsetup program to control the device-mapper driver
|
||||
directly. End users will be advised to use a higher-level volume
|
||||
manager such as LVM2 once support has been added.
|
||||
|
||||
Pool device
|
||||
-----------
|
||||
|
||||
The pool device ties together the metadata volume and the data volume.
|
||||
It maps I/O linearly to the data volume and updates the metadata via
|
||||
two mechanisms:
|
||||
|
||||
- Function calls from the thin targets
|
||||
|
||||
- Device-mapper 'messages' from userspace which control the creation of new
|
||||
virtual devices amongst other things.
|
||||
|
||||
Setting up a fresh pool device
|
||||
------------------------------
|
||||
|
||||
Setting up a pool device requires a valid metadata device, and a
|
||||
data device. If you do not have an existing metadata device you can
|
||||
make one by zeroing the first 4k to indicate empty metadata.
|
||||
|
||||
dd if=/dev/zero of=$metadata_dev bs=4096 count=1
|
||||
|
||||
The amount of metadata you need will vary according to how many blocks
|
||||
are shared between thin devices (i.e. through snapshots). If you have
|
||||
less sharing than average you'll need a larger-than-average metadata device.
|
||||
|
||||
As a guide, we suggest you calculate the number of bytes to use in the
|
||||
metadata device as 48 * $data_dev_size / $data_block_size but round it up
|
||||
to 2MB if the answer is smaller. The largest size supported is 16GB.
|
||||
|
||||
If you're creating large numbers of snapshots which are recording large
|
||||
amounts of change, you may need find you need to increase this.
|
||||
|
||||
Reloading a pool table
|
||||
----------------------
|
||||
|
||||
You may reload a pool's table, indeed this is how the pool is resized
|
||||
if it runs out of space. (N.B. While specifying a different metadata
|
||||
device when reloading is not forbidden at the moment, things will go
|
||||
wrong if it does not route I/O to exactly the same on-disk location as
|
||||
previously.)
|
||||
|
||||
Using an existing pool device
|
||||
-----------------------------
|
||||
|
||||
dmsetup create pool \
|
||||
--table "0 20971520 thin-pool $metadata_dev $data_dev \
|
||||
$data_block_size $low_water_mark"
|
||||
|
||||
$data_block_size gives the smallest unit of disk space that can be
|
||||
allocated at a time expressed in units of 512-byte sectors. People
|
||||
primarily interested in thin provisioning may want to use a value such
|
||||
as 1024 (512KB). People doing lots of snapshotting may want a smaller value
|
||||
such as 128 (64KB). If you are not zeroing newly-allocated data,
|
||||
a larger $data_block_size in the region of 256000 (128MB) is suggested.
|
||||
$data_block_size must be the same for the lifetime of the
|
||||
metadata device.
|
||||
|
||||
$low_water_mark is expressed in blocks of size $data_block_size. If
|
||||
free space on the data device drops below this level then a dm event
|
||||
will be triggered which a userspace daemon should catch allowing it to
|
||||
extend the pool device. Only one such event will be sent.
|
||||
Resuming a device with a new table itself triggers an event so the
|
||||
userspace daemon can use this to detect a situation where a new table
|
||||
already exceeds the threshold.
|
||||
|
||||
Thin provisioning
|
||||
-----------------
|
||||
|
||||
i) Creating a new thinly-provisioned volume.
|
||||
|
||||
To create a new thinly- provisioned volume you must send a message to an
|
||||
active pool device, /dev/mapper/pool in this example.
|
||||
|
||||
dmsetup message /dev/mapper/pool 0 "create_thin 0"
|
||||
|
||||
Here '0' is an identifier for the volume, a 24-bit number. It's up
|
||||
to the caller to allocate and manage these identifiers. If the
|
||||
identifier is already in use, the message will fail with -EEXIST.
|
||||
|
||||
ii) Using a thinly-provisioned volume.
|
||||
|
||||
Thinly-provisioned volumes are activated using the 'thin' target:
|
||||
|
||||
dmsetup create thin --table "0 2097152 thin /dev/mapper/pool 0"
|
||||
|
||||
The last parameter is the identifier for the thinp device.
|
||||
|
||||
Internal snapshots
|
||||
------------------
|
||||
|
||||
i) Creating an internal snapshot.
|
||||
|
||||
Snapshots are created with another message to the pool.
|
||||
|
||||
N.B. If the origin device that you wish to snapshot is active, you
|
||||
must suspend it before creating the snapshot to avoid corruption.
|
||||
This is NOT enforced at the moment, so please be careful!
|
||||
|
||||
dmsetup suspend /dev/mapper/thin
|
||||
dmsetup message /dev/mapper/pool 0 "create_snap 1 0"
|
||||
dmsetup resume /dev/mapper/thin
|
||||
|
||||
Here '1' is the identifier for the volume, a 24-bit number. '0' is the
|
||||
identifier for the origin device.
|
||||
|
||||
ii) Using an internal snapshot.
|
||||
|
||||
Once created, the user doesn't have to worry about any connection
|
||||
between the origin and the snapshot. Indeed the snapshot is no
|
||||
different from any other thinly-provisioned device and can be
|
||||
snapshotted itself via the same method. It's perfectly legal to
|
||||
have only one of them active, and there's no ordering requirement on
|
||||
activating or removing them both. (This differs from conventional
|
||||
device-mapper snapshots.)
|
||||
|
||||
Activate it exactly the same way as any other thinly-provisioned volume:
|
||||
|
||||
dmsetup create snap --table "0 2097152 thin /dev/mapper/pool 1"
|
||||
|
||||
Deactivation
|
||||
------------
|
||||
|
||||
All devices using a pool must be deactivated before the pool itself
|
||||
can be.
|
||||
|
||||
dmsetup remove thin
|
||||
dmsetup remove snap
|
||||
dmsetup remove pool
|
||||
|
||||
Reference
|
||||
=========
|
||||
|
||||
'thin-pool' target
|
||||
------------------
|
||||
|
||||
i) Constructor
|
||||
|
||||
thin-pool <metadata dev> <data dev> <data block size (sectors)> \
|
||||
<low water mark (blocks)> [<number of feature args> [<arg>]*]
|
||||
|
||||
Optional feature arguments:
|
||||
- 'skip_block_zeroing': skips the zeroing of newly-provisioned blocks.
|
||||
|
||||
Data block size must be between 64KB (128 sectors) and 1GB
|
||||
(2097152 sectors) inclusive.
|
||||
|
||||
|
||||
ii) Status
|
||||
|
||||
<transaction id> <used metadata blocks>/<total metadata blocks>
|
||||
<used data blocks>/<total data blocks> <held metadata root>
|
||||
|
||||
|
||||
transaction id:
|
||||
A 64-bit number used by userspace to help synchronise with metadata
|
||||
from volume managers.
|
||||
|
||||
used data blocks / total data blocks
|
||||
If the number of free blocks drops below the pool's low water mark a
|
||||
dm event will be sent to userspace. This event is edge-triggered and
|
||||
it will occur only once after each resume so volume manager writers
|
||||
should register for the event and then check the target's status.
|
||||
|
||||
held metadata root:
|
||||
The location, in sectors, of the metadata root that has been
|
||||
'held' for userspace read access. '-' indicates there is no
|
||||
held root. This feature is not yet implemented so '-' is
|
||||
always returned.
|
||||
|
||||
iii) Messages
|
||||
|
||||
create_thin <dev id>
|
||||
|
||||
Create a new thinly-provisioned device.
|
||||
<dev id> is an arbitrary unique 24-bit identifier chosen by
|
||||
the caller.
|
||||
|
||||
create_snap <dev id> <origin id>
|
||||
|
||||
Create a new snapshot of another thinly-provisioned device.
|
||||
<dev id> is an arbitrary unique 24-bit identifier chosen by
|
||||
the caller.
|
||||
<origin id> is the identifier of the thinly-provisioned device
|
||||
of which the new device will be a snapshot.
|
||||
|
||||
delete <dev id>
|
||||
|
||||
Deletes a thin device. Irreversible.
|
||||
|
||||
trim <dev id> <new size in sectors>
|
||||
|
||||
Delete mappings from the end of a thin device. Irreversible.
|
||||
You might want to use this if you're reducing the size of
|
||||
your thinly-provisioned device. In many cases, due to the
|
||||
sharing of blocks between devices, it is not possible to
|
||||
determine in advance how much space 'trim' will release. (In
|
||||
future a userspace tool might be able to perform this
|
||||
calculation.)
|
||||
|
||||
set_transaction_id <current id> <new id>
|
||||
|
||||
Userland volume managers, such as LVM, need a way to
|
||||
synchronise their external metadata with the internal metadata of the
|
||||
pool target. The thin-pool target offers to store an
|
||||
arbitrary 64-bit transaction id and return it on the target's
|
||||
status line. To avoid races you must provide what you think
|
||||
the current transaction id is when you change it with this
|
||||
compare-and-swap message.
|
||||
|
||||
'thin' target
|
||||
-------------
|
||||
|
||||
i) Constructor
|
||||
|
||||
thin <pool dev> <dev id>
|
||||
|
||||
pool dev:
|
||||
the thin-pool device, e.g. /dev/mapper/my_pool or 253:0
|
||||
|
||||
dev id:
|
||||
the internal device identifier of the device to be
|
||||
activated.
|
||||
|
||||
The pool doesn't store any size against the thin devices. If you
|
||||
load a thin target that is smaller than you've been using previously,
|
||||
then you'll have no access to blocks mapped beyond the end. If you
|
||||
load a target that is bigger than before, then extra blocks will be
|
||||
provisioned as and when needed.
|
||||
|
||||
If you wish to reduce the size of your thin device and potentially
|
||||
regain some space then send the 'trim' message to the pool.
|
||||
|
||||
ii) Status
|
||||
|
||||
<nr mapped sectors> <highest mapped sector>
|
||||
@@ -0,0 +1,8 @@
|
||||
Calxeda Highbank Platforms Device Tree Bindings
|
||||
-----------------------------------------------
|
||||
|
||||
Boards with Calxeda Cortex-A9 based Highbank SOC shall have the following
|
||||
properties.
|
||||
|
||||
Required root node properties:
|
||||
- compatible = "calxeda,highbank";
|
||||
@@ -0,0 +1,26 @@
|
||||
Freescale i.MX Platforms Device Tree Bindings
|
||||
-----------------------------------------------
|
||||
|
||||
i.MX51 Babbage Board
|
||||
Required root node properties:
|
||||
- compatible = "fsl,imx51-babbage", "fsl,imx51";
|
||||
|
||||
i.MX53 Automotive Reference Design Board
|
||||
Required root node properties:
|
||||
- compatible = "fsl,imx53-ard", "fsl,imx53";
|
||||
|
||||
i.MX53 Evaluation Kit
|
||||
Required root node properties:
|
||||
- compatible = "fsl,imx53-evk", "fsl,imx53";
|
||||
|
||||
i.MX53 Quick Start Board
|
||||
Required root node properties:
|
||||
- compatible = "fsl,imx53-qsb", "fsl,imx53";
|
||||
|
||||
i.MX53 Smart Mobile Reference Design Board
|
||||
Required root node properties:
|
||||
- compatible = "fsl,imx53-smd", "fsl,imx53";
|
||||
|
||||
i.MX6 Quad SABRE Automotive Board
|
||||
Required root node properties:
|
||||
- compatible = "fsl,imx6q-sabreauto", "fsl,imx6q";
|
||||
@@ -0,0 +1,55 @@
|
||||
* ARM Generic Interrupt Controller
|
||||
|
||||
ARM SMP cores are often associated with a GIC, providing per processor
|
||||
interrupts (PPI), shared processor interrupts (SPI) and software
|
||||
generated interrupts (SGI).
|
||||
|
||||
Primary GIC is attached directly to the CPU and typically has PPIs and SGIs.
|
||||
Secondary GICs are cascaded into the upward interrupt controller and do not
|
||||
have PPIs or SGIs.
|
||||
|
||||
Main node required properties:
|
||||
|
||||
- compatible : should be one of:
|
||||
"arm,cortex-a9-gic"
|
||||
"arm,arm11mp-gic"
|
||||
- interrupt-controller : Identifies the node as an interrupt controller
|
||||
- #interrupt-cells : Specifies the number of cells needed to encode an
|
||||
interrupt source. The type shall be a <u32> and the value shall be 3.
|
||||
|
||||
The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI
|
||||
interrupts.
|
||||
|
||||
The 2nd cell contains the interrupt number for the interrupt type.
|
||||
SPI interrupts are in the range [0-987]. PPI interrupts are in the
|
||||
range [0-15].
|
||||
|
||||
The 3rd cell is the flags, encoded as follows:
|
||||
bits[3:0] trigger type and level flags.
|
||||
1 = low-to-high edge triggered
|
||||
2 = high-to-low edge triggered
|
||||
4 = active high level-sensitive
|
||||
8 = active low level-sensitive
|
||||
bits[15:8] PPI interrupt cpu mask. Each bit corresponds to each of
|
||||
the 8 possible cpus attached to the GIC. A bit set to '1' indicated
|
||||
the interrupt is wired to that CPU. Only valid for PPI interrupts.
|
||||
|
||||
- reg : Specifies base physical address(s) and size of the GIC registers. The
|
||||
first region is the GIC distributor register base and size. The 2nd region is
|
||||
the GIC cpu interface register base and size.
|
||||
|
||||
Optional
|
||||
- interrupts : Interrupt source of the parent interrupt controller. Only
|
||||
present on secondary GICs.
|
||||
|
||||
Example:
|
||||
|
||||
intc: interrupt-controller@fff11000 {
|
||||
compatible = "arm,cortex-a9-gic";
|
||||
#interrupt-cells = <3>;
|
||||
#address-cells = <1>;
|
||||
interrupt-controller;
|
||||
reg = <0xfff11000 0x1000>,
|
||||
<0xfff10100 0x100>;
|
||||
};
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user