asgardius/android_kernel_motorola_sm6225
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Merge branch 'sched/urgent' into sched/core

Browse source 
Merge in fixes before applying ongoing new work.

Signed-off-by: Ingo Molnar <mingo@kernel.org>
This commit is contained in:
Ingo Molnar 2013-06-19 12:55:31 +02:00
commit d81344c508
2751 changed files with 127011 additions and 45059 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

156
Documentation/ABI/testing/sysfs-block-bcache Normal file
View file

@ -0,0 +1,156 @@
What: /sys/block/<disk>/bcache/unregister
Date: November 2010
Contact: Kent Overstreet <kent.overstreet@gmail.com>
Description:
A write to this file causes the backing device or cache to be
unregistered. If a backing device had dirty data in the cache,
writeback mode is automatically disabled and all dirty data is
flushed before the device is unregistered. Caches unregister
all associated backing devices before unregistering themselves.
What: /sys/block/<disk>/bcache/clear_stats
Date: November 2010
Contact: Kent Overstreet <kent.overstreet@gmail.com>
Description:
Writing to this file resets all the statistics for the device.
What: /sys/block/<disk>/bcache/cache
Date: November 2010
Contact: Kent Overstreet <kent.overstreet@gmail.com>
Description:
For a backing device that has cache, a symlink to
the bcache/ dir of that cache.
What: /sys/block/<disk>/bcache/cache_hits
Date: November 2010
Contact: Kent Overstreet <kent.overstreet@gmail.com>
Description:
For backing devices: integer number of full cache hits,
counted per bio. A partial cache hit counts as a miss.
What: /sys/block/<disk>/bcache/cache_misses
Date: November 2010
Contact: Kent Overstreet <kent.overstreet@gmail.com>
Description:
For backing devices: integer number of cache misses.
What: /sys/block/<disk>/bcache/cache_hit_ratio
Date: November 2010
Contact: Kent Overstreet <kent.overstreet@gmail.com>
Description:
For backing devices: cache hits as a percentage.
What: /sys/block/<disk>/bcache/sequential_cutoff
Date: November 2010
Contact: Kent Overstreet <kent.overstreet@gmail.com>
Description:
For backing devices: Threshold past which sequential IO will
skip the cache. Read and written as bytes in human readable
units (i.e. echo 10M > sequntial_cutoff).
What: /sys/block/<disk>/bcache/bypassed
Date: November 2010
Contact: Kent Overstreet <kent.overstreet@gmail.com>
Description:
Sum of all reads and writes that have bypassed the cache (due
to the sequential cutoff). Expressed as bytes in human
readable units.
What: /sys/block/<disk>/bcache/writeback
Date: November 2010
Contact: Kent Overstreet <kent.overstreet@gmail.com>
Description:
For backing devices: When on, writeback caching is enabled and
writes will be buffered in the cache. When off, caching is in
writethrough mode; reads and writes will be added to the
cache but no write buffering will take place.
What: /sys/block/<disk>/bcache/writeback_running
Date: November 2010
Contact: Kent Overstreet <kent.overstreet@gmail.com>
Description:
For backing devices: when off, dirty data will not be written
from the cache to the backing device. The cache will still be
used to buffer writes until it is mostly full, at which point
writes transparently revert to writethrough mode. Intended only
for benchmarking/testing.
What: /sys/block/<disk>/bcache/writeback_delay
Date: November 2010
Contact: Kent Overstreet <kent.overstreet@gmail.com>
Description:
For backing devices: In writeback mode, when dirty data is
written to the cache and the cache held no dirty data for that
backing device, writeback from cache to backing device starts
after this delay, expressed as an integer number of seconds.
What: /sys/block/<disk>/bcache/writeback_percent
Date: November 2010
Contact: Kent Overstreet <kent.overstreet@gmail.com>
Description:
For backing devices: If nonzero, writeback from cache to
backing device only takes place when more than this percentage
of the cache is used, allowing more write coalescing to take
place and reducing total number of writes sent to the backing
device. Integer between 0 and 40.
What: /sys/block/<disk>/bcache/synchronous
Date: November 2010
Contact: Kent Overstreet <kent.overstreet@gmail.com>
Description:
For a cache, a boolean that allows synchronous mode to be
switched on and off. In synchronous mode all writes are ordered
such that the cache can reliably recover from unclean shutdown;
if disabled bcache will not generally wait for writes to
complete but if the cache is not shut down cleanly all data
will be discarded from the cache. Should not be turned off with
writeback caching enabled.
What: /sys/block/<disk>/bcache/discard
Date: November 2010
Contact: Kent Overstreet <kent.overstreet@gmail.com>
Description:
For a cache, a boolean allowing discard/TRIM to be turned off
or back on if the device supports it.
What: /sys/block/<disk>/bcache/bucket_size
Date: November 2010
Contact: Kent Overstreet <kent.overstreet@gmail.com>
Description:
For a cache, bucket size in human readable units, as set at
cache creation time; should match the erase block size of the
SSD for optimal performance.
What: /sys/block/<disk>/bcache/nbuckets
Date: November 2010
Contact: Kent Overstreet <kent.overstreet@gmail.com>
Description:
For a cache, the number of usable buckets.
What: /sys/block/<disk>/bcache/tree_depth
Date: November 2010
Contact: Kent Overstreet <kent.overstreet@gmail.com>
Description:
For a cache, height of the btree excluding leaf nodes (i.e. a
one node tree will have a depth of 0).
What: /sys/block/<disk>/bcache/btree_cache_size
Date: November 2010
Contact: Kent Overstreet <kent.overstreet@gmail.com>
Description:
Number of btree buckets/nodes that are currently cached in
memory; cache dynamically grows and shrinks in response to
memory pressure from the rest of the system.
What: /sys/block/<disk>/bcache/written
Date: November 2010
Contact: Kent Overstreet <kent.overstreet@gmail.com>
Description:
For a cache, total amount of data in human readable units
written to the cache, excluding all metadata.
What: /sys/block/<disk>/bcache/btree_written
Date: November 2010
Contact: Kent Overstreet <kent.overstreet@gmail.com>
Description:
For a cache, sum of all btree writes in human readable units.

20
Documentation/ABI/testing/sysfs-bus-rbd
View file

@ -66,27 +66,7 @@ current_snap
The current snapshot for which the device is mapped.
snap_*
A directory per each snapshot
parent
Information identifying the pool, image, and snapshot id for
the parent image in a layered rbd image (format 2 only).
Entries under /sys/bus/rbd/devices/<dev-id>/snap_<snap-name>
-------------------------------------------------------------
snap_id
The rados internal snapshot id assigned for this snapshot
snap_size
The size of the image when this snapshot was taken.
snap_features
A hexadecimal encoding of the feature bits for this snapshot.

6
Documentation/ABI/testing/sysfs-class-mtd
View file

@ -14,8 +14,7 @@ Description:
The /sys/class/mtd/mtd{0,1,2,3,...} directories correspond
to each /dev/mtdX character device. These may represent
physical/simulated flash devices, partitions on a flash
device, or concatenated flash devices. They exist regardless
of whether CONFIG_MTD_CHAR is actually enabled.
device, or concatenated flash devices.
What: /sys/class/mtd/mtdXro/
Date: April 2009
@ -23,8 +22,7 @@ KernelVersion: 2.6.29
Contact: linux-mtd@lists.infradead.org
Description:
These directories provide the corresponding read-only device
nodes for /sys/class/mtd/mtdX/ . They are only created
(for the benefit of udev) if CONFIG_MTD_CHAR is enabled.
nodes for /sys/class/mtd/mtdX/ .
What: /sys/class/mtd/mtdX/dev
Date: April 2009

109
Documentation/acpi/enumeration.txt
View file

@ -66,6 +66,83 @@ the ACPI device explicitly to acpi_platform_device_ids list defined in
drivers/acpi/acpi_platform.c. This limitation is only for the platform
devices, SPI and I2C devices are created automatically as described below.
DMA support
~~~~~~~~~~~
DMA controllers enumerated via ACPI should be registered in the system to
provide generic access to their resources. For example, a driver that would
like to be accessible to slave devices via generic API call
dma_request_slave_channel() must register itself at the end of the probe
function like this:
err = devm_acpi_dma_controller_register(dev, xlate_func, dw);
/* Handle the error if it's not a case of !CONFIG_ACPI */
and implement custom xlate function if needed (usually acpi_dma_simple_xlate()
is enough) which converts the FixedDMA resource provided by struct
acpi_dma_spec into the corresponding DMA channel. A piece of code for that case
could look like:
#ifdef CONFIG_ACPI
struct filter_args {
/* Provide necessary information for the filter_func */
...
};
static bool filter_func(struct dma_chan *chan, void *param)
{
/* Choose the proper channel */
...
}
static struct dma_chan *xlate_func(struct acpi_dma_spec *dma_spec,
struct acpi_dma *adma)
{
dma_cap_mask_t cap;
struct filter_args args;
/* Prepare arguments for filter_func */
...
return dma_request_channel(cap, filter_func, &args);
}
#else
static struct dma_chan *xlate_func(struct acpi_dma_spec *dma_spec,
struct acpi_dma *adma)
{
return NULL;
}
#endif
dma_request_slave_channel() will call xlate_func() for each registered DMA
controller. In the xlate function the proper channel must be chosen based on
information in struct acpi_dma_spec and the properties of the controller
provided by struct acpi_dma.
Clients must call dma_request_slave_channel() with the string parameter that
corresponds to a specific FixedDMA resource. By default "tx" means the first
entry of the FixedDMA resource array, "rx" means the second entry. The table
below shows a layout:
Device (I2C0)
{
...
Method (_CRS, 0, NotSerialized)
{
Name (DBUF, ResourceTemplate ()
{
FixedDMA (0x0018, 0x0004, Width32bit, _Y48)
FixedDMA (0x0019, 0x0005, Width32bit, )
})
...
}
}
So, the FixedDMA with request line 0x0018 is "tx" and next one is "rx" in
this example.
In robust cases the client unfortunately needs to call
acpi_dma_request_slave_chan_by_index() directly and therefore choose the
specific FixedDMA resource by its index.
SPI serial bus support
~~~~~~~~~~~~~~~~~~~~~~
Slave devices behind SPI bus have SpiSerialBus resource attached to them.
@ -199,6 +276,8 @@ the device to the driver. For example:
{
Name (SBUF, ResourceTemplate()
{
...
// Used to power on/off the device
GpioIo (Exclusive, PullDefault, 0x0000, 0x0000,
IoRestrictionOutputOnly, "\\_SB.PCI0.GPI0",
0x00, ResourceConsumer,,)
@ -206,10 +285,20 @@ the device to the driver. For example:
// Pin List
0x0055
}
// Interrupt for the device
GpioInt (Edge, ActiveHigh, ExclusiveAndWake, PullNone,
0x0000, "\\_SB.PCI0.GPI0", 0x00, ResourceConsumer,,)
{
// Pin list
0x0058
}
...
Return (SBUF)
}
Return (SBUF)
}
These GPIO numbers are controller relative and path "\\_SB.PCI0.GPI0"
@ -220,6 +309,24 @@ 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
device resources list. For example:
int gpio_irq, gpio_power;
int ret;
gpio_irq = acpi_get_gpio_by_index(dev, 1, NULL);
if (gpio_irq < 0)
/* handle error */
gpio_power = acpi_get_gpio_by_index(dev, 0, NULL);
if (gpio_power < 0)
/* handle error */
/* Now we can use the GPIO numbers */
Other GpioIo parameters must be converted first by the driver to be
suitable to the gpiolib before passing them.

431
Documentation/bcache.txt Normal file
View file

