Merge branch 'master' into for-2.6.39
This commit is contained in:
commit
43d133c18b
1
.mailmap
1
.mailmap
|
@ -23,6 +23,7 @@ Andy Adamson <andros@citi.umich.edu>
|
|||
Arnaud Patard <arnaud.patard@rtp-net.org>
|
||||
Arnd Bergmann <arnd@arndb.de>
|
||||
Axel Dyks <xl@xlsigned.net>
|
||||
Axel Lin <axel.lin@gmail.com>
|
||||
Ben Gardner <bgardner@wabtec.com>
|
||||
Ben M Cahill <ben.m.cahill@intel.com>
|
||||
Björn Steinbrink <B.Steinbrink@gmx.de>
|
||||
|
|
|
@ -0,0 +1,25 @@
|
|||
What: /sys/devices/platform/at91_can/net/<iface>/mb0_id
|
||||
Date: January 2011
|
||||
KernelVersion: 2.6.38
|
||||
Contact: Marc Kleine-Budde <kernel@pengutronix.de>
|
||||
Description:
|
||||
Value representing the can_id of mailbox 0.
|
||||
|
||||
Default: 0x7ff (standard frame)
|
||||
|
||||
Due to a chip bug (errata 50.2.6.3 & 50.3.5.3 in
|
||||
"AT91SAM9263 Preliminary 6249H-ATARM-27-Jul-09") the
|
||||
contents of mailbox 0 may be send under certain
|
||||
conditions (even if disabled or in rx mode).
|
||||
|
||||
The workaround in the errata suggests not to use the
|
||||
mailbox and load it with an unused identifier.
|
||||
|
||||
In order to use an extended can_id add the
|
||||
CAN_EFF_FLAG (0x80000000U) to the can_id. Example:
|
||||
|
||||
- standard id 0x7ff:
|
||||
echo 0x7ff > /sys/class/net/can0/mb0_id
|
||||
|
||||
- extended id 0x1fffffff:
|
||||
echo 0x9fffffff > /sys/class/net/can0/mb0_id
|
|
@ -73,8 +73,8 @@
|
|||
services.
|
||||
</para>
|
||||
<para>
|
||||
The core of every DRM driver is struct drm_device. Drivers
|
||||
will typically statically initialize a drm_device structure,
|
||||
The core of every DRM driver is struct drm_driver. Drivers
|
||||
will typically statically initialize a drm_driver structure,
|
||||
then pass it to drm_init() at load time.
|
||||
</para>
|
||||
|
||||
|
@ -84,7 +84,7 @@
|
|||
<title>Driver initialization</title>
|
||||
<para>
|
||||
Before calling the DRM initialization routines, the driver must
|
||||
first create and fill out a struct drm_device structure.
|
||||
first create and fill out a struct drm_driver structure.
|
||||
</para>
|
||||
<programlisting>
|
||||
static struct drm_driver driver = {
|
||||
|
|
|
@ -13,7 +13,6 @@ Table of Contents
|
|||
|
||||
I - Introduction
|
||||
1) Entry point for arch/powerpc
|
||||
2) Board support
|
||||
|
||||
II - The DT block format
|
||||
1) Header
|
||||
|
@ -41,13 +40,6 @@ Table of Contents
|
|||
VI - System-on-a-chip devices and nodes
|
||||
1) Defining child nodes of an SOC
|
||||
2) Representing devices without a current OF specification
|
||||
a) PHY nodes
|
||||
b) Interrupt controllers
|
||||
c) 4xx/Axon EMAC ethernet nodes
|
||||
d) Xilinx IP cores
|
||||
e) USB EHCI controllers
|
||||
f) MDIO on GPIOs
|
||||
g) SPI busses
|
||||
|
||||
VII - Specifying interrupt information for devices
|
||||
1) interrupts property
|
||||
|
@ -123,7 +115,7 @@ Revision Information
|
|||
I - Introduction
|
||||
================
|
||||
|
||||
During the recent development of the Linux/ppc64 kernel, and more
|
||||
During the development of the Linux/ppc64 kernel, and more
|
||||
specifically, the addition of new platform types outside of the old
|
||||
IBM pSeries/iSeries pair, it was decided to enforce some strict rules
|
||||
regarding the kernel entry and bootloader <-> kernel interfaces, in
|
||||
|
@ -146,7 +138,7 @@ section III, but, for example, the kernel does not require you to
|
|||
create a node for every PCI device in the system. It is a requirement
|
||||
to have a node for PCI host bridges in order to provide interrupt
|
||||
routing informations and memory/IO ranges, among others. It is also
|
||||
recommended to define nodes for on chip devices and other busses that
|
||||
recommended to define nodes for on chip devices and other buses that
|
||||
don't specifically fit in an existing OF specification. This creates a
|
||||
great flexibility in the way the kernel can then probe those and match
|
||||
drivers to device, without having to hard code all sorts of tables. It
|
||||
|
@ -158,7 +150,7 @@ it with special cases.
|
|||
1) Entry point for arch/powerpc
|
||||
-------------------------------
|
||||
|
||||
There is one and one single entry point to the kernel, at the start
|
||||
There is one single entry point to the kernel, at the start
|
||||
of the kernel image. That entry point supports two calling
|
||||
conventions:
|
||||
|
||||
|
@ -210,12 +202,6 @@ it with special cases.
|
|||
with all CPUs. The way to do that with method b) will be
|
||||
described in a later revision of this document.
|
||||
|
||||
|
||||
2) Board support
|
||||
----------------
|
||||
|
||||
64-bit kernels:
|
||||
|
||||
Board supports (platforms) are not exclusive config options. An
|
||||
arbitrary set of board supports can be built in a single kernel
|
||||
image. The kernel will "know" what set of functions to use for a
|
||||
|
@ -234,48 +220,11 @@ it with special cases.
|
|||
containing the various callbacks that the generic code will
|
||||
use to get to your platform specific code
|
||||
|
||||
c) Add a reference to your "ppc_md" structure in the
|
||||
"machines" table in arch/powerpc/kernel/setup_64.c if you are
|
||||
a 64-bit platform.
|
||||
|
||||
d) request and get assigned a platform number (see PLATFORM_*
|
||||
constants in arch/powerpc/include/asm/processor.h
|
||||
|
||||
32-bit embedded kernels:
|
||||
|
||||
Currently, board support is essentially an exclusive config option.
|
||||
The kernel is configured for a single platform. Part of the reason
|
||||
for this is to keep kernels on embedded systems small and efficient;
|
||||
part of this is due to the fact the code is already that way. In the
|
||||
future, a kernel may support multiple platforms, but only if the
|
||||
A kernel image may support multiple platforms, but only if the
|
||||
platforms feature the same core architecture. A single kernel build
|
||||
cannot support both configurations with Book E and configurations
|
||||
with classic Powerpc architectures.
|
||||
|
||||
32-bit embedded platforms that are moved into arch/powerpc using a
|
||||
flattened device tree should adopt the merged tree practice of
|
||||
setting ppc_md up dynamically, even though the kernel is currently
|
||||
built with support for only a single platform at a time. This allows
|
||||
unification of the setup code, and will make it easier to go to a
|
||||
multiple-platform-support model in the future.
|
||||
|
||||
NOTE: I believe the above will be true once Ben's done with the merge
|
||||
of the boot sequences.... someone speak up if this is wrong!
|
||||
|
||||
To add a 32-bit embedded platform support, follow the instructions
|
||||
for 64-bit platforms above, with the exception that the Kconfig
|
||||
option should be set up such that the kernel builds exclusively for
|
||||
the platform selected. The processor type for the platform should
|
||||
enable another config option to select the specific board
|
||||
supported.
|
||||
|
||||
NOTE: If Ben doesn't merge the setup files, may need to change this to
|
||||
point to setup_32.c
|
||||
|
||||
|
||||
I will describe later the boot process and various callbacks that
|
||||
your platform should implement.
|
||||
|
||||
|
||||
II - The DT block format
|
||||
========================
|
||||
|
@ -300,8 +249,8 @@ the block to RAM before passing it to the kernel.
|
|||
1) Header
|
||||
---------
|
||||
|
||||
The kernel is entered with r3 pointing to an area of memory that is
|
||||
roughly described in arch/powerpc/include/asm/prom.h by the structure
|
||||
The kernel is passed the physical address pointing to an area of memory
|
||||
that is roughly described in include/linux/of_fdt.h by the structure
|
||||
boot_param_header:
|
||||
|
||||
struct boot_param_header {
|
||||
|
@ -339,7 +288,7 @@ struct boot_param_header {
|
|||
All values in this header are in big endian format, the various
|
||||
fields in this header are defined more precisely below. All
|
||||
"offset" values are in bytes from the start of the header; that is
|
||||
from the value of r3.
|
||||
from the physical base address of the device tree block.
|
||||
|
||||
- magic
|
||||
|
||||
|
@ -437,7 +386,7 @@ struct boot_param_header {
|
|||
|
||||
|
||||
------------------------------
|
||||
r3 -> | struct boot_param_header |
|
||||
base -> | struct boot_param_header |
|
||||
------------------------------
|
||||
| (alignment gap) (*) |
|
||||
------------------------------
|
||||
|
@ -457,7 +406,7 @@ struct boot_param_header {
|
|||
-----> ------------------------------
|
||||
|
|
||||
|
|
||||
--- (r3 + totalsize)
|
||||
--- (base + totalsize)
|
||||
|
||||
(*) The alignment gaps are not necessarily present; their presence
|
||||
and size are dependent on the various alignment requirements of
|
||||
|
@ -500,7 +449,7 @@ the device-tree structure. It is typically used to represent "path" in
|
|||
the device-tree. More details about the actual format of these will be
|
||||
below.
|
||||
|
||||
The kernel powerpc generic code does not make any formal use of the
|
||||
The kernel generic code does not make any formal use of the
|
||||
unit address (though some board support code may do) so the only real
|
||||
requirement here for the unit address is to ensure uniqueness of
|
||||
the node unit name at a given level of the tree. Nodes with no notion
|
||||
|
@ -518,20 +467,21 @@ path to the root node is "/".
|
|||
|
||||
Every node which actually represents an actual device (that is, a node
|
||||
which isn't only a virtual "container" for more nodes, like "/cpus"
|
||||
is) is also required to have a "device_type" property indicating the
|
||||
type of node .
|
||||
is) is also required to have a "compatible" property indicating the
|
||||
specific hardware and an optional list of devices it is fully
|
||||
backwards compatible with.
|
||||
|
||||
Finally, every node that can be referenced from a property in another
|
||||
node is required to have a "linux,phandle" property. Real open
|
||||
firmware implementations provide a unique "phandle" value for every
|
||||
node that the "prom_init()" trampoline code turns into
|
||||
"linux,phandle" properties. However, this is made optional if the
|
||||
flattened device tree is used directly. An example of a node
|
||||
node is required to have either a "phandle" or a "linux,phandle"
|
||||
property. Real Open Firmware implementations provide a unique
|
||||
"phandle" value for every node that the "prom_init()" trampoline code
|
||||
turns into "linux,phandle" properties. However, this is made optional
|
||||
if the flattened device tree is used directly. An example of a node
|
||||
referencing another node via "phandle" is when laying out the
|
||||
interrupt tree which will be described in a further version of this
|
||||
document.
|
||||
|
||||
This "linux, phandle" property is a 32-bit value that uniquely
|
||||
The "phandle" property is a 32-bit value that uniquely
|
||||
identifies a node. You are free to use whatever values or system of
|
||||
values, internal pointers, or whatever to generate these, the only
|
||||
requirement is that every node for which you provide that property has
|
||||
|
@ -694,7 +644,7 @@ made of 3 cells, the bottom two containing the actual address itself
|
|||
while the top cell contains address space indication, flags, and pci
|
||||
bus & device numbers.
|
||||
|
||||
For busses that support dynamic allocation, it's the accepted practice
|
||||
For buses that support dynamic allocation, it's the accepted practice
|
||||
to then not provide the address in "reg" (keep it 0) though while
|
||||
providing a flag indicating the address is dynamically allocated, and
|
||||
then, to provide a separate "assigned-addresses" property that
|
||||
|
@ -711,7 +661,7 @@ prom_parse.c file of the recent kernels for your bus type.
|
|||
The "reg" property only defines addresses and sizes (if #size-cells is
|
||||
non-0) within a given bus. In order to translate addresses upward
|
||||
(that is into parent bus addresses, and possibly into CPU physical
|
||||
addresses), all busses must contain a "ranges" property. If the
|
||||
addresses), all buses must contain a "ranges" property. If the
|
||||
"ranges" property is missing at a given level, it's assumed that
|
||||
translation isn't possible, i.e., the registers are not visible on the
|
||||
parent bus. The format of the "ranges" property for a bus is a list
|
||||
|
@ -727,9 +677,9 @@ example, for a PCI host controller, that would be a CPU address. For a
|
|||
PCI<->ISA bridge, that would be a PCI address. It defines the base
|
||||
address in the parent bus where the beginning of that range is mapped.
|
||||
|
||||
For a new 64-bit powerpc board, I recommend either the 2/2 format or
|
||||
For new 64-bit board support, I recommend either the 2/2 format or
|
||||
Apple's 2/1 format which is slightly more compact since sizes usually
|
||||
fit in a single 32-bit word. New 32-bit powerpc boards should use a
|
||||
fit in a single 32-bit word. New 32-bit board support should use a
|
||||
1/1 format, unless the processor supports physical addresses greater
|
||||
than 32-bits, in which case a 2/1 format is recommended.
|
||||
|
||||
|
@ -754,7 +704,7 @@ of their actual names.
|
|||
While earlier users of Open Firmware like OldWorld macintoshes tended
|
||||
to use the actual device name for the "name" property, it's nowadays
|
||||
considered a good practice to use a name that is closer to the device
|
||||
class (often equal to device_type). For example, nowadays, ethernet
|
||||
class (often equal to device_type). For example, nowadays, Ethernet
|
||||
controllers are named "ethernet", an additional "model" property
|
||||
defining precisely the chip type/model, and "compatible" property
|
||||
defining the family in case a single driver can driver more than one
|
||||
|
@ -772,7 +722,7 @@ is present).
|
|||
4) Note about node and property names and character set
|
||||
-------------------------------------------------------
|
||||
|
||||
While open firmware provides more flexible usage of 8859-1, this
|
||||
While Open Firmware provides more flexible usage of 8859-1, this
|
||||
specification enforces more strict rules. Nodes and properties should
|
||||
be comprised only of ASCII characters 'a' to 'z', '0' to
|
||||
'9', ',', '.', '_', '+', '#', '?', and '-'. Node names additionally
|
||||
|
@ -792,7 +742,7 @@ address which can extend beyond that limit.
|
|||
--------------------------------
|
||||
These are all that are currently required. However, it is strongly
|
||||
recommended that you expose PCI host bridges as documented in the
|
||||
PCI binding to open firmware, and your interrupt tree as documented
|
||||
PCI binding to Open Firmware, and your interrupt tree as documented
|
||||
in OF interrupt tree specification.
|
||||
|
||||
a) The root node
|
||||
|
@ -802,20 +752,12 @@ address which can extend beyond that limit.
|
|||
- model : this is your board name/model
|
||||
- #address-cells : address representation for "root" devices
|
||||
- #size-cells: the size representation for "root" devices
|
||||
- device_type : This property shouldn't be necessary. However, if
|
||||
you decide to create a device_type for your root node, make sure it
|
||||
is _not_ "chrp" unless your platform is a pSeries or PAPR compliant
|
||||
one for 64-bit, or a CHRP-type machine for 32-bit as this will
|
||||
matched by the kernel this way.
|
||||
|
||||
Additionally, some recommended properties are:
|
||||
|
||||
- compatible : the board "family" generally finds its way here,
|
||||
for example, if you have 2 board models with a similar layout,
|
||||
that typically get driven by the same platform code in the
|
||||
kernel, you would use a different "model" property but put a
|
||||
value in "compatible". The kernel doesn't directly use that
|
||||
value but it is generally useful.
|
||||
kernel, you would specify the exact board model in the
|
||||
compatible property followed by an entry that represents the SoC
|
||||
model.
|
||||
|
||||
The root node is also generally where you add additional properties
|
||||
specific to your board like the serial number if any, that sort of
|
||||
|
@ -841,8 +783,11 @@ address which can extend beyond that limit.
|
|||
|
||||
So under /cpus, you are supposed to create a node for every CPU on
|
||||
the machine. There is no specific restriction on the name of the
|
||||
CPU, though It's common practice to call it PowerPC,<name>. For
|
||||
CPU, though it's common to call it <architecture>,<core>. For
|
||||
example, Apple uses PowerPC,G5 while IBM uses PowerPC,970FX.
|
||||
However, the Generic Names convention suggests that it would be
|
||||
better to simply use 'cpu' for each cpu node and use the compatible
|
||||
property to identify the specific cpu core.
|
||||
|
||||
Required properties:
|
||||
|
||||
|
@ -923,7 +868,7 @@ compatibility.
|
|||
|
||||
e) The /chosen node
|
||||
|
||||
This node is a bit "special". Normally, that's where open firmware
|
||||
This node is a bit "special". Normally, that's where Open Firmware
|
||||
puts some variable environment information, like the arguments, or
|
||||
the default input/output devices.
|
||||
|
||||
|
@ -940,11 +885,7 @@ compatibility.
|
|||
console device if any. Typically, if you have serial devices on
|
||||
your board, you may want to put the full path to the one set as
|
||||
the default console in the firmware here, for the kernel to pick
|
||||
it up as its own default console. If you look at the function
|
||||
set_preferred_console() in arch/ppc64/kernel/setup.c, you'll see
|
||||
that the kernel tries to find out the default console and has
|
||||
knowledge of various types like 8250 serial ports. You may want
|
||||
to extend this function to add your own.
|
||||
it up as its own default console.
|
||||
|
||||
Note that u-boot creates and fills in the chosen node for platforms
|
||||
that use it.
|
||||
|
@ -955,23 +896,23 @@ compatibility.
|
|||
|
||||
f) the /soc<SOCname> node
|
||||
|
||||
This node is used to represent a system-on-a-chip (SOC) and must be
|
||||
present if the processor is a SOC. The top-level soc node contains
|
||||
information that is global to all devices on the SOC. The node name
|
||||
should contain a unit address for the SOC, which is the base address
|
||||
of the memory-mapped register set for the SOC. The name of an soc
|
||||
This node is used to represent a system-on-a-chip (SoC) and must be
|
||||
present if the processor is a SoC. The top-level soc node contains
|
||||
information that is global to all devices on the SoC. The node name
|
||||
should contain a unit address for the SoC, which is the base address
|
||||
of the memory-mapped register set for the SoC. The name of an SoC
|
||||
node should start with "soc", and the remainder of the name should
|
||||
represent the part number for the soc. For example, the MPC8540's
|
||||
soc node would be called "soc8540".
|
||||
|
||||
Required properties:
|
||||
|
||||
- device_type : Should be "soc"
|
||||
- ranges : Should be defined as specified in 1) to describe the
|
||||
translation of SOC addresses for memory mapped SOC registers.
|
||||
- bus-frequency: Contains the bus frequency for the SOC node.
|
||||
translation of SoC addresses for memory mapped SoC registers.
|
||||
- bus-frequency: Contains the bus frequency for the SoC node.
|
||||
Typically, the value of this field is filled in by the boot
|
||||
loader.
|
||||
- compatible : Exact model of the SoC
|
||||
|
||||
|
||||
Recommended properties:
|
||||
|
@ -1155,12 +1096,13 @@ while all this has been defined and implemented.
|
|||
|
||||
- An example of code for iterating nodes & retrieving properties
|
||||
directly from the flattened tree format can be found in the kernel
|
||||
file arch/ppc64/kernel/prom.c, look at scan_flat_dt() function,
|
||||
file drivers/of/fdt.c. Look at the of_scan_flat_dt() function,
|
||||
its usage in early_init_devtree(), and the corresponding various
|
||||
early_init_dt_scan_*() callbacks. That code can be re-used in a
|
||||
GPL bootloader, and as the author of that code, I would be happy
|
||||
to discuss possible free licensing to any vendor who wishes to
|
||||
integrate all or part of this code into a non-GPL bootloader.
|
||||
(reference needed; who is 'I' here? ---gcl Jan 31, 2011)
|
||||
|
||||
|
||||
|
||||
|
@ -1203,18 +1145,19 @@ MPC8540.
|
|||
2) Representing devices without a current OF specification
|
||||
----------------------------------------------------------
|
||||
|
||||
Currently, there are many devices on SOCs that do not have a standard
|
||||
representation pre-defined as part of the open firmware
|
||||
specifications, mainly because the boards that contain these SOCs are
|
||||
not currently booted using open firmware. This section contains
|
||||
descriptions for the SOC devices for which new nodes have been
|
||||
defined; this list will expand as more and more SOC-containing
|
||||
platforms are moved over to use the flattened-device-tree model.
|
||||
Currently, there are many devices on SoCs that do not have a standard
|
||||
representation defined as part of the Open Firmware specifications,
|
||||
mainly because the boards that contain these SoCs are not currently
|
||||
booted using Open Firmware. Binding documentation for new devices
|
||||
should be added to the Documentation/devicetree/bindings directory.
|
||||
That directory will expand as device tree support is added to more and
|
||||
more SoCs.
|
||||
|
||||
|
||||
VII - Specifying interrupt information for devices
|
||||
===================================================
|
||||
|
||||
The device tree represents the busses and devices of a hardware
|
||||
The device tree represents the buses and devices of a hardware
|
||||
system in a form similar to the physical bus topology of the
|
||||
hardware.
|
||||
|
|
@ -603,3 +603,19 @@ Why: The adm9240, w83792d and w83793 hardware monitoring drivers have
|
|||
Who: Jean Delvare <khali@linux-fr.org>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: noswapaccount kernel command line parameter
|
||||
When: 2.6.40
|
||||
Why: The original implementation of memsw feature enabled by
|
||||
CONFIG_CGROUP_MEM_RES_CTLR_SWAP could be disabled by the noswapaccount
|
||||
kernel parameter (introduced in 2.6.29-rc1). Later on, this decision
|
||||
turned out to be not ideal because we cannot have the feature compiled
|
||||
in and disabled by default and let only interested to enable it
|
||||
(e.g. general distribution kernels might need it). Therefore we have
|
||||
added swapaccount[=0|1] parameter (introduced in 2.6.37) which provides
|
||||
the both possibilities. If we remove noswapaccount we will have
|
||||
less command line parameters with the same functionality and we
|
||||
can also cleanup the parameter handling a bit ().
|
||||
Who: Michal Hocko <mhocko@suse.cz>
|
||||
|
||||
----------------------------
|
||||
|
|
|
@ -460,6 +460,8 @@ Note, a technical ChangeLog aimed at kernel hackers is in fs/ntfs/ChangeLog.
|
|||
2.1.30:
|
||||
- Fix writev() (it kept writing the first segment over and over again
|
||||
instead of moving onto subsequent segments).
|
||||
- Fix crash in ntfs_mft_record_alloc() when mapping the new extent mft
|
||||
record failed.
|
||||
2.1.29:
|
||||
- Fix a deadlock when mounting read-write.
|
||||
2.1.28:
|
||||
|
|
|
@ -51,7 +51,8 @@ Supported chips:
|
|||
* JEDEC JC 42.4 compliant temperature sensor chips
|
||||
Prefix: 'jc42'
|
||||
Addresses scanned: I2C 0x18 - 0x1f
|
||||
Datasheet: -
|
||||
Datasheet:
|
||||
http://www.jedec.org/sites/default/files/docs/4_01_04R19.pdf
|
||||
|
||||
Author:
|
||||
Guenter Roeck <guenter.roeck@ericsson.com>
|
||||
|
@ -60,7 +61,11 @@ Author:
|
|||
Description
|
||||
-----------
|
||||
|
||||
This driver implements support for JEDEC JC 42.4 compliant temperature sensors.
|
||||
This driver implements support for JEDEC JC 42.4 compliant temperature sensors,
|
||||
which are used on many DDR3 memory modules for mobile devices and servers. Some
|
||||
systems use the sensor to prevent memory overheating by automatically throttling
|
||||
the memory controller.
|
||||
|
||||
The driver auto-detects the chips listed above, but can be manually instantiated
|
||||
to support other JC 42.4 compliant chips.
|
||||
|
||||
|
@ -81,15 +86,19 @@ limits. The chip supports only a single register to configure the hysteresis,
|
|||
which applies to all limits. This register can be written by writing into
|
||||
temp1_crit_hyst. Other hysteresis attributes are read-only.
|
||||
|
||||
If the BIOS has configured the sensor for automatic temperature management, it
|
||||
is likely that it has locked the registers, i.e., that the temperature limits
|
||||
cannot be changed.
|
||||
|
||||
Sysfs entries
|
||||
-------------
|
||||
|
||||
temp1_input Temperature (RO)
|
||||
temp1_min Minimum temperature (RW)
|
||||
temp1_max Maximum temperature (RW)
|
||||
temp1_crit Critical high temperature (RW)
|
||||
temp1_min Minimum temperature (RO or RW)
|
||||
temp1_max Maximum temperature (RO or RW)
|
||||
temp1_crit Critical high temperature (RO or RW)
|
||||
|
||||
temp1_crit_hyst Critical hysteresis temperature (RW)
|
||||
temp1_crit_hyst Critical hysteresis temperature (RO or RW)
|
||||
temp1_max_hyst Maximum hysteresis temperature (RO)
|
||||
|
||||
temp1_min_alarm Temperature low alarm
|
||||
|
|
|
@ -9,6 +9,8 @@ Supported chips:
|
|||
Socket S1G3: Athlon II, Sempron, Turion II
|
||||
* AMD Family 11h processors:
|
||||
Socket S1G2: Athlon (X2), Sempron (X2), Turion X2 (Ultra)
|
||||
* AMD Family 12h processors: "Llano"
|
||||
* AMD Family 14h processors: "Brazos" (C/E/G-Series)
|
||||
|
||||
Prefix: 'k10temp'
|
||||
Addresses scanned: PCI space
|
||||
|
@ -17,10 +19,14 @@ Supported chips:
|
|||
http://support.amd.com/us/Processor_TechDocs/31116.pdf
|
||||
BIOS and Kernel Developer's Guide (BKDG) for AMD Family 11h Processors:
|
||||
http://support.amd.com/us/Processor_TechDocs/41256.pdf
|
||||
BIOS and Kernel Developer's Guide (BKDG) for AMD Family 14h Models 00h-0Fh Processors:
|
||||
http://support.amd.com/us/Processor_TechDocs/43170.pdf
|
||||
Revision Guide for AMD Family 10h Processors:
|
||||
http://support.amd.com/us/Processor_TechDocs/41322.pdf
|
||||
Revision Guide for AMD Family 11h Processors:
|
||||
http://support.amd.com/us/Processor_TechDocs/41788.pdf
|
||||
Revision Guide for AMD Family 14h Models 00h-0Fh Processors:
|
||||
http://support.amd.com/us/Processor_TechDocs/47534.pdf
|
||||
AMD Family 11h Processor Power and Thermal Data Sheet for Notebooks:
|
||||
http://support.amd.com/us/Processor_TechDocs/43373.pdf
|
||||
AMD Family 10h Server and Workstation Processor Power and Thermal Data Sheet:
|
||||
|
@ -34,7 +40,7 @@ Description
|
|||
-----------
|
||||
|
||||
This driver permits reading of the internal temperature sensor of AMD
|
||||
Family 10h and 11h processors.
|
||||
Family 10h/11h/12h/14h processors.
|
||||
|
||||
All these processors have a sensor, but on those for Socket F or AM2+,
|
||||
the sensor may return inconsistent values (erratum 319). The driver
|
||||
|
|
|
@ -43,11 +43,11 @@ parameter is applicable:
|
|||
AVR32 AVR32 architecture is enabled.
|
||||
AX25 Appropriate AX.25 support is enabled.
|
||||
BLACKFIN Blackfin architecture is enabled.
|
||||
DRM Direct Rendering Management support is enabled.
|
||||
DYNAMIC_DEBUG Build in debug messages and enable them at runtime
|
||||
EDD BIOS Enhanced Disk Drive Services (EDD) is enabled
|
||||
EFI EFI Partitioning (GPT) is enabled
|
||||
EIDE EIDE/ATAPI support is enabled.
|
||||
DRM Direct Rendering Management support is enabled.
|
||||
DYNAMIC_DEBUG Build in debug messages and enable them at runtime
|
||||
FB The frame buffer device is enabled.
|
||||
GCOV GCOV profiling is enabled.
|
||||
HW Appropriate hardware is enabled.
|
||||
|
|
|
@ -4,6 +4,8 @@ obj- := dummy.o
|
|||
# List of programs to build
|
||||
hostprogs-y := ifenslave
|
||||
|
||||
HOSTCFLAGS_ifenslave.o += -I$(objtree)/usr/include
|
||||
|
||||
# Tell kbuild to always build the programs
|
||||
always := $(hostprogs-y)
|
||||
|
||||
|
|
|
@ -49,7 +49,8 @@ Table of Contents
|
|||
3.3 Configuring Bonding Manually with Ifenslave
|
||||
3.3.1 Configuring Multiple Bonds Manually
|
||||
3.4 Configuring Bonding Manually via Sysfs
|
||||
3.5 Overriding Configuration for Special Cases
|
||||
3.5 Configuration with Interfaces Support
|
||||
3.6 Overriding Configuration for Special Cases
|
||||
|
||||
4. Querying Bonding Configuration
|
||||
4.1 Bonding Configuration
|
||||
|
@ -161,8 +162,8 @@ onwards) do not have /usr/include/linux symbolically linked to the
|
|||
default kernel source include directory.
|
||||
|
||||
SECOND IMPORTANT NOTE:
|
||||
If you plan to configure bonding using sysfs, you do not need
|
||||
to use ifenslave.
|
||||
If you plan to configure bonding using sysfs or using the
|
||||
/etc/network/interfaces file, you do not need to use ifenslave.
|
||||
|
||||
2. Bonding Driver Options
|
||||
=========================
|
||||
|
@ -779,22 +780,26 @@ resend_igmp
|
|||
|
||||
You can configure bonding using either your distro's network
|
||||
initialization scripts, or manually using either ifenslave or the
|
||||
sysfs interface. Distros generally use one of two packages for the
|
||||
network initialization scripts: initscripts or sysconfig. Recent
|
||||
versions of these packages have support for bonding, while older
|
||||
sysfs interface. Distros generally use one of three packages for the
|
||||
network initialization scripts: initscripts, sysconfig or interfaces.
|
||||
Recent versions of these packages have support for bonding, while older
|
||||
versions do not.
|
||||
|
||||
We will first describe the options for configuring bonding for
|
||||
distros using versions of initscripts and sysconfig with full or
|
||||
partial support for bonding, then provide information on enabling
|
||||
distros using versions of initscripts, sysconfig and interfaces with full
|
||||
or partial support for bonding, then provide information on enabling
|
||||
bonding without support from the network initialization scripts (i.e.,
|
||||
older versions of initscripts or sysconfig).
|
||||
|
||||
If you're unsure whether your distro uses sysconfig or
|
||||
initscripts, or don't know if it's new enough, have no fear.
|
||||
If you're unsure whether your distro uses sysconfig,
|
||||
initscripts or interfaces, or don't know if it's new enough, have no fear.
|
||||
Determining this is fairly straightforward.
|
||||
|
||||
First, issue the command:
|
||||
First, look for a file called interfaces in /etc/network directory.
|
||||
If this file is present in your system, then your system use interfaces. See
|
||||
Configuration with Interfaces Support.
|
||||
|
||||
Else, issue the command:
|
||||
|
||||
$ rpm -qf /sbin/ifup
|
||||
|
||||
|
@ -1327,8 +1332,62 @@ echo 2000 > /sys/class/net/bond1/bonding/arp_interval
|
|||
echo +eth2 > /sys/class/net/bond1/bonding/slaves
|
||||
echo +eth3 > /sys/class/net/bond1/bonding/slaves
|
||||
|
||||
3.5 Overriding Configuration for Special Cases
|
||||
3.5 Configuration with Interfaces Support
|
||||
-----------------------------------------
|
||||
|
||||
This section applies to distros which use /etc/network/interfaces file
|
||||
to describe network interface configuration, most notably Debian and it's
|
||||
derivatives.
|
||||
|
||||
The ifup and ifdown commands on Debian don't support bonding out of
|
||||
the box. The ifenslave-2.6 package should be installed to provide bonding
|
||||
support. Once installed, this package will provide bond-* options to be used
|
||||
into /etc/network/interfaces.
|
||||
|
||||
Note that ifenslave-2.6 package will load the bonding module and use
|
||||
the ifenslave command when appropriate.
|
||||
|
||||
Example Configurations
|
||||
----------------------
|
||||
|
||||
In /etc/network/interfaces, the following stanza will configure bond0, in
|
||||
active-backup mode, with eth0 and eth1 as slaves.
|
||||
|
||||
auto bond0
|
||||
iface bond0 inet dhcp
|
||||
bond-slaves eth0 eth1
|
||||
bond-mode active-backup
|
||||
bond-miimon 100
|
||||
bond-primary eth0 eth1
|
||||
|
||||
If the above configuration doesn't work, you might have a system using
|
||||
upstart for system startup. This is most notably true for recent
|
||||
Ubuntu versions. The following stanza in /etc/network/interfaces will
|
||||
produce the same result on those systems.
|
||||
|
||||
auto bond0
|
||||
iface bond0 inet dhcp
|
||||
bond-slaves none
|
||||
bond-mode active-backup
|
||||
bond-miimon 100
|
||||
|
||||
auto eth0
|
||||
iface eth0 inet manual
|
||||
bond-master bond0
|
||||
bond-primary eth0 eth1
|
||||
|
||||
auto eth1
|
||||
iface eth1 inet manual
|
||||
bond-master bond0
|
||||
bond-primary eth0 eth1
|
||||
|
||||
For a full list of bond-* supported options in /etc/network/interfaces and some
|
||||
more advanced examples tailored to you particular distros, see the files in
|
||||
/usr/share/doc/ifenslave-2.6.
|
||||
|
||||
3.6 Overriding Configuration for Special Cases
|
||||
----------------------------------------------
|
||||
|
||||
When using the bonding driver, the physical port which transmits a frame is
|
||||
typically selected by the bonding driver, and is not relevant to the user or
|
||||
system administrator. The output port is simply selected using the policies of
|
||||
|
|
|
@ -187,7 +187,7 @@ tcp_cookie_size - INTEGER
|
|||
tcp_dsack - BOOLEAN
|
||||
Allows TCP to send "duplicate" SACKs.
|
||||
|
||||
tcp_ecn - BOOLEAN
|
||||
tcp_ecn - INTEGER
|
||||
Enable Explicit Congestion Notification (ECN) in TCP. ECN is only
|
||||
used when both ends of the TCP flow support it. It is useful to
|
||||
avoid losses due to congestion (when the bottleneck router supports
|
||||
|
|
|
@ -1,3 +1,7 @@
|
|||
Version 15 of schedstats dropped counters for some sched_yield:
|
||||
yld_exp_empty, yld_act_empty and yld_both_empty. Otherwise, it is
|
||||
identical to version 14.
|
||||
|
||||
Version 14 of schedstats includes support for sched_domains, which hit the
|
||||
mainline kernel in 2.6.20 although it is identical to the stats from version
|
||||
12 which was in the kernel from 2.6.13-2.6.19 (version 13 never saw a kernel
|
||||
|
@ -28,32 +32,25 @@ to write their own scripts, the fields are described here.
|
|||
|
||||
CPU statistics
|
||||
--------------
|
||||
cpu<N> 1 2 3 4 5 6 7 8 9 10 11 12
|
||||
cpu<N> 1 2 3 4 5 6 7 8 9
|
||||
|
||||
NOTE: In the sched_yield() statistics, the active queue is considered empty
|
||||
if it has only one process in it, since obviously the process calling
|
||||
sched_yield() is that process.
|
||||
|
||||
First four fields are sched_yield() statistics:
|
||||
1) # of times both the active and the expired queue were empty
|
||||
2) # of times just the active queue was empty
|
||||
3) # of times just the expired queue was empty
|
||||
4) # of times sched_yield() was called
|
||||
First field is a sched_yield() statistic:
|
||||
1) # of times sched_yield() was called
|
||||
|
||||
Next three are schedule() statistics:
|
||||
5) # of times we switched to the expired queue and reused it
|
||||
6) # of times schedule() was called
|
||||
7) # of times schedule() left the processor idle
|
||||
2) # of times we switched to the expired queue and reused it
|
||||
3) # of times schedule() was called
|
||||
4) # of times schedule() left the processor idle
|
||||
|
||||
Next two are try_to_wake_up() statistics:
|
||||
8) # of times try_to_wake_up() was called
|
||||
9) # of times try_to_wake_up() was called to wake up the local cpu
|
||||
5) # of times try_to_wake_up() was called
|
||||
6) # of times try_to_wake_up() was called to wake up the local cpu
|
||||
|
||||
Next three are statistics describing scheduling latency:
|
||||
10) sum of all time spent running by tasks on this processor (in jiffies)
|
||||
11) sum of all time spent waiting to run by tasks on this processor (in
|
||||
7) sum of all time spent running by tasks on this processor (in jiffies)
|
||||
8) sum of all time spent waiting to run by tasks on this processor (in
|
||||
jiffies)
|
||||
12) # of timeslices run on this cpu
|
||||
9) # of timeslices run on this cpu
|
||||
|
||||
|
||||
Domain statistics
|
||||
|
|
|
@ -296,6 +296,7 @@ Conexant 5066
|
|||
=============
|
||||
laptop Basic Laptop config (default)
|
||||
hp-laptop HP laptops, e g G60
|
||||
asus Asus K52JU, Lenovo G560
|
||||
dell-laptop Dell laptops
|
||||
dell-vostro Dell Vostro
|
||||
olpc-xo-1_5 OLPC XO 1.5
|
||||
|
|
|
@ -190,9 +190,9 @@ resources, scheduled and executed.
|
|||
* Long running CPU intensive workloads which can be better
|
||||
managed by the system scheduler.
|
||||
|
||||
WQ_FREEZEABLE
|
||||
WQ_FREEZABLE
|
||||
|
||||
A freezeable wq participates in the freeze phase of the system
|
||||
A freezable wq participates in the freeze phase of the system
|
||||
suspend operations. Work items on the wq are drained and no
|
||||
new work item starts execution until thawed.
|
||||
|
||||
|
|
61
MAINTAINERS
61
MAINTAINERS
|
@ -885,7 +885,7 @@ S: Supported
|
|||
|
||||
ARM/QUALCOMM MSM MACHINE SUPPORT
|
||||
M: David Brown <davidb@codeaurora.org>
|
||||
M: Daniel Walker <dwalker@codeaurora.org>
|
||||
M: Daniel Walker <dwalker@fifo99.com>
|
||||
M: Bryan Huntsman <bryanh@codeaurora.org>
|
||||
L: linux-arm-msm@vger.kernel.org
|
||||
F: arch/arm/mach-msm/
|
||||
|
@ -978,6 +978,8 @@ S: Maintained
|
|||
F: arch/arm/plat-samsung/
|
||||
F: arch/arm/plat-s3c24xx/
|
||||
F: arch/arm/plat-s5p/
|
||||
F: drivers/*/*s3c2410*
|
||||
F: drivers/*/*/*s3c2410*
|
||||
|
||||
ARM/S3C2410 ARM ARCHITECTURE
|
||||
M: Ben Dooks <ben-linux@fluff.org>
|
||||
|
@ -2124,6 +2126,7 @@ S: Supported
|
|||
F: fs/dlm/
|
||||
|
||||
DMA GENERIC OFFLOAD ENGINE SUBSYSTEM
|
||||
M: Vinod Koul <vinod.koul@intel.com>
|
||||
M: Dan Williams <dan.j.williams@intel.com>
|
||||
S: Supported
|
||||
F: drivers/dma/
|
||||
|
@ -2772,6 +2775,15 @@ F: Documentation/isdn/README.gigaset
|
|||
F: drivers/isdn/gigaset/
|
||||
F: include/linux/gigaset_dev.h
|
||||
|
||||
GPIO SUBSYSTEM
|
||||
M: Grant Likely <grant.likely@secretlab.ca>
|
||||
L: linux-kernel@vger.kernel.org
|
||||
S: Maintained
|
||||
T: git git://git.secretlab.ca/git/linux-2.6.git
|
||||
F: Documentation/gpio/gpio.txt
|
||||
F: drivers/gpio/
|
||||
F: include/linux/gpio*
|
||||
|
||||
GRETH 10/100/1G Ethernet MAC device driver
|
||||
M: Kristoffer Glembo <kristoffer@gaisler.com>
|
||||
L: netdev@vger.kernel.org
|
||||
|
@ -2861,7 +2873,6 @@ M: Guenter Roeck <guenter.roeck@ericsson.com>
|
|||
L: lm-sensors@lm-sensors.org
|
||||
W: http://www.lm-sensors.org/
|
||||
T: quilt kernel.org/pub/linux/kernel/people/jdelvare/linux-2.6/jdelvare-hwmon/
|
||||
T: quilt kernel.org/pub/linux/kernel/people/groeck/linux-staging/
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git
|
||||
S: Maintained
|
||||
F: Documentation/hwmon/
|
||||
|
@ -3139,6 +3150,12 @@ S: Maintained
|
|||
F: net/ieee802154/
|
||||
F: drivers/ieee802154/
|
||||
|
||||
IKANOS/ADI EAGLE ADSL USB DRIVER
|
||||
M: Matthieu Castet <castet.matthieu@free.fr>
|
||||
M: Stanislaw Gruszka <stf_xl@wp.pl>
|
||||
S: Maintained
|
||||
F: drivers/usb/atm/ueagle-atm.c
|
||||
|
||||
INTEGRITY MEASUREMENT ARCHITECTURE (IMA)
|
||||
M: Mimi Zohar <zohar@us.ibm.com>
|
||||
S: Supported
|
||||
|
@ -3327,7 +3344,6 @@ F: drivers/net/wimax/i2400m/
|
|||
F: include/linux/wimax/i2400m.h
|
||||
|
||||
INTEL WIRELESS WIFI LINK (iwlwifi)
|
||||
M: Reinette Chatre <reinette.chatre@intel.com>
|
||||
M: Wey-Yi Guy <wey-yi.w.guy@intel.com>
|
||||
M: Intel Linux Wireless <ilw@linux.intel.com>
|
||||
L: linux-wireless@vger.kernel.org
|
||||
|
@ -4584,7 +4600,7 @@ F: drivers/i2c/busses/i2c-ocores.c
|
|||
|
||||
OPEN FIRMWARE AND FLATTENED DEVICE TREE
|
||||
M: Grant Likely <grant.likely@secretlab.ca>
|
||||
L: devicetree-discuss@lists.ozlabs.org
|
||||
L: devicetree-discuss@lists.ozlabs.org (moderated for non-subscribers)
|
||||
W: http://fdt.secretlab.ca
|
||||
T: git git://git.secretlab.ca/git/linux-2.6.git
|
||||
S: Maintained
|
||||
|
@ -5544,12 +5560,11 @@ S: Supported
|
|||
F: drivers/scsi/be2iscsi/
|
||||
|
||||
SERVER ENGINES 10Gbps NIC - BladeEngine 2 DRIVER
|
||||
M: Sathya Perla <sathyap@serverengines.com>
|
||||
M: Subbu Seetharaman <subbus@serverengines.com>
|
||||
M: Sarveshwar Bandi <sarveshwarb@serverengines.com>
|
||||
M: Ajit Khaparde <ajitk@serverengines.com>
|
||||
M: Sathya Perla <sathya.perla@emulex.com>
|
||||
M: Subbu Seetharaman <subbu.seetharaman@emulex.com>
|
||||
M: Ajit Khaparde <ajit.khaparde@emulex.com>
|
||||
L: netdev@vger.kernel.org
|
||||
W: http://www.serverengines.com
|
||||
W: http://www.emulex.com
|
||||
S: Supported
|
||||
F: drivers/net/benet/
|
||||
|
||||
|
@ -5609,18 +5624,20 @@ F: include/linux/sfi*.h
|
|||
|
||||
SIMTEC EB110ATX (Chalice CATS)
|
||||
P: Ben Dooks
|
||||
M: Vincent Sanders <support@simtec.co.uk>
|
||||
P: Vincent Sanders <vince@simtec.co.uk>
|
||||
M: Simtec Linux Team <linux@simtec.co.uk>
|
||||
W: http://www.simtec.co.uk/products/EB110ATX/
|
||||
S: Supported
|
||||
|
||||
SIMTEC EB2410ITX (BAST)
|
||||
P: Ben Dooks
|
||||
M: Vincent Sanders <support@simtec.co.uk>
|
||||
P: Vincent Sanders <vince@simtec.co.uk>
|
||||
M: Simtec Linux Team <linux@simtec.co.uk>
|
||||
W: http://www.simtec.co.uk/products/EB2410ITX/
|
||||
S: Supported
|
||||
F: arch/arm/mach-s3c2410/
|
||||
F: drivers/*/*s3c2410*
|
||||
F: drivers/*/*/*s3c2410*
|
||||
F: arch/arm/mach-s3c2410/mach-bast.c
|
||||
F: arch/arm/mach-s3c2410/bast-ide.c
|
||||
F: arch/arm/mach-s3c2410/bast-irq.c
|
||||
|
||||
TI DAVINCI MACHINE SUPPORT
|
||||
M: Kevin Hilman <khilman@deeprootsystems.com>
|
||||
|
@ -6595,6 +6612,16 @@ S: Maintained
|
|||
F: drivers/char/virtio_console.c
|
||||
F: include/linux/virtio_console.h
|
||||
|
||||
VIRTIO CORE, NET AND BLOCK DRIVERS
|
||||
M: Rusty Russell <rusty@rustcorp.com.au>
|
||||
M: "Michael S. Tsirkin" <mst@redhat.com>
|
||||
L: virtualization@lists.linux-foundation.org
|
||||
S: Maintained
|
||||
F: drivers/virtio/
|
||||
F: drivers/net/virtio_net.c
|
||||
F: drivers/block/virtio_blk.c
|
||||
F: include/linux/virtio_*.h
|
||||
|
||||
VIRTIO HOST (VHOST)
|
||||
M: "Michael S. Tsirkin" <mst@redhat.com>
|
||||
L: kvm@vger.kernel.org
|
||||
|
@ -6768,12 +6795,12 @@ S: Maintained
|
|||
F: drivers/net/wireless/wl1251/*
|
||||
|
||||
WL1271 WIRELESS DRIVER
|
||||
M: Luciano Coelho <luciano.coelho@nokia.com>
|
||||
M: Luciano Coelho <coelho@ti.com>
|
||||
L: linux-wireless@vger.kernel.org
|
||||
W: http://wireless.kernel.org
|
||||
W: http://wireless.kernel.org/en/users/Drivers/wl12xx
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/luca/wl12xx.git
|
||||
S: Maintained
|
||||
F: drivers/net/wireless/wl12xx/wl1271*
|
||||
F: drivers/net/wireless/wl12xx/
|
||||
F: include/linux/wl12xx.h
|
||||
|
||||
WL3501 WIRELESS PCMCIA CARD DRIVER
|
||||
|
|
2
Makefile
2
Makefile
|
@ -1,7 +1,7 @@
|
|||
VERSION = 2
|
||||
PATCHLEVEL = 6
|
||||
SUBLEVEL = 38
|
||||
EXTRAVERSION = -rc2
|
||||
EXTRAVERSION = -rc5
|
||||
NAME = Flesh-Eating Bats with Fangs
|
||||
|
||||
# *DOCUMENTATION*
|
||||
|
|
|
@ -1391,7 +1391,7 @@ config AEABI
|
|||
|
||||
config OABI_COMPAT
|
||||
bool "Allow old ABI binaries to run with this kernel (EXPERIMENTAL)"
|
||||
depends on AEABI && EXPERIMENTAL
|
||||
depends on AEABI && EXPERIMENTAL && !THUMB2_KERNEL
|
||||
default y
|
||||
help
|
||||
This option preserves the old syscall interface along with the
|
||||
|
|
|
@ -50,6 +50,12 @@
|
|||
#define SCPCELLID2 0xFF8
|
||||
#define SCPCELLID3 0xFFC
|
||||
|
||||
#define SCCTRL_TIMEREN0SEL_REFCLK (0 << 15)
|
||||
#define SCCTRL_TIMEREN0SEL_TIMCLK (1 << 15)
|
||||
|
||||
#define SCCTRL_TIMEREN1SEL_REFCLK (0 << 17)
|
||||
#define SCCTRL_TIMEREN1SEL_TIMCLK (1 << 17)
|
||||
|
||||
static inline void sysctl_soft_reset(void __iomem *base)
|
||||
{
|
||||
/* writing any value to SCSYSSTAT reg will reset system */
|
||||
|
|
|
@ -95,6 +95,15 @@ static inline void __iomem *__typesafe_io(unsigned long addr)
|
|||
return (void __iomem *)addr;
|
||||
}
|
||||
|
||||
/* IO barriers */
|
||||
#ifdef CONFIG_ARM_DMA_MEM_BUFFERABLE
|
||||
#define __iormb() rmb()
|
||||
#define __iowmb() wmb()
|
||||
#else
|
||||
#define __iormb() do { } while (0)
|
||||
#define __iowmb() do { } while (0)
|
||||
#endif
|
||||
|
||||
/*
|
||||
* Now, pick up the machine-defined IO definitions
|
||||
*/
|
||||
|
@ -125,17 +134,17 @@ static inline void __iomem *__typesafe_io(unsigned long addr)
|
|||
* The {in,out}[bwl] macros are for emulating x86-style PCI/ISA IO space.
|
||||
*/
|
||||
#ifdef __io
|
||||
#define outb(v,p) __raw_writeb(v,__io(p))
|
||||
#define outw(v,p) __raw_writew((__force __u16) \
|
||||
cpu_to_le16(v),__io(p))
|
||||
#define outl(v,p) __raw_writel((__force __u32) \
|
||||
cpu_to_le32(v),__io(p))
|
||||
#define outb(v,p) ({ __iowmb(); __raw_writeb(v,__io(p)); })
|
||||
#define outw(v,p) ({ __iowmb(); __raw_writew((__force __u16) \
|
||||
cpu_to_le16(v),__io(p)); })
|
||||
#define outl(v,p) ({ __iowmb(); __raw_writel((__force __u32) \
|
||||
cpu_to_le32(v),__io(p)); })
|
||||
|
||||
#define inb(p) ({ __u8 __v = __raw_readb(__io(p)); __v; })
|
||||
#define inb(p) ({ __u8 __v = __raw_readb(__io(p)); __iormb(); __v; })
|
||||
#define inw(p) ({ __u16 __v = le16_to_cpu((__force __le16) \
|
||||
__raw_readw(__io(p))); __v; })
|
||||
__raw_readw(__io(p))); __iormb(); __v; })
|
||||
#define inl(p) ({ __u32 __v = le32_to_cpu((__force __le32) \
|
||||
__raw_readl(__io(p))); __v; })
|
||||
__raw_readl(__io(p))); __iormb(); __v; })
|
||||
|
||||
#define outsb(p,d,l) __raw_writesb(__io(p),d,l)
|
||||
#define outsw(p,d,l) __raw_writesw(__io(p),d,l)
|
||||
|
@ -192,14 +201,6 @@ extern void _memset_io(volatile void __iomem *, int, size_t);
|
|||
#define writel_relaxed(v,c) ((void)__raw_writel((__force u32) \
|
||||
cpu_to_le32(v),__mem_pci(c)))
|
||||
|
||||
#ifdef CONFIG_ARM_DMA_MEM_BUFFERABLE
|
||||
#define __iormb() rmb()
|
||||
#define __iowmb() wmb()
|
||||
#else
|
||||
#define __iormb() do { } while (0)
|
||||
#define __iowmb() do { } while (0)
|
||||
#endif
|
||||
|
||||
#define readb(c) ({ u8 __v = readb_relaxed(c); __iormb(); __v; })
|
||||
#define readw(c) ({ u16 __v = readw_relaxed(c); __iormb(); __v; })
|
||||
#define readl(c) ({ u32 __v = readl_relaxed(c); __iormb(); __v; })
|
||||
|
|
|
@ -188,7 +188,7 @@
|
|||
* translation for translating DMA addresses. Use the driver
|
||||
* DMA support - see dma-mapping.h.
|
||||
*/
|
||||
static inline unsigned long virt_to_phys(void *x)
|
||||
static inline unsigned long virt_to_phys(const volatile void *x)
|
||||
{
|
||||
return __virt_to_phys((unsigned long)(x));
|
||||
}
|
||||
|
|
|
@ -391,25 +391,24 @@ ENDPROC(__turn_mmu_on)
|
|||
|
||||
|
||||
#ifdef CONFIG_SMP_ON_UP
|
||||
__INIT
|
||||
__fixup_smp:
|
||||
mov r4, #0x00070000
|
||||
orr r3, r4, #0xff000000 @ mask 0xff070000
|
||||
orr r4, r4, #0x41000000 @ val 0x41070000
|
||||
and r0, r9, r3
|
||||
teq r0, r4 @ ARM CPU and ARMv6/v7?
|
||||
and r3, r9, #0x000f0000 @ architecture version
|
||||
teq r3, #0x000f0000 @ CPU ID supported?
|
||||
bne __fixup_smp_on_up @ no, assume UP
|
||||
|
||||
orr r3, r3, #0x0000ff00
|
||||
orr r3, r3, #0x000000f0 @ mask 0xff07fff0
|
||||
bic r3, r9, #0x00ff0000
|
||||
bic r3, r3, #0x0000000f @ mask 0xff00fff0
|
||||
mov r4, #0x41000000
|
||||
orr r4, r4, #0x0000b000
|
||||
orr r4, r4, #0x00000020 @ val 0x4107b020
|
||||
and r0, r9, r3
|
||||
teq r0, r4 @ ARM 11MPCore?
|
||||
orr r4, r4, #0x00000020 @ val 0x4100b020
|
||||
teq r3, r4 @ ARM 11MPCore?
|
||||
moveq pc, lr @ yes, assume SMP
|
||||
|
||||
mrc p15, 0, r0, c0, c0, 5 @ read MPIDR
|
||||
tst r0, #1 << 31
|
||||
movne pc, lr @ bit 31 => SMP
|
||||
and r0, r0, #0xc0000000 @ multiprocessing extensions and
|
||||
teq r0, #0x80000000 @ not part of a uniprocessor system?
|
||||
moveq pc, lr @ yes, assume SMP
|
||||
|
||||
__fixup_smp_on_up:
|
||||
adr r0, 1f
|
||||
|
@ -417,18 +416,7 @@ __fixup_smp_on_up:
|
|||
sub r3, r0, r3
|
||||
add r4, r4, r3
|
||||
add r5, r5, r3
|
||||
2: cmp r4, r5
|
||||
movhs pc, lr
|
||||
ldmia r4!, {r0, r6}
|
||||
ARM( str r6, [r0, r3] )
|
||||
THUMB( add r0, r0, r3 )
|
||||
#ifdef __ARMEB__
|
||||
THUMB( mov r6, r6, ror #16 ) @ Convert word order for big-endian.
|
||||
#endif
|
||||
THUMB( strh r6, [r0], #2 ) @ For Thumb-2, store as two halfwords
|
||||
THUMB( mov r6, r6, lsr #16 ) @ to be robust against misaligned r3.
|
||||
THUMB( strh r6, [r0] )
|
||||
b 2b
|
||||
b __do_fixup_smp_on_up
|
||||
ENDPROC(__fixup_smp)
|
||||
|
||||
.align
|
||||
|
@ -442,7 +430,31 @@ smp_on_up:
|
|||
ALT_SMP(.long 1)
|
||||
ALT_UP(.long 0)
|
||||
.popsection
|
||||
|
||||
#endif
|
||||
|
||||
.text
|
||||
__do_fixup_smp_on_up:
|
||||
cmp r4, r5
|
||||
movhs pc, lr
|
||||
ldmia r4!, {r0, r6}
|
||||
ARM( str r6, [r0, r3] )
|
||||
THUMB( add r0, r0, r3 )
|
||||
#ifdef __ARMEB__
|
||||
THUMB( mov r6, r6, ror #16 ) @ Convert word order for big-endian.
|
||||
#endif
|
||||
THUMB( strh r6, [r0], #2 ) @ For Thumb-2, store as two halfwords
|
||||
THUMB( mov r6, r6, lsr #16 ) @ to be robust against misaligned r3.
|
||||
THUMB( strh r6, [r0] )
|
||||
b __do_fixup_smp_on_up
|
||||
ENDPROC(__do_fixup_smp_on_up)
|
||||
|
||||
ENTRY(fixup_smp)
|
||||
stmfd sp!, {r4 - r6, lr}
|
||||
mov r4, r0
|
||||
add r5, r0, r1
|
||||
mov r3, #0
|
||||
bl __do_fixup_smp_on_up
|
||||
ldmfd sp!, {r4 - r6, pc}
|
||||
ENDPROC(fixup_smp)
|
||||
|
||||
#include "head-common.S"
|
||||
|
|
|
@ -137,11 +137,10 @@ static u8 get_debug_arch(void)
|
|||
u32 didr;
|
||||
|
||||
/* Do we implement the extended CPUID interface? */
|
||||
if (((read_cpuid_id() >> 16) & 0xf) != 0xf) {
|
||||
pr_warning("CPUID feature registers not supported. "
|
||||
"Assuming v6 debug is present.\n");
|
||||
if (WARN_ONCE((((read_cpuid_id() >> 16) & 0xf) != 0xf),
|
||||
"CPUID feature registers not supported. "
|
||||
"Assuming v6 debug is present.\n"))
|
||||
return ARM_DEBUG_ARCH_V6;
|
||||
}
|
||||
|
||||
ARM_DBG_READ(c0, 0, didr);
|
||||
return (didr >> 16) & 0xf;
|
||||
|
@ -152,6 +151,12 @@ u8 arch_get_debug_arch(void)
|
|||
return debug_arch;
|
||||
}
|
||||
|
||||
static int debug_arch_supported(void)
|
||||
{
|
||||
u8 arch = get_debug_arch();
|
||||
return arch >= ARM_DEBUG_ARCH_V6 && arch <= ARM_DEBUG_ARCH_V7_ECP14;
|
||||
}
|
||||
|
||||
/* Determine number of BRP register available. */
|
||||
static int get_num_brp_resources(void)
|
||||
{
|
||||
|
@ -268,6 +273,9 @@ out:
|
|||
|
||||
int hw_breakpoint_slots(int type)
|
||||
{
|
||||
if (!debug_arch_supported())
|
||||
return 0;
|
||||
|
||||
/*
|
||||
* We can be called early, so don't rely on
|
||||
* our static variables being initialised.
|
||||
|
@ -834,11 +842,11 @@ static void reset_ctrl_regs(void *unused)
|
|||
|
||||
/*
|
||||
* v7 debug contains save and restore registers so that debug state
|
||||
* can be maintained across low-power modes without leaving
|
||||
* the debug logic powered up. It is IMPLEMENTATION DEFINED whether
|
||||
* we can write to the debug registers out of reset, so we must
|
||||
* unlock the OS Lock Access Register to avoid taking undefined
|
||||
* instruction exceptions later on.
|
||||
* can be maintained across low-power modes without leaving the debug
|
||||
* logic powered up. It is IMPLEMENTATION DEFINED whether we can access
|
||||
* the debug registers out of reset, so we must unlock the OS Lock
|
||||
* Access Register to avoid taking undefined instruction exceptions
|
||||
* later on.
|
||||
*/
|
||||
if (debug_arch >= ARM_DEBUG_ARCH_V7_ECP14) {
|
||||
/*
|
||||
|
@ -882,7 +890,7 @@ static int __init arch_hw_breakpoint_init(void)
|
|||
|
||||
debug_arch = get_debug_arch();
|
||||
|
||||
if (debug_arch > ARM_DEBUG_ARCH_V7_ECP14) {
|
||||
if (!debug_arch_supported()) {
|
||||
pr_info("debug architecture 0x%x unsupported.\n", debug_arch);
|
||||
return 0;
|
||||
}
|
||||
|
@ -899,18 +907,18 @@ static int __init arch_hw_breakpoint_init(void)
|
|||
pr_info("%d breakpoint(s) reserved for watchpoint "
|
||||
"single-step.\n", core_num_reserved_brps);
|
||||
|
||||
/*
|
||||
* Reset the breakpoint resources. We assume that a halting
|
||||
* debugger will leave the world in a nice state for us.
|
||||
*/
|
||||
on_each_cpu(reset_ctrl_regs, NULL, 1);
|
||||
|
||||
ARM_DBG_READ(c1, 0, dscr);
|
||||
if (dscr & ARM_DSCR_HDBGEN) {
|
||||
max_watchpoint_len = 4;
|
||||
pr_warning("halting debug mode enabled. Assuming maximum "
|
||||
"watchpoint size of 4 bytes.");
|
||||
"watchpoint size of %u bytes.", max_watchpoint_len);
|
||||
} else {
|
||||
/*
|
||||
* Reset the breakpoint resources. We assume that a halting
|
||||
* debugger will leave the world in a nice state for us.
|
||||
*/
|
||||
smp_call_function(reset_ctrl_regs, NULL, 1);
|
||||
reset_ctrl_regs(NULL);
|
||||
|
||||
/* Work out the maximum supported watchpoint length. */
|
||||
max_watchpoint_len = get_max_wp_len();
|
||||
pr_info("maximum watchpoint size is %u bytes.\n",
|
||||
|
|
|
@ -22,6 +22,7 @@
|
|||
|
||||
#include <asm/pgtable.h>
|
||||
#include <asm/sections.h>
|
||||
#include <asm/smp_plat.h>
|
||||
#include <asm/unwind.h>
|
||||
|
||||
#ifdef CONFIG_XIP_KERNEL
|
||||
|
@ -268,12 +269,28 @@ struct mod_unwind_map {
|
|||
const Elf_Shdr *txt_sec;
|
||||
};
|
||||
|
||||
static const Elf_Shdr *find_mod_section(const Elf32_Ehdr *hdr,
|
||||
const Elf_Shdr *sechdrs, const char *name)
|
||||
{
|
||||
const Elf_Shdr *s, *se;
|
||||
const char *secstrs = (void *)hdr + sechdrs[hdr->e_shstrndx].sh_offset;
|
||||
|
||||
for (s = sechdrs, se = sechdrs + hdr->e_shnum; s < se; s++)
|
||||
if (strcmp(name, secstrs + s->sh_name) == 0)
|
||||
return s;
|
||||
|
||||
return NULL;
|
||||
}
|
||||
|
||||
extern void fixup_smp(const void *, unsigned long);
|
||||
|
||||
int module_finalize(const Elf32_Ehdr *hdr, const Elf_Shdr *sechdrs,
|
||||
struct module *mod)
|
||||
{
|
||||
const Elf_Shdr * __maybe_unused s = NULL;
|
||||
#ifdef CONFIG_ARM_UNWIND
|
||||
const char *secstrs = (void *)hdr + sechdrs[hdr->e_shstrndx].sh_offset;
|
||||
const Elf_Shdr *s, *sechdrs_end = sechdrs + hdr->e_shnum;
|
||||
const Elf_Shdr *sechdrs_end = sechdrs + hdr->e_shnum;
|
||||
struct mod_unwind_map maps[ARM_SEC_MAX];
|
||||
int i;
|
||||
|
||||
|
@ -315,6 +332,9 @@ int module_finalize(const Elf32_Ehdr *hdr, const Elf_Shdr *sechdrs,
|
|||
maps[i].txt_sec->sh_addr,
|
||||
maps[i].txt_sec->sh_size);
|
||||
#endif
|
||||
s = find_mod_section(hdr, sechdrs, ".alt.smp.init");
|
||||
if (s && !is_smp())
|
||||
fixup_smp((void *)s->sh_addr, s->sh_size);
|
||||
return 0;
|
||||
}
|
||||
|
||||
|
|
|
@ -700,7 +700,7 @@ user_backtrace(struct frame_tail __user *tail,
|
|||
* Frame pointers should strictly progress back up the stack
|
||||
* (towards higher addresses).
|
||||
*/
|
||||
if (tail >= buftail.fp)
|
||||
if (tail + 1 >= buftail.fp)
|
||||
return NULL;
|
||||
|
||||
return buftail.fp - 1;
|
||||
|
|
|
@ -36,6 +36,7 @@ static void twd_set_mode(enum clock_event_mode mode,
|
|||
/* timer load already set up */
|
||||
ctrl = TWD_TIMER_CONTROL_ENABLE | TWD_TIMER_CONTROL_IT_ENABLE
|
||||
| TWD_TIMER_CONTROL_PERIODIC;
|
||||
__raw_writel(twd_timer_rate / HZ, twd_base + TWD_TIMER_LOAD);
|
||||
break;
|
||||
case CLOCK_EVT_MODE_ONESHOT:
|
||||
/* period set, and timer enabled in 'next_event' hook */
|
||||
|
@ -81,7 +82,7 @@ int twd_timer_ack(void)
|
|||
|
||||
static void __cpuinit twd_calibrate_rate(void)
|
||||
{
|
||||
unsigned long load, count;
|
||||
unsigned long count;
|
||||
u64 waitjiffies;
|
||||
|
||||
/*
|
||||
|
@ -116,10 +117,6 @@ static void __cpuinit twd_calibrate_rate(void)
|
|||
printk("%lu.%02luMHz.\n", twd_timer_rate / 1000000,
|
||||
(twd_timer_rate / 1000000) % 100);
|
||||
}
|
||||
|
||||
load = twd_timer_rate / HZ;
|
||||
|
||||
__raw_writel(load, twd_base + TWD_TIMER_LOAD);
|
||||
}
|
||||
|
||||
/*
|
||||
|
|
|
@ -838,7 +838,7 @@ EXPORT_SYMBOL(ep93xx_i2s_release);
|
|||
static struct resource ep93xx_ac97_resources[] = {
|
||||
{
|
||||
.start = EP93XX_AAC_PHYS_BASE,
|
||||
.end = EP93XX_AAC_PHYS_BASE + 0xb0 - 1,
|
||||
.end = EP93XX_AAC_PHYS_BASE + 0xac - 1,
|
||||
.flags = IORESOURCE_MEM,
|
||||
},
|
||||
{
|
||||
|
|
|
@ -427,6 +427,13 @@ void __init ep93xx_gpio_init(void)
|
|||
{
|
||||
int i;
|
||||
|
||||
/* Set Ports C, D, E, G, and H for GPIO use */
|
||||
ep93xx_devcfg_set_bits(EP93XX_SYSCON_DEVCFG_KEYS |
|
||||
EP93XX_SYSCON_DEVCFG_GONK |
|
||||
EP93XX_SYSCON_DEVCFG_EONIDE |
|
||||
EP93XX_SYSCON_DEVCFG_GONIDE |
|
||||
EP93XX_SYSCON_DEVCFG_HONIDE);
|
||||
|
||||
for (i = 0; i < ARRAY_SIZE(ep93xx_gpio_banks); i++)
|
||||
gpiochip_add(&ep93xx_gpio_banks[i].chip);
|
||||
}
|
||||
|
|
|
@ -17,8 +17,8 @@
|
|||
/* For NetWinder debugging */
|
||||
.macro addruart, rp, rv
|
||||
mov \rp, #0x000003f8
|
||||
orr \rv, \rp, #0x7c000000 @ physical
|
||||
orr \rp, \rp, #0xff000000 @ virtual
|
||||
orr \rv, \rp, #0xff000000 @ virtual
|
||||
orr \rp, \rp, #0x7c000000 @ physical
|
||||
.endm
|
||||
|
||||
#define UART_SHIFT 0
|
||||
|
|
|
@ -180,7 +180,7 @@ static const uint32_t mx25pdk_keymap[] = {
|
|||
KEY(3, 3, KEY_POWER),
|
||||
};
|
||||
|
||||
static const struct matrix_keymap_data mx25pdk_keymap_data __initdata = {
|
||||
static const struct matrix_keymap_data mx25pdk_keymap_data __initconst = {
|
||||
.keymap = mx25pdk_keymap,
|
||||
.keymap_size = ARRAY_SIZE(mx25pdk_keymap),
|
||||
};
|
||||
|
|
|
@ -432,7 +432,7 @@ static struct clocksource clocksource_ixp4xx = {
|
|||
.flags = CLOCK_SOURCE_IS_CONTINUOUS,
|
||||
};
|
||||
|
||||
unsigned long ixp4xx_timer_freq = FREQ;
|
||||
unsigned long ixp4xx_timer_freq = IXP4XX_TIMER_FREQ;
|
||||
EXPORT_SYMBOL(ixp4xx_timer_freq);
|
||||
static void __init ixp4xx_clocksource_init(void)
|
||||
{
|
||||
|
@ -496,7 +496,7 @@ static struct clock_event_device clockevent_ixp4xx = {
|
|||
|
||||
static void __init ixp4xx_clockevent_init(void)
|
||||
{
|
||||
clockevent_ixp4xx.mult = div_sc(FREQ, NSEC_PER_SEC,
|
||||
clockevent_ixp4xx.mult = div_sc(IXP4XX_TIMER_FREQ, NSEC_PER_SEC,
|
||||
clockevent_ixp4xx.shift);
|
||||
clockevent_ixp4xx.max_delta_ns =
|
||||
clockevent_delta2ns(0xfffffffe, &clockevent_ixp4xx);
|
||||
|
|
|
@ -10,6 +10,7 @@
|
|||
* 66.66... MHz. We do a convulted calculation of CLOCK_TICK_RATE b/c the
|
||||
* timer register ignores the bottom 2 bits of the LATCH value.
|
||||
*/
|
||||
#define FREQ 66666000
|
||||
#define CLOCK_TICK_RATE (((FREQ / HZ & ~IXP4XX_OST_RELOAD_MASK) + 1) * HZ)
|
||||
#define IXP4XX_TIMER_FREQ 66666000
|
||||
#define CLOCK_TICK_RATE \
|
||||
(((IXP4XX_TIMER_FREQ / HZ & ~IXP4XX_OST_RELOAD_MASK) + 1) * HZ)
|
||||
|
||||
|
|
|
@ -265,6 +265,11 @@ void qmgr_release_queue(unsigned int queue)
|
|||
qmgr_queue_descs[queue], queue);
|
||||
qmgr_queue_descs[queue][0] = '\x0';
|
||||
#endif
|
||||
|
||||
while ((addr = qmgr_get_entry(queue)))
|
||||
printk(KERN_ERR "qmgr: released queue %i not empty: 0x%08X\n",
|
||||
queue, addr);
|
||||
|
||||
__raw_writel(0, &qmgr_regs->sram[queue]);
|
||||
|
||||
used_sram_bitmap[0] &= ~mask[0];
|
||||
|
@ -275,10 +280,6 @@ void qmgr_release_queue(unsigned int queue)
|
|||
spin_unlock_irq(&qmgr_lock);
|
||||
|
||||
module_put(THIS_MODULE);
|
||||
|
||||
while ((addr = qmgr_get_entry(queue)))
|
||||
printk(KERN_ERR "qmgr: released queue %i not empty: 0x%08X\n",
|
||||
queue, addr);
|
||||
}
|
||||
|
||||
static int qmgr_init(void)
|
||||
|
|
|
@ -304,7 +304,7 @@ static int name##_set_rate(struct clk *clk, unsigned long rate) \
|
|||
reg = __raw_readl(CLKCTRL_BASE_ADDR + HW_CLKCTRL_##dr); \
|
||||
reg &= ~BM_CLKCTRL_##dr##_DIV; \
|
||||
reg |= div << BP_CLKCTRL_##dr##_DIV; \
|
||||
if (reg | (1 << clk->enable_shift)) { \
|
||||
if (reg & (1 << clk->enable_shift)) { \
|
||||
pr_err("%s: clock is gated\n", __func__); \
|
||||
return -EINVAL; \
|
||||
} \
|
||||
|
@ -347,7 +347,7 @@ static int name##_set_parent(struct clk *clk, struct clk *parent) \
|
|||
{ \
|
||||
if (parent != clk->parent) { \
|
||||
__raw_writel(BM_CLKCTRL_CLKSEQ_BYPASS_##bit, \
|
||||
HW_CLKCTRL_CLKSEQ_TOG); \
|
||||
CLKCTRL_BASE_ADDR + HW_CLKCTRL_CLKSEQ_TOG); \
|
||||
clk->parent = parent; \
|
||||
} \
|
||||
\
|
||||
|
|
|
@ -355,12 +355,12 @@ static int name##_set_rate(struct clk *clk, unsigned long rate) \
|
|||
} else { \
|
||||
reg &= ~BM_CLKCTRL_##dr##_DIV; \
|
||||
reg |= div << BP_CLKCTRL_##dr##_DIV; \
|
||||
if (reg | (1 << clk->enable_shift)) { \
|
||||
if (reg & (1 << clk->enable_shift)) { \
|
||||
pr_err("%s: clock is gated\n", __func__); \
|
||||
return -EINVAL; \
|
||||
} \
|
||||
} \
|
||||
__raw_writel(reg, CLKCTRL_BASE_ADDR + HW_CLKCTRL_CPU); \
|
||||
__raw_writel(reg, CLKCTRL_BASE_ADDR + HW_CLKCTRL_##dr); \
|
||||
\
|
||||
for (i = 10000; i; i--) \
|
||||
if (!(__raw_readl(CLKCTRL_BASE_ADDR + \
|
||||
|
@ -483,7 +483,7 @@ static int name##_set_parent(struct clk *clk, struct clk *parent) \
|
|||
{ \
|
||||
if (parent != clk->parent) { \
|
||||
__raw_writel(BM_CLKCTRL_CLKSEQ_BYPASS_##bit, \
|
||||
HW_CLKCTRL_CLKSEQ_TOG); \
|
||||
CLKCTRL_BASE_ADDR + HW_CLKCTRL_CLKSEQ_TOG); \
|
||||
clk->parent = parent; \
|
||||
} \
|
||||
\
|
||||
|
@ -609,7 +609,6 @@ static struct clk_lookup lookups[] = {
|
|||
_REGISTER_CLOCK("duart", NULL, uart_clk)
|
||||
_REGISTER_CLOCK("imx28-fec.0", NULL, fec_clk)
|
||||
_REGISTER_CLOCK("imx28-fec.1", NULL, fec_clk)
|
||||
_REGISTER_CLOCK("fec.0", NULL, fec_clk)
|
||||
_REGISTER_CLOCK("rtc", NULL, rtc_clk)
|
||||
_REGISTER_CLOCK("pll2", NULL, pll2_clk)
|
||||
_REGISTER_CLOCK(NULL, "hclk", hbus_clk)
|
||||
|
|
|
@ -57,7 +57,6 @@ static void __clk_disable(struct clk *clk)
|
|||
if (clk->disable)
|
||||
clk->disable(clk);
|
||||
__clk_disable(clk->parent);
|
||||
__clk_disable(clk->secondary);
|
||||
}
|
||||
}
|
||||
|
||||
|
@ -68,7 +67,6 @@ static int __clk_enable(struct clk *clk)
|
|||
|
||||
if (clk->usecount++ == 0) {
|
||||
__clk_enable(clk->parent);
|
||||
__clk_enable(clk->secondary);
|
||||
|
||||
if (clk->enable)
|
||||
clk->enable(clk);
|
||||
|
|
|
@ -139,6 +139,8 @@ static void mxs_gpio_irq_handler(u32 irq, struct irq_desc *desc)
|
|||
struct mxs_gpio_port *port = (struct mxs_gpio_port *)get_irq_data(irq);
|
||||
u32 gpio_irq_no_base = port->virtual_irq_start;
|
||||
|
||||
desc->irq_data.chip->irq_ack(&desc->irq_data);
|
||||
|
||||
irq_stat = __raw_readl(port->base + PINCTRL_IRQSTAT(port->id)) &
|
||||
__raw_readl(port->base + PINCTRL_IRQEN(port->id));
|
||||
|
||||
|
|
|
@ -29,8 +29,6 @@ struct clk {
|
|||
int id;
|
||||
/* Source clock this clk depends on */
|
||||
struct clk *parent;
|
||||
/* Secondary clock to enable/disable with this clock */
|
||||
struct clk *secondary;
|
||||
/* Reference count of clock enable/disable */
|
||||
__s8 usecount;
|
||||
/* Register bit position for clock's enable/disable control. */
|
||||
|
|
|
@ -14,19 +14,6 @@
|
|||
#include <mach/irqs.h>
|
||||
#include <asm/hardware/gic.h>
|
||||
|
||||
/*
|
||||
* We use __glue to avoid errors with multiple definitions of
|
||||
* .globl omap_irq_flags as it's included from entry-armv.S but not
|
||||
* from entry-common.S.
|
||||
*/
|
||||
#ifdef __glue
|
||||
.pushsection .data
|
||||
.globl omap_irq_flags
|
||||
omap_irq_flags:
|
||||
.word 0
|
||||
.popsection
|
||||
#endif
|
||||
|
||||
.macro disable_fiq
|
||||
.endm
|
||||
|
||||
|
|
|
@ -57,6 +57,7 @@ struct omap_irq_bank {
|
|||
unsigned long wake_enable;
|
||||
};
|
||||
|
||||
u32 omap_irq_flags;
|
||||
static unsigned int irq_bank_count;
|
||||
static struct omap_irq_bank *irq_banks;
|
||||
|
||||
|
@ -176,7 +177,6 @@ static struct irq_chip omap_irq_chip = {
|
|||
|
||||
void __init omap_init_irq(void)
|
||||
{
|
||||
extern unsigned int omap_irq_flags;
|
||||
int i, j;
|
||||
|
||||
#if defined(CONFIG_ARCH_OMAP730) || defined(CONFIG_ARCH_OMAP850)
|
||||
|
|
|
@ -37,7 +37,7 @@ int omap_lcd_dma_running(void)
|
|||
* On OMAP1510, internal LCD controller will start the transfer
|
||||
* when it gets enabled, so assume DMA running if LCD enabled.
|
||||
*/
|
||||
if (cpu_is_omap1510())
|
||||
if (cpu_is_omap15xx())
|
||||
if (omap_readw(OMAP_LCDC_CONTROL) & OMAP_LCDC_CTRL_LCD_EN)
|
||||
return 1;
|
||||
|
||||
|
@ -95,7 +95,7 @@ EXPORT_SYMBOL(omap_set_lcd_dma_single_transfer);
|
|||
|
||||
void omap_set_lcd_dma_b1_rotation(int rotate)
|
||||
{
|
||||
if (cpu_is_omap1510()) {
|
||||
if (cpu_is_omap15xx()) {
|
||||
printk(KERN_ERR "DMA rotation is not supported in 1510 mode\n");
|
||||
BUG();
|
||||
return;
|
||||
|
@ -106,7 +106,7 @@ EXPORT_SYMBOL(omap_set_lcd_dma_b1_rotation);
|
|||
|
||||
void omap_set_lcd_dma_b1_mirror(int mirror)
|
||||
{
|
||||
if (cpu_is_omap1510()) {
|
||||
if (cpu_is_omap15xx()) {
|
||||
printk(KERN_ERR "DMA mirror is not supported in 1510 mode\n");
|
||||
BUG();
|
||||
}
|
||||
|
@ -116,7 +116,7 @@ EXPORT_SYMBOL(omap_set_lcd_dma_b1_mirror);
|
|||
|
||||
void omap_set_lcd_dma_b1_vxres(unsigned long vxres)
|
||||
{
|
||||
if (cpu_is_omap1510()) {
|
||||
if (cpu_is_omap15xx()) {
|
||||
printk(KERN_ERR "DMA virtual resulotion is not supported "
|
||||
"in 1510 mode\n");
|
||||
BUG();
|
||||
|
@ -127,7 +127,7 @@ EXPORT_SYMBOL(omap_set_lcd_dma_b1_vxres);
|
|||
|
||||
void omap_set_lcd_dma_b1_scale(unsigned int xscale, unsigned int yscale)
|
||||
{
|
||||
if (cpu_is_omap1510()) {
|
||||
if (cpu_is_omap15xx()) {
|
||||
printk(KERN_ERR "DMA scale is not supported in 1510 mode\n");
|
||||
BUG();
|
||||
}
|
||||
|
@ -177,7 +177,7 @@ static void set_b1_regs(void)
|
|||
bottom = PIXADDR(lcd_dma.xres - 1, lcd_dma.yres - 1);
|
||||
/* 1510 DMA requires the bottom address to be 2 more
|
||||
* than the actual last memory access location. */
|
||||
if (cpu_is_omap1510() &&
|
||||
if (cpu_is_omap15xx() &&
|
||||
lcd_dma.data_type == OMAP_DMA_DATA_TYPE_S32)
|
||||
bottom += 2;
|
||||
ei = PIXSTEP(0, 0, 1, 0);
|
||||
|
@ -241,7 +241,7 @@ static void set_b1_regs(void)
|
|||
return; /* Suppress warning about uninitialized vars */
|
||||
}
|
||||
|
||||
if (cpu_is_omap1510()) {
|
||||
if (cpu_is_omap15xx()) {
|
||||
omap_writew(top >> 16, OMAP1510_DMA_LCD_TOP_F1_U);
|
||||
omap_writew(top, OMAP1510_DMA_LCD_TOP_F1_L);
|
||||
omap_writew(bottom >> 16, OMAP1510_DMA_LCD_BOT_F1_U);
|
||||
|
@ -343,7 +343,7 @@ void omap_free_lcd_dma(void)
|
|||
BUG();
|
||||
return;
|
||||
}
|
||||
if (!cpu_is_omap1510())
|
||||
if (!cpu_is_omap15xx())
|
||||
omap_writew(omap_readw(OMAP1610_DMA_LCD_CCR) & ~1,
|
||||
OMAP1610_DMA_LCD_CCR);
|
||||
lcd_dma.reserved = 0;
|
||||
|
@ -360,7 +360,7 @@ void omap_enable_lcd_dma(void)
|
|||
* connected. Otherwise the OMAP internal controller will
|
||||
* start the transfer when it gets enabled.
|
||||
*/
|
||||
if (cpu_is_omap1510() || !lcd_dma.ext_ctrl)
|
||||
if (cpu_is_omap15xx() || !lcd_dma.ext_ctrl)
|
||||
return;
|
||||
|
||||
w = omap_readw(OMAP1610_DMA_LCD_CTRL);
|
||||
|
@ -378,14 +378,14 @@ EXPORT_SYMBOL(omap_enable_lcd_dma);
|
|||
void omap_setup_lcd_dma(void)
|
||||
{
|
||||
BUG_ON(lcd_dma.active);
|
||||
if (!cpu_is_omap1510()) {
|
||||
if (!cpu_is_omap15xx()) {
|
||||
/* Set some reasonable defaults */
|
||||
omap_writew(0x5440, OMAP1610_DMA_LCD_CCR);
|
||||
omap_writew(0x9102, OMAP1610_DMA_LCD_CSDP);
|
||||
omap_writew(0x0004, OMAP1610_DMA_LCD_LCH_CTRL);
|
||||
}
|
||||
set_b1_regs();
|
||||
if (!cpu_is_omap1510()) {
|
||||
if (!cpu_is_omap15xx()) {
|
||||
u16 w;
|
||||
|
||||
w = omap_readw(OMAP1610_DMA_LCD_CCR);
|
||||
|
@ -407,7 +407,7 @@ void omap_stop_lcd_dma(void)
|
|||
u16 w;
|
||||
|
||||
lcd_dma.active = 0;
|
||||
if (cpu_is_omap1510() || !lcd_dma.ext_ctrl)
|
||||
if (cpu_is_omap15xx() || !lcd_dma.ext_ctrl)
|
||||
return;
|
||||
|
||||
w = omap_readw(OMAP1610_DMA_LCD_CCR);
|
||||
|
|
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue