Merge branch 'sched/urgent' into sched/core
Merge in fixes before applying ongoing new work. Signed-off-by: Ingo Molnar <mingo@kernel.org>
This commit is contained in:
Ingo Molnar
Коммит
d81344c508
|
|
@ -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.
|
||||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -114,7 +114,7 @@ To apply Coccinelle to a specific directory, M= can be used.
|
|||
For example, to check drivers/net/wireless/ one may write:
|
||||
|
||||
make coccicheck M=drivers/net/wireless/
|
||||
|
||||
|
||||
To apply Coccinelle on a file basis, instead of a directory basis, the
|
||||
following command may be used:
|
||||
|
||||
|
|
@ -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
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
|
|
|||
|
|
@ -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"
|
||||
|
|
|
|||
|
|
@ -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>;
|
||||
};
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
@ -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";
|
||||
};
|
||||
|
|
|
|||
|
|
@ -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):
|
||||
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
||||
|
|
|
|||
|
|
@ -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";
|
||||
};
|
||||
|
|
|
|||
|
|
@ -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";
|
||||
};
|
||||
|
|
|
|||
|
|
@ -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>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
@ -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>;
|
||||
};
|
||||
|
|
@ -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>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -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";
|
||||
};
|
||||
|
|
@ -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";
|
||||
};
|
||||
|
|
|
|||
|
|
@ -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";
|
||||
};
|
||||
|
|
@ -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>;
|
||||
};
|
||||
|
|
@ -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;
|
||||
};
|
||||
};
|
||||
|
|
@ -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.
|
||||
|
|
@ -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>;
|
||||
};
|
||||
|
|
@ -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";
|
||||
};
|
||||
|
|
@ -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
|
||||
|
|
@ -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>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -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>;
|
||||
|
|
|
|||
|
|
@ -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 {
|
||||
...
|
||||
|
|
|
|||
|
|
@ -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>;
|
||||
};
|
||||
};
|
||||
|
|
|
|||
|
|
@ -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;
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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 {
|
||||
|
|
|
|||
|
|
@ -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>;
|
||||
}
|
||||
|
|
@ -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>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -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>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
@ -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
|
||||
|
|
@ -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";
|
||||
};
|
||||
|
|
|
|||
|
|
@ -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";
|
||||
};
|
||||
|
|
|
|||
|
|
@ -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";
|
||||
};
|
||||
|
||||
|
|
|
|||
|
|
@ -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";
|
||||
};
|
||||
|
||||
|
|
|
|||
|
|
@ -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";
|
||||
};
|
||||
|
|
|
|||
|
|
@ -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 = <®ulator>;
|
||||
CPVDD-supply = <®ulator>;
|
||||
DBVDD1-supply = <®ulator>;
|
||||
DBVDD2-supply = <®ulator>;
|
||||
DBVDD3-supply = <®ulator>;
|
||||
SPKVDD1-supply = <®ulator>;
|
||||
SPKVDD2-supply = <®ulator>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -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";
|
||||
};
|
||||
|
|
|
|||
|
|
@ -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>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
@ -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>;
|
||||
};
|
||||
};
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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";
|
||||
};
|
||||
|
|
@ -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";
|
||||
};
|
||||
|
|
@ -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,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";
|
||||
};
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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,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";
|
||||
};
|
||||
|
|
@ -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";
|
||||
};
|
||||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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>
|
||||
|
||||
|
|
|
|||
|
|
@ -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'
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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,
|
||||
};
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
-------------
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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,
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -0,0 +1 @@
|
|||
This directory contains specific device bindings for KVM_CAP_DEVICE_CTRL.
|
||||
|
|
@ -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.
|
||||
|
|
@ -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.
|
||||
|
|
@ -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
|
||||
|
|
@ -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
65
MAINTAINERS
|
|
@ -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
6
Makefile
|
|
@ -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)
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -55,9 +55,6 @@ config GENERIC_CALIBRATE_DELAY
|
|||
bool
|
||||
default y
|
||||
|
||||
config GENERIC_GPIO
|
||||
bool
|
||||
|
||||
config ZONE_DMA
|
||||
bool
|
||||
default y
|
||||
|
|
|
|||
|
|
@ -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"
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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'
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
Некоторые файлы не были показаны из-за слишком большого количества измененных файлов Показать больше
Загрузка…
Ссылка в новой задаче