@ -0,0 +1,431 @@
Say you've got a big slow raid 6, and an X-25E or three. Wouldn't it be
nice if you could use them as cache... Hence bcache.
Wiki and git repositories are at:
http://bcache.evilpiepirate.org
http://evilpiepirate.org/git/linux-bcache.git
http://evilpiepirate.org/git/bcache-tools.git
It's designed around the performance characteristics of SSDs - it only allocates
in erase block sized buckets, and it uses a hybrid btree/log to track cached
extants (which can be anywhere from a single sector to the bucket size). It's
designed to avoid random writes at all costs; it fills up an erase block
sequentially, then issues a discard before reusing it.
Both writethrough and writeback caching are supported. Writeback defaults to
off, but can be switched on and off arbitrarily at runtime. Bcache goes to
great lengths to protect your data - it reliably handles unclean shutdown. (It
doesn't even have a notion of a clean shutdown; bcache simply doesn't return
writes as completed until they're on stable storage).
Writeback caching can use most of the cache for buffering writes - writing
dirty data to the backing device is always done sequentially, scanning from the
start to the end of the index.
Since random IO is what SSDs excel at, there generally won't be much benefit
to caching large sequential IO. Bcache detects sequential IO and skips it;
it also keeps a rolling average of the IO sizes per task, and as long as the
average is above the cutoff it will skip all IO from that task - instead of
caching the first 512k after every seek. Backups and large file copies should
thus entirely bypass the cache.
In the event of a data IO error on the flash it will try to recover by reading
from disk or invalidating cache entries. For unrecoverable errors (meta data
or dirty data), caching is automatically disabled; if dirty data was present
in the cache it first disables writeback caching and waits for all dirty data
to be flushed.
Getting started:
You'll need make-bcache from the bcache-tools repository. Both the cache device
and backing device must be formatted before use.
make-bcache -B /dev/sdb
make-bcache -C /dev/sdc
make-bcache has the ability to format multiple devices at the same time - if
you format your backing devices and cache device at the same time, you won't
have to manually attach:
make-bcache -B /dev/sda /dev/sdb -C /dev/sdc
To make bcache devices known to the kernel, echo them to /sys/fs/bcache/register:
echo /dev/sdb > /sys/fs/bcache/register
echo /dev/sdc > /sys/fs/bcache/register
To register your bcache devices automatically, you could add something like
this to an init script:
echo /dev/sd* > /sys/fs/bcache/register_quiet
It'll look for bcache superblocks and ignore everything that doesn't have one.
Registering the backing device makes the bcache show up in /dev; you can now
format it and use it as normal. But the first time using a new bcache device,
it'll be running in passthrough mode until you attach it to a cache. See the
section on attaching.
The devices show up at /dev/bcacheN, and can be controlled via sysfs from
/sys/block/bcacheN/bcache:
mkfs.ext4 /dev/bcache0
mount /dev/bcache0 /mnt
Cache devices are managed as sets; multiple caches per set isn't supported yet
but will allow for mirroring of metadata and dirty data in the future. Your new
cache set shows up as /sys/fs/bcache/<UUID>
ATTACHING:
After your cache device and backing device are registered, the backing device
must be attached to your cache set to enable caching. Attaching a backing
device to a cache set is done thusly, with the UUID of the cache set in
/sys/fs/bcache:
echo <UUID> > /sys/block/bcache0/bcache/attach
This only has to be done once. The next time you reboot, just reregister all
your bcache devices. If a backing device has data in a cache somewhere, the
/dev/bcache# device won't be created until the cache shows up - particularly
important if you have writeback caching turned on.
If you're booting up and your cache device is gone and never coming back, you
can force run the backing device:
echo 1 > /sys/block/sdb/bcache/running
(You need to use /sys/block/sdb (or whatever your backing device is called), not
/sys/block/bcache0, because bcache0 doesn't exist yet. If you're using a
partition, the bcache directory would be at /sys/block/sdb/sdb2/bcache)
The backing device will still use that cache set if it shows up in the future,
but all the cached data will be invalidated. If there was dirty data in the
cache, don't expect the filesystem to be recoverable - you will have massive
filesystem corruption, though ext4's fsck does work miracles.
ERROR HANDLING:
Bcache tries to transparently handle IO errors to/from the cache device without
affecting normal operation; if it sees too many errors (the threshold is
configurable, and defaults to 0) it shuts down the cache device and switches all
the backing devices to passthrough mode.
- For reads from the cache, if they error we just retry the read from the
backing device.
- For writethrough writes, if the write to the cache errors we just switch to
invalidating the data at that lba in the cache (i.e. the same thing we do for
a write that bypasses the cache)
- For writeback writes, we currently pass that error back up to the
filesystem/userspace. This could be improved - we could retry it as a write
that skips the cache so we don't have to error the write.
- When we detach, we first try to flush any dirty data (if we were running in
writeback mode). It currently doesn't do anything intelligent if it fails to
read some of the dirty data, though.
TROUBLESHOOTING PERFORMANCE:
Bcache has a bunch of config options and tunables. The defaults are intended to
be reasonable for typical desktop and server workloads, but they're not what you
want for getting the best possible numbers when benchmarking.
- Bad write performance
If write performance is not what you expected, you probably wanted to be
running in writeback mode, which isn't the default (not due to a lack of
maturity, but simply because in writeback mode you'll lose data if something
happens to your SSD)
# echo writeback > /sys/block/bcache0/cache_mode
- Bad performance, or traffic not going to the SSD that you'd expect
By default, bcache doesn't cache everything. It tries to skip sequential IO -
because you really want to be caching the random IO, and if you copy a 10
gigabyte file you probably don't want that pushing 10 gigabytes of randomly
accessed data out of your cache.
But if you want to benchmark reads from cache, and you start out with fio
writing an 8 gigabyte test file - so you want to disable that.
# echo 0 > /sys/block/bcache0/bcache/sequential_cutoff
To set it back to the default (4 mb), do
# echo 4M > /sys/block/bcache0/bcache/sequential_cutoff
- Traffic's still going to the spindle/still getting cache misses
In the real world, SSDs don't always keep up with disks - particularly with
slower SSDs, many disks being cached by one SSD, or mostly sequential IO. So
you want to avoid being bottlenecked by the SSD and having it slow everything
down.
To avoid that bcache tracks latency to the cache device, and gradually
throttles traffic if the latency exceeds a threshold (it does this by
cranking down the sequential bypass).
You can disable this if you need to by setting the thresholds to 0:
# echo 0 > /sys/fs/bcache/<cache set>/congested_read_threshold_us
# echo 0 > /sys/fs/bcache/<cache set>/congested_write_threshold_us
The default is 2000 us (2 milliseconds) for reads, and 20000 for writes.
- Still getting cache misses, of the same data
One last issue that sometimes trips people up is actually an old bug, due to
the way cache coherency is handled for cache misses. If a btree node is full,
a cache miss won't be able to insert a key for the new data and the data
won't be written to the cache.
In practice this isn't an issue because as soon as a write comes along it'll
cause the btree node to be split, and you need almost no write traffic for
this to not show up enough to be noticable (especially since bcache's btree
nodes are huge and index large regions of the device). But when you're
benchmarking, if you're trying to warm the cache by reading a bunch of data
and there's no other traffic - that can be a problem.
Solution: warm the cache by doing writes, or use the testing branch (there's
a fix for the issue there).
SYSFS - BACKING DEVICE:
attach
Echo the UUID of a cache set to this file to enable caching.
cache_mode
Can be one of either writethrough, writeback, writearound or none.
clear_stats
Writing to this file resets the running total stats (not the day/hour/5 minute
decaying versions).
detach
Write to this file to detach from a cache set. If there is dirty data in the
cache, it will be flushed first.
dirty_data
Amount of dirty data for this backing device in the cache. Continuously
updated unlike the cache set's version, but may be slightly off.
label
Name of underlying device.
readahead
Size of readahead that should be performed. Defaults to 0. If set to e.g.
1M, it will round cache miss reads up to that size, but without overlapping
existing cache entries.
running
1 if bcache is running (i.e. whether the /dev/bcache device exists, whether
it's in passthrough mode or caching).
sequential_cutoff
A sequential IO will bypass the cache once it passes this threshhold; the
most recent 128 IOs are tracked so sequential IO can be detected even when
it isn't all done at once.
sequential_merge
If non zero, bcache keeps a list of the last 128 requests submitted to compare
against all new requests to determine which new requests are sequential
continuations of previous requests for the purpose of determining sequential
cutoff. This is necessary if the sequential cutoff value is greater than the
maximum acceptable sequential size for any single request.
state
The backing device can be in one of four different states:
no cache: Has never been attached to a cache set.
clean: Part of a cache set, and there is no cached dirty data.
dirty: Part of a cache set, and there is cached dirty data.
inconsistent: The backing device was forcibly run by the user when there was
dirty data cached but the cache set was unavailable; whatever data was on the
backing device has likely been corrupted.
stop
Write to this file to shut down the bcache device and close the backing
device.
writeback_delay
When dirty data is written to the cache and it previously did not contain
any, waits some number of seconds before initiating writeback. Defaults to
30.
writeback_percent
If nonzero, bcache tries to keep around this percentage of the cache dirty by
throttling background writeback and using a PD controller to smoothly adjust
the rate.
writeback_rate
Rate in sectors per second - if writeback_percent is nonzero, background
writeback is throttled to this rate. Continuously adjusted by bcache but may
also be set by the user.
writeback_running
If off, writeback of dirty data will not take place at all. Dirty data will
still be added to the cache until it is mostly full; only meant for
benchmarking. Defaults to on.
SYSFS - BACKING DEVICE STATS:
There are directories with these numbers for a running total, as well as
versions that decay over the past day, hour and 5 minutes; they're also
aggregated in the cache set directory as well.
bypassed
Amount of IO (both reads and writes) that has bypassed the cache
cache_hits
cache_misses
cache_hit_ratio
Hits and misses are counted per individual IO as bcache sees them; a
partial hit is counted as a miss.
cache_bypass_hits
cache_bypass_misses
Hits and misses for IO that is intended to skip the cache are still counted,
but broken out here.
cache_miss_collisions
Counts instances where data was going to be inserted into the cache from a
cache miss, but raced with a write and data was already present (usually 0
since the synchronization for cache misses was rewritten)
cache_readaheads
Count of times readahead occured.
SYSFS - CACHE SET:
average_key_size
Average data per key in the btree.
bdev<0..n>
Symlink to each of the attached backing devices.
block_size
Block size of the cache devices.
btree_cache_size
Amount of memory currently used by the btree cache
bucket_size
Size of buckets
cache<0..n>
Symlink to each of the cache devices comprising this cache set.
cache_available_percent
Percentage of cache device free.
clear_stats
Clears the statistics associated with this cache
dirty_data
Amount of dirty data is in the cache (updated when garbage collection runs).
flash_vol_create
Echoing a size to this file (in human readable units, k/M/G) creates a thinly
provisioned volume backed by the cache set.
io_error_halflife
io_error_limit
These determines how many errors we accept before disabling the cache.
Each error is decayed by the half life (in # ios). If the decaying count
reaches io_error_limit dirty data is written out and the cache is disabled.
journal_delay_ms
Journal writes will delay for up to this many milliseconds, unless a cache
flush happens sooner. Defaults to 100.
root_usage_percent
Percentage of the root btree node in use. If this gets too high the node
will split, increasing the tree depth.
stop
Write to this file to shut down the cache set - waits until all attached
backing devices have been shut down.
tree_depth
Depth of the btree (A single node btree has depth 0).
unregister
Detaches all backing devices and closes the cache devices; if dirty data is
present it will disable writeback caching and wait for it to be flushed.
SYSFS - CACHE SET INTERNAL:
This directory also exposes timings for a number of internal operations, with
separate files for average duration, average frequency, last occurence and max
duration: garbage collection, btree read, btree node sorts and btree splits.
active_journal_entries
Number of journal entries that are newer than the index.
btree_nodes
Total nodes in the btree.
btree_used_percent
Average fraction of btree in use.
bset_tree_stats
Statistics about the auxiliary search trees
btree_cache_max_chain
Longest chain in the btree node cache's hash table
cache_read_races
Counts instances where while data was being read from the cache, the bucket
was reused and invalidated - i.e. where the pointer was stale after the read
completed. When this occurs the data is reread from the backing device.
trigger_gc
Writing to this file forces garbage collection to run.
SYSFS - CACHE DEVICE:
block_size
Minimum granularity of writes - should match hardware sector size.
btree_written
Sum of all btree writes, in (kilo/mega/giga) bytes
bucket_size
Size of buckets
cache_replacement_policy
One of either lru, fifo or random.
discard
Boolean; if on a discard/TRIM will be issued to each bucket before it is
reused. Defaults to off, since SATA TRIM is an unqueued command (and thus
slow).
freelist_percent
Size of the freelist as a percentage of nbuckets. Can be written to to
increase the number of buckets kept on the freelist, which lets you
artificially reduce the size of the cache at runtime. Mostly for testing
purposes (i.e. testing how different size caches affect your hit rate), but
since buckets are discarded when they move on to the freelist will also make
the SSD's garbage collection easier by effectively giving it more reserved
space.
io_errors
Number of errors that have occured, decayed by io_error_halflife.
metadata_written
Sum of all non data writes (btree writes and all other metadata).
nbuckets
Total buckets in this cache
priority_stats
Statistics about how recently data in the cache has been accessed. This can
reveal your working set size.
written
Sum of all data that has been written to the cache; comparison with
btree_written gives the amount of write inflation in bcache.

47
Documentation/block/cfq-iosched.txt
View file

@ -5,7 +5,7 @@ The main aim of CFQ scheduler is to provide a fair allocation of the disk
I/O bandwidth for all the processes which requests an I/O operation.
CFQ maintains the per process queue for the processes which request I/O
operation(syncronous requests). In case of asynchronous requests, all the
operation(synchronous requests). In case of asynchronous requests, all the
requests from all the processes are batched together according to their
process's I/O priority.
@ -66,6 +66,47 @@ This parameter is used to set the timeout of synchronous requests. Default
value of this is 124ms. In case to favor synchronous requests over asynchronous
one, this value should be decreased relative to fifo_expire_async.
group_idle
-----------
This parameter forces idling at the CFQ group level instead of CFQ
queue level. This was introduced after after a bottleneck was observed
in higher end storage due to idle on sequential queue and allow dispatch
from a single queue. The idea with this parameter is that it can be run with
slice_idle=0 and group_idle=8, so that idling does not happen on individual
queues in the group but happens overall on the group and thus still keeps the
IO controller working.
Not idling on individual queues in the group will dispatch requests from
multiple queues in the group at the same time and achieve higher throughput
on higher end storage.
Default value for this parameter is 8ms.
latency
-------
This parameter is used to enable/disable the latency mode of the CFQ
scheduler. If latency mode (called low_latency) is enabled, CFQ tries
to recompute the slice time for each process based on the target_latency set
for the system. This favors fairness over throughput. Disabling low
latency (setting it to 0) ignores target latency, allowing each process in the
system to get a full time slice.
By default low latency mode is enabled.
target_latency
--------------
This parameter is used to calculate the time slice for a process if cfq's
latency mode is enabled. It will ensure that sync requests have an estimated
latency. But if sequential workload is higher(e.g. sequential read),
then to meet the latency constraints, throughput may decrease because of less
time for each process to issue I/O request before the cfq queue is switched.
Though this can be overcome by disabling the latency_mode, it may increase
the read latency for some applications. This parameter allows for changing
target_latency through the sysfs interface which can provide the balanced
throughput and read latency.
Default value for target_latency is 300ms.
slice_async
-----------
This parameter is same as of slice_sync but for asynchronous queue. The
@ -98,8 +139,8 @@ in the device exceeds this parameter. This parameter is used for synchronous
request.
In case of storage with several disk, this setting can limit the parallel
processing of request. Therefore, increasing the value can imporve the
performace although this can cause the latency of some I/O to increase due
processing of request. Therefore, increasing the value can improve the
performance although this can cause the latency of some I/O to increase due
to more number of requests.
CFQ Group scheduling

4
Documentation/cgroups/memory.txt
View file

@ -480,7 +480,9 @@ memory.stat file includes following statistics
# per-memory cgroup local status
cache - # of bytes of page cache memory.
rss - # of bytes of anonymous and swap cache memory.
rss - # of bytes of anonymous and swap cache memory (includes
transparent hugepages).
rss_huge - # of bytes of anonymous transparent hugepages.
mapped_file - # of bytes of mapped file (includes tmpfs/shmem)
pgpgin - # of charging events to the memory cgroup. The charging
event happens each time a page is accounted as either mapped

9
Documentation/coccinelle.txt
View file

@ -134,6 +134,15 @@ MODE variable explained above.
In this mode, there is no information about semantic patches
displayed, and no commit message proposed.
Additional flags
~~~~~~~~~~~~~~~~~~
Additional flags can be passed to spatch through the SPFLAGS
variable.
make SPFLAGS=--use_glimpse coccicheck
See spatch --help to learn more about spatch options.
Proposing new semantic patches
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1
Documentation/devicetree/bindings/arm/omap/l3-noc.txt
View file

@ -6,6 +6,7 @@ provided by Arteris.
Required properties:
- compatible : Should be "ti,omap3-l3-smx" for OMAP3 family
Should be "ti,omap4-l3-noc" for OMAP4 family
- reg: Contains L3 register address range for each noc domain.
- ti,hwmods: "l3_main_1", ... One hwmod for each noc domain.
Examples:

17
Documentation/devicetree/bindings/arm/omap/timer.txt
View file

@ -1,7 +1,20 @@
OMAP Timer bindings
Required properties:
- compatible: Must be "ti,omap2-timer" for OMAP2+ controllers.
- compatible: Should be set to one of the below. Please note that
OMAP44xx devices have timer instances that are 100%
register compatible with OMAP3xxx devices as well as
newer timers that are not 100% register compatible.
So for OMAP44xx devices timer instances may use
different compatible strings.
ti,omap2420-timer (applicable to OMAP24xx devices)
ti,omap3430-timer (applicable to OMAP3xxx/44xx devices)
ti,omap4430-timer (applicable to OMAP44xx devices)
ti,omap5430-timer (applicable to OMAP543x devices)
ti,am335x-timer (applicable to AM335x devices)
ti,am335x-timer-1ms (applicable to AM335x devices)
- reg: Contains timer register address range (base address and
length).
- interrupts: Contains the interrupt information for the timer. The
@ -22,7 +35,7 @@ Optional properties:
Example:
timer12: timer@48304000 {
compatible = "ti,omap2-timer";
compatible = "ti,omap3430-timer";
reg = <0x48304000 0x400>;
interrupts = <95>;
ti,hwmods = "timer12"

17
Documentation/devicetree/bindings/arm/primecell.txt
View file

@ -16,14 +16,31 @@ Optional properties:
- clocks : From common clock binding. First clock is phandle to clock for apb
pclk. Additional clocks are optional and specific to those peripherals.
- clock-names : From common clock binding. Shall be "apb_pclk" for first clock.
- dmas : From common DMA binding. If present, refers to one or more dma channels.
- dma-names : From common DMA binding, needs to match the 'dmas' property.
Devices with exactly one receive and transmit channel shall name
these "rx" and "tx", respectively.
- pinctrl-<n> : Pinctrl states as described in bindings/pinctrl/pinctrl-bindings.txt
- pinctrl-names : Names corresponding to the numbered pinctrl states
- interrupts : one or more interrupt specifiers
- interrupt-names : names corresponding to the interrupts properties
Example:
serial@fff36000 {
compatible = "arm,pl011", "arm,primecell";
arm,primecell-periphid = <0x00341011>;
clocks = <&pclk>;
clock-names = "apb_pclk";
dmas = <&dma-controller 4>, <&dma-controller 5>;
dma-names = "rx", "tx";
pinctrl-0 = <&uart0_default_mux>, <&uart0_default_mode>;
pinctrl-1 = <&uart0_sleep_mode>;
pinctrl-names = "default","sleep";
interrupts = <0 11 0x4>;
};

7
Documentation/devicetree/bindings/arm/samsung/sysreg.txt Normal file
View file

@ -0,0 +1,7 @@
SAMSUNG S5P/Exynos SoC series System Registers (SYSREG)
Properties:
- name : should be 'sysreg';
- compatible : should contain "samsung,<chip name>-sysreg", "syscon";
For Exynos4 SoC series it should be "samsung,exynos4-sysreg", "syscon";
- reg : offset and length of the register set.

22
Documentation/devicetree/bindings/ata/pata-arasan.txt
View file

@ -6,6 +6,26 @@ Required properties:
- interrupt-parent: Should be the phandle for the interrupt controller
that services interrupts for this device
- interrupt: Should contain the CF interrupt number
- clock-frequency: Interface clock rate, in Hz, one of
25000000
33000000
40000000
50000000
66000000
75000000
100000000
125000000
150000000
166000000
200000000
Optional properties:
- arasan,broken-udma: if present, UDMA mode is unusable
- arasan,broken-mwdma: if present, MWDMA mode is unusable
- arasan,broken-pio: if present, PIO mode is unusable
- dmas: one DMA channel, as described in bindings/dma/dma.txt
required unless both UDMA and MWDMA mode are broken
- dma-names: the corresponding channel name, must be "data"
Example:
@ -14,4 +34,6 @@ Example:
reg = <0xfc000000 0x1000>;
interrupt-parent = <&vic1>;
interrupts = <12>;
dmas = <&dma-controller 23>;
dma-names = "data";
};

14
Documentation/devicetree/bindings/clock/imx5-clock.txt
View file

@ -38,7 +38,6 @@ clocks and IDs.
usb_phy_podf 23
cpu_podf 24
di_pred 25
tve_di 26
tve_s 27
uart1_ipg_gate 28
uart1_per_gate 29
@ -172,6 +171,19 @@ clocks and IDs.
can1_serial_gate 157
can1_ipg_gate 158
owire_gate 159
gpu3d_s 160
gpu2d_s 161
gpu3d_gate 162
gpu2d_gate 163
garb_gate 164
cko1_sel 165
cko1_podf 166
cko1 167
cko2_sel 168
cko2_podf 169
cko2 170
srtc_gate 171
pata_gate 172
Examples (for mx53):

3
Documentation/devicetree/bindings/clock/imx6q-clock.txt
View file

@ -205,6 +205,9 @@ clocks and IDs.
enet_ref 190
usbphy1_gate 191
usbphy2_gate 192
pll4_post_div 193
pll5_post_div 194
pll5_video_div 195
Examples:

35
Documentation/devicetree/bindings/dma/atmel-dma.txt
View file

@ -1,14 +1,39 @@
* Atmel Direct Memory Access Controller (DMA)
Required properties:
- compatible: Should be "atmel,<chip>-dma"
- reg: Should contain DMA registers location and length
- interrupts: Should contain DMA interrupt
- compatible: Should be "atmel,<chip>-dma".
- reg: Should contain DMA registers location and length.
- interrupts: Should contain DMA interrupt.
- #dma-cells: Must be <2>, used to represent the number of integer cells in
the dmas property of client devices.
Examples:
Example:
dma@ffffec00 {
dma0: dma@ffffec00 {
compatible = "atmel,at91sam9g45-dma";
reg = <0xffffec00 0x200>;
interrupts = <21>;
#dma-cells = <2>;
};
DMA clients connected to the Atmel DMA controller must use the format
described in the dma.txt file, using a three-cell specifier for each channel:
a phandle plus two interger cells.
The three cells in order are:
1. A phandle pointing to the DMA controller.
2. The memory interface (16 most significant bits), the peripheral interface
(16 less significant bits).
3. The peripheral identifier for the hardware handshaking interface. The
identifier can be different for tx and rx.
Example:
i2c0@i2c@f8010000 {
compatible = "atmel,at91sam9x5-i2c";
reg = <0xf8010000 0x100>;
interrupts = <9 4 6>;
dmas = <&dma0 1 7>,
<&dma0 1 8>;
dma-names = "tx", "rx";
};

49
Documentation/devicetree/bindings/dma/fsl-mxs-dma.txt
View file

@ -3,17 +3,58 @@
Required properties:
- compatible : Should be "fsl,<chip>-dma-apbh" or "fsl,<chip>-dma-apbx"
- reg : Should contain registers location and length
- interrupts : Should contain the interrupt numbers of DMA channels.
If a channel is empty/reserved, 0 should be filled in place.
- #dma-cells : Must be <1>. The number cell specifies the channel ID.
- dma-channels : Number of channels supported by the DMA controller
Optional properties:
- interrupt-names : Name of DMA channel interrupts
Supported chips:
imx23, imx28.
Examples:
dma-apbh@80004000 {
dma_apbh: dma-apbh@80004000 {
compatible = "fsl,imx28-dma-apbh";
reg = <0x80004000 2000>;
reg = <0x80004000 0x2000>;
interrupts = <82 83 84 85
88 88 88 88
88 88 88 88
87 86 0 0>;
interrupt-names = "ssp0", "ssp1", "ssp2", "ssp3",
"gpmi0", "gmpi1", "gpmi2", "gmpi3",
"gpmi4", "gmpi5", "gpmi6", "gmpi7",
"hsadc", "lcdif", "empty", "empty";
#dma-cells = <1>;
dma-channels = <16>;
};
dma-apbx@80024000 {
dma_apbx: dma-apbx@80024000 {
compatible = "fsl,imx28-dma-apbx";
reg = <0x80024000 2000>;
reg = <0x80024000 0x2000>;
interrupts = <78 79 66 0
80 81 68 69
70 71 72 73
74 75 76 77>;
interrupt-names = "auart4-rx", "aurat4-tx", "spdif-tx", "empty",
"saif0", "saif1", "i2c0", "i2c1",
"auart0-rx", "auart0-tx", "auart1-rx", "auart1-tx",
"auart2-rx", "auart2-tx", "auart3-rx", "auart3-tx";
#dma-cells = <1>;
dma-channels = <16>;
};
DMA clients connected to the MXS DMA controller must use the format
described in the dma.txt file.
Examples:
auart0: serial@8006a000 {
compatible = "fsl,imx28-auart", "fsl,imx23-auart";
reg = <0x8006a000 0x2000>;
interrupts = <112>;
dmas = <&dma_apbx 8>, <&dma_apbx 9>;
dma-names = "rx", "tx";
};

36
Documentation/devicetree/bindings/fb/mxsfb.txt
View file

@ -5,9 +5,16 @@ Required properties:
imx23 and imx28.
- reg: Address and length of the register set for lcdif
- interrupts: Should contain lcdif interrupts
- display : phandle to display node (see below for details)
Optional properties:
- panel-enable-gpios : Should specify the gpio for panel enable
* display node
Required properties:
- bits-per-pixel : <16> for RGB565, <32> for RGB888/666.
- bus-width : number of data lines. Could be <8>, <16>, <18> or <24>.
Required sub-node:
- display-timings : Refer to binding doc display-timing.txt for details.
Examples:
@ -15,5 +22,28 @@ lcdif@80030000 {
compatible = "fsl,imx28-lcdif";
reg = <0x80030000 2000>;
interrupts = <38 86>;
panel-enable-gpios = <&gpio3 30 0>;
display: display {
bits-per-pixel = <32>;
bus-width = <24>;
display-timings {
native-mode = <&timing0>;
timing0: timing0 {
clock-frequency = <33500000>;
hactive = <800>;
vactive = <480>;
hfront-porch = <164>;
hback-porch = <89>;
hsync-len = <10>;
vback-porch = <23>;
vfront-porch = <10>;
vsync-len = <10>;
hsync-active = <0>;
vsync-active = <0>;
de-active = <1>;
pixelclk-active = <0>;
};
};
};
};

26
Documentation/devicetree/bindings/gpio/gpio-grgpio.txt Normal file
View file

@ -0,0 +1,26 @@
Aeroflex Gaisler GRGPIO General Purpose I/O cores.
The GRGPIO GPIO core is available in the GRLIB VHDL IP core library.
Note: In the ordinary environment for the GRGPIO core, a Leon SPARC system,
these properties are built from information in the AMBA plug&play.
Required properties:
- name : Should be "GAISLER_GPIO" or "01_01a"
- reg : Address and length of the register set for the device
- interrupts : Interrupt numbers for this device
Optional properties:
- nbits : The number of gpio lines. If not present driver assumes 32 lines.
- irqmap : An array with an index for each gpio line. An index is either a valid
index into the interrupts property array, or 0xffffffff that indicates
no irq for that line. Driver provides no interrupt support if not
present.
For further information look in the documentation for the GLIB IP core library:
http://www.gaisler.com/products/grlib/grip.pdf

47
Documentation/devicetree/bindings/gpio/gpio-mcp23s08.txt Normal file
View file

@ -0,0 +1,47 @@
Microchip MCP2308/MCP23S08/MCP23017/MCP23S17 driver for
8-/16-bit I/O expander with serial interface (I2C/SPI)
Required properties:
- compatible : Should be
- "mcp,mcp23s08" for 8 GPIO SPI version
- "mcp,mcp23s17" for 16 GPIO SPI version
- "mcp,mcp23008" for 8 GPIO I2C version or
- "mcp,mcp23017" for 16 GPIO I2C version of the chip
- #gpio-cells : Should be two.
- first cell is the pin number
- second cell is used to specify flags. Flags are currently unused.
- gpio-controller : Marks the device node as a GPIO controller.
- reg : For an address on its bus. I2C uses this a the I2C address of the chip.
SPI uses this to specify the chipselect line which the chip is
connected to. The driver and the SPI variant of the chip support
multiple chips on the same chipselect. Have a look at
mcp,spi-present-mask below.
Required device specific properties (only for SPI chips):
- mcp,spi-present-mask : This is a present flag, that makes only sense for SPI
chips - as the name suggests. Multiple SPI chips can share the same
SPI chipselect. Set a bit in bit0-7 in this mask to 1 if there is a
chip connected with the corresponding spi address set. For example if
you have a chip with address 3 connected, you have to set bit3 to 1,
which is 0x08. mcp23s08 chip variant only supports bits 0-3. It is not
possible to mix mcp23s08 and mcp23s17 on the same chipselect. Set at
least one bit to 1 for SPI chips.
- spi-max-frequency = The maximum frequency this chip is able to handle
Example I2C:
gpiom1: gpio@20 {
compatible = "mcp,mcp23017";
gpio-controller;
#gpio-cells = <2>;
reg = <0x20>;
};
Example SPI:
gpiom1: gpio@0 {
compatible = "mcp,mcp23s17";
gpio-controller;
#gpio-cells = <2>;
spi-present-mask = <0x01>;
reg = <0>;
spi-max-frequency = <1000000>;
};

15
Documentation/devicetree/bindings/gpio/gpio-omap.txt
View file

@ -5,12 +5,12 @@ Required properties:
- "ti,omap2-gpio" for OMAP2 controllers
- "ti,omap3-gpio" for OMAP3 controllers
- "ti,omap4-gpio" for OMAP4 controllers
- gpio-controller : Marks the device node as a GPIO controller.
- #gpio-cells : Should be two.
- first cell is the pin number
- second cell is used to specify optional parameters (unused)
- gpio-controller : Marks the device node as a GPIO controller.
- interrupt-controller: Mark the device node as an interrupt controller.
- #interrupt-cells : Should be 2.
- interrupt-controller: Mark the device node as an interrupt controller
The first cell is the GPIO number.
The second cell is used to specify flags:
bits[3:0] trigger type and level flags:
@ -20,8 +20,11 @@ Required properties:
8 = active low level-sensitive.
OMAP specific properties:
- ti,hwmods: Name of the hwmod associated to the GPIO:
"gpio<X>", <X> being the 1-based instance number from the HW spec
- ti,hwmods: Name of the hwmod associated to the GPIO:
"gpio<X>", <X> being the 1-based instance number
from the HW spec.
- ti,gpio-always-on: Indicates if a GPIO bank is always powered and
so will never lose its logic state.
Example:
@ -29,8 +32,8 @@ Example:
gpio4: gpio4 {
compatible = "ti,omap4-gpio";
ti,hwmods = "gpio4";
#gpio-cells = <2>;
gpio-controller;
#interrupt-cells = <2>;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
};

20
Documentation/devicetree/bindings/gpu/samsung-g2d.txt Normal file
View file

@ -0,0 +1,20 @@
* Samsung 2D Graphics Accelerator
Required properties:
- compatible : value should be one among the following:
(a) "samsung,s5pv210-g2d" for G2D IP present in S5PV210 & Exynos4210 SoC
(b) "samsung,exynos4212-g2d" for G2D IP present in Exynos4x12 SoCs
(c) "samsung,exynos5250-g2d" for G2D IP present in Exynos5250 SoC
- reg : Physical base address of the IP registers and length of memory
mapped region.
- interrupts : G2D interrupt number to the CPU.
Example:
g2d@12800000 {
compatible = "samsung,s5pv210-g2d";
reg = <0x12800000 0x1000>;
interrupts = <0 89 0>;
status = "disabled";
};

12
Documentation/devicetree/bindings/i2c/i2c-mxs.txt
View file

@ -3,10 +3,13 @@
Required properties:
- compatible: Should be "fsl,<chip>-i2c"
- reg: Should contain registers location and length
- interrupts: Should contain ERROR and DMA interrupts
- interrupts: Should contain ERROR interrupt number
- clock-frequency: Desired I2C bus clock frequency in Hz.
Only 100000Hz and 400000Hz modes are supported.
- fsl,i2c-dma-channel: APBX DMA channel for the I2C
- dmas: DMA specifier, consisting of a phandle to DMA controller node
and I2C DMA channel ID.
Refer to dma.txt and fsl-mxs-dma.txt for details.
- dma-names: Must be "rx-tx".
Examples:
@ -15,7 +18,8 @@ i2c0: i2c@80058000 {
#size-cells = <0>;
compatible = "fsl,imx28-i2c";
reg = <0x80058000 2000>;
interrupts = <111 68>;
interrupts = <111>;
clock-frequency = <100000>;
fsl,i2c-dma-channel = <6>;
dmas = <&dma_apbx 6>;
dma-names = "rx-tx";
};

60
Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.txt Normal file
View file

@ -0,0 +1,60 @@
NVIDIA Tegra20/Tegra30/Tegra114 I2C controller driver.
Required properties:
- compatible : should be:
"nvidia,tegra114-i2c"
"nvidia,tegra30-i2c"
"nvidia,tegra20-i2c"
"nvidia,tegra20-i2c-dvc"
Details of compatible are as follows:
nvidia,tegra20-i2c-dvc: Tegra20 has specific I2C controller called as DVC I2C
controller. This only support master mode of I2C communication. Register
interface/offset and interrupts handling are different than generic I2C
controller. Driver of DVC I2C controller is only compatible with
"nvidia,tegra20-i2c-dvc".
nvidia,tegra20-i2c: Tegra20 has 4 generic I2C controller. This can support
master and slave mode of I2C communication. The i2c-tegra driver only
support master mode of I2C communication. Driver of I2C controller is
only compatible with "nvidia,tegra20-i2c".
nvidia,tegra30-i2c: Tegra30 has 5 generic I2C controller. This controller is
very much similar to Tegra20 I2C controller with additional feature:
Continue Transfer Support. This feature helps to implement M_NO_START
as per I2C core API transfer flags. Driver of I2C controller is
compatible with "nvidia,tegra30-i2c" to enable the continue transfer
support. This is also compatible with "nvidia,tegra20-i2c" without
continue transfer support.
nvidia,tegra114-i2c: Tegra114 has 5 generic I2C controller. This controller is
very much similar to Tegra30 I2C controller with some hardware
modification:
- Tegra30/Tegra20 I2C controller has 2 clock source called div-clk and
fast-clk. Tegra114 has only one clock source called as div-clk and
hence clock mechanism is changed in I2C controller.
- Tegra30/Tegra20 I2C controller has enabled per packet transfer by
default and there is no way to disable it. Tegra114 has this
interrupt disable by default and SW need to enable explicitly.
Due to above changes, Tegra114 I2C driver makes incompatible with
previous hardware driver. Hence, tegra114 I2C controller is compatible
with "nvidia,tegra114-i2c".
- reg: Should contain I2C controller registers physical address and length.
- interrupts: Should contain I2C controller interrupts.
- address-cells: Address cells for I2C device address.
- size-cells: Size of the I2C device address.
- clocks: Clock ID as per
Documentation/devicetree/bindings/clock/tegra<chip-id>.txt
for I2C controller.
- clock-names: Name of the clock:
Tegra20/Tegra30 I2C controller: "div-clk and "fast-clk".
Tegra114 I2C controller: "div-clk".
Example:
i2c@7000c000 {
compatible = "nvidia,tegra20-i2c";
reg = <0x7000c000 0x100>;
interrupts = <0 38 0x04>;
#address-cells = <1>;
#size-cells = <0>;
clocks = <&tegra_car 12>, <&tegra_car 124>;
clock-names = "div-clk", "fast-clk";
status = "disabled";
};

72
Documentation/devicetree/bindings/input/cros-ec-keyb.txt Normal file
View file

@ -0,0 +1,72 @@
ChromeOS EC Keyboard
Google's ChromeOS EC Keyboard is a simple matrix keyboard implemented on
a separate EC (Embedded Controller) device. It provides a message for reading
key scans from the EC. These are then converted into keycodes for processing
by the kernel.
This binding is based on matrix-keymap.txt and extends/modifies it as follows:
Required properties:
- compatible: "google,cros-ec-keyb"
Optional properties:
- google,needs-ghost-filter: True to enable a ghost filter for the matrix
keyboard. This is recommended if the EC does not have its own logic or
hardware for this.
Example:
cros-ec-keyb {
compatible = "google,cros-ec-keyb";
keypad,num-rows = <8>;
keypad,num-columns = <13>;
google,needs-ghost-filter;
/*
* Keymap entries take the form of 0xRRCCKKKK where
* RR=Row CC=Column KKKK=Key Code
* The values below are for a US keyboard layout and
* are taken from the Linux driver. Note that the
* 102ND key is not used for US keyboards.
*/
linux,keymap = <
/* CAPSLCK F1 B F10 */
0x0001003a 0x0002003b 0x00030030 0x00040044
/* N = R_ALT ESC */
0x00060031 0x0008000d 0x000a0064 0x01010001
/* F4 G F7 H */
0x0102003e 0x01030022 0x01040041 0x01060023
/* ' F9 BKSPACE L_CTRL */
0x01080028 0x01090043 0x010b000e 0x0200001d
/* TAB F3 T F6 */
0x0201000f 0x0202003d 0x02030014 0x02040040
/* ] Y 102ND [ */
0x0205001b 0x02060015 0x02070056 0x0208001a
/* F8 GRAVE F2 5 */
0x02090042 0x03010029 0x0302003c 0x03030006
/* F5 6 - \ */
0x0304003f 0x03060007 0x0308000c 0x030b002b
/* R_CTRL A D F */
0x04000061 0x0401001e 0x04020020 0x04030021
/* S K J ; */
0x0404001f 0x04050025 0x04060024 0x04080027
/* L ENTER Z C */
0x04090026 0x040b001c 0x0501002c 0x0502002e
/* V X , M */
0x0503002f 0x0504002d 0x05050033 0x05060032
/* L_SHIFT / . SPACE */
0x0507002a 0x05080035 0x05090034 0x050B0039
/* 1 3 4 2 */
0x06010002 0x06020004 0x06030005 0x06040003
/* 8 7 0 9 */
0x06050009 0x06060008 0x0608000b 0x0609000a
/* L_ALT DOWN RIGHT Q */
0x060a0038 0x060b006c 0x060c006a 0x07010010
/* E R W I */
0x07020012 0x07030013 0x07040011 0x07050017
/* U R_SHIFT P O */
0x07060016 0x07070036 0x07080019 0x07090018
/* UP LEFT */
0x070b0067 0x070c0069>;
};

73
Documentation/devicetree/bindings/mfd/as3711.txt Normal file
View file

@ -0,0 +1,73 @@
AS3711 is an I2C PMIC from Austria MicroSystems with multiple DCDC and LDO power
supplies, a battery charger and an RTC. So far only bindings for the two stepup
DCDC converters are defined. Other DCDC and LDO supplies are configured, using
standard regulator properties, they must belong to a sub-node, called
"regulators" and be called "sd1" to "sd4" and "ldo1" to "ldo8." Stepup converter
configuration should be placed in a subnode, called "backlight."
Compulsory properties:
- compatible : must be "ams,as3711"
- reg : specifies the I2C address
To use the SU1 converter as a backlight source the following two properties must
be provided:
- su1-dev : framebuffer phandle
- su1-max-uA : maximum current
To use the SU2 converter as a backlight source the following two properties must
be provided:
- su2-dev : framebuffer phandle
- su1-max-uA : maximum current
Additionally one of these properties must be provided to select the type of
feedback used:
- su2-feedback-voltage : voltage feedback is used
- su2-feedback-curr1 : CURR1 input used for current feedback
- su2-feedback-curr2 : CURR2 input used for current feedback
- su2-feedback-curr3 : CURR3 input used for current feedback
- su2-feedback-curr-auto: automatic current feedback selection
and one of these to select the over-voltage protection pin
- su2-fbprot-lx-sd4 : LX_SD4 is used for over-voltage protection
- su2-fbprot-gpio2 : GPIO2 is used for over-voltage protection
- su2-fbprot-gpio3 : GPIO3 is used for over-voltage protection
- su2-fbprot-gpio4 : GPIO4 is used for over-voltage protection
If "su2-feedback-curr-auto" is selected, one or more of the following properties
have to be specified:
- su2-auto-curr1 : use CURR1 input for current feedback
- su2-auto-curr2 : use CURR2 input for current feedback
- su2-auto-curr3 : use CURR3 input for current feedback
Example:
as3711@40 {
compatible = "ams,as3711";
reg = <0x40>;
regulators {
sd4 {
regulator-name = "1.215V";
regulator-min-microvolt = <1215000>;
regulator-max-microvolt = <1235000>;
};
ldo2 {
regulator-name = "2.8V CPU";
regulator-min-microvolt = <2800000>;
regulator-max-microvolt = <2800000>;
regulator-always-on;
regulator-boot-on;
};
};
backlight {
compatible = "ams,as3711-bl";
su2-dev = <&lcdc>;
su2-max-uA = <36000>;
su2-feedback-curr-auto;
su2-fbprot-gpio4;
su2-auto-curr1;
su2-auto-curr2;
su2-auto-curr3;
};
};

56
Documentation/devicetree/bindings/mfd/cros-ec.txt Normal file
View file

@ -0,0 +1,56 @@
ChromeOS Embedded Controller
Google's ChromeOS EC is a Cortex-M device which talks to the AP and
implements various function such as keyboard and battery charging.
The EC can be connect through various means (I2C, SPI, LPC) and the
compatible string used depends on the inteface. Each connection method has
its own driver which connects to the top level interface-agnostic EC driver.
Other Linux driver (such as cros-ec-keyb for the matrix keyboard) connect to
the top-level driver.
Required properties (I2C):
- compatible: "google,cros-ec-i2c"
- reg: I2C slave address
Required properties (SPI):
- compatible: "google,cros-ec-spi"
- reg: SPI chip select
Required properties (LPC):
- compatible: "google,cros-ec-lpc"
- reg: List of (IO address, size) pairs defining the interface uses
Example for I2C:
i2c@12CA0000 {
cros-ec@1e {
reg = <0x1e>;
compatible = "google,cros-ec-i2c";
interrupts = <14 0>;
interrupt-parent = <&wakeup_eint>;
wakeup-source;
};
Example for SPI:
spi@131b0000 {
ec@0 {
compatible = "google,cros-ec-spi";
reg = <0x0>;
interrupts = <14 0>;
interrupt-parent = <&wakeup_eint>;
wakeup-source;
spi-max-frequency = <5000000>;
controller-data {
cs-gpio = <&gpf0 3 4 3 0>;
samsung,spi-cs;
samsung,spi-feedback-delay = <2>;
};
};
};
Example for LPC is not supplied as it is not yet implemented.

80
Documentation/devicetree/bindings/mfd/omap-usb-host.txt Normal file
View file

@ -0,0 +1,80 @@
OMAP HS USB Host
Required properties:
- compatible: should be "ti,usbhs-host"
- reg: should contain one register range i.e. start and length
- ti,hwmods: must contain "usb_host_hs"
Optional properties:
- num-ports: number of USB ports. Usually this is automatically detected
from the IP's revision register but can be overridden by specifying
this property. A maximum of 3 ports are supported at the moment.
- portN-mode: String specifying the port mode for port N, where N can be
from 1 to 3. If the port mode is not specified, that port is treated
as unused. When specified, it must be one of the following.
"ehci-phy",
"ehci-tll",
"ehci-hsic",
"ohci-phy-6pin-datse0",
"ohci-phy-6pin-dpdm",
"ohci-phy-3pin-datse0",
"ohci-phy-4pin-dpdm",
"ohci-tll-6pin-datse0",
"ohci-tll-6pin-dpdm",
"ohci-tll-3pin-datse0",
"ohci-tll-4pin-dpdm",
"ohci-tll-2pin-datse0",
"ohci-tll-2pin-dpdm",
- single-ulpi-bypass: Must be present if the controller contains a single
ULPI bypass control bit. e.g. OMAP3 silicon <= ES2.1
Required properties if child node exists:
- #address-cells: Must be 1
- #size-cells: Must be 1
- ranges: must be present
Properties for children:
The OMAP HS USB Host subsystem contains EHCI and OHCI controllers.
See Documentation/devicetree/bindings/usb/omap-ehci.txt and
omap3-ohci.txt
Example for OMAP4:
usbhshost: usbhshost@4a064000 {
compatible = "ti,usbhs-host";
reg = <0x4a064000 0x800>;
ti,hwmods = "usb_host_hs";
#address-cells = <1>;
#size-cells = <1>;
ranges;
usbhsohci: ohci@4a064800 {
compatible = "ti,ohci-omap3", "usb-ohci";
reg = <0x4a064800 0x400>;
interrupt-parent = <&gic>;
interrupts = <0 76 0x4>;
};
usbhsehci: ehci@4a064c00 {
compatible = "ti,ehci-omap", "usb-ehci";
reg = <0x4a064c00 0x400>;
interrupt-parent = <&gic>;
interrupts = <0 77 0x4>;
};
};
&usbhshost {
port1-mode = "ehci-phy";
port2-mode = "ehci-tll";
port3-mode = "ehci-phy";
};
&usbhsehci {
phys = <&hsusb1_phy 0 &hsusb3_phy>;
};

17
Documentation/devicetree/bindings/mfd/omap-usb-tll.txt Normal file
View file

@ -0,0 +1,17 @@
OMAP HS USB Host TLL (Transceiver-Less Interface)
Required properties:
- compatible : should be "ti,usbhs-tll"
- reg : should contain one register range i.e. start and length
- interrupts : should contain the TLL module's interrupt
- ti,hwmod : must contain "usb_tll_hs"
Example:
usbhstll: usbhstll@4a062000 {
compatible = "ti,usbhs-tll";
reg = <0x4a062000 0x1000>;
interrupts = <78>;
ti,hwmods = "usb_tll_hs";
};

17
Documentation/devicetree/bindings/mips/ralink.txt Normal file
View file

@ -0,0 +1,17 @@
Ralink MIPS SoC device tree bindings
1. SoCs
Each device tree must specify a compatible value for the Ralink SoC
it uses in the compatible property of the root node. The compatible
value must be one of the following values:
ralink,rt2880-soc
ralink,rt3050-soc
ralink,rt3052-soc
ralink,rt3350-soc
ralink,rt3352-soc
ralink,rt3883-soc
ralink,rt5350-soc
ralink,mt7620a-soc
ralink,mt7620n-soc

12
Documentation/devicetree/bindings/mmc/mxs-mmc.txt
View file

@ -9,15 +9,19 @@ and the properties used by the mxsmmc driver.
Required properties:
- compatible: Should be "fsl,<chip>-mmc". The supported chips include
imx23 and imx28.
- interrupts: Should contain ERROR and DMA interrupts
- fsl,ssp-dma-channel: APBH DMA channel for the SSP
- interrupts: Should contain ERROR interrupt number
- dmas: DMA specifier, consisting of a phandle to DMA controller node
and SSP DMA channel ID.
Refer to dma.txt and fsl-mxs-dma.txt for details.
- dma-names: Must be "rx-tx".
Examples:
ssp0: ssp@80010000 {
compatible = "fsl,imx28-mmc";
reg = <0x80010000 2000>;
interrupts = <96 82>;
fsl,ssp-dma-channel = <0>;
interrupts = <96>;
dmas = <&dma_apbh 0>;
dma-names = "rx-tx";
bus-width = <8>;
};

28
Documentation/devicetree/bindings/mtd/gpmc-nand.txt
View file

@ -56,20 +56,20 @@ Example for an AM33xx board:
nand-bus-width = <16>;
ti,nand-ecc-opt = "bch8";
gpmc,sync-clk = <0>;
gpmc,cs-on = <0>;
gpmc,cs-rd-off = <44>;
gpmc,cs-wr-off = <44>;
gpmc,adv-on = <6>;
gpmc,adv-rd-off = <34>;
gpmc,adv-wr-off = <44>;
gpmc,we-off = <40>;
gpmc,oe-off = <54>;
gpmc,access = <64>;
gpmc,rd-cycle = <82>;
gpmc,wr-cycle = <82>;
gpmc,wr-access = <40>;
gpmc,wr-data-mux-bus = <0>;
gpmc,sync-clk-ps = <0>;
gpmc,cs-on-ns = <0>;
gpmc,cs-rd-off-ns = <44>;
gpmc,cs-wr-off-ns = <44>;
gpmc,adv-on-ns = <6>;
gpmc,adv-rd-off-ns = <34>;
gpmc,adv-wr-off-ns = <44>;
gpmc,we-off-ns = <40>;
gpmc,oe-off-ns = <54>;
gpmc,access-ns = <64>;
gpmc,rd-cycle-ns = <82>;
gpmc,wr-cycle-ns = <82>;
gpmc,wr-access-ns = <40>;
gpmc,wr-data-mux-bus-ns = <0>;
#address-cells = <1>;
#size-cells = <1>;

17
Documentation/devicetree/bindings/mtd/gpmi-nand.txt
View file

@ -7,10 +7,12 @@ Required properties:
- compatible : should be "fsl,<chip>-gpmi-nand"
- reg : should contain registers location and length for gpmi and bch.
- reg-names: Should contain the reg names "gpmi-nand" and "bch"
- interrupts : The first is the DMA interrupt number for GPMI.
The second is the BCH interrupt number.
- interrupt-names : The interrupt names "gpmi-dma", "bch";
- fsl,gpmi-dma-channel : Should contain the dma channel it uses.
- interrupts : BCH interrupt number.
- interrupt-names : Should be "bch".
- dmas: DMA specifier, consisting of a phandle to DMA controller node
and GPMI DMA channel ID.
Refer to dma.txt and fsl-mxs-dma.txt for details.
- dma-names: Must be "rx-tx".
Optional properties:
- nand-on-flash-bbt: boolean to enable on flash bbt option if not
@ -27,9 +29,10 @@ gpmi-nand@8000c000 {
#size-cells = <1>;
reg = <0x8000c000 2000>, <0x8000a000 2000>;
reg-names = "gpmi-nand", "bch";
interrupts = <88>, <41>;
interrupt-names = "gpmi-dma", "bch";
fsl,gpmi-dma-channel = <4>;
interrupts = <41>;
interrupt-names = "bch";
dmas = <&dma_apbh 4>;
dma-names = "rx-tx";
partition@0 {
...

36
Documentation/devicetree/bindings/mtd/partition.txt
View file

@ -5,8 +5,12 @@ on platforms which have strong conventions about which portions of a flash are
used for what purposes, but which don't use an on-flash partition table such
as RedBoot.
#address-cells & #size-cells must both be present in the mtd device and be
equal to 1.
#address-cells & #size-cells must both be present in the mtd device. There are
two valid values for both:
<1>: for partitions that require a single 32-bit cell to represent their
size/address (aka the value is below 4 GiB)
<2>: for partitions that require two 32-bit cells to represent their
size/address (aka the value is 4 GiB or greater).
Required properties:
- reg : The partition's offset and size within the mtd bank.
@ -36,3 +40,31 @@ flash@0 {
reg = <0x0100000 0x200000>;
};
};
flash@1 {
#address-cells = <1>;
#size-cells = <2>;
/* a 4 GiB partition */
partition@0 {
label = "filesystem";
reg = <0x00000000 0x1 0x00000000>;
};
};
flash@2 {
#address-cells = <2>;
#size-cells = <2>;
/* an 8 GiB partition */
partition@0 {
label = "filesystem #1";
reg = <0x0 0x00000000 0x2 0x00000000>;
};
/* a 4 GiB partition */
partition@200000000 {
label = "filesystem #2";
reg = <0x2 0x00000000 0x1 0x00000000>;
};
};

56
Documentation/devicetree/bindings/net/gpmc-eth.txt
View file

@ -26,16 +26,16 @@ Required properties:
- bank-width: Address width of the device in bytes. GPMC supports 8-bit
and 16-bit devices and so must be either 1 or 2 bytes.
- compatible: Compatible string property for the ethernet child device.
- gpmc,cs-on: Chip-select assertion time
- gpmc,cs-rd-off: Chip-select de-assertion time for reads
- gpmc,cs-wr-off: Chip-select de-assertion time for writes
- gpmc,oe-on: Output-enable assertion time
- gpmc,oe-off Output-enable de-assertion time
- gpmc,we-on: Write-enable assertion time
- gpmc,we-off: Write-enable de-assertion time
- gpmc,access: Start cycle to first data capture (read access)
- gpmc,rd-cycle: Total read cycle time
- gpmc,wr-cycle: Total write cycle time
- gpmc,cs-on-ns: Chip-select assertion time
- gpmc,cs-rd-off-ns: Chip-select de-assertion time for reads
- gpmc,cs-wr-off-ns: Chip-select de-assertion time for writes
- gpmc,oe-on-ns: Output-enable assertion time
- gpmc,oe-off-ns: Output-enable de-assertion time
- gpmc,we-on-ns: Write-enable assertion time
- gpmc,we-off-ns: Write-enable de-assertion time
- gpmc,access-ns: Start cycle to first data capture (read access)
- gpmc,rd-cycle-ns: Total read cycle time
- gpmc,wr-cycle-ns: Total write cycle time
- reg: Chip-select, base address (relative to chip-select)
and size of the memory mapped for the device.
Note that base address will be typically 0 as this
@ -65,24 +65,24 @@ gpmc: gpmc@6e000000 {
bank-width = <2>;
gpmc,mux-add-data;
gpmc,cs-on = <0>;
gpmc,cs-rd-off = <186>;
gpmc,cs-wr-off = <186>;
gpmc,adv-on = <12>;
gpmc,adv-rd-off = <48>;
gpmc,adv-wr-off = <48>;
gpmc,oe-on = <54>;
gpmc,oe-off = <168>;
gpmc,we-on = <54>;
gpmc,we-off = <168>;
gpmc,rd-cycle = <186>;
gpmc,wr-cycle = <186>;
gpmc,access = <114>;
gpmc,page-burst-access = <6>;
gpmc,bus-turnaround = <12>;
gpmc,cycle2cycle-delay = <18>;
gpmc,wr-data-mux-bus = <90>;
gpmc,wr-access = <186>;
gpmc,cs-on-ns = <0>;
gpmc,cs-rd-off-ns = <186>;
gpmc,cs-wr-off-ns = <186>;
gpmc,adv-on-ns = <12>;
gpmc,adv-rd-off-ns = <48>;
gpmc,adv-wr-off-ns = <48>;
gpmc,oe-on-ns = <54>;
gpmc,oe-off-ns = <168>;
gpmc,we-on-ns = <54>;
gpmc,we-off-ns = <168>;
gpmc,rd-cycle-ns = <186>;
gpmc,wr-cycle-ns = <186>;
gpmc,access-ns = <114>;
gpmc,page-burst-access-ns = <6>;
gpmc,bus-turnaround-ns = <12>;
gpmc,cycle2cycle-delay-ns = <18>;
gpmc,wr-data-mux-bus-ns = <90>;
gpmc,wr-access-ns = <186>;
gpmc,cycle2cycle-samecsen;
gpmc,cycle2cycle-diffcsen;

2
Documentation/devicetree/bindings/net/macb.txt
View file

@ -4,7 +4,7 @@ Required properties:
- compatible: Should be "cdns,[<chip>-]{macb|gem}"
Use "cdns,at91sam9260-macb" Atmel at91sam9260 and at91sam9263 SoCs.
Use "cdns,at32ap7000-macb" for other 10/100 usage or use the generic form: "cdns,macb".
Use "cnds,pc302-gem" for Picochip picoXcell pc302 and later devices based on
Use "cdns,pc302-gem" for Picochip picoXcell pc302 and later devices based on
the Cadence GEM, or the generic form: "cdns,gem".
- reg: Address and length of the register set for the device
- interrupts: Should contain macb interrupt

4
Documentation/devicetree/bindings/pinctrl/fsl,mxs-pinctrl.txt
View file

@ -70,6 +70,10 @@ Optional subnode-properties:
0: Disable the internal pull-up
1: Enable the internal pull-up
Note that when enabling the pull-up, the internal pad keeper gets disabled.
Also, some pins doesn't have a pull up, in that case, setting the fsl,pull-up
will only disable the internal pad keeper.
Examples:
pinctrl@80018000 {

43
Documentation/devicetree/bindings/pwm/pwm-samsung.txt Normal file
View file

@ -0,0 +1,43 @@
* Samsung PWM timers
Samsung SoCs contain PWM timer blocks which can be used for system clock source
and clock event timers, as well as to drive SoC outputs with PWM signal. Each
PWM timer block provides 5 PWM channels (not all of them can drive physical
outputs - see SoC and board manual).
Be aware that the clocksource driver supports only uniprocessor systems.
Required properties:
- compatible : should be one of following:
samsung,s3c2410-pwm - for 16-bit timers present on S3C24xx SoCs
samsung,s3c6400-pwm - for 32-bit timers present on S3C64xx SoCs
samsung,s5p6440-pwm - for 32-bit timers present on S5P64x0 SoCs
samsung,s5pc100-pwm - for 32-bit timers present on S5PC100, S5PV210,
Exynos4210 rev0 SoCs
samsung,exynos4210-pwm - for 32-bit timers present on Exynos4210,
Exynos4x12 and Exynos5250 SoCs
- reg: base address and size of register area
- interrupts: list of timer interrupts (one interrupt per timer, starting at
timer 0)
- #pwm-cells: number of cells used for PWM specifier - must be 3
the specifier format is as follows:
- phandle to PWM controller node
- index of PWM channel (from 0 to 4)
- PWM signal period in nanoseconds
- bitmask of optional PWM flags:
0x1 - invert PWM signal
Optional properties:
- samsung,pwm-outputs: list of PWM channels used as PWM outputs on particular
platform - an array of up to 5 elements being indices of PWM channels
(from 0 to 4), the order does not matter.
Example:
pwm@7f006000 {
compatible = "samsung,s3c6400-pwm";
reg = <0x7f006000 0x1000>;
interrupt-parent = <&vic0>;
interrupts = <23>, <24>, <25>, <27>, <28>;
samsung,pwm-outputs = <0>, <1>;
#pwm-cells = <3>;
}

12
Documentation/devicetree/bindings/pwm/pwm-tiecap.txt
View file

@ -1,7 +1,9 @@
TI SOC ECAP based APWM controller
Required properties:
- compatible: Must be "ti,am33xx-ecap"
- compatible: Must be "ti,<soc>-ecap".
for am33xx - compatible = "ti,am33xx-ecap";
for da850 - compatible = "ti,da850-ecap", "ti,am33xx-ecap";
- #pwm-cells: Should be 3. Number of cells being used to specify PWM property.
First cell specifies the per-chip index of the PWM to use, the second
cell is the period in nanoseconds and bit 0 in the third cell is used to
@ -15,9 +17,15 @@ Optional properties:
Example:
ecap0: ecap@0 {
ecap0: ecap@0 { /* ECAP on am33xx */
compatible = "ti,am33xx-ecap";
#pwm-cells = <3>;
reg = <0x48300100 0x80>;
ti,hwmods = "ecap0";
};
ecap0: ecap@0 { /* ECAP on da850 */
compatible = "ti,da850-ecap", "ti,am33xx-ecap";
#pwm-cells = <3>;
reg = <0x306000 0x80>;
};

12
Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt
View file

@ -1,7 +1,9 @@
TI SOC EHRPWM based PWM controller
Required properties:
- compatible : Must be "ti,am33xx-ehrpwm"
- compatible: Must be "ti,<soc>-ehrpwm".
for am33xx - compatible = "ti,am33xx-ehrpwm";
for da850 - compatible = "ti,da850-ehrpwm", "ti,am33xx-ehrpwm";
- #pwm-cells: Should be 3. Number of cells being used to specify PWM property.
First cell specifies the per-chip index of the PWM to use, the second
cell is the period in nanoseconds and bit 0 in the third cell is used to
@ -15,9 +17,15 @@ Optional properties:
Example:
ehrpwm0: ehrpwm@0 {
ehrpwm0: ehrpwm@0 { /* EHRPWM on am33xx */
compatible = "ti,am33xx-ehrpwm";
#pwm-cells = <3>;
reg = <0x48300200 0x100>;
ti,hwmods = "ehrpwm0";
};
ehrpwm0: ehrpwm@0 { /* EHRPWM on da850 */
compatible = "ti,da850-ehrpwm", "ti,am33xx-ehrpwm";
#pwm-cells = <3>;
reg = <0x300000 0x2000>;
};

49
Documentation/devicetree/bindings/reset/fsl,imx-src.txt Normal file
View file

@ -0,0 +1,49 @@
Freescale i.MX System Reset Controller
======================================
Please also refer to reset.txt in this directory for common reset
controller binding usage.
Required properties:
- compatible: Should be "fsl,<chip>-src"
- reg: should be register base and length as documented in the
datasheet
- interrupts: Should contain SRC interrupt and CPU WDOG interrupt,
in this order.
- #reset-cells: 1, see below
example:
src: src@020d8000 {
compatible = "fsl,imx6q-src";
reg = <0x020d8000 0x4000>;
interrupts = <0 91 0x04 0 96 0x04>;
#reset-cells = <1>;
};
Specifying reset lines connected to IP modules
==============================================
The system reset controller can be used to reset the GPU, VPU,
IPU, and OpenVG IP modules on i.MX5 and i.MX6 ICs. Those device
nodes should specify the reset line on the SRC in their resets
property, containing a phandle to the SRC device node and a
RESET_INDEX specifying which module to reset, as described in
reset.txt
example:
ipu1: ipu@02400000 {
resets = <&src 2>;
};
ipu2: ipu@02800000 {
resets = <&src 4>;
};
The following RESET_INDEX values are valid for i.MX5:
GPU_RESET 0
VPU_RESET 1
IPU1_RESET 2
OPEN_VG_RESET 3
The following additional RESET_INDEX value is valid for i.MX6:
IPU2_RESET 4

17
Documentation/devicetree/bindings/serial/pl011.txt Normal file
View file

@ -0,0 +1,17 @@
* ARM AMBA Primecell PL011 serial UART
Required properties:
- compatible: must be "arm,primecell", "arm,pl011"
- reg: exactly one register range with length 0x1000
- interrupts: exactly one interrupt specifier
Optional properties:
- pinctrl: When present, must have one state named "sleep"
and one state named "default"
- clocks: When present, must refer to exactly one clock named
"apb_pclk"
- dmas: When present, may have one or two dma channels.
The first one must be named "rx", the second one
must be named "tx".
See also bindings/arm/primecell.txt

8
Documentation/devicetree/bindings/sound/nvidia,tegra-audio-alc5632.txt
View file

@ -2,6 +2,11 @@ NVIDIA Tegra audio complex
Required properties:
- compatible : "nvidia,tegra-audio-alc5632"
- clocks : Must contain an entry for each entry in clock-names.
- clock-names : Must include the following entries:
"pll_a" (The Tegra clock of that name),
"pll_a_out0" (The Tegra clock of that name),
"mclk" (The Tegra cdev1/extern1 clock, which feeds the CODEC's mclk)
- nvidia,model : The user-visible name of this sound complex.
- nvidia,audio-routing : A list of the connections between audio components.
Each entry is a pair of strings, the first being the connection's sink,
@ -56,4 +61,7 @@ sound {
nvidia,i2s-controller = <&tegra_i2s1>;
nvidia,audio-codec = <&alc5632>;
clocks = <&tegra_car 112>, <&tegra_car 113>, <&tegra_car 93>;
clock-names = "pll_a", "pll_a_out0", "mclk";
};

7
Documentation/devicetree/bindings/sound/nvidia,tegra-audio-trimslice.txt
View file

@ -2,6 +2,11 @@ NVIDIA Tegra audio complex for TrimSlice
Required properties:
- compatible : "nvidia,tegra-audio-trimslice"
- clocks : Must contain an entry for each entry in clock-names.
- clock-names : Must include the following entries:
"pll_a" (The Tegra clock of that name),
"pll_a_out0" (The Tegra clock of that name),
"mclk" (The Tegra cdev1/extern1 clock, which feeds the CODEC's mclk)
- nvidia,i2s-controller : The phandle of the Tegra I2S1 controller
- nvidia,audio-codec : The phandle of the WM8903 audio codec
@ -11,4 +16,6 @@ sound {
compatible = "nvidia,tegra-audio-trimslice";
nvidia,i2s-controller = <&tegra_i2s1>;
nvidia,audio-codec = <&codec>;
clocks = <&tegra_car 112>, <&tegra_car 113>, <&tegra_car 93>;
clock-names = "pll_a", "pll_a_out0", "mclk";
};

8
Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8753.txt
View file

@ -2,6 +2,11 @@ NVIDIA Tegra audio complex
Required properties:
- compatible : "nvidia,tegra-audio-wm8753"
- clocks : Must contain an entry for each entry in clock-names.
- clock-names : Must include the following entries:
"pll_a" (The Tegra clock of that name),
"pll_a_out0" (The Tegra clock of that name),
"mclk" (The Tegra cdev1/extern1 clock, which feeds the CODEC's mclk)
- nvidia,model : The user-visible name of this sound complex.
- nvidia,audio-routing : A list of the connections between audio components.
Each entry is a pair of strings, the first being the connection's sink,
@ -50,5 +55,8 @@ sound {
nvidia,i2s-controller = <&i2s1>;
nvidia,audio-codec = <&wm8753>;
clocks = <&tegra_car 112>, <&tegra_car 113>, <&tegra_car 93>;
clock-names = "pll_a", "pll_a_out0", "mclk";
};

8
Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8903.txt
View file

@ -2,6 +2,11 @@ NVIDIA Tegra audio complex
Required properties:
- compatible : "nvidia,tegra-audio-wm8903"
- clocks : Must contain an entry for each entry in clock-names.
- clock-names : Must include the following entries:
"pll_a" (The Tegra clock of that name),
"pll_a_out0" (The Tegra clock of that name),
"mclk" (The Tegra cdev1/extern1 clock, which feeds the CODEC's mclk)
- nvidia,model : The user-visible name of this sound complex.
- nvidia,audio-routing : A list of the connections between audio components.
Each entry is a pair of strings, the first being the connection's sink,
@ -67,5 +72,8 @@ sound {
nvidia,hp-det-gpios = <&gpio 178 0>; /* gpio PW2 */
nvidia,int-mic-en-gpios = <&gpio 184 0>; /*gpio PX0 */
nvidia,ext-mic-en-gpios = <&gpio 185 0>; /* gpio PX1 */
clocks = <&tegra_car 112>, <&tegra_car 113>, <&tegra_car 93>;
clock-names = "pll_a", "pll_a_out0", "mclk";
};

8
Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm9712.txt
View file

@ -2,6 +2,11 @@ NVIDIA Tegra audio complex
Required properties:
- compatible : "nvidia,tegra-audio-wm9712"
- clocks : Must contain an entry for each entry in clock-names.
- clock-names : Must include the following entries:
"pll_a" (The Tegra clock of that name),
"pll_a_out0" (The Tegra clock of that name),
"mclk" (The Tegra cdev1/extern1 clock, which feeds the CODEC's mclk)
- nvidia,model : The user-visible name of this sound complex.
- nvidia,audio-routing : A list of the connections between audio components.
Each entry is a pair of strings, the first being the connection's sink,
@ -48,4 +53,7 @@ sound {
"Mic", "MIC1";
nvidia,ac97-controller = <&ac97>;
clocks = <&tegra_car 112>, <&tegra_car 113>, <&tegra_car 93>;
clock-names = "pll_a", "pll_a_out0", "mclk";
};

58
Documentation/devicetree/bindings/sound/wm8994.txt
View file

@ -5,14 +5,70 @@ on the board).
Required properties:
- compatible : "wlf,wm1811", "wlf,wm8994", "wlf,wm8958"
- compatible : One of "wlf,wm1811", "wlf,wm8994" or "wlf,wm8958".
- reg : the I2C address of the device for I2C, the chip select
number for SPI.
- gpio-controller : Indicates this device is a GPIO controller.
- #gpio-cells : Must be 2. The first cell is the pin number and the
second cell is used to specify optional parameters (currently unused).
- AVDD2-supply, DBVDD1-supply, DBVDD2-supply, DBVDD3-supply, CPVDD-supply,
SPKVDD1-supply, SPKVDD2-supply : power supplies for the device, as covered
in Documentation/devicetree/bindings/regulator/regulator.txt
Optional properties:
- interrupts : The interrupt line the IRQ signal for the device is
connected to. This is optional, if it is not connected then none
of the interrupt related properties should be specified.
- interrupt-controller : These devices contain interrupt controllers
and may provide interrupt services to other devices if they have an
interrupt line connected.
- interrupt-parent : The parent interrupt controller.
- #interrupt-cells: the number of cells to describe an IRQ, this should be 2.
The first cell is the IRQ number.
The second cell is the flags, encoded as the trigger masks from
Documentation/devicetree/bindings/interrupts.txt
- wlf,gpio-cfg : A list of GPIO configuration register values. If absent,
no configuration of these registers is performed. If any value is
over 0xffff then the register will be left as default. If present 11
values must be supplied.
- wlf,micbias-cfg : Two MICBIAS register values for WM1811 or
WM8958. If absent the register defaults will be used.
- wlf,ldo1ena : GPIO specifier for control of LDO1ENA input to device.
- wlf,ldo2ena : GPIO specifier for control of LDO2ENA input to device.
- wlf,lineout1-se : If present LINEOUT1 is in single ended mode.
- wlf,lineout2-se : If present LINEOUT2 is in single ended mode.
- wlf,lineout1-feedback : If present LINEOUT1 has common mode feedback
connected.
- wlf,lineout2-feedback : If present LINEOUT2 has common mode feedback
connected.
- wlf,ldoena-always-driven : If present LDOENA is always driven.
Example:
codec: wm8994@1a {
compatible = "wlf,wm8994";
reg = <0x1a>;
gpio-controller;
#gpio-cells = <2>;
lineout1-se;
AVDD2-supply = <&regulator>;
CPVDD-supply = <&regulator>;
DBVDD1-supply = <&regulator>;
DBVDD2-supply = <&regulator>;
DBVDD3-supply = <&regulator>;
SPKVDD1-supply = <&regulator>;
SPKVDD2-supply = <&regulator>;
};

12
Documentation/devicetree/bindings/spi/mxs-spi.txt
View file

@ -3,8 +3,11 @@
Required properties:
- compatible: Should be "fsl,<soc>-spi", where soc is "imx23" or "imx28"
- reg: Offset and length of the register set for the device
- interrupts: Should contain SSP interrupts (error irq first, dma irq second)
- fsl,ssp-dma-channel: APBX DMA channel for the SSP
- interrupts: Should contain SSP ERROR interrupt
- dmas: DMA specifier, consisting of a phandle to DMA controller node
and SSP DMA channel ID.
Refer to dma.txt and fsl-mxs-dma.txt for details.
- dma-names: Must be "rx-tx".
Optional properties:
- clock-frequency : Input clock frequency to the SPI block in Hz.
@ -17,6 +20,7 @@ ssp0: ssp@80010000 {
#size-cells = <0>;
compatible = "fsl,imx28-spi";
reg = <0x80010000 0x2000>;
interrupts = <96 82>;
fsl,ssp-dma-channel = <0>;
interrupts = <96>;
dmas = <&dma_apbh 0>;
dma-names = "rx-tx";
};

51
Documentation/devicetree/bindings/spi/spi-davinci.txt Normal file
View file

@ -0,0 +1,51 @@
Davinci SPI controller device bindings
Required properties:
- #address-cells: number of cells required to define a chip select
address on the SPI bus. Should be set to 1.
- #size-cells: should be zero.
- compatible:
- "ti,dm6441-spi" for SPI used similar to that on DM644x SoC family
- "ti,da830-spi" for SPI used similar to that on DA8xx SoC family
- reg: Offset and length of SPI controller register space
- num-cs: Number of chip selects
- ti,davinci-spi-intr-line: interrupt line used to connect the SPI
IP to the interrupt controller within the SoC. Possible values
are 0 and 1. Manual says one of the two possible interrupt
lines can be tied to the interrupt controller. Set this
based on a specifc SoC configuration.
- interrupts: interrupt number mapped to CPU.
- clocks: spi clk phandle
Example of a NOR flash slave device (n25q032) connected to DaVinci
SPI controller device over the SPI bus.
spi0:spi@20BF0000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "ti,dm6446-spi";
reg = <0x20BF0000 0x1000>;
num-cs = <4>;
ti,davinci-spi-intr-line = <0>;
interrupts = <338>;
clocks = <&clkspi>;
flash: n25q032@0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "st,m25p32";
spi-max-frequency = <25000000>;
reg = <0>;
partition@0 {
label = "u-boot-spl";
reg = <0x0 0x80000>;
read-only;
};
partition@1 {
label = "test";
reg = <0x80000 0x380000>;
};
};
};

36
Documentation/devicetree/bindings/spi/spi_pl022.txt
View file

@ -16,6 +16,11 @@ Optional properties:
device will be suspended immediately
- pl022,rt : indicates the controller should run the message pump with realtime
priority to minimise the transfer latency on the bus (boolean)
- dmas : Two or more DMA channel specifiers following the convention outlined
in bindings/dma/dma.txt
- dma-names: Names for the dma channels, if present. There must be at
least one channel named "tx" for transmit and named "rx" for
receive.
SPI slave nodes must be children of the SPI master node and can
@ -32,3 +37,34 @@ contain the following properties.
- pl022,wait-state : Microwire interface: Wait state
- pl022,duplex : Microwire interface: Full/Half duplex
Example:
spi@e0100000 {
compatible = "arm,pl022", "arm,primecell";
reg = <0xe0100000 0x1000>;
#address-cells = <1>;
#size-cells = <0>;
interrupts = <0 31 0x4>;
dmas = <&dma-controller 23 1>,
<&dma-controller 24 0>;
dma-names = "rx", "tx";
m25p80@1 {
compatible = "st,m25p80";
reg = <1>;
spi-max-frequency = <12000000>;
spi-cpol;
spi-cpha;
pl022,hierarchy = <0>;
pl022,interface = <0>;
pl022,slave-tx-disable;
pl022,com-mode = <0x2>;
pl022,rx-level-trig = <0>;
pl022,tx-level-trig = <0>;
pl022,ctrl-len = <0x11>;
pl022,wait-state = <0>;
pl022,duplex = <0>;
};
};

3
Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
View file

@ -8,6 +8,8 @@ Required properties:
- interrupts: Should contain sync interrupt and error interrupt,
in this order.
- #crtc-cells: 1, See below
- resets: phandle pointing to the system reset controller and
reset line index, see reset/fsl,imx-src.txt for details
example:
@ -16,6 +18,7 @@ ipu: ipu@18000000 {
compatible = "fsl,imx53-ipu";
reg = <0x18000000 0x080000000>;
interrupts = <11 10>;
resets = <&src 2>;
};
Parallel display support

22
Documentation/devicetree/bindings/thermal/armada-thermal.txt Normal file
View file

@ -0,0 +1,22 @@
* Marvell Armada 370/XP thermal management
Required properties:
- compatible: Should be set to one of the following:
marvell,armada370-thermal
marvell,armadaxp-thermal
- reg: Device's register space.
Two entries are expected, see the examples below.
The first one is required for the sensor register;
the second one is required for the control register
to be used for sensor initialization (a.k.a. calibration).
Example:
thermal@d0018300 {
compatible = "marvell,armada370-thermal";
reg = <0xd0018300 0x4
0xd0018304 0x4>;
status = "okay";
};

29
Documentation/devicetree/bindings/timer/arm,sp804.txt Normal file
View file

@ -0,0 +1,29 @@
ARM sp804 Dual Timers
---------------------------------------
Required properties:
- compatible: Should be "arm,sp804" & "arm,primecell"
- interrupts: Should contain the list of Dual Timer interrupts. This is the
interrupt for timer 1 and timer 2. In the case of a single entry, it is
the combined interrupt or if "arm,sp804-has-irq" is present that
specifies which timer interrupt is connected.
- reg: Should contain location and length for dual timer register.
- clocks: clocks driving the dual timer hardware. This list should be 1 or 3
clocks. With 3 clocks, the order is timer0 clock, timer1 clock,
apb_pclk. A single clock can also be specified if the same clock is
used for all clock inputs.
Optional properties:
- arm,sp804-has-irq = <#>: In the case of only 1 timer irq line connected, this
specifies if the irq connection is for timer 1 or timer 2. A value of 1
or 2 should be used.
Example:
timer0: timer@fc800000 {
compatible = "arm,sp804", "arm,primecell";
reg = <0xfc800000 0x1000>;
interrupts = <0 0 4>, <0 1 4>;
clocks = <&timclk1 &timclk2 &pclk>;
clock-names = "timer1", "timer2", "apb_pclk";
};

16
Documentation/devicetree/bindings/tty/serial/fsl-mxs-auart.txt
View file

@ -5,20 +5,18 @@ Required properties:
imx23 and imx28.
- reg : Address and length of the register set for the device
- interrupts : Should contain the auart interrupt numbers
Optional properties:
- fsl,auart-dma-channel : The DMA channels, the first is for RX, the other
is for TX. If you add this property, it also means that you
will enable the DMA support for the auart.
Note: due to the hardware bug in imx23(see errata : 2836),
only the imx28 can enable the DMA support for the auart.
- dmas: DMA specifier, consisting of a phandle to DMA controller node
and AUART DMA channel ID.
Refer to dma.txt and fsl-mxs-dma.txt for details.
- dma-names: "rx" for RX channel, "tx" for TX channel.
Example:
auart0: serial@8006a000 {
compatible = "fsl,imx28-auart", "fsl,imx23-auart";
reg = <0x8006a000 0x2000>;
interrupts = <112 70 71>;
fsl,auart-dma-channel = <8 9>;
interrupts = <112>;
dmas = <&dma_apbx 8>, <&dma_apbx 9>;
dma-names = "rx", "tx";
};
Note: Each auart port should have an alias correctly numbered in "aliases"

10
Documentation/devicetree/bindings/usb/exynos-usb.txt
View file

@ -10,6 +10,8 @@ Required properties:
- reg: physical base address of the controller and length of memory mapped
region.
- interrupts: interrupt number to the cpu.
- clocks: from common clock binding: handle to usb clock.
- clock-names: from common clock binding: Shall be "usbhost".
Optional properties:
- samsung,vbus-gpio: if present, specifies the GPIO that
@ -22,6 +24,9 @@ Example:
reg = <0x12110000 0x100>;
interrupts = <0 71 0>;
samsung,vbus-gpio = <&gpx2 6 1 3 3>;
clocks = <&clock 285>;
clock-names = "usbhost";
};
OHCI
@ -31,10 +36,15 @@ Required properties:
- reg: physical base address of the controller and length of memory mapped
region.
- interrupts: interrupt number to the cpu.
- clocks: from common clock binding: handle to usb clock.
- clock-names: from common clock binding: Shall be "usbhost".
Example:
usb@12120000 {
compatible = "samsung,exynos4210-ohci";
reg = <0x12120000 0x100>;
interrupts = <0 71 0>;
clocks = <&clock 285>;
clock-names = "usbhost";
};

1
Documentation/devicetree/bindings/usb/omap-usb.txt
View file

@ -18,6 +18,7 @@ OMAP MUSB GLUE
represents PERIPHERAL.
- power : Should be "50". This signifies the controller can supply upto
100mA when operating in host mode.
- usb-phy : the phandle for the PHY device
Optional properties:
- ctrl-module : phandle of the control module this glue uses to write to

1
Documentation/devicetree/bindings/vendor-prefixes.txt
View file

@ -42,6 +42,7 @@ onnn ON Semiconductor Corp.
picochip Picochip Ltd
powervr PowerVR (deprecated, use img)
qcom Qualcomm, Inc.
ralink Mediatek/Ralink Technology Corp.
ramtron Ramtron International
realtek Realtek Semiconductor Corp.
renesas Renesas Electronics Corporation

0
Documentation/devicetree/bindings/drm/exynos/hdmi.txt → Documentation/devicetree/bindings/video/exynos_hdmi.txt
View file

0
Documentation/devicetree/bindings/drm/exynos/hdmiddc.txt → Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
View file

0
Documentation/devicetree/bindings/drm/exynos/hdmiphy.txt → Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
View file

0
Documentation/devicetree/bindings/drm/exynos/mixer.txt → Documentation/devicetree/bindings/video/exynos_mixer.txt
View file

65
Documentation/devicetree/bindings/video/samsung-fimd.txt Normal file
View file

@ -0,0 +1,65 @@
Device-Tree bindings for Samsung SoC display controller (FIMD)
FIMD (Fully Interactive Mobile Display) is the Display Controller for the
Samsung series of SoCs which transfers the image data from a video memory
buffer to an external LCD interface.
Required properties:
- compatible: value should be one of the following
"samsung,s3c2443-fimd"; /* for S3C24XX SoCs */
"samsung,s3c6400-fimd"; /* for S3C64XX SoCs */
"samsung,s5p6440-fimd"; /* for S5P64X0 SoCs */
"samsung,s5pc100-fimd"; /* for S5PC100 SoC */
"samsung,s5pv210-fimd"; /* for S5PV210 SoC */
"samsung,exynos4210-fimd"; /* for Exynos4 SoCs */
"samsung,exynos5250-fimd"; /* for Exynos5 SoCs */
- reg: physical base address and length of the FIMD registers set.
- interrupt-parent: should be the phandle of the fimd controller's
parent interrupt controller.
- interrupts: should contain a list of all FIMD IP block interrupts in the
order: FIFO Level, VSYNC, LCD_SYSTEM. The interrupt specifier
format depends on the interrupt controller used.
- interrupt-names: should contain the interrupt names: "fifo", "vsync",
"lcd_sys", in the same order as they were listed in the interrupts
property.
- pinctrl-0: pin control group to be used for this controller.
- pinctrl-names: must contain a "default" entry.
- clocks: must include clock specifiers corresponding to entries in the
clock-names property.
- clock-names: list of clock names sorted in the same order as the clocks
property. Must contain "sclk_fimd" and "fimd".
Optional Properties:
- samsung,power-domain: a phandle to FIMD power domain node.
Example:
SoC specific DT entry:
fimd@11c00000 {
compatible = "samsung,exynos4210-fimd";
interrupt-parent = <&combiner>;
reg = <0x11c00000 0x20000>;
interrupt-names = "fifo", "vsync", "lcd_sys";
interrupts = <11 0>, <11 1>, <11 2>;
clocks = <&clock 140>, <&clock 283>;
clock-names = "sclk_fimd", "fimd";
samsung,power-domain = <&pd_lcd0>;
status = "disabled";
};
Board specific DT entry:
fimd@11c00000 {
pinctrl-0 = <&lcd_clk &lcd_data24 &pwm1_out>;
pinctrl-names = "default";
status = "okay";
};

25
Documentation/devicetree/bindings/video/simple-framebuffer.txt Normal file
View file

@ -0,0 +1,25 @@
Simple Framebuffer
A simple frame-buffer describes a raw memory region that may be rendered to,
with the assumption that the display hardware has already been set up to scan
out from that buffer.
Required properties:
- compatible: "simple-framebuffer"
- reg: Should contain the location and size of the framebuffer memory.
- width: The width of the framebuffer in pixels.
- height: The height of the framebuffer in pixels.
- stride: The number of bytes in each line of the framebuffer.
- format: The format of the framebuffer surface. Valid values are:
- r5g6b5 (16-bit pixels, d[15:11]=r, d[10:5]=g, d[4:0]=b).
Example:
framebuffer {
compatible = "simple-framebuffer";
reg = <0x1d385000 (1600 * 1200 * 2)>;
width = <1600>;
height = <1200>;
stride = <(1600 * 2)>;
format = "r5g6b5";
};

8
Documentation/devicetree/usage-model.txt
View file

@ -191,9 +191,11 @@ Linux it will look something like this:
};
The bootargs property contains the kernel arguments, and the initrd-*
properties define the address and size of an initrd blob. The
chosen node may also optionally contain an arbitrary number of
additional properties for platform-specific configuration data.
properties define the address and size of an initrd blob. Note that
initrd-end is the first address after the initrd image, so this doesn't
match the usual semantic of struct resource. The chosen node may also
optionally contain an arbitrary number of additional properties for
platform-specific configuration data.
During early boot, the architecture setup code calls of_scan_flat_dt()
several times with different helper callbacks to parse device tree

81
Documentation/dmatest.txt Normal file
View file

@ -0,0 +1,81 @@
DMA Test Guide
==============
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
This small document introduces how to test DMA drivers using dmatest module.
Part 1 - How to build the test module
The menuconfig contains an option that could be found by following path:
Device Drivers -> DMA Engine support -> DMA Test client
In the configuration file the option called CONFIG_DMATEST. The dmatest could
be built as module or inside kernel. Let's consider those cases.
Part 2 - When dmatest is built as a module...
After mounting debugfs and loading the module, the /sys/kernel/debug/dmatest
folder with nodes will be created. They are the same as module parameters with
addition of the 'run' node that controls run and stop phases of the test.
Note that in this case test will not run on load automatically.
Example of usage:
% echo dma0chan0 > /sys/kernel/debug/dmatest/channel
% echo 2000 > /sys/kernel/debug/dmatest/timeout
% echo 1 > /sys/kernel/debug/dmatest/iterations
% echo 1 > /sys/kernel/debug/dmatest/run
Hint: available channel list could be extracted by running the following
command:
% ls -1 /sys/class/dma/
After a while you will start to get messages about current status or error like
in the original code.
Note that running a new test will stop any in progress test.
The following command should return actual state of the test.
% cat /sys/kernel/debug/dmatest/run
To wait for test done the user may perform a busy loop that checks the state.
% while [ $(cat /sys/kernel/debug/dmatest/run) = "Y" ]
> do
> echo -n "."
> sleep 1
> done
> echo
Part 3 - When built-in in the kernel...
The module parameters that is supplied to the kernel command line will be used
for the first performed test. After user gets a control, the test could be
interrupted or re-run with same or different parameters. For the details see
the above section "Part 2 - When dmatest is built as a module..."
In both cases the module parameters are used as initial values for the test case.
You always could check them at run-time by running
% grep -H . /sys/module/dmatest/parameters/*
Part 4 - Gathering the test results
The module provides a storage for the test results in the memory. The gathered
data could be used after test is done.
The special file 'results' in the debugfs represents gathered data of the in
progress test. The messages collected are printed to the kernel log as well.
Example of output:
% cat /sys/kernel/debug/dmatest/results
dma0chan0-copy0: #1: No errors with src_off=0x7bf dst_off=0x8ad len=0x3fea (0)
The message format is unified across the different types of errors. A number in
the parens represents additional information, e.g. error code, error counter,
or status.
Comparison between buffers is stored to the dedicated structure.
Note that the verify result is now accessible only via file 'results' in the
debugfs.

180
Documentation/filesystems/btrfs.txt
View file

@ -1,8 +1,8 @@
BTRFS
=====
BTRFS
=====
Btrfs is a new copy on write filesystem for Linux aimed at
Btrfs is a copy on write filesystem for Linux aimed at
implementing advanced features while focusing on fault tolerance,
repair and easy administration. Initially developed by Oracle, Btrfs
is licensed under the GPL and open for contribution from anyone.
@ -34,9 +34,175 @@ The main Btrfs features include:
* Online filesystem defragmentation
Mount Options
=============
MAILING LIST
============
When mounting a btrfs filesystem, the following option are accepted.
Unless otherwise specified, all options default to off.
alloc_start=<bytes>
Debugging option to force all block allocations above a certain
byte threshold on each block device. The value is specified in
bytes, optionally with a K, M, or G suffix, case insensitive.
Default is 1MB.
autodefrag
Detect small random writes into files and queue them up for the
defrag process. Works best for small files; Not well suited for
large database workloads.
check_int
check_int_data
check_int_print_mask=<value>
These debugging options control the behavior of the integrity checking
module (the BTRFS_FS_CHECK_INTEGRITY config option required).
check_int enables the integrity checker module, which examines all
block write requests to ensure on-disk consistency, at a large
memory and CPU cost.
check_int_data includes extent data in the integrity checks, and
implies the check_int option.
check_int_print_mask takes a bitmask of BTRFSIC_PRINT_MASK_* values
as defined in fs/btrfs/check-integrity.c, to control the integrity
checker module behavior.
See comments at the top of fs/btrfs/check-integrity.c for more info.
compress
compress=<type>
compress-force
compress-force=<type>
Control BTRFS file data compression. Type may be specified as "zlib"
"lzo" or "no" (for no compression, used for remounting). If no type
is specified, zlib is used. If compress-force is specified,
all files will be compressed, whether or not they compress well.
If compression is enabled, nodatacow and nodatasum are disabled.
degraded
Allow mounts to continue with missing devices. A read-write mount may
fail with too many devices missing, for example if a stripe member
is completely missing.
device=<devicepath>
Specify a device during mount so that ioctls on the control device
can be avoided. Especialy useful when trying to mount a multi-device
setup as root. May be specified multiple times for multiple devices.
discard
Issue frequent commands to let the block device reclaim space freed by
the filesystem. This is useful for SSD devices, thinly provisioned
LUNs and virtual machine images, but may have a significant
performance impact. (The fstrim command is also available to
initiate batch trims from userspace).
enospc_debug
Debugging option to be more verbose in some ENOSPC conditions.
fatal_errors=<action>
Action to take when encountering a fatal error:
"bug" - BUG() on a fatal error. This is the default.
"panic" - panic() on a fatal error.
flushoncommit
The 'flushoncommit' mount option forces any data dirtied by a write in a
prior transaction to commit as part of the current commit. This makes
the committed state a fully consistent view of the file system from the
application's perspective (i.e., it includes all completed file system
operations). This was previously the behavior only when a snapshot is
created.
inode_cache
Enable free inode number caching. Defaults to off due to an overflow
problem when the free space crcs don't fit inside a single page.
max_inline=<bytes>
Specify the maximum amount of space, in bytes, that can be inlined in
a metadata B-tree leaf. The value is specified in bytes, optionally
with a K, M, or G suffix, case insensitive. In practice, this value
is limited by the root sector size, with some space unavailable due
to leaf headers. For a 4k sectorsize, max inline data is ~3900 bytes.
metadata_ratio=<value>
Specify that 1 metadata chunk should be allocated after every <value>
data chunks. Off by default.
noacl
Disable support for Posix Access Control Lists (ACLs). See the
acl(5) manual page for more information about ACLs.
nobarrier
Disables the use of block layer write barriers. Write barriers ensure
that certain IOs make it through the device cache and are on persistent
storage. If used on a device with a volatile (non-battery-backed)
write-back cache, this option will lead to filesystem corruption on a
system crash or power loss.
nodatacow
Disable data copy-on-write for newly created files. Implies nodatasum,
and disables all compression.
nodatasum
Disable data checksumming for newly created files.
notreelog
Disable the tree logging used for fsync and O_SYNC writes.
recovery
Enable autorecovery attempts if a bad tree root is found at mount time.
Currently this scans a list of several previous tree roots and tries to
use the first readable.
skip_balance
Skip automatic resume of interrupted balance operation after mount.
May be resumed with "btrfs balance resume."
space_cache (*)
Enable the on-disk freespace cache.
nospace_cache
Disable freespace cache loading without clearing the cache.
clear_cache
Force clearing and rebuilding of the disk space cache if something
has gone wrong.
ssd
nossd
ssd_spread
Options to control ssd allocation schemes. By default, BTRFS will
enable or disable ssd allocation heuristics depending on whether a
rotational or nonrotational disk is in use. The ssd and nossd options
can override this autodetection.
The ssd_spread mount option attempts to allocate into big chunks
of unused space, and may perform better on low-end ssds. ssd_spread
implies ssd, enabling all other ssd heuristics as well.
subvol=<path>
Mount subvolume at <path> rather than the root subvolume. <path> is
relative to the top level subvolume.
subvolid=<ID>
Mount subvolume specified by an ID number rather than the root subvolume.
This allows mounting of subvolumes which are not in the root of the mounted
filesystem.
You can use "btrfs subvolume list" to see subvolume ID numbers.
subvolrootid=<objectid> (deprecated)
Mount subvolume specified by <objectid> rather than the root subvolume.
This allows mounting of subvolumes which are not in the root of the mounted
filesystem.
You can use "btrfs subvolume show " to see the object ID for a subvolume.
thread_pool=<number>
The number of worker threads to allocate. The default number is equal
to the number of CPUs + 2, or 8, whichever is smaller.
user_subvol_rm_allowed
Allow subvolumes to be deleted by a non-root user. Use with caution.
MAILING LIST
============
There is a Btrfs mailing list hosted on vger.kernel.org. You can
find details on how to subscribe here:
@ -49,8 +215,8 @@ http://dir.gmane.org/gmane.comp.file-systems.btrfs
IRC
===
IRC
===
Discussion of Btrfs also occurs on the #btrfs channel of the Freenode
IRC network.

4
Documentation/filesystems/f2fs.txt
View file

@ -146,7 +146,7 @@ USAGE
Format options
--------------
-l [label] : Give a volume label, up to 256 unicode name.
-l [label] : Give a volume label, up to 512 unicode name.
-a [0 or 1] : Split start location of each area for heap-based allocation.
1 is set by default, which performs this.
-o [int] : Set overprovision ratio in percent over volume size.
@ -156,6 +156,8 @@ Format options
-z [int] : Set the number of sections per zone.
1 is set by default.
-e [str] : Set basic extension list. e.g. "mp3,gif,mov"
-t [0 or 1] : Disable discard command or not.
1 is set by default, which conducts discard.
================================================================================
DESIGN

10
Documentation/gpio.txt
View file

@ -72,11 +72,11 @@ in this document, but drivers acting as clients to the GPIO interface must
not care how it's implemented.)
That said, if the convention is supported on their platform, drivers should
use it when possible. Platforms must declare GENERIC_GPIO support in their
Kconfig (boolean true), and provide an <asm/gpio.h> file. Drivers that can't
work without standard GPIO calls should have Kconfig entries which depend
on GENERIC_GPIO. The GPIO calls are available, either as "real code" or as
optimized-away stubs, when drivers use the include file:
use it when possible. Platforms must select ARCH_REQUIRE_GPIOLIB or
ARCH_WANT_OPTIONAL_GPIOLIB in their Kconfig. Drivers that can't work without
standard GPIO calls should have Kconfig entries which depend on GPIOLIB. The
GPIO calls are available, either as "real code" or as optimized-away stubs,
when drivers use the include file:
#include <linux/gpio.h>

36
Documentation/kbuild/kconfig.txt
View file

@ -89,6 +89,42 @@ These examples will disable most options (allnoconfig) but enable or
disable the options that are explicitly listed in the specified
mini-config files.
______________________________________________________________________
Environment variables for 'randconfig'
KCONFIG_SEED
--------------------------------------------------
You can set this to the integer value used to seed the RNG, if you want
to somehow debug the behaviour of the kconfig parser/frontends.
If not set, the current time will be used.
KCONFIG_PROBABILITY
--------------------------------------------------
This variable can be used to skew the probabilities. This variable can
be unset or empty, or set to three different formats:
KCONFIG_PROBABILITY y:n split y:m:n split
-----------------------------------------------------------------
unset or empty 50 : 50 33 : 33 : 34
N N : 100-N N/2 : N/2 : 100-N
[1] N:M N+M : 100-(N+M) N : M : 100-(N+M)
[2] N:M:L N : 100-N M : L : 100-(M+L)
where N, M and L are integers (in base 10) in the range [0,100], and so
that:
[1] N+M is in the range [0,100]
[2] M+L is in the range [0,100]
Examples:
KCONFIG_PROBABILITY=10
10% of booleans will be set to 'y', 90% to 'n'
5% of tristates will be set to 'y', 5% to 'm', 90% to 'n'
KCONFIG_PROBABILITY=15:25
40% of booleans will be set to 'y', 60% to 'n'
15% of tristates will be set to 'y', 25% to 'm', 60% to 'n'
KCONFIG_PROBABILITY=10:15:15
10% of booleans will be set to 'y', 90% to 'n'
15% of tristates will be set to 'y', 15% to 'm', 70% to 'n'
______________________________________________________________________
Environment variables for 'silentoldconfig'

7
Documentation/kbuild/makefiles.txt
View file

@ -593,7 +593,7 @@ more details, with real examples.
Example:
#Makefile
LDFLAGS_vmlinux += $(call really-ld-option, -X)
LDFLAGS_vmlinux += $(call ld-option, -X)
=== 4 Host Program support
@ -921,8 +921,9 @@ When kbuild executes, the following steps are followed (roughly):
Often, the KBUILD_CFLAGS variable depends on the configuration.
Example:
#arch/x86/Makefile
cflags-$(CONFIG_M386) += -march=i386
#arch/x86/boot/compressed/Makefile
cflags-$(CONFIG_X86_32) := -march=i386
cflags-$(CONFIG_X86_64) := -mcmodel=small
KBUILD_CFLAGS += $(cflags-y)
Many arch Makefiles dynamically run the target C compiler to

35
Documentation/kernel-parameters.txt
View file

@ -1277,6 +1277,20 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
iucv= [HW,NET]
ivrs_ioapic [HW,X86_64]
Provide an override to the IOAPIC-ID<->DEVICE-ID
mapping provided in the IVRS ACPI table. For
example, to map IOAPIC-ID decimal 10 to
PCI device 00:14.0 write the parameter as:
ivrs_ioapic[10]=00:14.0
ivrs_hpet [HW,X86_64]
Provide an override to the HPET-ID<->DEVICE-ID
mapping provided in the IVRS ACPI table. For
example, to map HPET-ID decimal 0 to
PCI device 00:14.0 write the parameter as:
ivrs_hpet[0]=00:14.0
js= [HW,JOY] Analog joystick
See Documentation/input/joystick.txt.
@ -2991,6 +3005,27 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
Force threading of all interrupt handlers except those
marked explicitly IRQF_NO_THREAD.
tmem [KNL,XEN]
Enable the Transcendent memory driver if built-in.
tmem.cleancache=0|1 [KNL, XEN]
Default is on (1). Disable the usage of the cleancache
API to send anonymous pages to the hypervisor.
tmem.frontswap=0|1 [KNL, XEN]
Default is on (1). Disable the usage of the frontswap
API to send swap pages to the hypervisor. If disabled
the selfballooning and selfshrinking are force disabled.
tmem.selfballooning=0|1 [KNL, XEN]
Default is on (1). Disable the driving of swap pages
to the hypervisor.
tmem.selfshrinking=0|1 [KNL, XEN]
Default is on (1). Partial swapoff that immediately
transfers pages from Xen hypervisor back to the
kernel based on different criteria.
topology= [S390]
Format: {off | on}
Specify if the kernel should make use of the cpu

202
Documentation/kernel-per-CPU-kthreads.txt Normal file
View file

@ -0,0 +1,202 @@
REDUCING OS JITTER DUE TO PER-CPU KTHREADS
This document lists per-CPU kthreads in the Linux kernel and presents
options to control their OS jitter. Note that non-per-CPU kthreads are
not listed here. To reduce OS jitter from non-per-CPU kthreads, bind
them to a "housekeeping" CPU dedicated to such work.
REFERENCES
o Documentation/IRQ-affinity.txt: Binding interrupts to sets of CPUs.
o Documentation/cgroups: Using cgroups to bind tasks to sets of CPUs.
o man taskset: Using the taskset command to bind tasks to sets
of CPUs.
o man sched_setaffinity: Using the sched_setaffinity() system
call to bind tasks to sets of CPUs.
o /sys/devices/system/cpu/cpuN/online: Control CPU N's hotplug state,
writing "0" to offline and "1" to online.
o In order to locate kernel-generated OS jitter on CPU N:
cd /sys/kernel/debug/tracing
echo 1 > max_graph_depth # Increase the "1" for more detail
echo function_graph > current_tracer
# run workload
cat per_cpu/cpuN/trace
KTHREADS
Name: ehca_comp/%u
Purpose: Periodically process Infiniband-related work.
To reduce its OS jitter, do any of the following:
1. Don't use eHCA Infiniband hardware, instead choosing hardware
that does not require per-CPU kthreads. This will prevent these
kthreads from being created in the first place. (This will
work for most people, as this hardware, though important, is
relatively old and is produced in relatively low unit volumes.)
2. Do all eHCA-Infiniband-related work on other CPUs, including
interrupts.
3. Rework the eHCA driver so that its per-CPU kthreads are
provisioned only on selected CPUs.
Name: irq/%d-%s
Purpose: Handle threaded interrupts.
To reduce its OS jitter, do the following:
1. Use irq affinity to force the irq threads to execute on
some other CPU.
Name: kcmtpd_ctr_%d
Purpose: Handle Bluetooth work.
To reduce its OS jitter, do one of the following:
1. Don't use Bluetooth, in which case these kthreads won't be
created in the first place.
2. Use irq affinity to force Bluetooth-related interrupts to
occur on some other CPU and furthermore initiate all
Bluetooth activity on some other CPU.
Name: ksoftirqd/%u
Purpose: Execute softirq handlers when threaded or when under heavy load.
To reduce its OS jitter, each softirq vector must be handled
separately as follows:
TIMER_SOFTIRQ: Do all of the following:
1. To the extent possible, keep the CPU out of the kernel when it
is non-idle, for example, by avoiding system calls and by forcing
both kernel threads and interrupts to execute elsewhere.
2. Build with CONFIG_HOTPLUG_CPU=y. After boot completes, force
the CPU offline, then bring it back online. This forces
recurring timers to migrate elsewhere. If you are concerned
with multiple CPUs, force them all offline before bringing the
first one back online. Once you have onlined the CPUs in question,
do not offline any other CPUs, because doing so could force the
timer back onto one of the CPUs in question.
NET_TX_SOFTIRQ and NET_RX_SOFTIRQ: Do all of the following:
1. Force networking interrupts onto other CPUs.
2. Initiate any network I/O on other CPUs.
3. Once your application has started, prevent CPU-hotplug operations
from being initiated from tasks that might run on the CPU to
be de-jittered. (It is OK to force this CPU offline and then
bring it back online before you start your application.)
BLOCK_SOFTIRQ: Do all of the following:
1. Force block-device interrupts onto some other CPU.
2. Initiate any block I/O on other CPUs.
3. Once your application has started, prevent CPU-hotplug operations
from being initiated from tasks that might run on the CPU to
be de-jittered. (It is OK to force this CPU offline and then
bring it back online before you start your application.)
BLOCK_IOPOLL_SOFTIRQ: Do all of the following:
1. Force block-device interrupts onto some other CPU.
2. Initiate any block I/O and block-I/O polling on other CPUs.
3. Once your application has started, prevent CPU-hotplug operations
from being initiated from tasks that might run on the CPU to
be de-jittered. (It is OK to force this CPU offline and then
bring it back online before you start your application.)
TASKLET_SOFTIRQ: Do one or more of the following:
1. Avoid use of drivers that use tasklets. (Such drivers will contain
calls to things like tasklet_schedule().)
2. Convert all drivers that you must use from tasklets to workqueues.
3. Force interrupts for drivers using tasklets onto other CPUs,
and also do I/O involving these drivers on other CPUs.
SCHED_SOFTIRQ: Do all of the following:
1. Avoid sending scheduler IPIs to the CPU to be de-jittered,
for example, ensure that at most one runnable kthread is present
on that CPU. If a thread that expects to run on the de-jittered
CPU awakens, the scheduler will send an IPI that can result in
a subsequent SCHED_SOFTIRQ.
2. Build with CONFIG_RCU_NOCB_CPU=y, CONFIG_RCU_NOCB_CPU_ALL=y,
CONFIG_NO_HZ_FULL=y, and, in addition, ensure that the CPU
to be de-jittered is marked as an adaptive-ticks CPU using the
"nohz_full=" boot parameter. This reduces the number of
scheduler-clock interrupts that the de-jittered CPU receives,
minimizing its chances of being selected to do the load balancing
work that runs in SCHED_SOFTIRQ context.
3. To the extent possible, keep the CPU out of the kernel when it
is non-idle, for example, by avoiding system calls and by
forcing both kernel threads and interrupts to execute elsewhere.
This further reduces the number of scheduler-clock interrupts
received by the de-jittered CPU.
HRTIMER_SOFTIRQ: Do all of the following:
1. To the extent possible, keep the CPU out of the kernel when it
is non-idle. For example, avoid system calls and force both
kernel threads and interrupts to execute elsewhere.
2. Build with CONFIG_HOTPLUG_CPU=y. Once boot completes, force the
CPU offline, then bring it back online. This forces recurring
timers to migrate elsewhere. If you are concerned with multiple
CPUs, force them all offline before bringing the first one
back online. Once you have onlined the CPUs in question, do not
offline any other CPUs, because doing so could force the timer
back onto one of the CPUs in question.
RCU_SOFTIRQ: Do at least one of the following:
1. Offload callbacks and keep the CPU in either dyntick-idle or
adaptive-ticks state by doing all of the following:
a. Build with CONFIG_RCU_NOCB_CPU=y, CONFIG_RCU_NOCB_CPU_ALL=y,
CONFIG_NO_HZ_FULL=y, and, in addition ensure that the CPU
to be de-jittered is marked as an adaptive-ticks CPU using
the "nohz_full=" boot parameter. Bind the rcuo kthreads
to housekeeping CPUs, which can tolerate OS jitter.
b. To the extent possible, keep the CPU out of the kernel
when it is non-idle, for example, by avoiding system
calls and by forcing both kernel threads and interrupts
to execute elsewhere.
2. Enable RCU to do its processing remotely via dyntick-idle by
doing all of the following:
a. Build with CONFIG_NO_HZ=y and CONFIG_RCU_FAST_NO_HZ=y.
b. Ensure that the CPU goes idle frequently, allowing other
CPUs to detect that it has passed through an RCU quiescent
state. If the kernel is built with CONFIG_NO_HZ_FULL=y,
userspace execution also allows other CPUs to detect that
the CPU in question has passed through a quiescent state.
c. To the extent possible, keep the CPU out of the kernel
when it is non-idle, for example, by avoiding system
calls and by forcing both kernel threads and interrupts
to execute elsewhere.
Name: rcuc/%u
Purpose: Execute RCU callbacks in CONFIG_RCU_BOOST=y kernels.
To reduce its OS jitter, do at least one of the following:
1. Build the kernel with CONFIG_PREEMPT=n. This prevents these
kthreads from being created in the first place, and also obviates
the need for RCU priority boosting. This approach is feasible
for workloads that do not require high degrees of responsiveness.
2. Build the kernel with CONFIG_RCU_BOOST=n. This prevents these
kthreads from being created in the first place. This approach
is feasible only if your workload never requires RCU priority
boosting, for example, if you ensure frequent idle time on all
CPUs that might execute within the kernel.
3. Build with CONFIG_RCU_NOCB_CPU=y and CONFIG_RCU_NOCB_CPU_ALL=y,
which offloads all RCU callbacks to kthreads that can be moved
off of CPUs susceptible to OS jitter. This approach prevents the
rcuc/%u kthreads from having any work to do, so that they are
never awakened.
4. Ensure that the CPU never enters the kernel, and, in particular,
avoid initiating any CPU hotplug operations on this CPU. This is
another way of preventing any callbacks from being queued on the
CPU, again preventing the rcuc/%u kthreads from having any work
to do.
Name: rcuob/%d, rcuop/%d, and rcuos/%d
Purpose: Offload RCU callbacks from the corresponding CPU.
To reduce its OS jitter, do at least one of the following:
1. Use affinity, cgroups, or other mechanism to force these kthreads
to execute on some other CPU.
2. Build with CONFIG_RCU_NOCB_CPUS=n, which will prevent these
kthreads from being created in the first place. However, please
note that this will not eliminate OS jitter, but will instead
shift it to RCU_SOFTIRQ.
Name: watchdog/%u
Purpose: Detect software lockups on each CPU.
To reduce its OS jitter, do at least one of the following:
1. Build with CONFIG_LOCKUP_DETECTOR=n, which will prevent these
kthreads from being created in the first place.
2. Echo a zero to /proc/sys/kernel/watchdog to disable the
watchdog timer.
3. Echo a large number of /proc/sys/kernel/watchdog_thresh in
order to reduce the frequency of OS jitter due to the watchdog
timer down to a level that is acceptable for your workload.

2
Documentation/leds/00-INDEX
View file

@ -6,6 +6,8 @@ leds-lp5521.txt
- notes on how to use the leds-lp5521 driver.
leds-lp5523.txt
- notes on how to use the leds-lp5523 driver.
leds-lp5562.txt
- notes on how to use the leds-lp5562 driver.
leds-lp55xx.txt
- description about lp55xx common driver.
leds-lm3556.txt

19
Documentation/leds/leds-lp5521.txt
View file

@ -81,22 +81,3 @@ static struct lp55xx_platform_data lp5521_platform_data = {
If the current is set to 0 in the platform data, that channel is
disabled and it is not visible in the sysfs.
The 'update_config' : CONFIG register (ADDR 08h)
This value is platform-specific data.
If update_config is not defined, the CONFIG register is set with
'LP5521_PWRSAVE_EN | LP5521_CP_MODE_AUTO | LP5521_R_TO_BATT'.
(Enable auto-powersave, set charge pump to auto, red to battery)
example of update_config :
#define LP5521_CONFIGS (LP5521_PWM_HF | LP5521_PWRSAVE_EN | \
LP5521_CP_MODE_AUTO | LP5521_R_TO_BATT | \
LP5521_CLK_INT)
static struct lp55xx_platform_data lp5521_pdata = {
.led_config = lp5521_led_config,
.num_channels = ARRAY_SIZE(lp5521_led_config),
.clock_mode = LP55XX_CLOCK_INT,
.update_config = LP5521_CONFIGS,
};

120
Documentation/leds/leds-lp5562.txt Normal file
View file

@ -0,0 +1,120 @@
Kernel driver for LP5562
========================
* TI LP5562 LED Driver
Author: Milo(Woogyom) Kim <milo.kim@ti.com>
Description
LP5562 can drive up to 4 channels. R/G/B and White.
LEDs can be controlled directly via the led class control interface.
All four channels can be also controlled using the engine micro programs.
LP5562 has the internal program memory for running various LED patterns.
For the details, please refer to 'firmware' section in leds-lp55xx.txt
Device attribute: engine_mux
3 Engines are allocated in LP5562, but the number of channel is 4.
Therefore each channel should be mapped to the engine number.
Value : RGB or W
This attribute is used for programming LED data with the firmware interface.
Unlike the LP5521/LP5523/55231, LP5562 has unique feature for the engine mux,
so additional sysfs is required.
LED Map
Red ... Engine 1 (fixed)
Green ... Engine 2 (fixed)
Blue ... Engine 3 (fixed)
White ... Engine 1 or 2 or 3 (selective)
How to load the program data using engine_mux
Before loading the LP5562 program data, engine_mux should be written between
the engine selection and loading the firmware.
Engine mux has two different mode, RGB and W.
RGB is used for loading RGB program data, W is used for W program data.
For example, run blinking green channel pattern,
echo 2 > /sys/bus/i2c/devices/xxxx/select_engine # 2 is for green channel
echo "RGB" > /sys/bus/i2c/devices/xxxx/engine_mux # engine mux for RGB
echo 1 > /sys/class/firmware/lp5562/loading
echo "4000600040FF6000" > /sys/class/firmware/lp5562/data
echo 0 > /sys/class/firmware/lp5562/loading
echo 1 > /sys/bus/i2c/devices/xxxx/run_engine
To run a blinking white pattern,
echo 1 or 2 or 3 > /sys/bus/i2c/devices/xxxx/select_engine
echo "W" > /sys/bus/i2c/devices/xxxx/engine_mux
echo 1 > /sys/class/firmware/lp5562/loading
echo "4000600040FF6000" > /sys/class/firmware/lp5562/data
echo 0 > /sys/class/firmware/lp5562/loading
echo 1 > /sys/bus/i2c/devices/xxxx/run_engine
How to load the predefined patterns
Please refer to 'leds-lp55xx.txt"
Setting Current of Each Channel
Like LP5521 and LP5523/55231, LP5562 provides LED current settings.
The 'led_current' and 'max_current' are used.
(Example of Platform data)
To configure the platform specific data, lp55xx_platform_data structure is used.
static struct lp55xx_led_config lp5562_led_config[] = {
{
.name = "R",
.chan_nr = 0,
.led_current = 20,
.max_current = 40,
},
{
.name = "G",
.chan_nr = 1,
.led_current = 20,
.max_current = 40,
},
{
.name = "B",
.chan_nr = 2,
.led_current = 20,
.max_current = 40,
},
{
.name = "W",
.chan_nr = 3,
.led_current = 20,
.max_current = 40,
},
};
static int lp5562_setup(void)
{
/* setup HW resources */
}
static void lp5562_release(void)
{
/* Release HW resources */
}
static void lp5562_enable(bool state)
{
/* Control of chip enable signal */
}
static struct lp55xx_platform_data lp5562_platform_data = {
.led_config = lp5562_led_config,
.num_channels = ARRAY_SIZE(lp5562_led_config),
.setup_resources = lp5562_setup,
.release_resources = lp5562_release,
.enable = lp5562_enable,
};
If the current is set to 0 in the platform data, that channel is
disabled and it is not visible in the sysfs.

46
Documentation/leds/leds-lp55xx.txt
View file

@ -5,7 +5,7 @@ Authors: Milo(Woogyom) Kim <milo.kim@ti.com>
Description
-----------
LP5521, LP5523/55231 have common features as below.
LP5521, LP5523/55231 and LP5562 have common features as below.
Register access via the I2C
Device initialization/deinitialization
@ -116,3 +116,47 @@ To support this, 'run_engine' and 'firmware_cb' are configurable in each driver.
run_engine : Control the selected engine
firmware_cb : The callback function after loading the firmware is done.
Chip specific commands for loading and updating program memory.
( Predefined pattern data )
Without the firmware interface, LP55xx driver provides another method for
loading a LED pattern. That is 'predefined' pattern.
A predefined pattern is defined in the platform data and load it(or them)
via the sysfs if needed.
To use the predefined pattern concept, 'patterns' and 'num_patterns' should be
configured.
Example of predefined pattern data:
/* mode_1: blinking data */
static const u8 mode_1[] = {
0x40, 0x00, 0x60, 0x00, 0x40, 0xFF, 0x60, 0x00,
};
/* mode_2: always on */
static const u8 mode_2[] = { 0x40, 0xFF, };
struct lp55xx_predef_pattern board_led_patterns[] = {
{
.r = mode_1,
.size_r = ARRAY_SIZE(mode_1),
},
{
.b = mode_2,
.size_b = ARRAY_SIZE(mode_2),
},
}
struct lp55xx_platform_data lp5562_pdata = {
...
.patterns = board_led_patterns,
.num_patterns = ARRAY_SIZE(board_led_patterns),
};
Then, mode_1 and mode_2 can be run via through the sysfs.
echo 1 > /sys/bus/i2c/devices/xxxx/led_pattern # red blinking LED pattern
echo 2 > /sys/bus/i2c/devices/xxxx/led_pattern # blue LED always on
To stop running pattern,
echo 0 > /sys/bus/i2c/devices/xxxx/led_pattern

15
Documentation/power/devices.txt
View file

@ -268,7 +268,7 @@ situations.
System Power Management Phases
------------------------------
Suspending or resuming the system is done in several phases. Different phases
are used for standby or memory sleep states ("suspend-to-RAM") and the
are used for freeze, standby, and memory sleep states ("suspend-to-RAM") and the
hibernation state ("suspend-to-disk"). Each phase involves executing callbacks
for every device before the next phase begins. Not all busses or classes
support all these callbacks and not all drivers use all the callbacks. The
@ -309,7 +309,8 @@ execute the corresponding method from dev->driver->pm instead if there is one.
Entering System Suspend
-----------------------
When the system goes into the standby or memory sleep state, the phases are:
When the system goes into the freeze, standby or memory sleep state,
the phases are:
prepare, suspend, suspend_late, suspend_noirq.
@ -368,7 +369,7 @@ the devices that were suspended.
Leaving System Suspend
----------------------
When resuming from standby or memory sleep, the phases are:
When resuming from freeze, standby or memory sleep, the phases are:
resume_noirq, resume_early, resume, complete.
@ -433,8 +434,8 @@ the system log.
Entering Hibernation
--------------------
Hibernating the system is more complicated than putting it into the standby or
memory sleep state, because it involves creating and saving a system image.
Hibernating the system is more complicated than putting it into the other
sleep states, because it involves creating and saving a system image.
Therefore there are more phases for hibernation, with a different set of
callbacks. These phases always run after tasks have been frozen and memory has
been freed.
@ -485,8 +486,8 @@ image forms an atomic snapshot of the system state.
At this point the system image is saved, and the devices then need to be
prepared for the upcoming system shutdown. This is much like suspending them
before putting the system into the standby or memory sleep state, and the phases
are similar.
before putting the system into the freeze, standby or memory sleep state,
and the phases are similar.
9. The prepare phase is discussed above.

4
Documentation/power/interface.txt
View file

@ -7,8 +7,8 @@ running. The interface exists in /sys/power/ directory (assuming sysfs
is mounted at /sys).
/sys/power/state controls system power state. Reading from this file
returns what states are supported, which is hard-coded to 'standby'
(Power-On Suspend), 'mem' (Suspend-to-RAM), and 'disk'
returns what states are supported, which is hard-coded to 'freeze',
'standby' (Power-On Suspend), 'mem' (Suspend-to-RAM), and 'disk'
(Suspend-to-Disk).
Writing to this file one of those strings causes the system to

6
Documentation/power/notifiers.txt
View file

@ -15,8 +15,10 @@ A suspend/hibernation notifier may be used for this purpose.
The subsystems or drivers having such needs can register suspend notifiers that
will be called upon the following events by the PM core:
PM_HIBERNATION_PREPARE The system is going to hibernate or suspend, tasks will
be frozen immediately.
PM_HIBERNATION_PREPARE The system is going to hibernate, tasks will be frozen
immediately. This is different from PM_SUSPEND_PREPARE
below because here we do additional work between notifiers
and drivers freezing.
PM_POST_HIBERNATION The system memory state has been restored from a
hibernation image or an error occurred during

30
Documentation/power/states.txt
View file

@ -2,12 +2,26 @@
System Power Management States
The kernel supports three power management states generically, though
each is dependent on platform support code to implement the low-level
details for each state. This file describes each state, what they are
The kernel supports four power management states generically, though
one is generic and the other three are dependent on platform support
code to implement the low-level details for each state.
This file describes each state, what they are
commonly called, what ACPI state they map to, and what string to write
to /sys/power/state to enter that state
state: Freeze / Low-Power Idle
ACPI state: S0
String: "freeze"
This state is a generic, pure software, light-weight, low-power state.
It allows more energy to be saved relative to idle by freezing user
space and putting all I/O devices into low-power states (possibly
lower-power than available at run time), such that the processors can
spend more time in their idle states.
This state can be used for platforms without Standby/Suspend-to-RAM
support, or it can be used in addition to Suspend-to-RAM (memory sleep)
to provide reduced resume latency.
State: Standby / Power-On Suspend
ACPI State: S1
@ -22,9 +36,6 @@ We try to put devices in a low-power state equivalent to D1, which
also offers low power savings, but low resume latency. Not all devices
support D1, and those that don't are left on.
A transition from Standby to the On state should take about 1-2
seconds.
State: Suspend-to-RAM
ACPI State: S3
@ -42,9 +53,6 @@ transition back to the On state.
For at least ACPI, STR requires some minimal boot-strapping code to
resume the system from STR. This may be true on other platforms.
A transition from Suspend-to-RAM to the On state should take about
3-5 seconds.
State: Suspend-to-disk
ACPI State: S4
@ -74,7 +82,3 @@ low-power state (like ACPI S4), or it may simply power down. Powering
down offers greater savings, and allows this mechanism to work on any
system. However, entering a real low-power state allows the user to
trigger wake up events (e.g. pressing a key or opening a laptop lid).
A transition from Suspend-to-Disk to the On state should take about 30
seconds, though it's typically a bit more with the current
implementation.

128
Documentation/rapidio/rapidio.txt
View file

@ -79,20 +79,63 @@ master port that is used to communicate with devices within the network.
In order to initialize the RapidIO subsystem, a platform must initialize and
register at least one master port within the RapidIO network. To register mport
within the subsystem controller driver initialization code calls function
rio_register_mport() for each available master port. After all active master
ports are registered with a RapidIO subsystem, the rio_init_mports() routine
is called to perform enumeration and discovery.
rio_register_mport() for each available master port.
In the current PowerPC-based implementation a subsys_initcall() is specified to
perform controller initialization and mport registration. At the end it directly
calls rio_init_mports() to execute RapidIO enumeration and discovery.
RapidIO subsystem uses subsys_initcall() or device_initcall() to perform
controller initialization (depending on controller device type).
After all active master ports are registered with a RapidIO subsystem,
an enumeration and/or discovery routine may be called automatically or
by user-space command.
4. Enumeration and Discovery
----------------------------
When rio_init_mports() is called it scans a list of registered master ports and
calls an enumeration or discovery routine depending on the configured role of a
master port: host or agent.
4.1 Overview
------------
RapidIO subsystem configuration options allow users to specify enumeration and
discovery methods as statically linked components or loadable modules.
An enumeration/discovery method implementation and available input parameters
define how any given method can be attached to available RapidIO mports:
simply to all available mports OR individually to the specified mport device.
Depending on selected enumeration/discovery build configuration, there are
several methods to initiate an enumeration and/or discovery process:
(a) Statically linked enumeration and discovery process can be started
automatically during kernel initialization time using corresponding module
parameters. This was the original method used since introduction of RapidIO
subsystem. Now this method relies on enumerator module parameter which is
'rio-scan.scan' for existing basic enumeration/discovery method.
When automatic start of enumeration/discovery is used a user has to ensure
that all discovering endpoints are started before the enumerating endpoint
and are waiting for enumeration to be completed.
Configuration option CONFIG_RAPIDIO_DISC_TIMEOUT defines time that discovering
endpoint waits for enumeration to be completed. If the specified timeout
expires the discovery process is terminated without obtaining RapidIO network
information. NOTE: a timed out discovery process may be restarted later using
a user-space command as it is described later if the given endpoint was
enumerated successfully.
(b) Statically linked enumeration and discovery process can be started by
a command from user space. This initiation method provides more flexibility
for a system startup compared to the option (a) above. After all participating
endpoints have been successfully booted, an enumeration process shall be
started first by issuing a user-space command, after an enumeration is
completed a discovery process can be started on all remaining endpoints.
(c) Modular enumeration and discovery process can be started by a command from
user space. After an enumeration/discovery module is loaded, a network scan
process can be started by issuing a user-space command.
Similar to the option (b) above, an enumerator has to be started first.
(d) Modular enumeration and discovery process can be started by a module
initialization routine. In this case an enumerating module shall be loaded
first.
When a network scan process is started it calls an enumeration or discovery
routine depending on the configured role of a master port: host or agent.
Enumeration is performed by a master port if it is configured as a host port by
assigning a host device ID greater than or equal to zero. A host device ID is
@ -104,8 +147,58 @@ for it.
The enumeration and discovery routines use RapidIO maintenance transactions
to access the configuration space of devices.
The enumeration process is implemented according to the enumeration algorithm
outlined in the RapidIO Interconnect Specification: Annex I [1].
4.2 Automatic Start of Enumeration and Discovery
------------------------------------------------
Automatic enumeration/discovery start method is applicable only to built-in
enumeration/discovery RapidIO configuration selection. To enable automatic
enumeration/discovery start by existing basic enumerator method set use boot
command line parameter "rio-scan.scan=1".
This configuration requires synchronized start of all RapidIO endpoints that
form a network which will be enumerated/discovered. Discovering endpoints have
to be started before an enumeration starts to ensure that all RapidIO
controllers have been initialized and are ready to be discovered. Configuration
parameter CONFIG_RAPIDIO_DISC_TIMEOUT defines time (in seconds) which
a discovering endpoint will wait for enumeration to be completed.
When automatic enumeration/discovery start is selected, basic method's
initialization routine calls rio_init_mports() to perform enumeration or
discovery for all known mport devices.
Depending on RapidIO network size and configuration this automatic
enumeration/discovery start method may be difficult to use due to the
requirement for synchronized start of all endpoints.
4.3 User-space Start of Enumeration and Discovery
-------------------------------------------------
User-space start of enumeration and discovery can be used with built-in and
modular build configurations. For user-space controlled start RapidIO subsystem
creates the sysfs write-only attribute file '/sys/bus/rapidio/scan'. To initiate
an enumeration or discovery process on specific mport device, a user needs to
write mport_ID (not RapidIO destination ID) into that file. The mport_ID is a
sequential number (0 ... RIO_MAX_MPORTS) assigned during mport device
registration. For example for machine with single RapidIO controller, mport_ID
for that controller always will be 0.
To initiate RapidIO enumeration/discovery on all available mports a user may
write '-1' (or RIO_MPORT_ANY) into the scan attribute file.
4.4 Basic Enumeration Method
----------------------------
This is an original enumeration/discovery method which is available since
first release of RapidIO subsystem code. The enumeration process is
implemented according to the enumeration algorithm outlined in the RapidIO
Interconnect Specification: Annex I [1].
This method can be configured as statically linked or loadable module.
The method's single parameter "scan" allows to trigger the enumeration/discovery
process from module initialization routine.
This enumeration/discovery method can be started only once and does not support
unloading if it is built as a module.
The enumeration process traverses the network using a recursive depth-first
algorithm. When a new device is found, the enumerator takes ownership of that
@ -160,6 +253,19 @@ time period. If this wait time period expires before enumeration is completed,
an agent skips RapidIO discovery and continues with remaining kernel
initialization.
4.5 Adding New Enumeration/Discovery Method
-------------------------------------------
RapidIO subsystem code organization allows addition of new enumeration/discovery
methods as new configuration options without significant impact to to the core
RapidIO code.
A new enumeration/discovery method has to be attached to one or more mport
devices before an enumeration/discovery process can be started. Normally,
method's module initialization routine calls rio_register_scan() to attach
an enumerator to a specified mport device (or devices). The basic enumerator
implementation demonstrates this process.
5. References
-------------

17
Documentation/rapidio/sysfs.txt
View file

@ -88,3 +88,20 @@ that exports additional attributes.
IDT_GEN2:
errlog - reads contents of device error log until it is empty.
5. RapidIO Bus Attributes
-------------------------
RapidIO bus subdirectory /sys/bus/rapidio implements the following bus-specific
attribute:
scan - allows to trigger enumeration discovery process from user space. This
is a write-only attribute. To initiate an enumeration or discovery
process on specific mport device, a user needs to write mport_ID (not
RapidIO destination ID) into this file. The mport_ID is a sequential
number (0 ... RIO_MAX_MPORTS) assigned to the mport device.
For example, for a machine with a single RapidIO controller, mport_ID
for that controller always will be 0.
To initiate RapidIO enumeration/discovery on all available mports
a user must write '-1' (or RIO_MPORT_ANY) into this attribute file.

12
Documentation/s390/CommonIO
View file

@ -8,9 +8,9 @@ Command line parameters
Enable logging of debug information in case of ccw device timeouts.
* cio_ignore = {all} |
{<device> | <range of devices>} |
{!<device> | !<range of devices>}
* cio_ignore = device[,device[,..]]
device := {all | [!]ipldev | [!]condev | [!]<devno> | [!]<devno>-<devno>}
The given devices will be ignored by the common I/O-layer; no detection
and device sensing will be done on any of those devices. The subchannel to
@ -24,8 +24,10 @@ Command line parameters
device numbers (0xabcd or abcd, for 2.4 backward compatibility). If you
give a device number 0xabcd, it will be interpreted as 0.0.abcd.
You can use the 'all' keyword to ignore all devices.
The '!' operator will cause the I/O-layer to _not_ ignore a device.
You can use the 'all' keyword to ignore all devices. The 'ipldev' and 'condev'
keywords can be used to refer to the CCW based boot device and CCW console
device respectively (these are probably useful only when combined with the '!'
operator). The '!' operator will cause the I/O-layer to _not_ ignore a device.
The command line is parsed from left to right.
For example,

8
Documentation/thermal/exynos_thermal_emulation
View file

@ -13,11 +13,11 @@ Thermal emulation mode supports software debug for TMU's operation. User can set
manually with software code and TMU will read current temperature from user value not from
sensor's value.
Enabling CONFIG_EXYNOS_THERMAL_EMUL option will make this support in available.
When it's enabled, sysfs node will be created under
/sys/bus/platform/devices/'exynos device name'/ with name of 'emulation'.
Enabling CONFIG_THERMAL_EMULATION option will make this support available.
When it's enabled, sysfs node will be created as
/sys/devices/virtual/thermal/thermal_zone'zone id'/emul_temp.
The sysfs node, 'emulation', will contain value 0 for the initial state. When you input any
The sysfs node, 'emul_node', will contain value 0 for the initial state. When you input any
temperature you want to update to sysfs node, it automatically enable emulation mode and
current temperature will be changed into it.
(Exynos also supports user changable delay time which would be used to delay of

28
Documentation/thermal/sysfs-api.txt
View file

@ -31,15 +31,17 @@ temperature) and throttle appropriate devices.
1. thermal sysfs driver interface functions
1.1 thermal zone device interface
1.1.1 struct thermal_zone_device *thermal_zone_device_register(char *name,
1.1.1 struct thermal_zone_device *thermal_zone_device_register(char *type,
int trips, int mask, void *devdata,
struct thermal_zone_device_ops *ops)
struct thermal_zone_device_ops *ops,
const struct thermal_zone_params *tzp,
int passive_delay, int polling_delay))
This interface function adds a new thermal zone device (sensor) to
/sys/class/thermal folder as thermal_zone[0-*]. It tries to bind all the
thermal cooling devices registered at the same time.
name: the thermal zone name.
type: the thermal zone type.
trips: the total number of trip points this thermal zone supports.
mask: Bit string: If 'n'th bit is set, then trip point 'n' is writeable.
devdata: device private data
@ -57,6 +59,12 @@ temperature) and throttle appropriate devices.
will be fired.
.set_emul_temp: set the emulation temperature which helps in debugging
different threshold temperature points.
tzp: thermal zone platform parameters.
passive_delay: number of milliseconds to wait between polls when
performing passive cooling.
polling_delay: number of milliseconds to wait between polls when checking
whether trip points have been crossed (0 for interrupt driven systems).
1.1.2 void thermal_zone_device_unregister(struct thermal_zone_device *tz)
@ -265,6 +273,10 @@ emul_temp
Unit: millidegree Celsius
WO, Optional
WARNING: Be careful while enabling this option on production systems,
because userland can easily disable the thermal policy by simply
flooding this sysfs node with low temperature values.
*****************************
* Cooling device attributes *
*****************************
@ -363,7 +375,7 @@ This function returns the thermal_instance corresponding to a given
{thermal_zone, cooling_device, trip_point} combination. Returns NULL
if such an instance does not exist.
5.3:notify_thermal_framework:
5.3:thermal_notify_framework:
This function handles the trip events from sensor drivers. It starts
throttling the cooling devices according to the policy configured.
For CRITICAL and HOT trip points, this notifies the respective drivers,
@ -375,11 +387,3 @@ platform data is provided, this uses the step_wise throttling policy.
This function serves as an arbitrator to set the state of a cooling
device. It sets the cooling device to the deepest cooling state if
possible.
5.5:thermal_register_governor:
This function lets the various thermal governors to register themselves
with the Thermal framework. At run time, depending on a zone's platform
data, a particular governor is used for throttling.
5.6:thermal_unregister_governor:
This function unregisters a governor from the thermal framework.

146
Documentation/virtual/kvm/api.txt
View file

@ -1486,15 +1486,23 @@ struct kvm_ioeventfd {
__u8 pad[36];
};
For the special case of virtio-ccw devices on s390, the ioevent is matched
to a subchannel/virtqueue tuple instead.
The following flags are defined:
#define KVM_IOEVENTFD_FLAG_DATAMATCH (1 << kvm_ioeventfd_flag_nr_datamatch)
#define KVM_IOEVENTFD_FLAG_PIO (1 << kvm_ioeventfd_flag_nr_pio)
#define KVM_IOEVENTFD_FLAG_DEASSIGN (1 << kvm_ioeventfd_flag_nr_deassign)
#define KVM_IOEVENTFD_FLAG_VIRTIO_CCW_NOTIFY \
(1 << kvm_ioeventfd_flag_nr_virtio_ccw_notify)
If datamatch flag is set, the event will be signaled only if the written value
to the registered address is equal to datamatch in struct kvm_ioeventfd.
For virtio-ccw devices, addr contains the subchannel id and datamatch the
virtqueue index.
4.60 KVM_DIRTY_TLB
@ -1780,27 +1788,48 @@ registers, find a list below:
PPC | KVM_REG_PPC_VPA_DTL | 128
PPC | KVM_REG_PPC_EPCR | 32
PPC | KVM_REG_PPC_EPR | 32
PPC | KVM_REG_PPC_TCR | 32
PPC | KVM_REG_PPC_TSR | 32
PPC | KVM_REG_PPC_OR_TSR | 32
PPC | KVM_REG_PPC_CLEAR_TSR | 32
PPC | KVM_REG_PPC_MAS0 | 32
PPC | KVM_REG_PPC_MAS1 | 32
PPC | KVM_REG_PPC_MAS2 | 64
PPC | KVM_REG_PPC_MAS7_3 | 64
PPC | KVM_REG_PPC_MAS4 | 32
PPC | KVM_REG_PPC_MAS6 | 32
PPC | KVM_REG_PPC_MMUCFG | 32
PPC | KVM_REG_PPC_TLB0CFG | 32
PPC | KVM_REG_PPC_TLB1CFG | 32
PPC | KVM_REG_PPC_TLB2CFG | 32
PPC | KVM_REG_PPC_TLB3CFG | 32
PPC | KVM_REG_PPC_TLB0PS | 32
PPC | KVM_REG_PPC_TLB1PS | 32
PPC | KVM_REG_PPC_TLB2PS | 32
PPC | KVM_REG_PPC_TLB3PS | 32
PPC | KVM_REG_PPC_EPTCFG | 32
PPC | KVM_REG_PPC_ICP_STATE | 64
ARM registers are mapped using the lower 32 bits. The upper 16 of that
is the register group type, or coprocessor number:
ARM core registers have the following id bit patterns:
0x4002 0000 0010 <index into the kvm_regs struct:16>
0x4020 0000 0010 <index into the kvm_regs struct:16>
ARM 32-bit CP15 registers have the following id bit patterns:
0x4002 0000 000F <zero:1> <crn:4> <crm:4> <opc1:4> <opc2:3>
0x4020 0000 000F <zero:1> <crn:4> <crm:4> <opc1:4> <opc2:3>
ARM 64-bit CP15 registers have the following id bit patterns:
0x4003 0000 000F <zero:1> <zero:4> <crm:4> <opc1:4> <zero:3>
0x4030 0000 000F <zero:1> <zero:4> <crm:4> <opc1:4> <zero:3>
ARM CCSIDR registers are demultiplexed by CSSELR value:
0x4002 0000 0011 00 <csselr:8>
0x4020 0000 0011 00 <csselr:8>
ARM 32-bit VFP control registers have the following id bit patterns:
0x4002 0000 0012 1 <regno:12>
0x4020 0000 0012 1 <regno:12>
ARM 64-bit FP registers have the following id bit patterns:
0x4002 0000 0012 0 <regno:12>
0x4030 0000 0012 0 <regno:12>
4.69 KVM_GET_ONE_REG
@ -2161,6 +2190,76 @@ header; first `n_valid' valid entries with contents from the data
written, then `n_invalid' invalid entries, invalidating any previously
valid entries found.
4.79 KVM_CREATE_DEVICE
Capability: KVM_CAP_DEVICE_CTRL
Type: vm ioctl
Parameters: struct kvm_create_device (in/out)
Returns: 0 on success, -1 on error
Errors:
ENODEV: The device type is unknown or unsupported
EEXIST: Device already created, and this type of device may not
be instantiated multiple times
Other error conditions may be defined by individual device types or
have their standard meanings.
Creates an emulated device in the kernel. The file descriptor returned
in fd can be used with KVM_SET/GET/HAS_DEVICE_ATTR.
If the KVM_CREATE_DEVICE_TEST flag is set, only test whether the
device type is supported (not necessarily whether it can be created
in the current vm).
Individual devices should not define flags. Attributes should be used
for specifying any behavior that is not implied by the device type
number.
struct kvm_create_device {
__u32 type; /* in: KVM_DEV_TYPE_xxx */
__u32 fd; /* out: device handle */
__u32 flags; /* in: KVM_CREATE_DEVICE_xxx */
};
4.80 KVM_SET_DEVICE_ATTR/KVM_GET_DEVICE_ATTR
Capability: KVM_CAP_DEVICE_CTRL
Type: device ioctl
Parameters: struct kvm_device_attr
Returns: 0 on success, -1 on error
Errors:
ENXIO: The group or attribute is unknown/unsupported for this device
EPERM: The attribute cannot (currently) be accessed this way
(e.g. read-only attribute, or attribute that only makes
sense when the device is in a different state)
Other error conditions may be defined by individual device types.
Gets/sets a specified piece of device configuration and/or state. The
semantics are device-specific. See individual device documentation in
the "devices" directory. As with ONE_REG, the size of the data
transferred is defined by the particular attribute.
struct kvm_device_attr {
__u32 flags; /* no flags currently defined */
__u32 group; /* device-defined */
__u64 attr; /* group-defined */
__u64 addr; /* userspace address of attr data */
};
4.81 KVM_HAS_DEVICE_ATTR
Capability: KVM_CAP_DEVICE_CTRL
Type: device ioctl
Parameters: struct kvm_device_attr
Returns: 0 on success, -1 on error
Errors:
ENXIO: The group or attribute is unknown/unsupported for this device
Tests whether a device supports a particular attribute. A successful
return indicates the attribute is implemented. It does not necessarily
indicate that the attribute can be read or written in the device's
current state. "addr" is ignored.
4.77 KVM_ARM_VCPU_INIT
@ -2243,6 +2342,25 @@ and distributor interface, the ioctl must be called after calling
KVM_CREATE_IRQCHIP, but before calling KVM_RUN on any of the VCPUs. Calling
this ioctl twice for any of the base addresses will return -EEXIST.
4.82 KVM_PPC_RTAS_DEFINE_TOKEN
Capability: KVM_CAP_PPC_RTAS
Architectures: ppc
Type: vm ioctl
Parameters: struct kvm_rtas_token_args
Returns: 0 on success, -1 on error
Defines a token value for a RTAS (Run Time Abstraction Services)
service in order to allow it to be handled in the kernel. The
argument struct gives the name of the service, which must be the name
of a service that has a kernel-side implementation. If the token
value is non-zero, it will be associated with that service, and
subsequent RTAS calls by the guest specifying that token will be
handled by the kernel. If the token value is 0, then any token
associated with the service will be forgotten, and subsequent RTAS
calls by the guest for that service will be passed to userspace to be
handled.
5. The kvm_run structure
------------------------
@ -2646,3 +2764,19 @@ to receive the topmost interrupt vector.
When disabled (args[0] == 0), behavior is as if this facility is unsupported.
When this capability is enabled, KVM_EXIT_EPR can occur.
6.6 KVM_CAP_IRQ_MPIC
Architectures: ppc
Parameters: args[0] is the MPIC device fd
args[1] is the MPIC CPU number for this vcpu
This capability connects the vcpu to an in-kernel MPIC device.
6.7 KVM_CAP_IRQ_XICS
Architectures: ppc
Parameters: args[0] is the XICS device fd
args[1] is the XICS CPU number (server ID) for this vcpu
This capability connects the vcpu to an in-kernel XICS device.

1
Documentation/virtual/kvm/devices/README Normal file
View file

@ -0,0 +1 @@
This directory contains specific device bindings for KVM_CAP_DEVICE_CTRL.

53
Documentation/virtual/kvm/devices/mpic.txt Normal file
View file

@ -0,0 +1,53 @@
MPIC interrupt controller
=========================
Device types supported:
KVM_DEV_TYPE_FSL_MPIC_20 Freescale MPIC v2.0
KVM_DEV_TYPE_FSL_MPIC_42 Freescale MPIC v4.2
Only one MPIC instance, of any type, may be instantiated. The created
MPIC will act as the system interrupt controller, connecting to each
vcpu's interrupt inputs.
Groups:
KVM_DEV_MPIC_GRP_MISC
Attributes:
KVM_DEV_MPIC_BASE_ADDR (rw, 64-bit)
Base address of the 256 KiB MPIC register space. Must be
naturally aligned. A value of zero disables the mapping.
Reset value is zero.
KVM_DEV_MPIC_GRP_REGISTER (rw, 32-bit)
Access an MPIC register, as if the access were made from the guest.
"attr" is the byte offset into the MPIC register space. Accesses
must be 4-byte aligned.
MSIs may be signaled by using this attribute group to write
to the relevant MSIIR.
KVM_DEV_MPIC_GRP_IRQ_ACTIVE (rw, 32-bit)
IRQ input line for each standard openpic source. 0 is inactive and 1
is active, regardless of interrupt sense.
For edge-triggered interrupts: Writing 1 is considered an activating
edge, and writing 0 is ignored. Reading returns 1 if a previously
signaled edge has not been acknowledged, and 0 otherwise.
"attr" is the IRQ number. IRQ numbers for standard sources are the
byte offset of the relevant IVPR from EIVPR0, divided by 32.
IRQ Routing:
The MPIC emulation supports IRQ routing. Only a single MPIC device can
be instantiated. Once that device has been created, it's available as
irqchip id 0.
This irqchip 0 has 256 interrupt pins, which expose the interrupts in
the main array of interrupt sources (a.k.a. "SRC" interrupts).
The numbering is the same as the MPIC device tree binding -- based on
the register offset from the beginning of the sources array, without
regard to any subdivisions in chip documentation such as "internal"
or "external" interrupts.
Access to non-SRC interrupts is not implemented through IRQ routing mechanisms.

66
Documentation/virtual/kvm/devices/xics.txt Normal file
View file

@ -0,0 +1,66 @@
XICS interrupt controller
Device type supported: KVM_DEV_TYPE_XICS
Groups:
KVM_DEV_XICS_SOURCES
Attributes: One per interrupt source, indexed by the source number.
This device emulates the XICS (eXternal Interrupt Controller
Specification) defined in PAPR. The XICS has a set of interrupt
sources, each identified by a 20-bit source number, and a set of
Interrupt Control Presentation (ICP) entities, also called "servers",
each associated with a virtual CPU.
The ICP entities are created by enabling the KVM_CAP_IRQ_ARCH
capability for each vcpu, specifying KVM_CAP_IRQ_XICS in args[0] and
the interrupt server number (i.e. the vcpu number from the XICS's
point of view) in args[1] of the kvm_enable_cap struct. Each ICP has
64 bits of state which can be read and written using the
KVM_GET_ONE_REG and KVM_SET_ONE_REG ioctls on the vcpu. The 64 bit
state word has the following bitfields, starting at the
least-significant end of the word:
* Unused, 16 bits
* Pending interrupt priority, 8 bits
Zero is the highest priority, 255 means no interrupt is pending.
* Pending IPI (inter-processor interrupt) priority, 8 bits
Zero is the highest priority, 255 means no IPI is pending.
* Pending interrupt source number, 24 bits
Zero means no interrupt pending, 2 means an IPI is pending
* Current processor priority, 8 bits
Zero is the highest priority, meaning no interrupts can be
delivered, and 255 is the lowest priority.
Each source has 64 bits of state that can be read and written using
the KVM_GET_DEVICE_ATTR and KVM_SET_DEVICE_ATTR ioctls, specifying the
KVM_DEV_XICS_SOURCES attribute group, with the attribute number being
the interrupt source number. The 64 bit state word has the following
bitfields, starting from the least-significant end of the word:
* Destination (server number), 32 bits
This specifies where the interrupt should be sent, and is the
interrupt server number specified for the destination vcpu.
* Priority, 8 bits
This is the priority specified for this interrupt source, where 0 is
the highest priority and 255 is the lowest. An interrupt with a
priority of 255 will never be delivered.
* Level sensitive flag, 1 bit
This bit is 1 for a level-sensitive interrupt source, or 0 for
edge-sensitive (or MSI).
* Masked flag, 1 bit
This bit is set to 1 if the interrupt is masked (cannot be delivered
regardless of its priority), for example by the ibm,int-off RTAS
call, or 0 if it is not masked.
* Pending flag, 1 bit
This bit is 1 if the source has a pending interrupt, otherwise 0.
Only one XICS instance may be created per VM.

46
Documentation/xtensa/mmu.txt Normal file
View file

@ -0,0 +1,46 @@
MMUv3 initialization sequence.
The code in the initialize_mmu macro sets up MMUv3 memory mapping
identically to MMUv2 fixed memory mapping. Depending on
CONFIG_INITIALIZE_XTENSA_MMU_INSIDE_VMLINUX symbol this code is
located in one of the following address ranges:
0xF0000000..0xFFFFFFFF (will keep same address in MMU v2 layout;
typically ROM)
0x00000000..0x07FFFFFF (system RAM; this code is actually linked
at 0xD0000000..0xD7FFFFFF [cached]
or 0xD8000000..0xDFFFFFFF [uncached];
in any case, initially runs elsewhere
than linked, so have to be careful)
The code has the following assumptions:
This code fragment is run only on an MMU v3.
TLBs are in their reset state.
ITLBCFG and DTLBCFG are zero (reset state).
RASID is 0x04030201 (reset state).
PS.RING is zero (reset state).
LITBASE is zero (reset state, PC-relative literals); required to be PIC.
TLB setup proceeds along the following steps.
Legend:
VA = virtual address (two upper nibbles of it);
PA = physical address (two upper nibbles of it);
pc = physical range that contains this code;
After step 2, we jump to virtual address in 0x40000000..0x5fffffff
that corresponds to next instruction to execute in this code.
After step 4, we jump to intended (linked) address of this code.
Step 0 Step1 Step 2 Step3 Step 4 Step5
============ ===== ============ ===== ============ =====
VA PA PA VA PA PA VA PA PA
------ -- -- ------ -- -- ------ -- --
E0..FF -> E0 -> E0 E0..FF -> E0 F0..FF -> F0 -> F0
C0..DF -> C0 -> C0 C0..DF -> C0 E0..EF -> F0 -> F0
A0..BF -> A0 -> A0 A0..BF -> A0 D8..DF -> 00 -> 00
80..9F -> 80 -> 80 80..9F -> 80 D0..D7 -> 00 -> 00
60..7F -> 60 -> 60 60..7F -> 60
40..5F -> 40 40..5F -> pc -> pc 40..5F -> pc
20..3F -> 20 -> 20 20..3F -> 20
00..1F -> 00 -> 00 00..1F -> 00

8
Documentation/zh_CN/gpio.txt
View file

@ -84,10 +84,10 @@ GPIO 公约
控制器的抽象函数来实现它。(有一些可选的代码能支持这种策略的实现,本文档
后面会介绍，但作为 GPIO 接口的客户端驱动程序必须与它的实现无关。)
也就是说,如果在他们的平台上支持这个公约，驱动应尽可能的使用它。平台
必须在 Kconfig 中声明对 GENERIC_GPIO的支持 (布尔型 true)，并提供
一个 <asm/gpio.h> 文件。那些调用标准 GPIO 函数的驱动应该在 Kconfig
入口中声明依赖GENERIC_GPIO。当驱动包含文件:
也就是说,如果在他们的平台上支持这个公约，驱动应尽可能的使用它。同时，平台
必须在 Kconfig 中选择 ARCH_REQUIRE_GPIOLIB 或者 ARCH_WANT_OPTIONAL_GPIOLIB
选项。那些调用标准 GPIO 函数的驱动应该在 Kconfig 入口中声明依赖GENERIC_GPIO。
当驱动包含文件:
#include <linux/gpio.h>

65
MAINTAINERS
View file

@ -1620,6 +1620,13 @@ W: http://www.baycom.org/~tom/ham/ham.html
S: Maintained
F: drivers/net/hamradio/baycom*
BCACHE (BLOCK LAYER CACHE)
M: Kent Overstreet <koverstreet@google.com>
L: linux-bcache@vger.kernel.org
W: http://bcache.evilpiepirate.org
S: Maintained:
F: drivers/md/bcache/
BEFS FILE SYSTEM
S: Orphan
F: Documentation/filesystems/befs.txt
@ -3858,9 +3865,16 @@ M: K. Y. Srinivasan <kys@microsoft.com>
M: Haiyang Zhang <haiyangz@microsoft.com>
L: devel@linuxdriverproject.org
S: Maintained
F: drivers/hv/
F: arch/x86/include/asm/mshyperv.h
F: arch/x86/include/uapi/asm/hyperv.h
F: arch/x86/kernel/cpu/mshyperv.c
F: drivers/hid/hid-hyperv.c
F: drivers/hv/
F: drivers/net/hyperv/
F: drivers/scsi/storvsc_drv.c
F: drivers/video/hyperv_fb.c
F: include/linux/hyperv.h
F: tools/hv/
I2C OVER PARALLEL PORT
M: Jean Delvare <khali@linux-fr.org>
@ -4634,12 +4648,13 @@ F: include/linux/sunrpc/
F: include/uapi/linux/sunrpc/
KERNEL VIRTUAL MACHINE (KVM)
M: Marcelo Tosatti <mtosatti@redhat.com>
M: Gleb Natapov <gleb@redhat.com>
M: Paolo Bonzini <pbonzini@redhat.com>
L: kvm@vger.kernel.org
W: http://kvm.qumranet.com
W: http://linux-kvm.org
S: Supported
F: Documentation/*/kvm.txt
F: Documentation/*/kvm*.txt
F: Documentation/virtual/kvm/
F: arch/*/kvm/
F: arch/*/include/asm/kvm*
F: include/linux/kvm*
@ -4969,6 +4984,13 @@ S: Maintained
F: Documentation/hwmon/lm90
F: drivers/hwmon/lm90.c
LM95234 HARDWARE MONITOR DRIVER
M: Guenter Roeck <linux@roeck-us.net>
L: lm-sensors@lm-sensors.org
S: Maintained
F: Documentation/hwmon/lm95234
F: drivers/hwmon/lm95234.c
LME2510 MEDIA DRIVER
M: Malcolm Priestley <tvboxspy@gmail.com>
L: linux-media@vger.kernel.org
@ -5502,18 +5524,18 @@ F: Documentation/networking/s2io.txt
F: Documentation/networking/vxge.txt
F: drivers/net/ethernet/neterion/
NETFILTER/IPTABLES/IPCHAINS
P: Harald Welte
P: Jozsef Kadlecsik
NETFILTER/IPTABLES
M: Pablo Neira Ayuso <pablo@netfilter.org>
M: Patrick McHardy <kaber@trash.net>
M: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
L: netfilter-devel@vger.kernel.org
L: netfilter@vger.kernel.org
L: coreteam@netfilter.org
W: http://www.netfilter.org/
W: http://www.iptables.org/
T: git git://1984.lsi.us.es/nf
T: git git://1984.lsi.us.es/nf-next
Q: http://patchwork.ozlabs.org/project/netfilter-devel/list/
T: git git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf-next.git
S: Supported
F: include/linux/netfilter*
F: include/linux/netfilter/
@ -6062,6 +6084,7 @@ L: linux-parisc@vger.kernel.org
W: http://www.parisc-linux.org/
Q: http://patchwork.kernel.org/project/linux-parisc/list/
T: git git://git.kernel.org/pub/scm/linux/kernel/git/jejb/parisc-2.6.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git
S: Maintained
F: arch/parisc/
F: drivers/parisc/
@ -6716,6 +6739,14 @@ F: drivers/remoteproc/
F: Documentation/remoteproc.txt
F: include/linux/remoteproc.h
REMOTE PROCESSOR MESSAGING (RPMSG) SUBSYSTEM
M: Ohad Ben-Cohen <ohad@wizery.com>
T: git git://git.kernel.org/pub/scm/linux/kernel/git/ohad/rpmsg.git
S: Maintained
F: drivers/rpmsg/
F: Documentation/rpmsg.txt
F: include/linux/rpmsg.h
RFKILL
M: Johannes Berg <johannes@sipsolutions.net>
L: linux-wireless@vger.kernel.org
@ -7140,9 +7171,9 @@ F: drivers/misc/phantom.c
F: include/uapi/linux/phantom.h
SERIAL ATA (SATA) SUBSYSTEM
M: Jeff Garzik <jgarzik@pobox.com>
M: Tejun Heo <tj@kernel.org>
L: linux-ide@vger.kernel.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata.git
S: Supported
F: drivers/ata/
F: include/linux/ata.h
@ -7839,7 +7870,7 @@ L: linux-scsi@vger.kernel.org
L: target-devel@vger.kernel.org
L: http://groups.google.com/group/linux-iscsi-target-dev
W: http://www.linux-iscsi.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/nab/lio-core.git master
T: git git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git master
S: Supported
F: drivers/target/
F: include/target/
@ -8014,11 +8045,14 @@ F: arch/xtensa/
THERMAL
M: Zhang Rui <rui.zhang@intel.com>
M: Eduardo Valentin <eduardo.valentin@ti.com>
L: linux-pm@vger.kernel.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git
Q: https://patchwork.kernel.org/project/linux-pm/list/
S: Supported
F: drivers/thermal/
F: include/linux/thermal.h
F: include/linux/cpu_cooling.h
THINGM BLINK(1) USB RGB LED DRIVER
M: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
@ -8164,6 +8198,13 @@ F: drivers/mmc/host/sh_mobile_sdhi.c
F: include/linux/mmc/tmio.h
F: include/linux/mmc/sh_mobile_sdhi.h
TMP401 HARDWARE MONITOR DRIVER
M: Guenter Roeck <linux@roeck-us.net>
L: lm-sensors@lm-sensors.org
S: Maintained
F: Documentation/hwmon/tmp401
F: drivers/hwmon/tmp401.c
TMPFS (SHMEM FILESYSTEM)
M: Hugh Dickins <hughd@google.com>
L: linux-mm@kvack.org

6
Makefile
View file

@ -1,7 +1,7 @@
VERSION = 3
PATCHLEVEL = 9
PATCHLEVEL = 10
SUBLEVEL = 0
EXTRAVERSION =
EXTRAVERSION = -rc3
NAME = Unicycling Gorilla
# *DOCUMENTATION*
@ -757,6 +757,8 @@ export KBUILD_VMLINUX_INIT := $(head-y) $(init-y)
export KBUILD_VMLINUX_MAIN := $(core-y) $(libs-y) $(drivers-y) $(net-y)
export KBUILD_LDS := arch/$(SRCARCH)/kernel/vmlinux.lds
export LDFLAGS_vmlinux
# used by scripts/pacmage/Makefile
export KBUILD_ALLDIRS := $(sort $(filter-out arch/%,$(vmlinux-alldirs)) arch Documentation include samples scripts tools virt)
vmlinux-deps := $(KBUILD_LDS) $(KBUILD_VMLINUX_INIT) $(KBUILD_VMLINUX_MAIN)

3
arch/Kconfig
View file

@ -213,6 +213,9 @@ config USE_GENERIC_SMP_HELPERS
config GENERIC_SMP_IDLE_THREAD
bool
config GENERIC_IDLE_POLL_SETUP
bool
# Select if arch init_task initializer is different to init/init_task.c
config ARCH_INIT_TASK
bool

3
arch/alpha/Kconfig
View file

@ -55,9 +55,6 @@ config GENERIC_CALIBRATE_DELAY
bool
default y
config GENERIC_GPIO
bool
config ZONE_DMA
bool
default y

35
arch/arc/Kconfig
View file

@ -16,8 +16,6 @@ config ARC
select GENERIC_FIND_FIRST_BIT
# for now, we don't need GENERIC_IRQ_PROBE, CONFIG_GENERIC_IRQ_CHIP
select GENERIC_IRQ_SHOW
select GENERIC_KERNEL_EXECVE
select GENERIC_KERNEL_THREAD
select GENERIC_PENDING_IRQ if SMP
select GENERIC_SMP_IDLE_THREAD
select HAVE_ARCH_KGDB
@ -61,9 +59,6 @@ config GENERIC_CALIBRATE_DELAY
config GENERIC_HWEIGHT
def_bool y
config BINFMT_ELF
def_bool y
config STACKTRACE_SUPPORT
def_bool y
select STACKTRACE
@ -82,6 +77,7 @@ menu "ARC Architecture Configuration"
menu "ARC Platform/SoC/Board"
source "arch/arc/plat-arcfpga/Kconfig"
source "arch/arc/plat-tb10x/Kconfig"
#New platform adds here
endmenu
@ -134,9 +130,6 @@ if SMP
config ARC_HAS_COH_CACHES
def_bool n
config ARC_HAS_COH_LLSC
def_bool n
config ARC_HAS_COH_RTSC
def_bool n
@ -189,6 +182,10 @@ config ARC_CACHE_PAGES
Note that Global I/D ENABLE + Per Page DISABLE works but corollary
Global DISABLE + Per Page ENABLE won't work
config ARC_CACHE_VIPT_ALIASING
bool "Support VIPT Aliasing D$"
default n
endif #ARC_CACHE
config ARC_HAS_ICCM
@ -304,6 +301,9 @@ config ARC_FPU_SAVE_RESTORE
based on actual usage of FPU by a task. Thus our implemn does
this for all tasks in system.
config ARC_CANT_LLSC
def_bool n
menuconfig ARC_CPU_REL_4_10
bool "Enable support for Rel 4.10 features"
default n
@ -314,9 +314,7 @@ menuconfig ARC_CPU_REL_4_10
config ARC_HAS_LLSC
bool "Insn: LLOCK/SCOND (efficient atomic ops)"
default y
depends on ARC_CPU_770
# if SMP, enable LLSC ONLY if ARC implementation has coherent atomics
depends on !SMP || ARC_HAS_COH_LLSC
depends on ARC_CPU_770 && !ARC_CANT_LLSC
config ARC_HAS_SWAPE
bool "Insn: SWAPE (endian-swap)"
@ -415,13 +413,6 @@ config ARC_DBG_TLB_MISS_COUNT
Counts number of I and D TLB Misses and exports them via Debugfs
The counters can be cleared via Debugfs as well
config CMDLINE
string "Kernel command line to built-in"
default "print-fatal-signals=1"
help
The default command line which will be appended to the optional
u-boot provided command line (see below)
config CMDLINE_UBOOT
bool "Support U-boot kernel command line passing"
default n
@ -430,8 +421,8 @@ config CMDLINE_UBOOT
command line from the U-boot environment to the Linux kernel then
switch this option on.
ARC U-boot will setup the cmdline in RAM/flash and set r2 to point
to it. kernel startup code will copy the string into cmdline buffer
and also append CONFIG_CMDLINE.
to it. kernel startup code will append this to DeviceTree
/bootargs provided cmdline args.
config ARC_BUILTIN_DTB_NAME
string "Built in DTB"
@ -441,6 +432,10 @@ config ARC_BUILTIN_DTB_NAME
source "kernel/Kconfig.preempt"
menu "Executable file formats"
source "fs/Kconfig.binfmt"
endmenu
endmenu # "ARC Architecture Configuration"
source "mm/Kconfig"

15
arch/arc/Makefile
View file

@ -8,6 +8,10 @@
UTS_MACHINE := arc
ifeq ($(CROSS_COMPILE),)
CROSS_COMPILE := arc-elf32-
endif
KBUILD_DEFCONFIG := fpga_defconfig
cflags-y += -mA7 -fno-common -pipe -fno-builtin -D__linux__
@ -87,20 +91,23 @@ core-y += arch/arc/
core-y += arch/arc/boot/dts/
core-$(CONFIG_ARC_PLAT_FPGA_LEGACY) += arch/arc/plat-arcfpga/
core-$(CONFIG_ARC_PLAT_TB10X) += arch/arc/plat-tb10x/
drivers-$(CONFIG_OPROFILE) += arch/arc/oprofile/
libs-y += arch/arc/lib/ $(LIBGCC)
boot := arch/arc/boot
#default target for make without any arguements.
KBUILD_IMAGE := bootpImage
KBUILD_IMAGE := bootpImage
all: $(KBUILD_IMAGE)
boot := arch/arc/boot
bootpImage: vmlinux
uImage: vmlinux
boot_targets += uImage uImage.bin uImage.gz
$(boot_targets): vmlinux
$(Q)$(MAKE) $(build)=$(boot) $(boot)/$@
%.dtb %.dtb.S %.dtb.o: scripts

19
arch/arc/boot/Makefile
View file

@ -3,7 +3,6 @@ targets := vmlinux.bin vmlinux.bin.gz uImage
# uImage build relies on mkimage being availble on your host for ARC target
# You will need to build u-boot for ARC, rename mkimage to arc-elf32-mkimage
# and make sure it's reacable from your PATH
MKIMAGE := $(srctree)/scripts/mkuboot.sh
OBJCOPYFLAGS= -O binary -R .note -R .note.gnu.build-id -R .comment -S
@ -12,7 +11,12 @@ LINUX_START_TEXT = $$(readelf -h vmlinux | \
UIMAGE_LOADADDR = $(CONFIG_LINUX_LINK_BASE)
UIMAGE_ENTRYADDR = $(LINUX_START_TEXT)
UIMAGE_COMPRESSION = gzip
suffix-y := bin
suffix-$(CONFIG_KERNEL_GZIP) := gz
targets += uImage uImage.bin uImage.gz
extra-y += vmlinux.bin vmlinux.bin.gz
$(obj)/vmlinux.bin: vmlinux FORCE
$(call if_changed,objcopy)
@ -20,7 +24,12 @@ $(obj)/vmlinux.bin: vmlinux FORCE
$(obj)/vmlinux.bin.gz: $(obj)/vmlinux.bin FORCE
$(call if_changed,gzip)
$(obj)/uImage: $(obj)/vmlinux.bin.gz FORCE
$(call if_changed,uimage)
$(obj)/uImage.bin: $(obj)/vmlinux.bin FORCE
$(call if_changed,uimage,none)
PHONY += FORCE
$(obj)/uImage.gz: $(obj)/vmlinux.bin.gz FORCE
$(call if_changed,uimage,gzip)
$(obj)/uImage: $(obj)/uImage.$(suffix-y)
@ln -sf $(notdir $<) $@
@echo ' Image $@ is ready'

4
arch/arc/boot/dts/Makefile
View file

@ -8,6 +8,8 @@ endif
obj-y += $(builtindtb-y).dtb.o
targets += $(builtindtb-y).dtb
.SECONDARY: $(obj)/$(builtindtb-y).dtb.S
dtbs: $(addprefix $(obj)/, $(builtindtb-y).dtb)
clean-files := *.dtb
clean-files := *.dtb *.dtb.S

Some files were not shown because too many files have changed in this diff Show more