You've already forked linux-apfs
mirror of
https://github.com/linux-apfs/linux-apfs.git
synced 2026-05-01 15:00:59 -07:00
Merge tag 'v3.16' into drm-next
Linux 3.16 backmerge requested by i915, nouveau and radeon authors Conflicts: drivers/gpu/drm/i915/i915_gem_render_state.c drivers/gpu/drm/i915/intel_drv.h
This commit is contained in:
@@ -62,6 +62,11 @@ Jeff Garzik <jgarzik@pretzel.yyz.us>
|
||||
Jens Axboe <axboe@suse.de>
|
||||
Jens Osterkamp <Jens.Osterkamp@de.ibm.com>
|
||||
John Stultz <johnstul@us.ibm.com>
|
||||
<josh@joshtriplett.org> <josh@freedesktop.org>
|
||||
<josh@joshtriplett.org> <josh@kernel.org>
|
||||
<josh@joshtriplett.org> <josht@linux.vnet.ibm.com>
|
||||
<josh@joshtriplett.org> <josht@us.ibm.com>
|
||||
<josh@joshtriplett.org> <josht@vnet.ibm.com>
|
||||
Juha Yrjola <at solidboot.com>
|
||||
Juha Yrjola <juha.yrjola@nokia.com>
|
||||
Juha Yrjola <juha.yrjola@solidboot.com>
|
||||
|
||||
@@ -3511,10 +3511,11 @@ S: MacGregor A.C.T 2615
|
||||
S: Australia
|
||||
|
||||
N: Josh Triplett
|
||||
E: josh@freedesktop.org
|
||||
P: 1024D/D0FE7AFB B24A 65C9 1D71 2AC2 DE87 CA26 189B 9946 D0FE 7AFB
|
||||
D: rcutorture maintainer
|
||||
E: josh@joshtriplett.org
|
||||
P: 4096R/8AFF873D 758E 5042 E397 4BA3 3A9C 1E67 0ED9 A3DF 8AFF 873D
|
||||
D: RCU and rcutorture
|
||||
D: lock annotations, finding and fixing lock bugs
|
||||
D: kernel tinification
|
||||
|
||||
N: Winfried Trümper
|
||||
E: winni@xpilot.org
|
||||
|
||||
@@ -280,12 +280,9 @@ that is possible.
|
||||
mcelog
|
||||
------
|
||||
|
||||
In Linux 2.6.31+ the i386 kernel needs to run the mcelog utility
|
||||
as a regular cronjob similar to the x86-64 kernel to process and log
|
||||
machine check events when CONFIG_X86_NEW_MCE is enabled. Machine check
|
||||
events are errors reported by the CPU. Processing them is strongly encouraged.
|
||||
All x86-64 kernels since 2.6.4 require the mcelog utility to
|
||||
process machine checks.
|
||||
On x86 kernels the mcelog utility is needed to process and log machine check
|
||||
events when CONFIG_X86_MCE is enabled. Machine check events are errors reported
|
||||
by the CPU. Processing them is strongly encouraged.
|
||||
|
||||
Getting updated software
|
||||
========================
|
||||
|
||||
@@ -708,7 +708,7 @@ hardware level details could be very different.
|
||||
|
||||
<para>Systems need specialized hardware support to implement OTG,
|
||||
notably including a special <emphasis>Mini-AB</emphasis> jack
|
||||
and associated transciever to support <emphasis>Dual-Role</emphasis>
|
||||
and associated transceiver to support <emphasis>Dual-Role</emphasis>
|
||||
operation:
|
||||
they can act either as a host, using the standard
|
||||
Linux-USB host side driver stack,
|
||||
|
||||
@@ -182,7 +182,7 @@
|
||||
<para>
|
||||
Each interrupt is described by an interrupt descriptor structure
|
||||
irq_desc. The interrupt is referenced by an 'unsigned int' numeric
|
||||
value which selects the corresponding interrupt decription structure
|
||||
value which selects the corresponding interrupt description structure
|
||||
in the descriptor structures array.
|
||||
The descriptor structure contains status information and pointers
|
||||
to the interrupt flow method and the interrupt chip structure
|
||||
@@ -470,7 +470,7 @@ if (desc->irq_data.chip->irq_eoi)
|
||||
<para>
|
||||
To avoid copies of identical implementations of IRQ chips the
|
||||
core provides a configurable generic interrupt chip
|
||||
implementation. Developers should check carefuly whether the
|
||||
implementation. Developers should check carefully whether the
|
||||
generic chip fits their needs before implementing the same
|
||||
functionality slightly differently themselves.
|
||||
</para>
|
||||
|
||||
@@ -1760,7 +1760,7 @@ as it would be on UP.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
There is a furthur optimization possible here: remember our original
|
||||
There is a further optimization possible here: remember our original
|
||||
cache code, where there were no reference counts and the caller simply
|
||||
held the lock whenever using the object? This is still possible: if
|
||||
you hold the lock, no one can delete the object, so you don't need to
|
||||
|
||||
@@ -677,7 +677,7 @@ and other resources, etc.
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
ATA_QCFLAG_ACTIVE is clared from qc->flags.
|
||||
ATA_QCFLAG_ACTIVE is cleared from qc->flags.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
@@ -708,7 +708,7 @@ and other resources, etc.
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
qc->waiting is claread & completed (in that order).
|
||||
qc->waiting is cleared & completed (in that order).
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
@@ -1163,7 +1163,7 @@ and other resources, etc.
|
||||
|
||||
<para>
|
||||
Once sense data is acquired, this type of errors can be
|
||||
handled similary to other SCSI errors. Note that sense data
|
||||
handled similarly to other SCSI errors. Note that sense data
|
||||
may indicate ATA bus error (e.g. Sense Key 04h HARDWARE ERROR
|
||||
&& ASC/ASCQ 47h/00h SCSI PARITY ERROR). In such
|
||||
cases, the error should be considered as an ATA bus error and
|
||||
|
||||
@@ -68,7 +68,7 @@
|
||||
several digital tv standards. While it is called as DVB API,
|
||||
in fact it covers several different video standards including
|
||||
DVB-T, DVB-S, DVB-C and ATSC. The API is currently being updated
|
||||
to documment support also for DVB-S2, ISDB-T and ISDB-S.</para>
|
||||
to document support also for DVB-S2, ISDB-T and ISDB-S.</para>
|
||||
<para>The third part covers the Remote Controller API.</para>
|
||||
<para>The fourth part covers the Media Controller API.</para>
|
||||
<para>For additional information and for the latest development code,
|
||||
|
||||
@@ -91,7 +91,7 @@
|
||||
<listitem><para>
|
||||
[MTD Interface]</para><para>
|
||||
These functions provide the interface to the MTD kernel API.
|
||||
They are not replacable and provide functionality
|
||||
They are not replaceable and provide functionality
|
||||
which is complete hardware independent.
|
||||
</para></listitem>
|
||||
<listitem><para>
|
||||
@@ -100,14 +100,14 @@
|
||||
</para></listitem>
|
||||
<listitem><para>
|
||||
[GENERIC]</para><para>
|
||||
Generic functions are not replacable and provide functionality
|
||||
Generic functions are not replaceable and provide functionality
|
||||
which is complete hardware independent.
|
||||
</para></listitem>
|
||||
<listitem><para>
|
||||
[DEFAULT]</para><para>
|
||||
Default functions provide hardware related functionality which is suitable
|
||||
for most of the implementations. These functions can be replaced by the
|
||||
board driver if neccecary. Those functions are called via pointers in the
|
||||
board driver if necessary. Those functions are called via pointers in the
|
||||
NAND chip description structure. The board driver can set the functions which
|
||||
should be replaced by board dependent functions before calling nand_scan().
|
||||
If the function pointer is NULL on entry to nand_scan() then the pointer
|
||||
@@ -264,7 +264,7 @@ static void board_hwcontrol(struct mtd_info *mtd, int cmd)
|
||||
is set up nand_scan() is called. This function tries to
|
||||
detect and identify then chip. If a chip is found all the
|
||||
internal data fields are initialized accordingly.
|
||||
The structure(s) have to be zeroed out first and then filled with the neccecary
|
||||
The structure(s) have to be zeroed out first and then filled with the necessary
|
||||
information about the device.
|
||||
</para>
|
||||
<programlisting>
|
||||
@@ -327,7 +327,7 @@ module_init(board_init);
|
||||
<sect1 id="Exit_function">
|
||||
<title>Exit function</title>
|
||||
<para>
|
||||
The exit function is only neccecary if the driver is
|
||||
The exit function is only necessary if the driver is
|
||||
compiled as a module. It releases all resources which
|
||||
are held by the chip driver and unregisters the partitions
|
||||
in the MTD layer.
|
||||
@@ -494,7 +494,7 @@ static void board_select_chip (struct mtd_info *mtd, int chip)
|
||||
in this case. See rts_from4.c and diskonchip.c for
|
||||
implementation reference. In those cases we must also
|
||||
use bad block tables on FLASH, because the ECC layout is
|
||||
interferring with the bad block marker positions.
|
||||
interfering with the bad block marker positions.
|
||||
See bad block table support for details.
|
||||
</para>
|
||||
</sect2>
|
||||
@@ -542,7 +542,7 @@ static void board_select_chip (struct mtd_info *mtd, int chip)
|
||||
<para>
|
||||
nand_scan() calls the function nand_default_bbt().
|
||||
nand_default_bbt() selects appropriate default
|
||||
bad block table desriptors depending on the chip information
|
||||
bad block table descriptors depending on the chip information
|
||||
which was retrieved by nand_scan().
|
||||
</para>
|
||||
<para>
|
||||
@@ -554,7 +554,7 @@ static void board_select_chip (struct mtd_info *mtd, int chip)
|
||||
<sect2 id="Flash_based_tables">
|
||||
<title>Flash based tables</title>
|
||||
<para>
|
||||
It may be desired or neccecary to keep a bad block table in FLASH.
|
||||
It may be desired or necessary to keep a bad block table in FLASH.
|
||||
For AG-AND chips this is mandatory, as they have no factory marked
|
||||
bad blocks. They have factory marked good blocks. The marker pattern
|
||||
is erased when the block is erased to be reused. So in case of
|
||||
@@ -565,10 +565,10 @@ static void board_select_chip (struct mtd_info *mtd, int chip)
|
||||
of the blocks.
|
||||
</para>
|
||||
<para>
|
||||
The blocks in which the tables are stored are procteted against
|
||||
The blocks in which the tables are stored are protected against
|
||||
accidental access by marking them bad in the memory bad block
|
||||
table. The bad block table management functions are allowed
|
||||
to circumvernt this protection.
|
||||
to circumvent this protection.
|
||||
</para>
|
||||
<para>
|
||||
The simplest way to activate the FLASH based bad block table support
|
||||
@@ -592,7 +592,7 @@ static void board_select_chip (struct mtd_info *mtd, int chip)
|
||||
User defined tables are created by filling out a
|
||||
nand_bbt_descr structure and storing the pointer in the
|
||||
nand_chip structure member bbt_td before calling nand_scan().
|
||||
If a mirror table is neccecary a second structure must be
|
||||
If a mirror table is necessary a second structure must be
|
||||
created and a pointer to this structure must be stored
|
||||
in bbt_md inside the nand_chip structure. If the bbt_md
|
||||
member is set to NULL then only the main table is used
|
||||
@@ -666,7 +666,7 @@ static void board_select_chip (struct mtd_info *mtd, int chip)
|
||||
<para>
|
||||
For automatic placement some blocks must be reserved for
|
||||
bad block table storage. The number of reserved blocks is defined
|
||||
in the maxblocks member of the babd block table description structure.
|
||||
in the maxblocks member of the bad block table description structure.
|
||||
Reserving 4 blocks for mirrored tables should be a reasonable number.
|
||||
This also limits the number of blocks which are scanned for the bad
|
||||
block table ident pattern.
|
||||
@@ -1068,11 +1068,11 @@ in this page</entry>
|
||||
<chapter id="filesystems">
|
||||
<title>Filesystem support</title>
|
||||
<para>
|
||||
The NAND driver provides all neccecary functions for a
|
||||
The NAND driver provides all necessary functions for a
|
||||
filesystem via the MTD interface.
|
||||
</para>
|
||||
<para>
|
||||
Filesystems must be aware of the NAND pecularities and
|
||||
Filesystems must be aware of the NAND peculiarities and
|
||||
restrictions. One major restrictions of NAND Flash is, that you cannot
|
||||
write as often as you want to a page. The consecutive writes to a page,
|
||||
before erasing it again, are restricted to 1-3 writes, depending on the
|
||||
@@ -1222,7 +1222,7 @@ in this page</entry>
|
||||
#define NAND_BBT_VERSION 0x00000100
|
||||
/* Create a bbt if none axists */
|
||||
#define NAND_BBT_CREATE 0x00000200
|
||||
/* Write bbt if neccecary */
|
||||
/* Write bbt if necessary */
|
||||
#define NAND_BBT_WRITE 0x00001000
|
||||
/* Read and write back block contents when writing bbt */
|
||||
#define NAND_BBT_SAVECONTENT 0x00002000
|
||||
|
||||
@@ -155,7 +155,7 @@
|
||||
release regulators. Functions are
|
||||
provided to <link linkend='API-regulator-enable'>enable</link>
|
||||
and <link linkend='API-regulator-disable'>disable</link> the
|
||||
reguator and to get and set the runtime parameters of the
|
||||
regulator and to get and set the runtime parameters of the
|
||||
regulator.
|
||||
</para>
|
||||
<para>
|
||||
|
||||
@@ -766,10 +766,10 @@ framework to set up sysfs files for this region. Simply leave it alone.
|
||||
<para>
|
||||
The dynamic memory regions will be allocated when the UIO device file,
|
||||
<varname>/dev/uioX</varname> is opened.
|
||||
Simiar to static memory resources, the memory region information for
|
||||
Similar to static memory resources, the memory region information for
|
||||
dynamic regions is then visible via sysfs at
|
||||
<varname>/sys/class/uio/uioX/maps/mapY/*</varname>.
|
||||
The dynmaic memory regions will be freed when the UIO device file is
|
||||
The dynamic memory regions will be freed when the UIO device file is
|
||||
closed. When no processes are holding the device file open, the address
|
||||
returned to userspace is ~0.
|
||||
</para>
|
||||
|
||||
@@ -153,7 +153,7 @@
|
||||
|
||||
<listitem><para>The Linux USB API supports synchronous calls for
|
||||
control and bulk messages.
|
||||
It also supports asynchnous calls for all kinds of data transfer,
|
||||
It also supports asynchronous calls for all kinds of data transfer,
|
||||
using request structures called "URBs" (USB Request Blocks).
|
||||
</para></listitem>
|
||||
|
||||
|
||||
@@ -5696,7 +5696,7 @@ struct _snd_pcm_runtime {
|
||||
suspending the PCM operations via
|
||||
<function>snd_pcm_suspend_all()</function> or
|
||||
<function>snd_pcm_suspend()</function>. It means that the PCM
|
||||
streams are already stoppped when the register snapshot is
|
||||
streams are already stopped when the register snapshot is
|
||||
taken. But, remember that you don't have to restart the PCM
|
||||
stream in the resume callback. It'll be restarted via
|
||||
trigger call with <constant>SNDRV_PCM_TRIGGER_RESUME</constant>
|
||||
|
||||
@@ -60,12 +60,6 @@ If the driver needs to perform more complex initialization like getting and
|
||||
configuring GPIOs it can get its ACPI handle and extract this information
|
||||
from ACPI tables.
|
||||
|
||||
Currently the kernel is not able to automatically determine from which ACPI
|
||||
device it should make the corresponding platform device so we need to add
|
||||
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
|
||||
|
||||
@@ -15,10 +15,13 @@ New sysfs files for controlling P state selection have been added to
|
||||
/sys/devices/system/cpu/intel_pstate/
|
||||
|
||||
max_perf_pct: limits the maximum P state that will be requested by
|
||||
the driver stated as a percentage of the available performance.
|
||||
the driver stated as a percentage of the available performance. The
|
||||
available (P states) performance may be reduced by the no_turbo
|
||||
setting described below.
|
||||
|
||||
min_perf_pct: limits the minimum P state that will be requested by
|
||||
the driver stated as a percentage of the available performance.
|
||||
the driver stated as a percentage of the max (non-turbo)
|
||||
performance level.
|
||||
|
||||
no_turbo: limits the driver to selecting P states below the turbo
|
||||
frequency range.
|
||||
|
||||
@@ -9,6 +9,18 @@ Required Properties:
|
||||
- reg: physical base address of the controller and length of memory mapped
|
||||
region.
|
||||
|
||||
Optional Properties:
|
||||
- clocks: List of clock handles. The parent clocks of the input clocks to the
|
||||
devices in this power domain are set to oscclk before power gating
|
||||
and restored back after powering on a domain. This is required for
|
||||
all domains which are powered on and off and not required for unused
|
||||
domains.
|
||||
- clock-names: The following clocks can be specified:
|
||||
- oscclk: Oscillator clock.
|
||||
- pclkN, clkN: Pairs of parent of input clock and input clock to the
|
||||
devices in this power domain. Maximum of 4 pairs (N = 0 to 3)
|
||||
are supported currently.
|
||||
|
||||
Node of a device using power domains must have a samsung,power-domain property
|
||||
defined with a phandle to respective power domain.
|
||||
|
||||
@@ -19,6 +31,14 @@ Example:
|
||||
reg = <0x10023C00 0x10>;
|
||||
};
|
||||
|
||||
mfc_pd: power-domain@10044060 {
|
||||
compatible = "samsung,exynos4210-pd";
|
||||
reg = <0x10044060 0x20>;
|
||||
clocks = <&clock CLK_FIN_PLL>, <&clock CLK_MOUT_SW_ACLK333>,
|
||||
<&clock CLK_MOUT_USER_ACLK333>;
|
||||
clock-names = "oscclk", "pclk0", "clk0";
|
||||
};
|
||||
|
||||
Example of the node using power domain:
|
||||
|
||||
node {
|
||||
|
||||
@@ -8,10 +8,12 @@ Both required and optional properties listed below must be defined
|
||||
under node /cpus/cpu@0.
|
||||
|
||||
Required properties:
|
||||
- operating-points: Refer to Documentation/devicetree/bindings/power/opp.txt
|
||||
for details
|
||||
- None
|
||||
|
||||
Optional properties:
|
||||
- operating-points: Refer to Documentation/devicetree/bindings/power/opp.txt for
|
||||
details. OPPs *must* be supplied either via DT, i.e. this property, or
|
||||
populated at runtime.
|
||||
- clock-latency: Specify the possible maximum transition latency for clock,
|
||||
in unit of nanoseconds.
|
||||
- voltage-tolerance: Specify the CPU voltage tolerance in percentage.
|
||||
|
||||
@@ -4,6 +4,13 @@ Required properties:
|
||||
|
||||
- compatible: Must contain one of the following:
|
||||
|
||||
- "renesas,scifa-sh73a0" for SH73A0 (SH-Mobile AG5) SCIFA compatible UART.
|
||||
- "renesas,scifb-sh73a0" for SH73A0 (SH-Mobile AG5) SCIFB compatible UART.
|
||||
- "renesas,scifa-r8a73a4" for R8A73A4 (R-Mobile APE6) SCIFA compatible UART.
|
||||
- "renesas,scifb-r8a73a4" for R8A73A4 (R-Mobile APE6) SCIFB compatible UART.
|
||||
- "renesas,scifa-r8a7740" for R8A7740 (R-Mobile A1) SCIFA compatible UART.
|
||||
- "renesas,scifb-r8a7740" for R8A7740 (R-Mobile A1) SCIFB compatible UART.
|
||||
- "renesas,scif-r8a7778" for R8A7778 (R-Car M1) SCIF compatible UART.
|
||||
- "renesas,scif-r8a7779" for R8A7779 (R-Car H1) SCIF compatible UART.
|
||||
- "renesas,scif-r8a7790" for R8A7790 (R-Car H2) SCIF compatible UART.
|
||||
- "renesas,scifa-r8a7790" for R8A7790 (R-Car H2) SCIFA compatible UART.
|
||||
|
||||
@@ -281,6 +281,19 @@ gestures can normally be extracted from it.
|
||||
If INPUT_PROP_SEMI_MT is not set, the device is assumed to be a true MT
|
||||
device.
|
||||
|
||||
INPUT_PROP_TOPBUTTONPAD:
|
||||
-----------------------
|
||||
Some laptops, most notably the Lenovo *40 series provide a trackstick
|
||||
device but do not have physical buttons associated with the trackstick
|
||||
device. Instead, the top area of the touchpad is marked to show
|
||||
visual/haptic areas for left, middle, right buttons intended to be used
|
||||
with the trackstick.
|
||||
|
||||
If INPUT_PROP_TOPBUTTONPAD is set, userspace should emulate buttons
|
||||
accordingly. This property does not affect kernel behavior.
|
||||
The kernel does not provide button emulation for such devices but treats
|
||||
them as any other INPUT_PROP_BUTTONPAD device.
|
||||
|
||||
Guidelines:
|
||||
==========
|
||||
The guidelines below ensure proper single-touch and multi-finger functionality.
|
||||
|
||||
@@ -2790,6 +2790,12 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
|
||||
leaf rcu_node structure. Useful for very large
|
||||
systems.
|
||||
|
||||
rcutree.jiffies_till_sched_qs= [KNL]
|
||||
Set required age in jiffies for a
|
||||
given grace period before RCU starts
|
||||
soliciting quiescent-state help from
|
||||
rcu_note_context_switch().
|
||||
|
||||
rcutree.jiffies_till_first_fqs= [KNL]
|
||||
Set delay from grace-period initialization to
|
||||
first attempt to force quiescent states.
|
||||
@@ -3526,7 +3532,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
|
||||
the allocated input device; If set to 0, video driver
|
||||
will only send out the event without touching backlight
|
||||
brightness level.
|
||||
default: 0
|
||||
default: 1
|
||||
|
||||
virtio_mmio.device=
|
||||
[VMMIO] Memory mapped virtio (platform) device.
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user