Commit 742eaa6a authored by Russell King's avatar Russell King
Browse files

Merge branch 'for-rmk' of...

Merge branch 'for-rmk' of git://git.kernel.org/pub/scm/linux/kernel/git/will/linux into devel-stable

Conflicts:
	arch/arm/common/gic.c
	arch/arm/plat-omap/include/plat/common.h
parents ba8bb18a ae72fd58
......@@ -206,16 +206,3 @@ Description:
when a discarded area is read the discard_zeroes_data
parameter will be set to one. Otherwise it will be 0 and
the result of reading a discarded area is undefined.
What: /sys/block/<disk>/alias
Date: Aug 2011
Contact: Nao Nishijima <nao.nishijima.xt@hitachi.com>
Description:
A raw device name of a disk does not always point a same disk
each boot-up time. Therefore, users have to use persistent
device names, which udev creates when the kernel finds a disk,
instead of raw device name. However, kernel doesn't show those
persistent names on its messages (e.g. dmesg).
This file can store an alias of the disk and it would be
appeared in kernel messages if it is set. A disk can have an
alias which length is up to 255bytes. Users can use alphabets,
numbers, "-" and "_" in alias name. This file is writeonce.
......@@ -520,6 +520,11 @@ Here's a description of the fields of <varname>struct uio_mem</varname>:
</para>
<itemizedlist>
<listitem><para>
<varname>const char *name</varname>: Optional. Set this to help identify
the memory region, it will show up in the corresponding sysfs node.
</para></listitem>
<listitem><para>
<varname>int memtype</varname>: Required if the mapping is used. Set this to
<varname>UIO_MEM_PHYS</varname> if you you have physical memory on your
......@@ -553,7 +558,7 @@ instead to remember such an address.
</itemizedlist>
<para>
Please do not touch the <varname>kobj</varname> element of
Please do not touch the <varname>map</varname> element of
<varname>struct uio_mem</varname>! It is used by the UIO framework
to set up sysfs files for this mapping. Simply leave it alone.
</para>
......
......@@ -98,14 +98,12 @@ You must enable "SCSI tape drive support for Smart Array 5xxx" and
"SCSI support" in your kernel configuration to be able to use SCSI
tape drives with your Smart Array 5xxx controller.
Additionally, note that the driver will not engage the SCSI core at init
time. The driver must be directed to dynamically engage the SCSI core via
the /proc filesystem entry which the "block" side of the driver creates as
/proc/driver/cciss/cciss* at runtime. This is because at driver init time,
the SCSI core may not yet be initialized (because the driver is a block
driver) and attempting to register it with the SCSI core in such a case
would cause a hang. This is best done via an initialization script
(typically in /etc/init.d, but could vary depending on distribution).
Additionally, note that the driver will engage the SCSI core at init
time if any tape drives or medium changers are detected. The driver may
also be directed to dynamically engage the SCSI core via the /proc filesystem
entry which the "block" side of the driver creates as
/proc/driver/cciss/cciss* at runtime. This is best done via a script.
For example:
for x in /proc/driver/cciss/cciss[0-9]*
......
......@@ -33,6 +33,7 @@ qcom Qualcomm, Inc.
ramtron Ramtron International
samsung Samsung Semiconductor
schindler Schindler
sil Silicon Image
simtek
sirf SiRF Technology, Inc.
stericsson ST-Ericsson
......
......@@ -63,8 +63,8 @@ IRC network.
Userspace tools for creating and manipulating Btrfs file systems are
available from the git repository at the following location:
http://git.kernel.org/?p=linux/kernel/git/mason/btrfs-progs-unstable.git
git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs-unstable.git
http://git.kernel.org/?p=linux/kernel/git/mason/btrfs-progs.git
git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git
These include the following tools:
......
The I2C protocol knows about two kinds of device addresses: normal 7 bit
addresses, and an extended set of 10 bit addresses. The sets of addresses
do not intersect: the 7 bit address 0x10 is not the same as the 10 bit
address 0x10 (though a single device could respond to both of them). You
select a 10 bit address by adding an extra byte after the address
byte:
S Addr7 Rd/Wr ....
becomes
S 11110 Addr10 Rd/Wr
S is the start bit, Rd/Wr the read/write bit, and if you count the number
of bits, you will see the there are 8 after the S bit for 7 bit addresses,
and 16 after the S bit for 10 bit addresses.
address 0x10 (though a single device could respond to both of them).
WARNING! The current 10 bit address support is EXPERIMENTAL. There are
several places in the code that will cause SEVERE PROBLEMS with 10 bit
addresses, even though there is some basic handling and hooks. Also,
almost no supported adapter handles the 10 bit addresses correctly.
I2C messages to and from 10-bit address devices have a different format.
See the I2C specification for the details.
As soon as a real 10 bit address device is spotted 'in the wild', we
can and will add proper support. Right now, 10 bit address devices
are defined by the I2C protocol, but we have never seen a single device
which supports them.
The current 10 bit address support is minimal. It should work, however
you can expect some problems along the way:
* Not all bus drivers support 10-bit addresses. Some don't because the
hardware doesn't support them (SMBus doesn't require 10-bit address
support for example), some don't because nobody bothered adding the
code (or it's there but not working properly.) Software implementation
(i2c-algo-bit) is known to work.
* Some optional features do not support 10-bit addresses. This is the
case of automatic detection and instantiation of devices by their,
drivers, for example.
* Many user-space packages (for example i2c-tools) lack support for
10-bit addresses.
Note that 10-bit address devices are still pretty rare, so the limitations
listed above could stay for a long time, maybe even forever if nobody
needs them to be fixed.
......@@ -20,7 +20,7 @@ ip_no_pmtu_disc - BOOLEAN
default FALSE
min_pmtu - INTEGER
default 562 - minimum discovered Path MTU
default 552 - minimum discovered Path MTU
route/max_size - INTEGER
Maximum number of routes allowed in the kernel. Increase
......
......@@ -123,9 +123,10 @@ please refer directly to the source code for more information about it.
Subsystem-Level Methods
-----------------------
The core methods to suspend and resume devices reside in struct dev_pm_ops
pointed to by the pm member of struct bus_type, struct device_type and
struct class. They are mostly of interest to the people writing infrastructure
for buses, like PCI or USB, or device type and device class drivers.
pointed to by the ops member of struct dev_pm_domain, or by the pm member of
struct bus_type, struct device_type and struct class. They are mostly of
interest to the people writing infrastructure for platforms and buses, like PCI
or USB, or device type and device class drivers.
Bus drivers implement these methods as appropriate for the hardware and the
drivers using it; PCI works differently from USB, and so on. Not many people
......@@ -139,41 +140,57 @@ sequencing in the driver model tree.
/sys/devices/.../power/wakeup files
-----------------------------------
All devices in the driver model have two flags to control handling of wakeup
events (hardware signals that can force the device and/or system out of a low
power state). These flags are initialized by bus or device driver code using
All device objects in the driver model contain fields that control the handling
of system wakeup events (hardware signals that can force the system out of a
sleep state). These fields are initialized by bus or device driver code using
device_set_wakeup_capable() and device_set_wakeup_enable(), defined in
include/linux/pm_wakeup.h.
The "can_wakeup" flag just records whether the device (and its driver) can
The "power.can_wakeup" flag just records whether the device (and its driver) can
physically support wakeup events. The device_set_wakeup_capable() routine
affects this flag. The "should_wakeup" flag controls whether the device should
try to use its wakeup mechanism. device_set_wakeup_enable() affects this flag;
for the most part drivers should not change its value. The initial value of
should_wakeup is supposed to be false for the majority of devices; the major
exceptions are power buttons, keyboards, and Ethernet adapters whose WoL
(wake-on-LAN) feature has been set up with ethtool. It should also default
to true for devices that don't generate wakeup requests on their own but merely
forward wakeup requests from one bus to another (like PCI bridges).
affects this flag. The "power.wakeup" field is a pointer to an object of type
struct wakeup_source used for controlling whether or not the device should use
its system wakeup mechanism and for notifying the PM core of system wakeup
events signaled by the device. This object is only present for wakeup-capable
devices (i.e. devices whose "can_wakeup" flags are set) and is created (or
removed) by device_set_wakeup_capable().
Whether or not a device is capable of issuing wakeup events is a hardware
matter, and the kernel is responsible for keeping track of it. By contrast,
whether or not a wakeup-capable device should issue wakeup events is a policy
decision, and it is managed by user space through a sysfs attribute: the
power/wakeup file. User space can write the strings "enabled" or "disabled" to
set or clear the "should_wakeup" flag, respectively. This file is only present
for wakeup-capable devices (i.e. devices whose "can_wakeup" flags are set)
and is created (or removed) by device_set_wakeup_capable(). Reads from the
file will return the corresponding string.
The device_may_wakeup() routine returns true only if both flags are set.
"power/wakeup" file. User space can write the strings "enabled" or "disabled"
to it to indicate whether or not, respectively, the device is supposed to signal
system wakeup. This file is only present if the "power.wakeup" object exists
for the given device and is created (or removed) along with that object, by
device_set_wakeup_capable(). Reads from the file will return the corresponding
string.
The "power/wakeup" file is supposed to contain the "disabled" string initially
for the majority of devices; the major exceptions are power buttons, keyboards,
and Ethernet adapters whose WoL (wake-on-LAN) feature has been set up with
ethtool. It should also default to "enabled" for devices that don't generate
wakeup requests on their own but merely forward wakeup requests from one bus to
another (like PCI Express ports).
The device_may_wakeup() routine returns true only if the "power.wakeup" object
exists and the corresponding "power/wakeup" file contains the string "enabled".
This information is used by subsystems, like the PCI bus type code, to see
whether or not to enable the devices' wakeup mechanisms. If device wakeup
mechanisms are enabled or disabled directly by drivers, they also should use
device_may_wakeup() to decide what to do during a system sleep transition.
However for runtime power management, wakeup events should be enabled whenever
the device and driver both support them, regardless of the should_wakeup flag.
Device drivers, however, are not supposed to call device_set_wakeup_enable()
directly in any case.
It ought to be noted that system wakeup is conceptually different from "remote
wakeup" used by runtime power management, although it may be supported by the
same physical mechanism. Remote wakeup is a feature allowing devices in
low-power states to trigger specific interrupts to signal conditions in which
they should be put into the full-power state. Those interrupts may or may not
be used to signal system wakeup events, depending on the hardware design. On
some systems it is impossible to trigger them from system sleep states. In any
case, remote wakeup should always be enabled for runtime power management for
all devices and drivers that support it.
/sys/devices/.../power/control files
------------------------------------
......@@ -249,20 +266,31 @@ 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
various phases always run after tasks have been frozen and before they are
unfrozen. Furthermore, the *_noirq phases run at a time when IRQ handlers have
been disabled (except for those marked with the IRQ_WAKEUP flag).
All phases use bus, type, or class callbacks (that is, methods defined in
dev->bus->pm, dev->type->pm, or dev->class->pm). These callbacks are mutually
exclusive, so if the device type provides a struct dev_pm_ops object pointed to
by its pm field (i.e. both dev->type and dev->type->pm are defined), the
callbacks included in that object (i.e. dev->type->pm) will be used. Otherwise,
if the class provides a struct dev_pm_ops object pointed to by its pm field
(i.e. both dev->class and dev->class->pm are defined), the PM core will use the
callbacks from that object (i.e. dev->class->pm). Finally, if the pm fields of
both the device type and class objects are NULL (or those objects do not exist),
the callbacks provided by the bus (that is, the callbacks from dev->bus->pm)
will be used (this allows device types to override callbacks provided by bus
types or classes if necessary).
been disabled (except for those marked with the IRQF_NO_SUSPEND flag).
All phases use PM domain, bus, type, or class callbacks (that is, methods
defined in dev->pm_domain->ops, dev->bus->pm, dev->type->pm, or dev->class->pm).
These callbacks are regarded by the PM core as mutually exclusive. Moreover,
PM domain callbacks always take precedence over bus, type and class callbacks,
while type callbacks take precedence over bus and class callbacks, and class
callbacks take precedence over bus callbacks. To be precise, the following
rules are used to determine which callback to execute in the given phase:
1. If dev->pm_domain is present, the PM core will attempt to execute the
callback included in dev->pm_domain->ops. If that callback is not
present, no action will be carried out for the given device.
2. Otherwise, if both dev->type and dev->type->pm are present, the callback
included in dev->type->pm will be executed.
3. Otherwise, if both dev->class and dev->class->pm are present, the
callback included in dev->class->pm will be executed.
4. Otherwise, if both dev->bus and dev->bus->pm are present, the callback
included in dev->bus->pm will be executed.
This allows PM domains and device types to override callbacks provided by bus
types or device classes if necessary.
These callbacks may in turn invoke device- or driver-specific methods stored in
dev->driver->pm, but they don't have to.
......@@ -283,9 +311,8 @@ When the system goes into the standby or memory sleep state, the phases are:
After the prepare callback method returns, no new children may be
registered below the device. The method may also prepare the device or
driver in some way for the upcoming system power transition (for
example, by allocating additional memory required for this purpose), but
it should not put the device into a low-power state.
driver in some way for the upcoming system power transition, but it
should not put the device into a low-power state.
2. The suspend methods should quiesce the device to stop it from performing
I/O. They also may save the device registers and put it into the
......
......@@ -44,25 +44,33 @@ struct dev_pm_ops {
};
The ->runtime_suspend(), ->runtime_resume() and ->runtime_idle() callbacks
are executed by the PM core for either the power domain, or the device type
(if the device power domain's struct dev_pm_ops does not exist), or the class
(if the device power domain's and type's struct dev_pm_ops object does not
exist), or the bus type (if the device power domain's, type's and class'
struct dev_pm_ops objects do not exist) of the given device, so the priority
order of callbacks from high to low is that power domain callbacks, device
type callbacks, class callbacks and bus type callbacks, and the high priority
one will take precedence over low priority one. The bus type, device type and
class callbacks are referred to as subsystem-level callbacks in what follows,
and generally speaking, the power domain callbacks are used for representing
power domains within a SoC.
are executed by the PM core for the device's subsystem that may be either of
the following:
1. PM domain of the device, if the device's PM domain object, dev->pm_domain,
is present.
2. Device type of the device, if both dev->type and dev->type->pm are present.
3. Device class of the device, if both dev->class and dev->class->pm are
present.
4. Bus type of the device, if both dev->bus and dev->bus->pm are present.
The PM core always checks which callback to use in the order given above, so the
priority order of callbacks from high to low is: PM domain, device type, class
and bus type. Moreover, the high-priority one will always take precedence over
a low-priority one. The PM domain, bus type, device type and class callbacks
are referred to as subsystem-level callbacks in what follows.
By default, the callbacks are always invoked in process context with interrupts
enabled. However, subsystems can use the pm_runtime_irq_safe() helper function
to tell the PM core that a device's ->runtime_suspend() and ->runtime_resume()
callbacks should be invoked in atomic context with interrupts disabled.
This implies that these callback routines must not block or sleep, but it also
means that the synchronous helper functions listed at the end of Section 4 can
be used within an interrupt handler or in an atomic context.
to tell the PM core that their ->runtime_suspend(), ->runtime_resume() and
->runtime_idle() callbacks may be invoked in atomic context with interrupts
disabled for a given device. This implies that the callback routines in
question must not block or sleep, but it also means that the synchronous helper
functions listed at the end of Section 4 may be used for that device within an
interrupt handler or generally in an atomic context.
The subsystem-level suspend callback is _entirely_ _responsible_ for handling
the suspend of the device as appropriate, which may, but need not include
......
......@@ -97,15 +97,23 @@
struct serial_rs485 rs485conf;
/* Set RS485 mode: */
/* Enable RS485 mode: */
rs485conf.flags |= SER_RS485_ENABLED;
/* Set logical level for RTS pin equal to 1 when sending: */
rs485conf.flags |= SER_RS485_RTS_ON_SEND;
/* or, set logical level for RTS pin equal to 0 when sending: */
rs485conf.flags &= ~(SER_RS485_RTS_ON_SEND);
/* Set logical level for RTS pin equal to 1 after sending: */
rs485conf.flags |= SER_RS485_RTS_AFTER_SEND;
/* or, set logical level for RTS pin equal to 0 after sending: */
rs485conf.flags &= ~(SER_RS485_RTS_AFTER_SEND);
/* Set rts delay before send, if needed: */
rs485conf.flags |= SER_RS485_RTS_BEFORE_SEND;
rs485conf.delay_rts_before_send = ...;
/* Set rts delay after send, if needed: */
rs485conf.flags |= SER_RS485_RTS_AFTER_SEND;
rs485conf.delay_rts_after_send = ...;
/* Set this flag if you want to receive data even whilst sending data */
......
......@@ -579,7 +579,7 @@ Development Tree
~~~~~~~~~~~~~~~~
The latest development codes for HD-audio are found on sound git tree:
- git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git
- git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
The master branch or for-next branches can be used as the main
development branches in general while the HD-audio specific patches
......@@ -594,7 +594,7 @@ is, installed via the usual spells: configure, make and make
install(-modules). See INSTALL in the package. The snapshot tarballs
are found at:
- ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/snapshot/
- ftp://ftp.suse.com/pub/people/tiwai/snapshot/
Sending a Bug Report
......@@ -696,7 +696,7 @@ via hda-verb won't change the mixer value.
The hda-verb program is found in the ftp directory:
- ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/misc/
- ftp://ftp.suse.com/pub/people/tiwai/misc/
Also a git repository is available:
......@@ -764,7 +764,7 @@ operation, the jack plugging simulation, etc.
The package is found in:
- ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/misc/
- ftp://ftp.suse.com/pub/people/tiwai/misc/
A git repository is available:
......
......@@ -789,6 +789,7 @@ L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
T: git git://git.pengutronix.de/git/imx/linux-2.6.git
F: arch/arm/mach-mx*/
F: arch/arm/mach-imx/
F: arch/arm/plat-mxc/
ARM/FREESCALE IMX51
......@@ -804,6 +805,13 @@ S: Maintained
T: git git://git.linaro.org/people/shawnguo/linux-2.6.git
F: arch/arm/mach-imx/*imx6*
ARM/FREESCALE MXS ARM ARCHITECTURE
M: Shawn Guo <shawn.guo@linaro.org>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
T: git git://git.linaro.org/people/shawnguo/linux-2.6.git
F: arch/arm/mach-mxs/
ARM/GLOMATION GESBC9312SX MACHINE SUPPORT
M: Lennert Buytenhek <kernel@wantstofly.org>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
......@@ -1789,6 +1797,14 @@ F: include/net/cfg80211.h
F: net/wireless/*
X: net/wireless/wext*
CHAR and MISC DRIVERS
M: Arnd Bergmann <arnd@arndb.de>
M: Greg Kroah-Hartman <greg@kroah.com>
T: git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
S: Maintained
F: drivers/char/*
F: drivers/misc/*
CHECKPATCH
M: Andy Whitcroft <apw@canonical.com>
S: Supported
......@@ -1927,9 +1943,11 @@ S: Maintained
F: drivers/connector/
CONTROL GROUPS (CGROUPS)
M: Paul Menage <paul@paulmenage.org>
M: Tejun Heo <tj@kernel.org>
M: Li Zefan <lizf@cn.fujitsu.com>
L: containers@lists.linux-foundation.org
L: cgroups@vger.kernel.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git
S: Maintained
F: include/linux/cgroup*
F: kernel/cgroup*
......@@ -2584,7 +2602,7 @@ S: Maintained
F: drivers/net/ethernet/i825xx/eexpress.*
ETHERNET BRIDGE
M: Stephen Hemminger <shemminger@linux-foundation.org>
M: Stephen Hemminger <shemminger@vyatta.com>
L: bridge@lists.linux-foundation.org
L: netdev@vger.kernel.org
W: http://www.linuxfoundation.org/en/Net:Bridge
......@@ -3718,7 +3736,7 @@ F: fs/jbd2/
F: include/linux/jbd2.h
JSM Neo PCI based serial card
M: Breno Leitao <leitao@linux.vnet.ibm.com>
M: Lucas Tavares <lucaskt@linux.vnet.ibm.com>
L: linux-serial@vger.kernel.org
S: Maintained
F: drivers/tty/serial/jsm/
......@@ -4304,6 +4322,7 @@ MEMORY RESOURCE CONTROLLER
M: Balbir Singh <bsingharora@gmail.com>
M: Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>
M: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
L: cgroups@vger.kernel.org
L: linux-mm@kvack.org
S: Maintained
F: mm/memcontrol.c
......@@ -4337,7 +4356,7 @@ MIPS
M: Ralf Baechle <ralf@linux-mips.org>
L: linux-mips@linux-mips.org
W: http://www.linux-mips.org/
T: git git://git.linux-mips.org/pub/scm/linux.git
T: git git://git.linux-mips.org/pub/scm/ralf/linux.git
Q: http://patchwork.linux-mips.org/project/linux-mips/list/
S: Supported
F: Documentation/mips/
......@@ -4470,7 +4489,7 @@ S: Supported
F: drivers/infiniband/hw/nes/
NETEM NETWORK EMULATOR
M: Stephen Hemminger <shemminger@linux-foundation.org>
M: Stephen Hemminger <shemminger@vyatta.com>
L: netem@lists.linux-foundation.org
S: Maintained
F: net/sched/sch_netem.c
......@@ -4947,7 +4966,7 @@ F: drivers/char/ppdev.c
F: include/linux/ppdev.h
PARAVIRT_OPS INTERFACE
M: Jeremy Fitzhardinge <jeremy@xensource.com>
M: Jeremy Fitzhardinge <jeremy@goop.org>
M: Chris Wright <chrisw@sous-sol.org>
M: Alok Kataria <akataria@vmware.com>
M: Rusty Russell <rusty@rustcorp.com.au>
......@@ -5656,7 +5675,6 @@ F: drivers/media/video/*7146*
F: include/media/*7146*
SAMSUNG AUDIO (ASoC) DRIVERS
M: Jassi Brar <jassisinghbrar@gmail.com>
M: Sangbeom Kim <sbkim73@samsung.com>
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
S: Supported
......@@ -5985,7 +6003,7 @@ S: Maintained
F: drivers/usb/misc/sisusbvga/
SKGE, SKY2 10/100/1000 GIGABIT ETHERNET DRIVERS
M: Stephen Hemminger <shemminger@linux-foundation.org>
M: Stephen Hemminger <shemminger@vyatta.com>
L: netdev@vger.kernel.org
S: Maintained
F: drivers/net/ethernet/marvell/sk*
......@@ -7399,8 +7417,8 @@ S: Maintained
F: arch/x86/kernel/cpu/mcheck/*
XEN HYPERVISOR INTERFACE
M: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
M: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
M: Jeremy Fitzhardinge <jeremy@goop.org>
L: xen-devel@lists.xensource.com (moderated for non-subscribers)
L: virtualization@lists.linux-foundation.org
S: Supported
......@@ -7433,7 +7451,8 @@ F: drivers/xen/*swiotlb*
XFS FILESYSTEM
P: Silicon Graphics Inc
M: Alex Elder <aelder@sgi.com>
M: Ben Myers <bpm@sgi.com>
M: Alex Elder <elder@kernel.org>
M: xfs-masters@oss.sgi.com
L: xfs@oss.sgi.com
W: http://oss.sgi.com/projects/xfs
......
VERSION = 3
PATCHLEVEL = 2
SUBLEVEL = 0
EXTRAVERSION = -rc2
EXTRAVERSION = -rc4
NAME = Saber-toothed Squirrel
# *DOCUMENTATION*
......
......@@ -1231,7 +1231,7 @@ config ARM_ERRATA_742231
capabilities of the processor.
config PL310_ERRATA_588369
bool "Clean & Invalidate maintenance operations do not invalidate clean lines"
bool "PL310 errata: Clean & Invalidate maintenance operations do not invalidate clean lines"
depends on CACHE_L2X0
help
The PL310 L2 cache controller implements three types of Clean &
......@@ -1256,7 +1256,7 @@ config ARM_ERRATA_720789
entries regardless of the ASID.
config PL310_ERRATA_727915
bool "Background Clean & Invalidate by Way operation can cause data corruption"
bool "PL310 errata: Background Clean & Invalidate by Way operation can cause data corruption"
depends on CACHE_L2X0
help
PL310 implements the Clean & Invalidate by Way L2 cache maintenance
......@@ -1289,8 +1289,8 @@ config ARM_ERRATA_751472
operation is received by a CPU before the ICIALLUIS has completed,
potentially leading to corrupted entries in the cache or TLB.
config ARM_ERRATA_753970
bool "ARM errata: cache sync operation may be faulty"
config PL310_ERRATA_753970
bool "PL310 errata: cache sync operation may be faulty"
depends on CACHE_PL310
help
This option enables the workaround for the 753970 PL310 (r3p0) erratum.
......@@ -1352,6 +1352,18 @@ config ARM_ERRATA_764369
relevant cache maintenance functions and sets a specific bit
in the diagnostic control register of the SCU.
config PL310_ERRATA_769419
bool "PL310 errata: no automatic Store Buffer drain"
depends on CACHE_L2X0
help
On revisions of the PL310 prior to r3p2, the Store Buffer does
not automatically drain. This can cause normal, non-cacheable
writes to be retained when the memory system is idle, leading
to suboptimal I/O performance for drivers using coherent DMA.
This option adds a write barrier to the cpu_idle loop so that,
on systems with an outer cache, the store buffer is drained
explicitly.
endmenu
source "arch/arm/common/Kconfig"
......
......@@ -65,6 +65,8 @@ $(obj)/%.dtb: $(src)/dts/%.dts
$(obj)/dtbs: $(addprefix $(obj)/, $(dtb-y))
clean-files := *.dtb
quiet_cmd_uimage = UIMAGE $@
cmd_uimage = $(CONFIG_SHELL) $(MKIMAGE) -A arm -O linux -T kernel \
-C none -a $(LOADADDR) -e $(STARTADDR) \
......
......@@ -612,7 +612,8 @@ static void __init gic_pm_init(struct gic_chip_data *gic)
sizeof(u32));
BUG_ON(!gic->saved_ppi_conf);
cpu_pm_register_notifier(&gic_notifier_block);
if (gic == &gic_data[0])
cpu_pm_register_notifier(&gic_notifier_block);
}
#else
static void __init gic_pm_init(struct gic_chip_data *gic)
......@@ -696,12 +697,14 @@ void __init gic_init_bases(unsigned int gic_nr, int irq_start,
* For primary GICs, skip over SGIs.
* For secondary GICs, skip over PPIs, too.
*/
domain->hwirq_base = 32;
if (gic_nr == 0) {
domain->hwirq_base = 16;
if (irq_start > 0)
irq_start = (irq_start & ~31) + 16;
} else
domain->hwirq_base = 32;
if ((irq_start & 31) > 0) {
domain->hwirq_base = 16;
if (irq_start != -1)
irq_start = (irq_start & ~31) + 16;
}
}
/*
* Find out how many interrupts are supported.
......
......@@ -1211,8 +1211,8 @@ static inline u32 _prepare_ccr(const struct pl330_reqcfg *rqc)
ccr |= (rqc->brst_size << CC_SRCBRSTSIZE_SHFT);
ccr |= (rqc->brst_size << CC_DSTBRSTSIZE_SHFT);
ccr |= (rqc->dcctl << CC_SRCCCTRL_SHFT);
ccr |= (rqc->scctl << CC_DSTCCTRL_SHFT);
ccr |= (rqc->scctl << CC_SRCCCTRL_SHFT);
ccr |= (rqc->dcctl << CC_DSTCCTRL_SHFT);
ccr |= (rqc->swap << CC_SWAP_SHFT);