Merge branch 'timers/posix-cpu-timers-for-tglx' of

git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks into timers/core

Frederic sayed: "Most of these patches have been hanging around for
several month now, in -mmotm for a significant chunk. They already
missed a few releases."

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
This commit is contained in:
Thomas Gleixner
2013-07-04 23:11:22 +02:00
1549 changed files with 23110 additions and 10654 deletions
+23 -14
View File
@@ -1,18 +1,27 @@
<title>Codec Interface</title>
<note>
<title>Suspended</title>
<para>This interface has been be suspended from the V4L2 API
implemented in Linux 2.6 until we have more experience with codec
device interfaces.</para>
</note>
<para>A V4L2 codec can compress, decompress, transform, or otherwise
convert video data from one format into another format, in memory.
Applications send data to be converted to the driver through a
&func-write; call, and receive the converted data through a
&func-read; call. For efficiency a driver may also support streaming
I/O.</para>
convert video data from one format into another format, in memory. Typically
such devices are memory-to-memory devices (i.e. devices with the
<constant>V4L2_CAP_VIDEO_M2M</constant> or <constant>V4L2_CAP_VIDEO_M2M_MPLANE</constant>
capability set).
</para>
<para>[to do]</para>
<para>A memory-to-memory video node acts just like a normal video node, but it
supports both output (sending frames from memory to the codec hardware) and
capture (receiving the processed frames from the codec hardware into memory)
stream I/O. An application will have to setup the stream
I/O for both sides and finally call &VIDIOC-STREAMON; for both capture and output
to start the codec.</para>
<para>Video compression codecs use the MPEG controls to setup their codec parameters
(note that the MPEG controls actually support many more codecs than just MPEG).
See <xref linkend="mpeg-controls"></xref>.</para>
<para>Memory-to-memory devices can often be used as a shared resource: you can
open the video node multiple times, each application setting up their own codec properties
that are local to the file handle, and each can use it independently from the others.
The driver will arbitrate access to the codec and reprogram it whenever another file
handler gets access. This is different from the usual video node behavior where the video properties
are global to the device (i.e. changing something through one file handle is visible
through another file handle).</para>
+1 -1
View File
@@ -493,7 +493,7 @@ and discussions on the V4L mailing list.</revremark>
</partinfo>
<title>Video for Linux Two API Specification</title>
<subtitle>Revision 3.9</subtitle>
<subtitle>Revision 3.10</subtitle>
<chapter id="common">
&sub-common;
+9 -3
View File
@@ -319,7 +319,10 @@ cache<0..n>
Symlink to each of the cache devices comprising this cache set.
cache_available_percent
Percentage of cache device free.
Percentage of cache device which doesn't contain dirty data, and could
potentially be used for writeback. This doesn't mean this space isn't used
for clean cached data; the unused statistic (in priority_stats) is typically
much lower.
clear_stats
Clears the statistics associated with this cache
@@ -423,8 +426,11 @@ 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.
Statistics about how recently data in the cache has been accessed.
This can reveal your working set size. Unused is the percentage of
the cache that doesn't contain any data. Metadata is bcache's
metadata overhead. Average is the average priority of cache buckets.
Next is a list of quantiles with the priority threshold of each.
written
Sum of all data that has been written to the cache; comparison with
+2 -6
View File
@@ -498,12 +498,8 @@ Your cooperation is appreciated.
Each device type has 5 bits (32 minors).
13 block 8-bit MFM/RLL/IDE controller
0 = /dev/xda First XT disk whole disk
64 = /dev/xdb Second XT disk whole disk
Partitions are handled in the same way as IDE disks
(see major number 3).
13 block Previously used for the XT disk (/dev/xdN)
Deleted in kernel v3.9.
14 char Open Sound System (OSS)
0 = /dev/mixer Mixer control
@@ -2,7 +2,7 @@ Exynos4x12/Exynos5 SoC series camera host interface (FIMC-LITE)
Required properties:
- compatible : should be "samsung,exynos4212-fimc" for Exynos4212 and
- compatible : should be "samsung,exynos4212-fimc-lite" for Exynos4212 and
Exynos4412 SoCs;
- reg : physical base address and size of the device memory mapped
registers;
@@ -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
@@ -1,7 +1,7 @@
Atmel AT91RM9200 Real Time Clock
Required properties:
- compatible: should be: "atmel,at91rm9200-rtc"
- compatible: should be: "atmel,at91rm9200-rtc" or "atmel,at91sam9x5-rtc"
- reg: physical base address of the controller and length of memory mapped
region.
- interrupts: rtc alarm/event interrupt
@@ -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";
};
+5 -3
View File
@@ -191,9 +191,11 @@ Linux it will look something like this:
};
The bootargs property contains the kernel arguments, and the initrd-*
properties define the address and size of an initrd blob. The
chosen node may also optionally contain an arbitrary number of
additional properties for platform-specific configuration data.
properties define the address and size of an initrd blob. Note that
initrd-end is the first address after the initrd image, so this doesn't
match the usual semantic of struct resource. The chosen node may also
optionally contain an arbitrary number of additional properties for
platform-specific configuration data.
During early boot, the architecture setup code calls of_scan_flat_dt()
several times with different helper callbacks to parse device tree
+3 -3
View File
@@ -34,7 +34,7 @@ command:
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.
Note that running a new test will not stop any in progress test.
The following command should return actual state of the test.
% cat /sys/kernel/debug/dmatest/run
@@ -52,8 +52,8 @@ To wait for test done the user may perform a busy loop that checks the state.
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..."
re-run with the 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
+3
View File
@@ -33,6 +33,9 @@ When mounting an XFS filesystem, the following options are accepted.
removing extended attributes) the on-disk superblock feature
bit field will be updated to reflect this format being in use.
CRC enabled filesystems always use the attr2 format, and so
will reject the noattr2 mount option if it is set.
barrier
Enables the use of block layer write barriers for writes into
the journal and unwritten extent conversion. This allows for
+21 -3
View File
@@ -3005,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
@@ -3330,9 +3351,6 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
plus one apbt timer for broadcast timer.
x86_mrst_timer=apbt_only | lapic_and_apbt
xd= [HW,XT] Original XT pre-IDE (RLL encoded) disks.
xd_geo= See header of drivers/block/xd.c.
xen_emul_unplug= [HW,X86,XEN]
Unplug Xen emulated devices
Format: [unplug0,][unplug1]
-2
View File
@@ -80,8 +80,6 @@ Valid names are:
/dev/sdd: -> 0x0830 (forth SCSI disk)
/dev/sde: -> 0x0840 (fifth SCSI disk)
/dev/fd : -> 0x0200 (floppy disk)
/dev/xda: -> 0x0c00 (first XT disk, unused in Linux/m68k)
/dev/xdb: -> 0x0c40 (second XT disk, unused in Linux/m68k)
The name must be followed by a decimal number, that stands for the
partition number. Internally, the value of the number is just
+2 -2
View File
@@ -420,10 +420,10 @@ tcp_synack_retries - INTEGER
for a passive TCP connection will happen after 63seconds.
tcp_syncookies - BOOLEAN
Only valid when the kernel was compiled with CONFIG_SYNCOOKIES
Only valid when the kernel was compiled with CONFIG_SYN_COOKIES
Send out syncookies when the syn backlog queue of a socket
overflows. This is to prevent against the common 'SYN flood attack'
Default: FALSE
Default: 1
Note, that syncookies is fallback facility.
It MUST NOT be used to help highly loaded servers to stand
+8 -7
View File
@@ -268,7 +268,7 @@ situations.
System Power Management Phases
------------------------------
Suspending or resuming the system is done in several phases. Different phases
are used for standby or memory sleep states ("suspend-to-RAM") and the
are used for freeze, standby, and memory sleep states ("suspend-to-RAM") and the
hibernation state ("suspend-to-disk"). Each phase involves executing callbacks
for every device before the next phase begins. Not all busses or classes
support all these callbacks and not all drivers use all the callbacks. The
@@ -309,7 +309,8 @@ execute the corresponding method from dev->driver->pm instead if there is one.
Entering System Suspend
-----------------------
When the system goes into the standby or memory sleep state, the phases are:
When the system goes into the freeze, standby or memory sleep state,
the phases are:
prepare, suspend, suspend_late, suspend_noirq.
@@ -368,7 +369,7 @@ the devices that were suspended.
Leaving System Suspend
----------------------
When resuming from standby or memory sleep, the phases are:
When resuming from freeze, standby or memory sleep, the phases are:
resume_noirq, resume_early, resume, complete.
@@ -433,8 +434,8 @@ the system log.
Entering Hibernation
--------------------
Hibernating the system is more complicated than putting it into the standby or
memory sleep state, because it involves creating and saving a system image.
Hibernating the system is more complicated than putting it into the other
sleep states, because it involves creating and saving a system image.
Therefore there are more phases for hibernation, with a different set of
callbacks. These phases always run after tasks have been frozen and memory has
been freed.
@@ -485,8 +486,8 @@ image forms an atomic snapshot of the system state.
At this point the system image is saved, and the devices then need to be
prepared for the upcoming system shutdown. This is much like suspending them
before putting the system into the standby or memory sleep state, and the phases
are similar.
before putting the system into the freeze, standby or memory sleep state,
and the phases are similar.
9. The prepare phase is discussed above.
+2 -2
View File
@@ -7,8 +7,8 @@ running. The interface exists in /sys/power/ directory (assuming sysfs
is mounted at /sys).
/sys/power/state controls system power state. Reading from this file
returns what states are supported, which is hard-coded to 'standby'
(Power-On Suspend), 'mem' (Suspend-to-RAM), and 'disk'
returns what states are supported, which is hard-coded to 'freeze',
'standby' (Power-On Suspend), 'mem' (Suspend-to-RAM), and 'disk'
(Suspend-to-Disk).
Writing to this file one of those strings causes the system to

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