leandrof/linux
1
0
Fork 0
forked from Minki/linux
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux into fixes

Browse Source 
The merge of the 'clk-for-linus' branch caused an automated
merge failure. Pull that in here so we can fix the problem.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
This commit is contained in:
Arnd Bergmann 2012-07-25 14:33:45 +02:00
commit 8cef081c71
2779 changed files with 127411 additions and 77668 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
Documentation/ABI/stable/vdso
View File

@ -24,4 +24,4 @@ though.
(As of this writing, this ABI documentation as been confirmed for x86_64.
The maintainers of the other vDSO-using architectures should confirm
that it is correct for their architecture.)
that it is correct for their architecture.)

2
Documentation/ABI/testing/sysfs-block-zram
View File

@ -96,4 +96,4 @@ Description:
overhead, allocated for this disk. So, allocator space
efficiency can be calculated using compr_data_size and this
statistic.
Unit: bytes
Unit: bytes

2
Documentation/ABI/testing/sysfs-bus-usb-devices-usbsevseg
View File

@ -40,4 +40,4 @@ Description: Controls the decimal places on the device.
the value of 10 ** n. Assume this field has
the value k and has 1 or more decimal places set,
to set the mth place (where m is not already set),
change this fields value to k + 10 ** m.
change this fields value to k + 10 ** m.

2
Documentation/ABI/testing/sysfs-class-backlight-driver-adp8870
View File

@ -53,4 +53,4 @@ Description:
Documentation/ABI/stable/sysfs-class-backlight.
It can be enabled by writing the value stored in
/sys/class/backlight/<backlight>/max_brightness to
/sys/class/backlight/<backlight>/brightness.
/sys/class/backlight/<backlight>/brightness.

20
Documentation/ABI/testing/sysfs-devices-system-xen_cpu Normal file
View File

@ -0,0 +1,20 @@
What: /sys/devices/system/xen_cpu/
Date: May 2012
Contact: Liu, Jinsong <jinsong.liu@intel.com>
Description:
A collection of global/individual Xen physical cpu attributes
Individual physical cpu attributes are contained in
subdirectories named by the Xen's logical cpu number, e.g.:
/sys/devices/system/xen_cpu/xen_cpu#/
What: /sys/devices/system/xen_cpu/xen_cpu#/online
Date: May 2012
Contact: Liu, Jinsong <jinsong.liu@intel.com>
Description:
Interface to online/offline Xen physical cpus
When running under Xen platform, it provide user interface
to online/offline physical cpus, except cpu0 due to several
logic restrictions and assumptions.

38
Documentation/ABI/testing/sysfs-driver-hid-lenovo-tpkbd Normal file
View File

@ -0,0 +1,38 @@
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/press_to_select
Date: July 2011
Contact: linux-input@vger.kernel.org
Description: This controls if mouse clicks should be generated if the trackpoint is quickly pressed. How fast this press has to be
is being controlled by press_speed.
Values are 0 or 1.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/dragging
Date: July 2011
Contact: linux-input@vger.kernel.org
Description: If this setting is enabled, it is possible to do dragging by pressing the trackpoint. This requires press_to_select to be enabled.
Values are 0 or 1.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/release_to_select
Date: July 2011
Contact: linux-input@vger.kernel.org
Description: For details regarding this setting please refer to http://www.pc.ibm.com/ww/healthycomputing/trkpntb.html
Values are 0 or 1.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/select_right
Date: July 2011
Contact: linux-input@vger.kernel.org
Description: This setting controls if the mouse click events generated by pressing the trackpoint (if press_to_select is enabled) generate
a left or right mouse button click.
Values are 0 or 1.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/sensitivity
Date: July 2011
Contact: linux-input@vger.kernel.org
Description: This file contains the trackpoint sensitivity.
Values are decimal integers from 1 (lowest sensitivity) to 255 (highest sensitivity).
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/press_speed
Date: July 2011
Contact: linux-input@vger.kernel.org
Description: This setting controls how fast the trackpoint needs to be pressed to generate a mouse click if press_to_select is enabled.
Values are decimal integers from 1 (slowest) to 255 (fastest).

77
Documentation/ABI/testing/sysfs-driver-hid-roccat-savu Normal file
View File

@ -0,0 +1,77 @@
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/savu/roccatsavu<minor>/buttons
Date: Mai 2012
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store 5 profiles which can be switched by the
press of a button. A profile is split into general settings and
button settings. buttons holds informations about button layout.
When written, this file lets one write the respective profile
buttons to the mouse. The data has to be 47 bytes long.
The mouse will reject invalid data.
Which profile to write is determined by the profile number
contained in the data.
Before reading this file, control has to be written to select
which profile to read.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/savu/roccatsavu<minor>/control
Date: Mai 2012
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When written, this file lets one select which data from which
profile will be read next. The data has to be 3 bytes long.
This file is writeonly.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/savu/roccatsavu<minor>/general
Date: Mai 2012
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store 5 profiles which can be switched by the
press of a button. A profile is split into general settings and
button settings. profile holds informations like resolution, sensitivity
and light effects.
When written, this file lets one write the respective profile
settings back to the mouse. The data has to be 43 bytes long.
The mouse will reject invalid data.
Which profile to write is determined by the profile number
contained in the data.
This file is writeonly.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/savu/roccatsavu<minor>/info
Date: Mai 2012
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When read, this file returns general data like firmware version.
The data is 8 bytes long.
This file is readonly.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/savu/roccatsavu<minor>/macro
Date: Mai 2012
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When written, this file lets one store macros with max 500
keystrokes for a specific button for a specific profile.
Button and profile numbers are included in written data.
The data has to be 2083 bytes long.
Before reading this file, control has to be written to select
which profile and key to read.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/savu/roccatsavu<minor>/profile
Date: Mai 2012
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store 5 profiles which can be switched by the
press of a button. profile holds number of actual profile.
This value is persistent, so its value determines the profile
that's active when the mouse is powered on next time.
When written, the mouse activates the set profile immediately.
The data has to be 3 bytes long.
The mouse will reject invalid data.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/savu/roccatsavu<minor>/sensor
Date: July 2012
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse has a Avago ADNS-3090 sensor.
This file allows reading and writing of the mouse sensors registers.
The data has to be 4 bytes long.
Users: http://roccat.sourceforge.net

14
Documentation/ABI/testing/sysfs-kernel-iommu_groups Normal file
View File

@ -0,0 +1,14 @@
What: /sys/kernel/iommu_groups/
Date: May 2012
KernelVersion: v3.5
Contact: Alex Williamson <alex.williamson@redhat.com>
Description: /sys/kernel/iommu_groups/ contains a number of sub-
directories, each representing an IOMMU group. The
name of the sub-directory matches the iommu_group_id()
for the group, which is an integer value. Within each
subdirectory is another directory named "devices" with
links to the sysfs devices contained in this group.
The group directory also optionally contains a "name"
file if the IOMMU driver has chosen to register a more
common name for the group.
Users:

1
Documentation/DocBook/80211.tmpl
View File

@ -404,7 +404,6 @@
!Finclude/net/mac80211.h ieee80211_get_tkip_p1k
!Finclude/net/mac80211.h ieee80211_get_tkip_p1k_iv
!Finclude/net/mac80211.h ieee80211_get_tkip_p2k
!Finclude/net/mac80211.h ieee80211_key_removed
</chapter>
<chapter id="powersave">

2
Documentation/ManagementStyle
View File

@ -178,7 +178,7 @@ sadly that you are one too, and that while we can all bask in the secure
knowledge that we're better than the average person (let's face it,
nobody ever believes that they're average or below-average), we should
also admit that we're not the sharpest knife around, and there will be
other people that are less of an idiot that you are.
other people that are less of an idiot than you are.
Some people react badly to smart people. Others take advantage of them.

2
Documentation/arm/Samsung-S3C24XX/H1940.txt
View File

@ -37,4 +37,4 @@ Maintainers
Thanks to the many others who have also provided support.
(c) 2005 Ben Dooks
(c) 2005 Ben Dooks

2
Documentation/arm/Samsung-S3C24XX/SMDK2440.txt
View File

@ -53,4 +53,4 @@ Maintainers
and to Simtec Electronics for allowing me time to work on this.
(c) 2004 Ben Dooks
(c) 2004 Ben Dooks

13
Documentation/connector/cn_test.c
View File

@ -69,9 +69,13 @@ static int cn_test_want_notify(void)
return -ENOMEM;
}
nlh = NLMSG_PUT(skb, 0, 0x123, NLMSG_DONE, size - sizeof(*nlh));
nlh = nlmsg_put(skb, 0, 0x123, NLMSG_DONE, size - sizeof(*nlh), 0);
if (!nlh) {
kfree_skb(skb);
return -EMSGSIZE;
}
msg = (struct cn_msg *)NLMSG_DATA(nlh);
msg = nlmsg_data(nlh);
memset(msg, 0, size0);
@ -117,11 +121,6 @@ static int cn_test_want_notify(void)
pr_info("request was sent: group=0x%x\n", ctl->group);
return 0;
nlmsg_failure:
pr_err("failed to send %u.%u\n", msg->seq, msg->ack);
kfree_skb(skb);
return -EINVAL;
}
#endif

2
Documentation/devices.txt
View File

@ -2416,6 +2416,8 @@ Your cooperation is appreciated.
1 = /dev/raw/raw1 First raw I/O device
2 = /dev/raw/raw2 Second raw I/O device
...
max minor number of raw device is set by kernel config
MAX_RAW_DEVS or raw module parameter 'max_raw_devs'
163 char

6
Documentation/devicetree/bindings/arm/primecell.txt
View File

@ -13,11 +13,17 @@ Required properties:
Optional properties:
- arm,primecell-periphid : Value to override the h/w value with
- clocks : From common clock binding. First clock is phandle to clock for apb
pclk. Additional clocks are optional and specific to those peripherals.
- clock-names : From common clock binding. Shall be "apb_pclk" for first clock.
Example:
serial@fff36000 {
compatible = "arm,pl011", "arm,primecell";
arm,primecell-periphid = <0x00341011>;
clocks = <&pclk>;
clock-names = "apb_pclk";
};

17
Documentation/devicetree/bindings/clock/calxeda.txt Normal file
View File

@ -0,0 +1,17 @@
Device Tree Clock bindings for Calxeda highbank platform
This binding uses the common clock binding[1].
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
Required properties:
- compatible : shall be one of the following:
"calxeda,hb-pll-clock" - for a PLL clock
"calxeda,hb-a9periph-clock" - The A9 peripheral clock divided from the
A9 clock.
"calxeda,hb-a9bus-clock" - The A9 bus clock divided from the A9 clock.
"calxeda,hb-emmc-clock" - Divided clock for MMC/SD controller.
- reg : shall be the control register offset from SYSREGs base for the clock.
- clocks : shall be the input parent clock phandle for the clock. This is
either an oscillator or a pll output.
- #clock-cells : from common clock binding; shall be set to 0.

117
Documentation/devicetree/bindings/clock/clock-bindings.txt Normal file
View File

@ -0,0 +1,117 @@
This binding is a work-in-progress, and are based on some experimental
work by benh[1].
Sources of clock signal can be represented by any node in the device
tree. Those nodes are designated as clock providers. Clock consumer
nodes use a phandle and clock specifier pair to connect clock provider
outputs to clock inputs. Similar to the gpio specifiers, a clock
specifier is an array of one more more cells identifying the clock
output on a device. The length of a clock specifier is defined by the
value of a #clock-cells property in the clock provider node.
[1] http://patchwork.ozlabs.org/patch/31551/
==Clock providers==
Required properties:
#clock-cells: Number of cells in a clock specifier; Typically 0 for nodes
with a single clock output and 1 for nodes with multiple
clock outputs.
Optional properties:
clock-output-names: Recommended to be a list of strings of clock output signal
names indexed by the first cell in the clock specifier.
However, the meaning of clock-output-names is domain
specific to the clock provider, and is only provided to
encourage using the same meaning for the majority of clock
providers. This format may not work for clock providers
using a complex clock specifier format. In those cases it
is recommended to omit this property and create a binding
specific names property.
Clock consumer nodes must never directly reference
the provider's clock-output-names property.
For example:
oscillator {
#clock-cells = <1>;
clock-output-names = "ckil", "ckih";
};
- this node defines a device with two clock outputs, the first named
"ckil" and the second named "ckih". Consumer nodes always reference
clocks by index. The names should reflect the clock output signal
names for the device.
==Clock consumers==
Required properties:
clocks: List of phandle and clock specifier pairs, one pair
for each clock input to the device. Note: if the
clock provider specifies '0' for #clock-cells, then
only the phandle portion of the pair will appear.
Optional properties:
clock-names: List of clock input name strings sorted in the same
order as the clocks property. Consumers drivers
will use clock-names to match clock input names
with clocks specifiers.
clock-ranges: Empty property indicating that child nodes can inherit named
clocks from this node. Useful for bus nodes to provide a
clock to their children.
For example:
device {
clocks = <&osc 1>, <&ref 0>;
clock-names = "baud", "register";
};
This represents a device with two clock inputs, named "baud" and "register".
The baud clock is connected to output 1 of the &osc device, and the register
clock is connected to output 0 of the &ref.
==Example==
/* external oscillator */
osc: oscillator {
compatible = "fixed-clock";
#clock-cells = <1>;
clock-frequency = <32678>;
clock-output-names = "osc";
};
/* phase-locked-loop device, generates a higher frequency clock
* from the external oscillator reference */
pll: pll@4c000 {
compatible = "vendor,some-pll-interface"
#clock-cells = <1>;
clocks = <&osc 0>;
clock-names = "ref";
reg = <0x4c000 0x1000>;
clock-output-names = "pll", "pll-switched";
};
/* UART, using the low frequency oscillator for the baud clock,
* and the high frequency switched PLL output for register
* clocking */
uart@a000 {
compatible = "fsl,imx-uart";
reg = <0xa000 0x1000>;
interrupts = <33>;
clocks = <&osc 0>, <&pll 1>;
clock-names = "baud", "register";
};
This DT fragment defines three devices: an external oscillator to provide a
low-frequency reference clock, a PLL device to generate a higher frequency
clock signal, and a UART.
* The oscillator is fixed-frequency, and provides one clock output, named "osc".
* The PLL is both a clock provider and a clock consumer. It uses the clock
signal generated by the external oscillator, and provides two output signals
("pll" and "pll-switched").
* The UART has its baud clock connected the external oscillator and its
register clock connected to the PLL clock (the "pll-switched" signal)

21
Documentation/devicetree/bindings/clock/fixed-clock.txt Normal file
View File

@ -0,0 +1,21 @@
Binding for simple fixed-rate clock sources.
This binding uses the common clock binding[1].
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
Required properties:
- compatible : shall be "fixed-clock".
- #clock-cells : from common clock binding; shall be set to 0.
- clock-frequency : frequency of clock in Hz. Should be a single cell.
Optional properties:
- gpios : From common gpio binding; gpio connection to clock enable pin.
- clock-output-names : From common clock binding.
Example:
clock {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <1000000000>;
};

2
Documentation/devicetree/bindings/gpio/led.txt
View File

@ -55,4 +55,4 @@ run-control {
gpios = <&mpc8572 7 0>;
default-state = "on";
};
}
};

21
Documentation/devicetree/bindings/iommu/nvidia,tegra30-smmu.txt Normal file
View File

@ -0,0 +1,21 @@
NVIDIA Tegra 30 IOMMU H/W, SMMU (System Memory Management Unit)
Required properties:
- compatible : "nvidia,tegra30-smmu"
- reg : Should contain 3 register banks(address and length) for each
of the SMMU register blocks.
- interrupts : Should contain MC General interrupt.
- nvidia,#asids : # of ASIDs
- dma-window : IOVA start address and length.
- nvidia,ahb : phandle to the ahb bus connected to SMMU.
Example:
smmu {
compatible = "nvidia,tegra30-smmu";
reg = <0x7000f010 0x02c
0x7000f1f0 0x010
0x7000f228 0x05c>;
nvidia,#asids = <4>; /* # of ASIDs */
dma-window = <0 0x40000000>; /* IOVA start & length */
nvidia,ahb = <&ahb>;
};

2
Documentation/devicetree/bindings/mtd/partition.txt
View File

@ -35,4 +35,4 @@ flash@0 {
uimage@100000 {
reg = <0x0100000 0x200000>;
};
];
};

29
Documentation/devicetree/bindings/net/broadcom-bcm87xx.txt Normal file
View File

@ -0,0 +1,29 @@
The Broadcom BCM87XX devices are a family of 10G Ethernet PHYs. They
have these bindings in addition to the standard PHY bindings.
Compatible: Should contain "broadcom,bcm8706" or "broadcom,bcm8727" and
"ethernet-phy-ieee802.3-c45"
Optional Properties:
- broadcom,c45-reg-init : one of more sets of 4 cells. The first cell
is the MDIO Manageable Device (MMD) address, the second a register
address within the MMD, the third cell contains a mask to be ANDed
with the existing register value, and the fourth cell is ORed with
he result to yield the new register value. If the third cell has a
value of zero, no read of the existing value is performed.
Example:
ethernet-phy@5 {
reg = <5>;
compatible = "broadcom,bcm8706", "ethernet-phy-ieee802.3-c45";
interrupt-parent = <&gpio>;
interrupts = <12 8>; /* Pin 12, active low */
/*
* Set PMD Digital Control Register for
* GPIO[1] Tx/Rx
* GPIO[0] R64 Sync Acquired
*/
broadcom,c45-reg-init = <1 0xc808 0xff8f 0x70>;
};

3
Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
View File

@ -11,6 +11,9 @@ Required properties:
- reg : Offset and length of the register set for this device
- interrupts : Interrupt tuple for this device
Optional properties:
- clock-frequency : The oscillator frequency driving the flexcan device
Example:

41
Documentation/devicetree/bindings/net/davinci_emac.txt Normal file
View File

@ -0,0 +1,41 @@
* Texas Instruments Davinci EMAC
This file provides information, what the device node
for the davinci_emac interface contains.
Required properties:
- compatible: "ti,davinci-dm6467-emac";
- reg: Offset and length of the register set for the device
- ti,davinci-ctrl-reg-offset: offset to control register
- ti,davinci-ctrl-mod-reg-offset: offset to control module register
- ti,davinci-ctrl-ram-offset: offset to control module ram
- ti,davinci-ctrl-ram-size: size of control module ram
- ti,davinci-rmii-en: use RMII
- ti,davinci-no-bd-ram: has the emac controller BD RAM
- phy-handle: Contains a phandle to an Ethernet PHY.
if not, davinci_emac driver defaults to 100/FULL
- interrupts: interrupt mapping for the davinci emac interrupts sources:
4 sources: <Receive Threshold Interrupt
Receive Interrupt
Transmit Interrupt
Miscellaneous Interrupt>
Optional properties:
- local-mac-address : 6 bytes, mac address
Example (enbw_cmc board):
eth0: emac@1e20000 {
compatible = "ti,davinci-dm6467-emac";
reg = <0x220000 0x4000>;
ti,davinci-ctrl-reg-offset = <0x3000>;
ti,davinci-ctrl-mod-reg-offset = <0x2000>;
ti,davinci-ctrl-ram-offset = <0>;
ti,davinci-ctrl-ram-size = <0x2000>;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <33
34
35
36
>;
interrupt-parent = <&intc>;
};

6
Documentation/devicetree/bindings/net/fsl-fec.txt
View File

@ -7,10 +7,14 @@ Required properties:
- phy-mode : String, operation mode of the PHY interface.
Supported values are: "mii", "gmii", "sgmii", "tbi", "rmii",
"rgmii", "rgmii-id", "rgmii-rxid", "rgmii-txid", "rtbi", "smii".
- phy-reset-gpios : Should specify the gpio for phy reset
Optional properties:
- local-mac-address : 6 bytes, mac address
- phy-reset-gpios : Should specify the gpio for phy reset
- phy-reset-duration : Reset duration in milliseconds. Should present
only if property "phy-reset-gpios" is available. Missing the property
will have the duration be 1 millisecond. Numbers greater than 1000 are
invalid and 1 millisecond will be used instead.
Example:

12
Documentation/devicetree/bindings/net/phy.txt
View File

@ -14,10 +14,20 @@ Required properties:
- linux,phandle : phandle for this node; likely referenced by an
ethernet controller node.
Optional Properties:
- compatible: Compatible list, may contain
"ethernet-phy-ieee802.3-c22" or "ethernet-phy-ieee802.3-c45" for
PHYs that implement IEEE802.3 clause 22 or IEEE802.3 clause 45
specifications. If neither of these are specified, the default is to
assume clause 22. The compatible list may also contain other
elements.
Example:
ethernet-phy@0 {
linux,phandle = <2452000>
compatible = "ethernet-phy-ieee802.3-c22";
linux,phandle = <2452000>;
interrupt-parent = <40000>;
interrupts = <35 1>;
reg = <0>;

3
Documentation/devicetree/bindings/net/stmmac.txt
View File

@ -1,7 +1,8 @@
* STMicroelectronics 10/100/1000 Ethernet driver (GMAC)
Required properties:
- compatible: Should be "st,spear600-gmac"
- compatible: Should be "snps,dwmac-<ip_version>" "snps,dwmac"
For backwards compatibility: "st,spear600-gmac" is also supported.
- reg: Address and length of the register set for the device
- interrupt-parent: Should be the phandle for the interrupt controller
that services interrupts for this device

93
Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt Normal file
View File

@ -0,0 +1,93 @@
One-register-per-pin type device tree based pinctrl driver
Required properties:
- compatible : "pinctrl-single"
- reg : offset and length of the register set for the mux registers
- pinctrl-single,register-width : pinmux register access width in bits
- pinctrl-single,function-mask : mask of allowed pinmux function bits
in the pinmux register
Optional properties:
- pinctrl-single,function-off : function off mode for disabled state if
available and same for all registers; if not specified, disabling of
pin functions is ignored
This driver assumes that there is only one register for each pin,
and uses the common pinctrl bindings as specified in the pinctrl-bindings.txt
document in this directory.
The pin configuration nodes for pinctrl-single are specified as pinctrl
register offset and value pairs using pinctrl-single,pins. Only the bits
specified in pinctrl-single,function-mask are updated. For example, setting
a pin for a device could be done with:
pinctrl-single,pins = <0xdc 0x118>;
Where 0xdc is the offset from the pinctrl register base address for the
device pinctrl register, and 0x118 contains the desired value of the
pinctrl register. See the device example and static board pins example
below for more information.
Example:
/* SoC common file */
/* first controller instance for pins in core domain */
pmx_core: pinmux@4a100040 {
compatible = "pinctrl-single";
reg = <0x4a100040 0x0196>;
#address-cells = <1>;
#size-cells = <0>;
pinctrl-single,register-width = <16>;
pinctrl-single,function-mask = <0xffff>;
};
/* second controller instance for pins in wkup domain */
pmx_wkup: pinmux@4a31e040 {
compatible = "pinctrl-single;
reg = <0x4a31e040 0x0038>;
#address-cells = <1>;
#size-cells = <0>;
pinctrl-single,register-width = <16>;
pinctrl-single,function-mask = <0xffff>;
};
/* board specific .dts file */
&pmx_core {
/*
* map all board specific static pins enabled by the pinctrl driver
* itself during the boot (or just set them up in the bootloader)
*/
pinctrl-names = "default";
pinctrl-0 = <&board_pins>;
board_pins: pinmux_board_pins {
pinctrl-single,pins = <
0x6c 0xf
0x6e 0xf
0x70 0xf
0x72 0xf
>;
};
/* map uart2 pins */
uart2_pins: pinmux_uart2_pins {
pinctrl-single,pins = <
0xd8 0x118
0xda 0
0xdc 0x118
0xde 0
>;
};
};
&uart2 {
pinctrl-names = "default";
pinctrl-0 = <&uart2_pins>;
};

2
Documentation/devicetree/usage-model.txt
View File

@ -312,7 +312,7 @@ device tree for the NVIDIA Tegra board.
};
};
At .machine_init() time, Tegra board support code will need to look at
At .init_machine() time, Tegra board support code will need to look at
this DT and decide which nodes to create platform_devices for.
However, looking at the tree, it is not immediately obvious what kind
of device each node represents, or even if a node represents a device

44
Documentation/feature-removal-schedule.txt
View File

@ -249,15 +249,6 @@ Who: Ravikiran Thirumalai <kiran@scalex86.org>
---------------------------
What: Code that is now under CONFIG_WIRELESS_EXT_SYSFS
(in net/core/net-sysfs.c)
When: 3.5
Why: Over 1K .text/.data size reduction, data is available in other
ways (ioctls)
Who: Johannes Berg <johannes@sipsolutions.net>
---------------------------
What: sysfs ui for changing p4-clockmod parameters
When: September 2009
Why: See commits 129f8ae9b1b5be94517da76009ea956e89104ce8 and
@ -414,21 +405,6 @@ Who: Jean Delvare <khali@linux-fr.org>
----------------------------
What: xt_connlimit rev 0
When: 2012
Who: Jan Engelhardt <jengelh@medozas.de>
Files: net/netfilter/xt_connlimit.c
----------------------------
What: ipt_addrtype match include file
When: 2012
Why: superseded by xt_addrtype
Who: Florian Westphal <fw@strlen.de>
Files: include/linux/netfilter_ipv4/ipt_addrtype.h
----------------------------
What: i2c_driver.attach_adapter
i2c_driver.detach_adapter
When: September 2011
@ -449,6 +425,19 @@ Who: Hans Verkuil <hans.verkuil@cisco.com>
----------------------------
What: CONFIG_CFG80211_WEXT
When: as soon as distributions ship new wireless tools, ie. wpa_supplicant 1.0
and NetworkManager/connman/etc. that are able to use nl80211
Why: Wireless extensions are deprecated, and userland tools are moving to
using nl80211. New drivers are no longer using wireless extensions,
and while there might still be old drivers, both new drivers and new
userland no longer needs them and they can't be used for an feature
developed in the past couple of years. As such, compatibility with
wireless extensions in new drivers will be removed.
Who: Johannes Berg <johannes@sipsolutions.net>
----------------------------
What: g_file_storage driver
When: 3.8
Why: This driver has been superseded by g_mass_storage.
@ -589,6 +578,13 @@ Why: Remount currently allows changing bound subsystems and
----------------------------
What: xt_recent rev 0
When: 2013
Who: Pablo Neira Ayuso <pablo@netfilter.org>
Files: net/netfilter/xt_recent.c
----------------------------
What: KVM debugfs statistics
When: 2013
Why: KVM tracepoints provide mostly equivalent information in a much more

169
Documentation/hid/uhid.txt Normal file
View File

@ -0,0 +1,169 @@
UHID - User-space I/O driver support for HID subsystem
========================================================
The HID subsystem needs two kinds of drivers. In this document we call them:
1. The "HID I/O Driver" is the driver that performs raw data I/O to the
low-level device. Internally, they register an hid_ll_driver structure with
the HID core. They perform device setup, read raw data from the device and
push it into the HID subsystem and they provide a callback so the HID
subsystem can send data to the device.
2. The "HID Device Driver" is the driver that parses HID reports and reacts on
them. There are generic drivers like "generic-usb" and "generic-bluetooth"
which adhere to the HID specification and provide the standardizes features.
But there may be special drivers and quirks for each non-standard device out
there. Internally, they use the hid_driver structure.
Historically, the USB stack was the first subsystem to provide an HID I/O
Driver. However, other standards like Bluetooth have adopted the HID specs and
may provide HID I/O Drivers, too. The UHID driver allows to implement HID I/O
Drivers in user-space and feed the data into the kernel HID-subsystem.
This allows user-space to operate on the same level as USB-HID, Bluetooth-HID
and similar. It does not provide a way to write HID Device Drivers, though. Use
hidraw for this purpose.
There is an example user-space application in ./samples/uhid/uhid-example.c
The UHID API
------------
UHID is accessed through a character misc-device. The minor-number is allocated
dynamically so you need to rely on udev (or similar) to create the device node.
This is /dev/uhid by default.
If a new device is detected by your HID I/O Driver and you want to register this
device with the HID subsystem, then you need to open /dev/uhid once for each
device you want to register. All further communication is done by read()'ing or
write()'ing "struct uhid_event" objects. Non-blocking operations are supported
by setting O_NONBLOCK.
struct uhid_event {
__u32 type;
union {
struct uhid_create_req create;
struct uhid_data_req data;
...
} u;
};
The "type" field contains the ID of the event. Depending on the ID different
payloads are sent. You must not split a single event across multiple read()'s or
multiple write()'s. A single event must always be sent as a whole. Furthermore,
only a single event can be sent per read() or write(). Pending data is ignored.
If you want to handle multiple events in a single syscall, then use vectored
I/O with readv()/writev().
The first thing you should do is sending an UHID_CREATE event. This will
register the device. UHID will respond with an UHID_START event. You can now
start sending data to and reading data from UHID. However, unless UHID sends the
UHID_OPEN event, the internally attached HID Device Driver has no user attached.
That is, you might put your device asleep unless you receive the UHID_OPEN
event. If you receive the UHID_OPEN event, you should start I/O. If the last
user closes the HID device, you will receive an UHID_CLOSE event. This may be
followed by an UHID_OPEN event again and so on. There is no need to perform
reference-counting in user-space. That is, you will never receive multiple
UHID_OPEN events without an UHID_CLOSE event. The HID subsystem performs
ref-counting for you.
You may decide to ignore UHID_OPEN/UHID_CLOSE, though. I/O is allowed even
though the device may have no users.
If you want to send data to the HID subsystem, you send an HID_INPUT event with
your raw data payload. If the kernel wants to send data to the device, you will
read an UHID_OUTPUT or UHID_OUTPUT_EV event.
If your device disconnects, you should send an UHID_DESTROY event. This will
unregister the device. You can now send UHID_CREATE again to register a new
device.
If you close() the fd, the device is automatically unregistered and destroyed
internally.
write()
-------
write() allows you to modify the state of the device and feed input data into
the kernel. The following types are supported: UHID_CREATE, UHID_DESTROY and
UHID_INPUT. The kernel will parse the event immediately and if the event ID is
not supported, it will return -EOPNOTSUPP. If the payload is invalid, then
-EINVAL is returned, otherwise, the amount of data that was read is returned and
the request was handled successfully.
UHID_CREATE:
This creates the internal HID device. No I/O is possible until you send this
event to the kernel. The payload is of type struct uhid_create_req and
contains information about your device. You can start I/O now.
UHID_DESTROY:
This destroys the internal HID device. No further I/O will be accepted. There
may still be pending messages that you can receive with read() but no further
UHID_INPUT events can be sent to the kernel.
You can create a new device by sending UHID_CREATE again. There is no need to
reopen the character device.
UHID_INPUT:
You must send UHID_CREATE before sending input to the kernel! This event
contains a data-payload. This is the raw data that you read from your device.
The kernel will parse the HID reports and react on it.
UHID_FEATURE_ANSWER:
If you receive a UHID_FEATURE request you must answer with this request. You
must copy the "id" field from the request into the answer. Set the "err" field
to 0 if no error occured or to EIO if an I/O error occurred.
If "err" is 0 then you should fill the buffer of the answer with the results
of the feature request and set "size" correspondingly.
read()
------
read() will return a queued ouput report. These output reports can be of type
UHID_START, UHID_STOP, UHID_OPEN, UHID_CLOSE, UHID_OUTPUT or UHID_OUTPUT_EV. No
reaction is required to any of them but you should handle them according to your
needs. Only UHID_OUTPUT and UHID_OUTPUT_EV have payloads.
UHID_START:
This is sent when the HID device is started. Consider this as an answer to
UHID_CREATE. This is always the first event that is sent.
UHID_STOP:
This is sent when the HID device is stopped. Consider this as an answer to
UHID_DESTROY.
If the kernel HID device driver closes the device manually (that is, you
didn't send UHID_DESTROY) then you should consider this device closed and send
an UHID_DESTROY event. You may want to reregister your device, though. This is
always the last message that is sent to you unless you reopen the device with
UHID_CREATE.
UHID_OPEN:
This is sent when the HID device is opened. That is, the data that the HID
device provides is read by some other process. You may ignore this event but
it is useful for power-management. As long as you haven't received this event
there is actually no other process that reads your data so there is no need to
send UHID_INPUT events to the kernel.
UHID_CLOSE:
This is sent when there are no more processes which read the HID data. It is
the counterpart of UHID_OPEN and you may as well ignore this event.
UHID_OUTPUT:
This is sent if the HID device driver wants to send raw data to the I/O
device. You should read the payload and forward it to the device. The payload
is of type "struct uhid_data_req".
This may be received even though you haven't received UHID_OPEN, yet.
UHID_OUTPUT_EV:
Same as UHID_OUTPUT but this contains a "struct input_event" as payload. This
is called for force-feedback, LED or similar events which are received through
an input device by the HID subsystem. You should convert this into raw reports
and send them to your device similar to events of type UHID_OUTPUT.
UHID_FEATURE:
This event is sent if the kernel driver wants to perform a feature request as
described in the HID specs. The report-type and report-number are available in
the payload.
The kernel serializes feature requests so there will never be two in parallel.
However, if you fail to respond with a UHID_FEATURE_ANSWER in a time-span of 5
seconds, then the requests will be dropped and a new one might be sent.
Therefore, the payload also contains an "id" field that identifies every
request.
Document by:
David Herrmann <dh.herrmann@googlemail.com>

61
Documentation/hwmon/da9052 Normal file
View File

@ -0,0 +1,61 @@
Supported chips:
* Dialog Semiconductors DA9052-BC and DA9053-AA/Bx PMICs
Prefix: 'da9052'
Datasheet: Datasheet is not publicly available.
Authors: David Dajun Chen <dchen@diasemi.com>
Description
-----------
The DA9052/53 provides an Analogue to Digital Converter (ADC) with 10 bits
resolution and track and hold circuitry combined with an analogue input
multiplexer. The analogue input multiplexer will allow conversion of up to 10
different inputs. The track and hold circuit ensures stable input voltages at
the input of the ADC during the conversion.
The ADC is used to measure the following inputs:
Channel 0: VDDOUT - measurement of the system voltage
Channel 1: ICH - internal battery charger current measurement
Channel 2: TBAT - output from the battery NTC
Channel 3: VBAT - measurement of the battery voltage
Channel 4: ADC_IN4 - high impedance input (0 - 2.5V)
Channel 5: ADC_IN5 - high impedance input (0 - 2.5V)
Channel 6: ADC_IN6 - high impedance input (0 - 2.5V)
Channel 7: XY - TSI interface to measure the X and Y voltage of the touch
screen resistive potentiometers
Channel 8: Internal Tjunc. - sense (internal temp. sensor)
Channel 9: VBBAT - measurement of the backup battery voltage
By using sysfs attributes we can measure the system voltage VDDOUT, the battery
charging current ICH, battery temperature TBAT, battery junction temperature
TJUNC, battery voltage VBAT and the back up battery voltage VBBAT.
Voltage Monitoring
------------------
Voltages are sampled by a 10 bit ADC.
The battery voltage is calculated as:
Milli volt = ((ADC value * 1000) / 512) + 2500
The backup battery voltage is calculated as:
Milli volt = (ADC value * 2500) / 512;
The voltages on ADC channels 4, 5 and 6 are calculated as:
Milli volt = (ADC value * 2500) / 1023
Temperature Monitoring
----------------------
Temperatures are sampled by a 10 bit ADC. Junction and battery temperatures
are monitored by the ADC channels.
The junction temperature is calculated:
Degrees celsius = 1.708 * (TJUNC_RES - T_OFFSET) - 108.8
The junction temperature attribute is supported by the driver.
The battery temperature is calculated:
Degree Celcius = 1 / (t1 + 1/298)- 273
where t1 = (1/B)* ln(( ADCval * 2.5)/(R25*ITBAT*255))
Default values of R25, B, ITBAT are 10e3, 3380 and 50e-6 respectively.

37
Documentation/hwmon/hih6130 Normal file
View File

@ -0,0 +1,37 @@
Kernel driver hih6130
=====================
Supported chips:
* Honeywell HIH-6130 / HIH-6131
Prefix: 'hih6130'
Addresses scanned: none
Datasheet: Publicly available at the Honeywell website
http://sensing.honeywell.com/index.php?ci_id=3106&la_id=1&defId=44872
Author:
Iain Paton <ipaton0@gmail.com>
Description
-----------
The HIH-6130 & HIH-6131 are humidity and temperature sensors in a SO8 package.
The difference between the two devices is that the HIH-6131 has a condensation
filter.
The devices communicate with the I2C protocol. All sensors are set to the same
I2C address 0x27 by default, so an entry with I2C_BOARD_INFO("hih6130", 0x27)
can be used in the board setup code.
Please see Documentation/i2c/instantiating-devices for details on how to
instantiate I2C devices.
sysfs-Interface
---------------
temp1_input - temperature input
humidity1_input - humidity input
Notes
-----
Command mode and alarms are not currently supported.

3
Documentation/hwmon/submitting-patches
View File

@ -70,6 +70,9 @@ increase the chances of your change being accepted.
review more difficult. It may also result in code which is more complicated
than necessary. Use inline functions or just regular functions instead.
* Use devres functions whenever possible to allocate resources. For rationale
and supported functions, please see Documentation/driver-model/devres.txt.
* If the driver has a detect function, make sure it is silent. Debug messages
and messages printed after a successful detection are acceptable, but it
must not print messages such as "Chip XXX not found/supported".

13
Documentation/i2c/busses/i2c-i801
View File

@ -38,9 +38,10 @@ Module Parameters
Disable selected features normally supported by the device. This makes it
possible to work around possible driver or hardware bugs if the feature in
question doesn't work as intended for whatever reason. Bit values:
1 disable SMBus PEC
2 disable the block buffer
8 disable the I2C block read functionality
0x01 disable SMBus PEC
0x02 disable the block buffer
0x08 disable the I2C block read functionality
0x10 don't use interrupts
Description
@ -86,6 +87,12 @@ SMBus 2.0 Support
The 82801DB (ICH4) and later chips support several SMBus 2.0 features.
Interrupt Support
-----------------
PCI interrupt support is supported on the 82801EB (ICH5) and later chips.
Hidden ICH SMBus
----------------

9
Documentation/i2c/busses/i2c-piix4
View File

@ -8,6 +8,11 @@ Supported adapters:
Datasheet: Only available via NDA from ServerWorks
* ATI IXP200, IXP300, IXP400, SB600, SB700 and SB800 southbridges
Datasheet: Not publicly available
SB700 register reference available at:
http://support.amd.com/us/Embedded_TechDocs/43009_sb7xx_rrg_pub_1.00.pdf
* AMD SP5100 (SB700 derivative found on some server mainboards)
Datasheet: Publicly available at the AMD website
http://support.amd.com/us/Embedded_TechDocs/44413.pdf
* AMD Hudson-2
Datasheet: Not publicly available
* Standard Microsystems (SMSC) SLC90E66 (Victory66) southbridge
@ -68,6 +73,10 @@ this driver on those mainboards.
The ServerWorks Southbridges, the Intel 440MX, and the Victory66 are
identical to the PIIX4 in I2C/SMBus support.
The AMD SB700 and SP5100 chipsets implement two PIIX4-compatible SMBus
controllers. If your BIOS initializes the secondary controller, it will
be detected by this driver as an "Auxiliary SMBus Host Controller".
If you own Force CPCI735 motherboard or other OSB4 based systems you may need
to change the SMBus Interrupt Select register so the SMBus controller uses
the SMI mode.

23
Documentation/i2c/writing-clients
View File

@ -245,11 +245,26 @@ static int __init foo_init(void)
{
return i2c_add_driver(&foo_driver);
}
module_init(foo_init);
static void __exit foo_cleanup(void)
{
i2c_del_driver(&foo_driver);
}
module_exit(foo_cleanup);
The module_i2c_driver() macro can be used to reduce above code.
module_i2c_driver(foo_driver);
Note that some functions are marked by `__init'. These functions can
be removed after kernel booting (or module loading) is completed.
Likewise, functions marked by `__exit' are dropped by the compiler when
the code is built into the kernel, as they would never be called.
Driver Information
==================
/* Substitute your own name and email address */
MODULE_AUTHOR("Frodo Looijaard <frodol@dds.nl>"
@ -258,14 +273,6 @@ MODULE_DESCRIPTION("Driver for Barf Inc. Foo I2C devices");
/* a few non-GPL license types are also allowed */
MODULE_LICENSE("GPL");
module_init(foo_init);
module_exit(foo_cleanup);
Note that some functions are marked by `__init'. These functions can
be removed after kernel booting (or module loading) is completed.
Likewise, functions marked by `__exit' are dropped by the compiler when
the code is built into the kernel, as they would never be called.
Power Management
================

1
Documentation/kernel-parameters.txt
View File

@ -1134,7 +1134,6 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
forcesac
soft
pt [x86, IA-64]
group_mf [x86, IA-64]
io7= [HW] IO7 for Marvel based alpha systems

3
Documentation/laptops/asus-laptop.txt
View File

@ -151,8 +151,7 @@ Display switching
Debugging:
1) Check whether the Fn+F8 key:
a) does not lock the laptop (try disabling CONFIG_X86_UP_APIC or boot with
noapic / nolapic if it does)
a) does not lock the laptop (try a boot with noapic / nolapic if it does)
b) generates events (0x6n, where n is the value corresponding to the
configuration above)
c) actually works

5
Documentation/networking/batman-adv.txt
View File

@ -211,6 +211,11 @@ The debug output can be changed at runtime using the file
will enable debug messages for when routes change.
Counters for different types of packets entering and leaving the
batman-adv module are available through ethtool:
# ethtool --statistics bat0
BATCTL
------

6
Documentation/networking/bonding.txt
View File

@ -1210,7 +1210,7 @@ options, you may wish to use the "max_bonds" module parameter,
documented above.
To create multiple bonding devices with differing options, it is
preferrable to use bonding parameters exported by sysfs, documented in the
preferable to use bonding parameters exported by sysfs, documented in the
section below.
For versions of bonding without sysfs support, the only means to
@ -1950,7 +1950,7 @@ access to fail over to. Additionally, the bonding load balance modes
support link monitoring of their members, so if individual links fail,
the load will be rebalanced across the remaining devices.
See Section 13, "Configuring Bonding for Maximum Throughput"
See Section 12, "Configuring Bonding for Maximum Throughput"
for information on configuring bonding with one peer device.
11.2 High Availability in a Multiple Switch Topology
@ -2620,7 +2620,7 @@ be found at:
https://lists.sourceforge.net/lists/listinfo/bonding-devel
Discussions regarding the developpement of the bonding driver take place
Discussions regarding the development of the bonding driver take place
on the main Linux network mailing list, hosted at vger.kernel.org. The list
address is:

13
Documentation/networking/bridge.txt
View File

@ -1,7 +1,14 @@
In order to use the Ethernet bridging functionality, you'll need the
userspace tools. These programs and documentation are available
at http://www.linuxfoundation.org/en/Net:Bridge. The download page is
http://prdownloads.sourceforge.net/bridge.
userspace tools.
Documentation for Linux bridging is on:
http://www.linuxfoundation.org/collaborate/workgroups/networking/bridge
The bridge-utilities are maintained at:
git://git.kernel.org/pub/scm/linux/kernel/git/shemminger/bridge-utils.git
Additionally, the iproute2 utilities can be used to configure
bridge devices.
If you still have questions, don't hesitate to post to the mailing list
(more info https://lists.linux-foundation.org/mailman/listinfo/bridge).

89
Documentation/networking/caif/Linux-CAIF.txt
View File

@ -19,60 +19,36 @@ and host. Currently, UART and Loopback are available for Linux.
Architecture:
------------
The implementation of CAIF is divided into:
* CAIF Socket Layer, Kernel API, and Net Device.
* CAIF Socket Layer and GPRS IP Interface.
* CAIF Core Protocol Implementation
* CAIF Link Layer, implemented as NET devices.
RTNL
!
! +------+ +------+ +------+
! +------+! +------+! +------+!
! ! Sock !! !Kernel!! ! Net !!
! ! API !+ ! API !+ ! Dev !+ <- CAIF Client APIs
! +------+ +------! +------+
! ! ! !
! +----------!----------+
! +------+ <- CAIF Protocol Implementation
+-------> ! CAIF !
! Core !
+------+
+--------!--------+
! !
+------+ +-----+
! ! ! TTY ! <- Link Layer (Net Devices)
+------+ +-----+
! +------+ +------+
! +------+! +------+!
! ! IP !! !Socket!!
+-------> !interf!+ ! API !+ <- CAIF Client APIs
! +------+ +------!
! ! !
! +-----------+
! !
! +------+ <- CAIF Core Protocol
! ! CAIF !
! ! Core !
! +------+
! +----------!---------+
! ! ! !
! +------+ +-----+ +------+
+--> ! HSI ! ! TTY ! ! USB ! <- Link Layer (Net Devices)
+------+ +-----+ +------+
Using the Kernel API
----------------------
The Kernel API is used for accessing CAIF channels from the
kernel.
The user of the API has to implement two callbacks for receive
and control.
The receive callback gives a CAIF packet as a SKB. The control
callback will
notify of channel initialization complete, and flow-on/flow-
off.
struct caif_device caif_dev = {
.caif_config = {
.name = "MYDEV"
.type = CAIF_CHTY_AT
}
.receive_cb = my_receive,
.control_cb = my_control,
};
caif_add_device(&caif_dev);
caif_transmit(&caif_dev, skb);
See the caif_kernel.h for details about the CAIF kernel API.
I M P L E M E N T A T I O N
===========================
===========================
CAIF Core Protocol Layer
=========================================
@ -88,17 +64,13 @@ The Core CAIF implementation contains:
- Simple implementation of CAIF.
- Layered architecture (a la Streams), each layer in the CAIF
specification is implemented in a separate c-file.
- Clients must implement PHY layer to access physical HW
with receive and transmit functions.
- Clients must call configuration function to add PHY layer.
- Clients must implement CAIF layer to consume/produce
CAIF payload with receive and transmit functions.
- Clients must call configuration function to add and connect the
Client layer.
- When receiving / transmitting CAIF Packets (cfpkt), ownership is passed
to the called function (except for framing layers' receive functions
or if a transmit function returns an error, in which case the caller
must free the packet).
to the called function (except for framing layers' receive function)
Layered Architecture
--------------------
@ -109,11 +81,6 @@ Implementation. The support functions include:
CAIF Packet has functions for creating, destroying and adding content
and for adding/extracting header and trailers to protocol packets.
- CFLST CAIF list implementation.
- CFGLUE CAIF Glue. Contains OS Specifics, such as memory
allocation, endianness, etc.
The CAIF Protocol implementation contains:
- CFCNFG CAIF Configuration layer. Configures the CAIF Protocol
@ -128,7 +95,7 @@ The CAIF Protocol implementation contains:
control and remote shutdown requests.
- CFVEI CAIF VEI layer. Handles CAIF AT Channels on VEI (Virtual
External Interface). This layer encodes/decodes VEI frames.
External Interface). This layer encodes/decodes VEI frames.
- CFDGML CAIF Datagram layer. Handles CAIF Datagram layer (IP
traffic), encodes/decodes Datagram frames.
@ -170,7 +137,7 @@ The CAIF Protocol implementation contains:
+---------+ +---------+
! !
+---------+ +---------+
| | | Serial |
| | | Serial |
| | | CFSERL |
+---------+ +---------+
@ -186,24 +153,20 @@ In this layered approach the following "rules" apply.
layer->dn->transmit(layer->dn, packet);
Linux Driver Implementation
CAIF Socket and IP interface
===========================
Linux GPRS Net Device and CAIF socket are implemented on top of the
CAIF Core protocol. The Net device and CAIF socket have an instance of
The IP interface and CAIF socket API are implemented on top of the
CAIF Core protocol. The IP Interface and CAIF socket have an instance of
'struct cflayer', just like the CAIF Core protocol stack.
Net device and Socket implement the 'receive()' function defined by
'struct cflayer', just like the rest of the CAIF stack. In this way, transmit and
receive of packets is handled as by the rest of the layers: the 'dn->transmit()'
function is called in order to transmit data.
The layer on top of the CAIF Core implementation is
sometimes referred to as the "Client layer".
Configuration of Link Layer
---------------------------
The Link Layer is implemented as Linux net devices (struct net_device).
The Link Layer is implemented as Linux network devices (struct net_device).
Payload handling and registration is done using standard Linux mechanisms.
The CAIF Protocol relies on a loss-less link layer without implementing

186
Documentation/networking/can.txt
View File

@ -22,7 +22,8 @@ This file contains
4.1.2 RAW socket option CAN_RAW_ERR_FILTER
4.1.3 RAW socket option CAN_RAW_LOOPBACK
4.1.4 RAW socket option CAN_RAW_RECV_OWN_MSGS
4.1.5 RAW socket returned message flags
4.1.5 RAW socket option CAN_RAW_FD_FRAMES
4.1.6 RAW socket returned message flags
4.2 Broadcast Manager protocol sockets (SOCK_DGRAM)
4.3 connected transport protocols (SOCK_SEQPACKET)
4.4 unconnected transport protocols (SOCK_DGRAM)
@ -41,7 +42,8 @@ This file contains
6.5.1 Netlink interface to set/get devices properties
6.5.2 Setting the CAN bit-timing
6.5.3 Starting and stopping the CAN network device
6.6 supported CAN hardware
6.6 CAN FD (flexible data rate) driver support
6.7 supported CAN hardware
7 Socket CAN resources
@ -232,16 +234,16 @@ solution for a couple of reasons:
arbitration problems and error frames caused by the different
ECUs. The occurrence of detected errors are important for diagnosis
and have to be logged together with the exact timestamp. For this
reason the CAN interface driver can generate so called Error Frames
that can optionally be passed to the user application in the same
way as other CAN frames. Whenever an error on the physical layer
reason the CAN interface driver can generate so called Error Message
Frames that can optionally be passed to the user application in the
same way as other CAN frames. Whenever an error on the physical layer
or the MAC layer is detected (e.g. by the CAN controller) the driver
creates an appropriate error frame. Error frames can be requested by
the user application using the common CAN filter mechanisms. Inside
this filter definition the (interested) type of errors may be
selected. The reception of error frames is disabled by default.
The format of the CAN error frame is briefly described in the Linux
header file "include/linux/can/error.h".
creates an appropriate error message frame. Error messages frames can
be requested by the user application using the common CAN filter
mechanisms. Inside this filter definition the (interested) type of
errors may be selected. The reception of error messages is disabled
by default. The format of the CAN error message frame is briefly
described in the Linux header file "include/linux/can/error.h".
4. How to use Socket CAN
------------------------
@ -273,7 +275,7 @@ solution for a couple of reasons:
struct can_frame {
canid_t can_id; /* 32 bit CAN_ID + EFF/RTR/ERR flags */
__u8 can_dlc; /* data length code: 0 .. 8 */
__u8 can_dlc; /* frame payload length in byte (0 .. 8) */
__u8 data[8] __attribute__((aligned(8)));
};
@ -375,6 +377,51 @@ solution for a couple of reasons:
nbytes = sendto(s, &frame, sizeof(struct can_frame),
0, (struct sockaddr*)&addr, sizeof(addr));
Remark about CAN FD (flexible data rate) support:
Generally the handling of CAN FD is very similar to the formerly described
examples. The new CAN FD capable CAN controllers support two different
bitrates for the arbitration phase and the payload phase of the CAN FD frame
and up to 64 bytes of payload. This extended payload length breaks all the
kernel interfaces (ABI) which heavily rely on the CAN frame with fixed eight
bytes of payload (struct can_frame) like the CAN_RAW socket. Therefore e.g.
the CAN_RAW socket supports a new socket option CAN_RAW_FD_FRAMES that
switches the socket into a mode that allows the handling of CAN FD frames
and (legacy) CAN frames simultaneously (see section 4.1.5).
The struct canfd_frame is defined in include/linux/can.h:
struct canfd_frame {
canid_t can_id; /* 32 bit CAN_ID + EFF/RTR/ERR flags */
__u8 len; /* frame payload length in byte (0 .. 64) */
__u8 flags; /* additional flags for CAN FD */
__u8 __res0; /* reserved / padding */
__u8 __res1; /* reserved / padding */
__u8 data[64] __attribute__((aligned(8)));
};
The struct canfd_frame and the existing struct can_frame have the can_id,
the payload length and the payload data at the same offset inside their
structures. This allows to handle the different structures very similar.
When the content of a struct can_frame is copied into a struct canfd_frame
all structure elements can be used as-is - only the data[] becomes extended.
When introducing the struct canfd_frame it turned out that the data length
code (DLC) of the struct can_frame was used as a length information as the
length and the DLC has a 1:1 mapping in the range of 0 .. 8. To preserve
the easy handling of the length information the canfd_frame.len element
contains a plain length value from 0 .. 64. So both canfd_frame.len and
can_frame.can_dlc are equal and contain a length information and no DLC.
For details about the distinction of CAN and CAN FD capable devices and
the mapping to the bus-relevant data length code (DLC), see chapter 6.6.
The length of the two CAN(FD) frame structures define the maximum transfer
unit (MTU) of the CAN(FD) network interface and skbuff data length. Two
definitions are specified for CAN specific MTUs in include/linux/can.h :
#define CAN_MTU (sizeof(struct can_frame)) == 16 => 'legacy' CAN frame
#define CANFD_MTU (sizeof(struct canfd_frame)) == 72 => CAN FD frame
4.1 RAW protocol sockets with can_filters (SOCK_RAW)
Using CAN_RAW sockets is extensively comparable to the commonly
@ -383,7 +430,7 @@ solution for a couple of reasons:
defaults are set at RAW socket binding time:
- The filters are set to exactly one filter receiving everything
- The socket only receives valid data frames (=> no error frames)
- The socket only receives valid data frames (=> no error message frames)
- The loopback of sent CAN frames is enabled (see chapter 3.2)
- The socket does not receive its own sent frames (in loopback mode)
@ -434,7 +481,7 @@ solution for a couple of reasons:
4.1.2 RAW socket option CAN_RAW_ERR_FILTER
As described in chapter 3.4 the CAN interface driver can generate so
called Error Frames that can optionally be passed to the user
called Error Message Frames that can optionally be passed to the user
application in the same way as other CAN frames. The possible
errors are divided into different error classes that may be filtered
using the appropriate error mask. To register for every possible
@ -472,7 +519,69 @@ solution for a couple of reasons:
setsockopt(s, SOL_CAN_RAW, CAN_RAW_RECV_OWN_MSGS,
&recv_own_msgs, sizeof(recv_own_msgs));
4.1.5 RAW socket returned message flags
4.1.5 RAW socket option CAN_RAW_FD_FRAMES
CAN FD support in CAN_RAW sockets can be enabled with a new socket option
CAN_RAW_FD_FRAMES which is off by default. When the new socket option is
not supported by the CAN_RAW socket (e.g. on older kernels), switching the
CAN_RAW_FD_FRAMES option returns the error -ENOPROTOOPT.
Once CAN_RAW_FD_FRAMES is enabled the application can send both CAN frames
and CAN FD frames. OTOH the application has to handle CAN and CAN FD frames
when reading from the socket.
CAN_RAW_FD_FRAMES enabled: CAN_MTU and CANFD_MTU are allowed
CAN_RAW_FD_FRAMES disabled: only CAN_MTU is allowed (default)
Example:
[ remember: CANFD_MTU == sizeof(struct canfd_frame) ]
struct canfd_frame cfd;
nbytes = read(s, &cfd, CANFD_MTU);
if (nbytes == CANFD_MTU) {
printf("got CAN FD frame with length %d\n", cfd.len);
/* cfd.flags contains valid data */
} else if (nbytes == CAN_MTU) {
printf("got legacy CAN frame with length %d\n", cfd.len);
/* cfd.flags is undefined */
} else {
fprintf(stderr, "read: invalid CAN(FD) frame\n");
return 1;
}
/* the content can be handled independently from the received MTU size */
printf("can_id: %X data length: %d data: ", cfd.can_id, cfd.len);
for (i = 0; i < cfd.len; i++)
printf("%02X ", cfd.data[i]);
When reading with size CANFD_MTU only returns CAN_MTU bytes that have
been received from the socket a legacy CAN frame has been read into the
provided CAN FD structure. Note that the canfd_frame.flags data field is
not specified in the struct can_frame and therefore it is only valid in
CANFD_MTU sized CAN FD frames.
As long as the payload length is <=8 the received CAN frames from CAN FD
capable CAN devices can be received and read by legacy sockets too. When
user-generated CAN FD frames have a payload length <=8 these can be send
by legacy CAN network interfaces too. Sending CAN FD frames with payload
length > 8 to a legacy CAN network interface returns an -EMSGSIZE error.
Implementation hint for new CAN applications:
To build a CAN FD aware application use struct canfd_frame as basic CAN
data structure for CAN_RAW based applications. When the application is
executed on an older Linux kernel and switching the CAN_RAW_FD_FRAMES
socket option returns an error: No problem. You'll get legacy CAN frames
or CAN FD frames and can process them the same way.
When sending to CAN devices make sure that the device is capable to handle
CAN FD frames by checking if the device maximum transfer unit is CANFD_MTU.
The CAN device MTU can be retrieved e.g. with a SIOCGIFMTU ioctl() syscall.
4.1.6 RAW socket returned message flags
When using recvmsg() call, the msg->msg_flags may contain following flags:
@ -527,7 +636,7 @@ solution for a couple of reasons:
rcvlist_all - list for unfiltered entries (no filter operations)
rcvlist_eff - list for single extended frame (EFF) entries
rcvlist_err - list for error frames masks
rcvlist_err - list for error message frames masks
rcvlist_fil - list for mask/value filters
rcvlist_inv - list for mask/value filters (inverse semantic)
rcvlist_sff - list for single standard frame (SFF) entries
@ -573,10 +682,13 @@ solution for a couple of reasons:
dev->type = ARPHRD_CAN; /* the netdevice hardware type */
dev->flags = IFF_NOARP; /* CAN has no arp */
dev->mtu = sizeof(struct can_frame);
dev->mtu = CAN_MTU; /* sizeof(struct can_frame) -> legacy CAN interface */
The struct can_frame is the payload of each socket buffer in the
protocol family PF_CAN.
or alternative, when the controller supports CAN with flexible data rate:
dev->mtu = CANFD_MTU; /* sizeof(struct canfd_frame) -> CAN FD interface */
The struct can_frame or struct canfd_frame is the payload of each socket
buffer (skbuff) in the protocol family PF_CAN.
6.2 local loopback of sent frames
@ -784,15 +896,41 @@ solution for a couple of reasons:
$ ip link set canX type can restart-ms 100
Alternatively, the application may realize the "bus-off" condition
by monitoring CAN error frames and do a restart when appropriate with
the command:
by monitoring CAN error message frames and do a restart when
appropriate with the command:
$ ip link set canX type can restart
Note that a restart will also create a CAN error frame (see also
chapter 3.4).
Note that a restart will also create a CAN error message frame (see
also chapter 3.4).
6.6 Supported CAN hardware
6.6 CAN FD (flexible data rate) driver support
CAN FD capable CAN controllers support two different bitrates for the
arbitration phase and the payload phase of the CAN FD frame. Therefore a
second bittiming has to be specified in order to enable the CAN FD bitrate.
Additionally CAN FD capable CAN controllers support up to 64 bytes of
payload. The representation of this length in can_frame.can_dlc and
canfd_frame.len for userspace applications and inside the Linux network
layer is a plain value from 0 .. 64 instead of the CAN 'data length code'.
The data length code was a 1:1 mapping to the payload length in the legacy
CAN frames anyway. The payload length to the bus-relevant DLC mapping is
only performed inside the CAN drivers, preferably with the helper
functions can_dlc2len() and can_len2dlc().
The CAN netdevice driver capabilities can be distinguished by the network
devices maximum transfer unit (MTU):
MTU = 16 (CAN_MTU) => sizeof(struct can_frame) => 'legacy' CAN device
MTU = 72 (CANFD_MTU) => sizeof(struct canfd_frame) => CAN FD capable device
The CAN device MTU can be retrieved e.g. with a SIOCGIFMTU ioctl() syscall.
N.B. CAN FD capable devices can also handle and send legacy CAN frames.
FIXME: Add details about the CAN FD controller configuration when available.
6.7 Supported CAN hardware
Please check the "Kconfig" file in "drivers/net/can" to get an actual
list of the support CAN hardware. On the Socket CAN project website

62
Documentation/networking/ip-sysctl.txt
View File

@ -468,6 +468,19 @@ tcp_syncookies - BOOLEAN
SYN flood warnings in logs not being really flooded, your server
is seriously misconfigured.
tcp_fastopen - INTEGER
Enable TCP Fast Open feature (draft-ietf-tcpm-fastopen) to send data
in the opening SYN packet. To use this feature, the client application
must not use connect(). Instead, it should use sendmsg() or sendto()
with MSG_FASTOPEN flag which performs a TCP handshake automatically.
The values (bitmap) are:
1: Enables sending data in the opening SYN on the client
5: Enables sending data in the opening SYN on the client regardless
of cookie availability.
Default: 0
tcp_syn_retries - INTEGER
Number of times initial SYNs for an active TCP connection attempt
will be retransmitted. Should not be higher than 255. Default value
@ -551,6 +564,25 @@ tcp_thin_dupack - BOOLEAN
Documentation/networking/tcp-thin.txt
Default: 0
tcp_limit_output_bytes - INTEGER
Controls TCP Small Queue limit per tcp socket.
TCP bulk sender tends to increase packets in flight until it
gets losses notifications. With SNDBUF autotuning, this can
result in a large amount of packets queued in qdisc/device
on the local machine, hurting latency of other flows, for
typical pfifo_fast qdiscs.
tcp_limit_output_bytes limits the number of bytes on qdisc
or device to reduce artificial RTT/cwnd and reduce bufferbloat.
Note: For GSO/TSO enabled flows, we try to have at least two
packets in flight. Reducing tcp_limit_output_bytes might also
reduce the size of individual GSO packet (64KB being the max)
Default: 131072
tcp_challenge_ack_limit - INTEGER
Limits number of Challenge ACK sent per second, as recommended
in RFC 5961 (Improving TCP's Robustness to Blind In-Window Attacks)
Default: 100
UDP variables:
udp_mem - vector of 3 INTEGERs: min, pressure, max
@ -857,9 +889,19 @@ accept_source_route - BOOLEAN
FALSE (host)
accept_local - BOOLEAN
Accept packets with local source addresses. In combination with
suitable routing, this can be used to direct packets between two
local interfaces over the wire and have them accepted properly.
Accept packets with local source addresses. In combination
with suitable routing, this can be used to direct packets
between two local interfaces over the wire and have them
accepted properly.
rp_filter must be set to a non-zero value in order for
accept_local to have an effect.
default FALSE
route_localnet - BOOLEAN
Do not consider loopback addresses as martian source or destination
while routing. This enables the use of 127/8 for local routing purposes.
default FALSE
rp_filter - INTEGER
@ -1398,6 +1440,20 @@ path_max_retrans - INTEGER
Default: 5
pf_retrans - INTEGER
The number of retransmissions that will be attempted on a given path
before traffic is redirected to an alternate transport (should one
exist). Note this is distinct from path_max_retrans, as a path that
passes the pf_retrans threshold can still be used. Its only
deprioritized when a transmission path is selected by the stack. This
setting is primarily used to enable fast failover mechanisms without
having to reduce path_max_retrans to a very low value. See:
http://www.ietf.org/id/draft-nishida-tsvwg-sctp-failover-05.txt
for details. Note also that a value of pf_retrans > path_max_retrans
disables this feature
Default: 0
rto_initial - INTEGER
The initial round trip timeout value in milliseconds that will be used
in calculating round trip times. This is the initial time interval

2
Documentation/networking/openvswitch.txt
View File

@ -118,7 +118,7 @@ essentially like this, ignoring metadata:
Naively, to add VLAN support, it makes sense to add a new "vlan" flow
key attribute to contain the VLAN tag, then continue to decode the
encapsulated headers beyond the VLAN tag using the existing field
definitions. With this change, an TCP packet in VLAN 10 would have a
definitions. With this change, a TCP packet in VLAN 10 would have a
flow key much like this:
eth(...), vlan(vid=10, pcp=0), eth_type(0x0800), ip(proto=6, ...), tcp(...)

14
Documentation/networking/s2io.txt
View File

@ -136,16 +136,6 @@ For more information, please review the AMD8131 errata at
http://vip.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/
26310_AMD-8131_HyperTransport_PCI-X_Tunnel_Revision_Guide_rev_3_18.pdf
6. Available Downloads
Neterion "s2io" driver in Red Hat and Suse 2.6-based distributions is kept up
to date, also the latest "s2io" code (including support for 2.4 kernels) is
available via "Support" link on the Neterion site: http://www.neterion.com.
For Xframe User Guide (Programming manual), visit ftp site ns1.s2io.com,
user: linuxdocs password: HALdocs
7. Support
6. Support
For further support please contact either your 10GbE Xframe NIC vendor (IBM,
HP, SGI etc.) or click on the "Support" link on the Neterion site:
http://www.neterion.com.
HP, SGI etc.)

36
Documentation/networking/stmmac.txt
View File

@ -257,9 +257,11 @@ reset procedure etc).
o Makefile
o stmmac_main.c: main network device driver;
o stmmac_mdio.c: mdio functions;
o stmmac_pci: PCI driver;
o stmmac_platform.c: platform driver
o stmmac_ethtool.c: ethtool support;
o stmmac_timer.[ch]: timer code used for mitigating the driver dma interrupts
Only tested on ST40 platforms based.
(only tested on ST40 platforms based);
o stmmac.h: private driver structure;
o common.h: common definitions and VFTs;
o descs.h: descriptor structure definitions;
@ -269,9 +271,11 @@ reset procedure etc).
o dwmac100_core: MAC 100 core and dma code;
o dwmac100_dma.c: dma funtions for the MAC chip;
o dwmac1000.h: specific header file for the MAC;
o dwmac_lib.c: generic DMA functions shared among chips
o enh_desc.c: functions for handling enhanced descriptors
o norm_desc.c: functions for handling normal descriptors
o dwmac_lib.c: generic DMA functions shared among chips;
o enh_desc.c: functions for handling enhanced descriptors;
o norm_desc.c: functions for handling normal descriptors;
o chain_mode.c/ring_mode.c:: functions to manage RING/CHAINED modes;
o mmc_core.c/mmc.h: Management MAC Counters;
5) Debug Information
@ -304,7 +308,27 @@ All these are only useful during the developing stage
and should never enabled inside the code for general usage.
In fact, these can generate an huge amount of debug messages.
6) TODO:
6) Energy Efficient Ethernet
Energy Efficient Ethernet(EEE) enables IEEE 802.3 MAC sublayer along
with a family of Physical layer to operate in the Low power Idle(LPI)
mode. The EEE mode supports the IEEE 802.3 MAC operation at 100Mbps,
1000Mbps & 10Gbps.
The LPI mode allows power saving by switching off parts of the
communication device functionality when there is no data to be
transmitted & received. The system on both the side of the link can
disable some functionalities & save power during the period of low-link
utilization. The MAC controls whether the system should enter or exit
the LPI mode & communicate this to PHY.
As soon as the interface is opened, the driver verifies if the EEE can
be supported. This is done by looking at both the DMA HW capability
register and the PHY devices MCD registers.
To enter in Tx LPI mode the driver needs to have a software timer
that enable and disable the LPI mode when there is nothing to be
transmitted.
7) TODO:
o XGMAC is not supported.
o Add the EEE - Energy Efficient Ethernet
o Add the PTP - precision time protocol

7
Documentation/networking/vxge.txt
View File

@ -91,10 +91,3 @@ v) addr_learn_en
virtualization environment.
Valid range: 0,1 (disabled, enabled respectively)
Default: 0
4) Troubleshooting:
-------------------
To resolve an issue with the source code or X3100 series adapter, please collect
the statistics, register dumps using ethool, relevant logs and email them to
support@neterion.com.

33
Documentation/nfc/nfc-hci.txt
View File

@ -178,3 +178,36 @@ ANY_GET_PARAMETER to the reader A gate to get information on the target
that was discovered).
Typically, such an event will be propagated to NFC Core from MSGRXWQ context.
Error management
----------------
Errors that occur synchronously with the execution of an NFC Core request are
simply returned as the execution result of the request. These are easy.
Errors that occur asynchronously (e.g. in a background protocol handling thread)
must be reported such that upper layers don't stay ignorant that something
went wrong below and know that expected events will probably never happen.
Handling of these errors is done as follows:
- driver (pn544) fails to deliver an incoming frame: it stores the error such
that any subsequent call to the driver will result in this error. Then it calls
the standard nfc_shdlc_recv_frame() with a NULL argument to report the problem
above. shdlc stores a EREMOTEIO sticky status, which will trigger SMW to
report above in turn.
- SMW is basically a background thread to handle incoming and outgoing shdlc
frames. This thread will also check the shdlc sticky status and report to HCI
when it discovers it is not able to run anymore because of an unrecoverable
error that happened within shdlc or below. If the problem occurs during shdlc
connection, the error is reported through the connect completion.
- HCI: if an internal HCI error happens (frame is lost), or HCI is reported an
error from a lower layer, HCI will either complete the currently executing
command with that error, or notify NFC Core directly if no command is executing.
- NFC Core: when NFC Core is notified of an error from below and polling is
active, it will send a tag discovered event with an empty tag list to the user
space to let it know that the poll operation will never be able to detect a tag.
If polling is not active and the error was sticky, lower levels will return it
at next invocation.

3
Documentation/sound/alsa/ALSA-Configuration.txt
View File

@ -875,8 +875,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
setup before initializing the codecs. This option is
available only when CONFIG_SND_HDA_PATCH_LOADER=y is set.
See HD-Audio.txt for details.
beep_mode - Selects the beep registration mode (0=off, 1=on, 2=
dynamic registration via mute switch on/off); the default
beep_mode - Selects the beep registration mode (0=off, 1=on); default
value is set via CONFIG_SND_HDA_INPUT_BEEP_MODE kconfig.
[Single (global) options]

13
Documentation/sound/alsa/HD-Audio-Models.txt
View File

@ -15,19 +15,24 @@ ALC260
ALC262
======
N/A
inv-dmic Inverted internal mic workaround
ALC267/268
==========
N/A
inv-dmic Inverted internal mic workaround
ALC269
ALC269/270/275/276/280/282
======
laptop-amic Laptops with analog-mic input
laptop-dmic Laptops with digital-mic input
alc269-dmic Enable ALC269(VA) digital mic workaround
alc271-dmic Enable ALC271X digital mic workaround
inv-dmic Inverted internal mic workaround
lenovo-dock Enables docking station I/O for some Lenovos
ALC662/663/272
==============
mario Chromebook mario model fixup
asus-mode1 ASUS
asus-mode2 ASUS
asus-mode3 ASUS
@ -36,6 +41,7 @@ ALC662/663/272
asus-mode6 ASUS
asus-mode7 ASUS
asus-mode8 ASUS
inv-dmic Inverted internal mic workaround
ALC680
======
@ -46,6 +52,7 @@ ALC882/883/885/888/889
acer-aspire-4930g Acer Aspire 4930G/5930G/6530G/6930G/7730G
acer-aspire-8930g Acer Aspire 8330G/6935G
acer-aspire Acer Aspire others
inv-dmic Inverted internal mic workaround
ALC861/660
==========

2
Documentation/sound/alsa/hdspm.txt
View File

@ -359,4 +359,4 @@ Calling Parameter:
enable_monitor int array (min = 1, max = 8),
"Enable Analog Out on Channel 63/64 by default."
note: here the analog output is enabled (but not routed).
note: here the analog output is enabled (but not routed).

2
Documentation/video4linux/cpia2_overview.txt
View File

@ -35,4 +35,4 @@ the camera. There are three modes for this. Block mode requests a number
of contiguous registers. Random mode reads or writes random registers with
a tuple structure containing address/value pairs. The repeat mode is only
used by VP4 to load a firmware patch. It contains a starting address and
a sequence of bytes to be written into a gpio port.
a sequence of bytes to be written into a gpio port.

2
Documentation/video4linux/stv680.txt
View File

@ -50,4 +50,4 @@ The latest info on this driver can be found at:
http://personal.clt.bellsouth.net/~kjsisson or at
http://stv0680-usb.sourceforge.net
Any questions to me can be send to: kjsisson@bellsouth.net
Any questions to me can be send to: kjsisson@bellsouth.net

34
Documentation/virtual/kvm/api.txt
View File

@ -1946,6 +1946,40 @@ the guest using the specified gsi pin. The irqfd is removed using
the KVM_IRQFD_FLAG_DEASSIGN flag, specifying both kvm_irqfd.fd
and kvm_irqfd.gsi.
4.76 KVM_PPC_ALLOCATE_HTAB
Capability: KVM_CAP_PPC_ALLOC_HTAB
Architectures: powerpc
Type: vm ioctl
Parameters: Pointer to u32 containing hash table order (in/out)
Returns: 0 on success, -1 on error
This requests the host kernel to allocate an MMU hash table for a
guest using the PAPR paravirtualization interface. This only does
anything if the kernel is configured to use the Book 3S HV style of
virtualization. Otherwise the capability doesn't exist and the ioctl
returns an ENOTTY error. The rest of this description assumes Book 3S
HV.
There must be no vcpus running when this ioctl is called; if there
are, it will do nothing and return an EBUSY error.
The parameter is a pointer to a 32-bit unsigned integer variable
containing the order (log base 2) of the desired size of the hash
table, which must be between 18 and 46. On successful return from the
ioctl, it will have been updated with the order of the hash table that
was allocated.
If no hash table has been allocated when any vcpu is asked to run
(with the KVM_RUN ioctl), the host kernel will allocate a
default-sized hash table (16 MB).
If this ioctl is called when a hash table has already been allocated,
the kernel will clear out the existing hash table (zero all HPTEs) and
return the hash table order in the parameter. (If the guest is using
the virtualized real-mode area (VRMA) facility, the kernel will
re-create the VMRA HPTEs on the next KVM_RUN of any vcpu.)
5. The kvm_run structure
------------------------

130
Documentation/virtual/kvm/locking.txt
View File

@ -6,7 +6,129 @@ KVM Lock Overview
(to be written)
2. Reference
2: Exception
------------
Fast page fault:
Fast page fault is the fast path which fixes the guest page fault out of
the mmu-lock on x86. Currently, the page fault can be fast only if the
shadow page table is present and it is caused by write-protect, that means
we just need change the W bit of the spte.
What we use to avoid all the race is the SPTE_HOST_WRITEABLE bit and
SPTE_MMU_WRITEABLE bit on the spte:
- SPTE_HOST_WRITEABLE means the gfn is writable on host.
- SPTE_MMU_WRITEABLE means the gfn is writable on mmu. The bit is set when
the gfn is writable on guest mmu and it is not write-protected by shadow
page write-protection.
On fast page fault path, we will use cmpxchg to atomically set the spte W
bit if spte.SPTE_HOST_WRITEABLE = 1 and spte.SPTE_WRITE_PROTECT = 1, this
is safe because whenever changing these bits can be detected by cmpxchg.
But we need carefully check these cases:
1): The mapping from gfn to pfn
The mapping from gfn to pfn may be changed since we can only ensure the pfn
is not changed during cmpxchg. This is a ABA problem, for example, below case
will happen:
At the beginning:
gpte = gfn1
gfn1 is mapped to pfn1 on host
spte is the shadow page table entry corresponding with gpte and
spte = pfn1
VCPU 0 VCPU0
on fast page fault path:
old_spte = *spte;
pfn1 is swapped out:
spte = 0;
pfn1 is re-alloced for gfn2.
gpte is changed to point to
gfn2 by the guest:
spte = pfn1;
if (cmpxchg(spte, old_spte, old_spte+W)
mark_page_dirty(vcpu->kvm, gfn1)
OOPS!!!
We dirty-log for gfn1, that means gfn2 is lost in dirty-bitmap.
For direct sp, we can easily avoid it since the spte of direct sp is fixed
to gfn. For indirect sp, before we do cmpxchg, we call gfn_to_pfn_atomic()
to pin gfn to pfn, because after gfn_to_pfn_atomic():
- We have held the refcount of pfn that means the pfn can not be freed and
be reused for another gfn.
- The pfn is writable that means it can not be shared between different gfns
by KSM.
Then, we can ensure the dirty bitmaps is correctly set for a gfn.
Currently, to simplify the whole things, we disable fast page fault for
indirect shadow page.
2): Dirty bit tracking
In the origin code, the spte can be fast updated (non-atomically) if the
spte is read-only and the Accessed bit has already been set since the
Accessed bit and Dirty bit can not be lost.
But it is not true after fast page fault since the spte can be marked
writable between reading spte and updating spte. Like below case:
At the beginning:
spte.W = 0
spte.Accessed = 1
VCPU 0 VCPU0
In mmu_spte_clear_track_bits():
old_spte = *spte;
/* 'if' condition is satisfied. */
if (old_spte.Accssed == 1 &&
old_spte.W == 0)
spte = 0ull;
on fast page fault path:
spte.W = 1
memory write on the spte:
spte.Dirty = 1
else
old_spte = xchg(spte, 0ull)
if (old_spte.Accssed == 1)
kvm_set_pfn_accessed(spte.pfn);
if (old_spte.Dirty == 1)
kvm_set_pfn_dirty(spte.pfn);
OOPS!!!
The Dirty bit is lost in this case.
In order to avoid this kind of issue, we always treat the spte as "volatile"
if it can be updated out of mmu-lock, see spte_has_volatile_bits(), it means,
the spte is always atomicly updated in this case.
3): flush tlbs due to spte updated
If the spte is updated from writable to readonly, we should flush all TLBs,
otherwise rmap_write_protect will find a read-only spte, even though the
writable spte might be cached on a CPU's TLB.
As mentioned before, the spte can be updated to writable out of mmu-lock on
fast page fault path, in order to easily audit the path, we see if TLBs need
be flushed caused by this reason in mmu_spte_update() since this is a common
function to update spte (present -> present).
Since the spte is "volatile" if it can be updated out of mmu-lock, we always
atomicly update the spte, the race caused by fast page fault can be avoided,
See the comments in spte_has_volatile_bits() and mmu_spte_update().
3. Reference
------------
Name: kvm_lock
@ -23,3 +145,9 @@ Arch: x86
Protects: - kvm_arch::{last_tsc_write,last_tsc_nsec,last_tsc_offset}
- tsc offset in vmcb
Comment: 'raw' because updating the tsc offsets must not be preempted.
Name: kvm->mmu_lock
Type: spinlock_t
Arch: any
Protects: -shadow page/shadow tlb entry
Comment: it is a spinlock since it is used in mmu notifier.

33
Documentation/virtual/kvm/msr.txt
View File

@ -223,3 +223,36 @@ MSR_KVM_STEAL_TIME: 0x4b564d03
steal: the amount of time in which this vCPU did not run, in
nanoseconds. Time during which the vcpu is idle, will not be
reported as steal time.
MSR_KVM_EOI_EN: 0x4b564d04
data: Bit 0 is 1 when PV end of interrupt is enabled on the vcpu; 0
when disabled. Bit 1 is reserved and must be zero. When PV end of
interrupt is enabled (bit 0 set), bits 63-2 hold a 4-byte aligned
physical address of a 4 byte memory area which must be in guest RAM and
must be zeroed.
The first, least significant bit of 4 byte memory location will be
written to by the hypervisor, typically at the time of interrupt
injection. Value of 1 means that guest can skip writing EOI to the apic
(using MSR or MMIO write); instead, it is sufficient to signal
EOI by clearing the bit in guest memory - this location will
later be polled by the hypervisor.
Value of 0 means that the EOI write is required.
It is always safe for the guest to ignore the optimization and perform
the APIC EOI write anyway.
Hypervisor is guaranteed to only modify this least
significant bit while in the current VCPU context, this means that
guest does not need to use either lock prefix or memory ordering
primitives to synchronise with the hypervisor.
However, hypervisor can set and clear this memory bit at any time:
therefore to make sure hypervisor does not interrupt the
guest and clear the least significant bit in the memory area
in the window between guest testing it to detect
whether it can skip EOI apic write and between guest
clearing it to signal EOI to the hypervisor,
guest must both read the least significant bit in the memory area and
clear it using a single CPU instruction, such as test and clear, or
compare and exchange.

2
Documentation/virtual/kvm/ppc-pv.txt
View File

@ -109,8 +109,6 @@ The following bits are safe to be set inside the guest:
MSR_EE
MSR_RI
MSR_CR
MSR_ME
If any other bit changes in the MSR, please still use mtmsr(d).

4
Documentation/vm/frontswap.txt
View File

@ -25,7 +25,7 @@ with the specified swap device number (aka "type"). A "store" will
copy the page to transcendent memory and associate it with the type and
offset associated with the page. A "load" will copy the page, if found,
from transcendent memory into kernel memory, but will NOT remove the page
from from transcendent memory. An "invalidate_page" will remove the page
from transcendent memory. An "invalidate_page" will remove the page
from transcendent memory and an "invalidate_area" will remove ALL pages
associated with the swap type (e.g., like swapoff) and notify the "device"
to refuse further stores with that swap type.
@ -99,7 +99,7 @@ server configured with a large amount of RAM... without pre-configuring
how much of the RAM is available for each of the clients!
In the virtual case, the whole point of virtualization is to statistically
multiplex physical resources acrosst the varying demands of multiple
multiplex physical resources across the varying demands of multiple
virtual machines. This is really hard to do with RAM and efforts to do
it well with no kernel changes have essentially failed (except in some
well-publicized special-case workloads).

80
MAINTAINERS
View File

@ -329,7 +329,7 @@ F: drivers/hwmon/adm1029.c
ADM8211 WIRELESS DRIVER
L: linux-wireless@vger.kernel.org
W: http://linuxwireless.org/
W: http://wireless.kernel.org/
S: Orphan
F: drivers/net/wireless/adm8211.*
@ -1441,7 +1441,7 @@ B43 WIRELESS DRIVER
M: Stefano Brivio <stefano.brivio@polimi.it>
L: linux-wireless@vger.kernel.org
L: b43-dev@lists.infradead.org
W: http://linuxwireless.org/en/users/Drivers/b43
W: http://wireless.kernel.org/en/users/Drivers/b43
S: Maintained
F: drivers/net/wireless/b43/
@ -1450,7 +1450,7 @@ M: Larry Finger <Larry.Finger@lwfinger.net>
M: Stefano Brivio <stefano.brivio@polimi.it>
L: linux-wireless@vger.kernel.org
L: b43-dev@lists.infradead.org
W: http://linuxwireless.org/en/users/Drivers/b43
W: http://wireless.kernel.org/en/users/Drivers/b43
S: Maintained
F: drivers/net/wireless/b43legacy/
@ -1613,6 +1613,7 @@ M: Arend van Spriel <arend@broadcom.com>
M: Franky (Zhenhui) Lin <frankyl@broadcom.com>
M: Kan Yan <kanyan@broadcom.com>
L: linux-wireless@vger.kernel.org
L: brcm80211-dev-list@broadcom.com
S: Supported
F: drivers/net/wireless/brcm80211/
@ -3679,14 +3680,6 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi.git
S: Supported
F: drivers/net/wireless/iwlwifi/
INTEL WIRELESS MULTICOMM 3200 WIFI (iwmc3200wifi)
M: Samuel Ortiz <samuel.ortiz@intel.com>
M: Intel Linux Wireless <ilw@linux.intel.com>
L: linux-wireless@vger.kernel.org
S: Supported
W: http://wireless.kernel.org/en/users/Drivers/iwmc3200wifi
F: drivers/net/wireless/iwmc3200wifi/
INTEL MANAGEMENT ENGINE (mei)
M: Tomas Winkler <tomas.winkler@intel.com>
L: linux-kernel@vger.kernel.org
@ -4009,8 +4002,8 @@ F: arch/ia64/include/asm/kvm*
F: arch/ia64/kvm/
KERNEL VIRTUAL MACHINE for s390 (KVM/s390)
M: Carsten Otte <cotte@de.ibm.com>
M: Christian Borntraeger <borntraeger@de.ibm.com>
M: Cornelia Huck <cornelia.huck@de.ibm.com>
M: linux390@de.ibm.com
L: linux-s390@vger.kernel.org
W: http://www.ibm.com/developerworks/linux/linux390/
@ -4370,7 +4363,7 @@ F: arch/m68k/hp300/
MAC80211
M: Johannes Berg <johannes@sipsolutions.net>
L: linux-wireless@vger.kernel.org
W: http://linuxwireless.org/
W: http://wireless.kernel.org/
T: git git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git
S: Maintained
@ -4382,7 +4375,7 @@ MAC80211 PID RATE CONTROL
M: Stefano Brivio <stefano.brivio@polimi.it>
M: Mattias Nissler <mattias.nissler@gmx.de>
L: linux-wireless@vger.kernel.org
W: http://linuxwireless.org/en/developers/Documentation/mac80211/RateControl/PID
W: http://wireless.kernel.org/en/developers/Documentation/mac80211/RateControl/PID
T: git git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git
S: Maintained
@ -4611,7 +4604,6 @@ S: Maintained
F: drivers/usb/musb/
MYRICOM MYRI-10G 10GbE DRIVER (MYRI10GE)
M: Jon Mason <mason@myri.com>
M: Andrew Gallatin <gallatin@myri.com>
L: netdev@vger.kernel.org
W: http://www.myri.com/scs/download-Myri10GE.html
@ -4656,8 +4648,6 @@ F: net/sched/sch_netem.c
NETERION 10GbE DRIVERS (s2io/vxge)
M: Jon Mason <jdmason@kudzu.us>
L: netdev@vger.kernel.org
W: http://trac.neterion.com/cgi-bin/trac.cgi/wiki/Linux?Anonymous
W: http://trac.neterion.com/cgi-bin/trac.cgi/wiki/X3100Linux?Anonymous
S: Supported
F: Documentation/networking/s2io.txt
F: Documentation/networking/vxge.txt
@ -5068,7 +5058,7 @@ F: fs/ocfs2/
ORINOCO DRIVER
L: linux-wireless@vger.kernel.org
W: http://linuxwireless.org/en/users/Drivers/orinoco
W: http://wireless.kernel.org/en/users/Drivers/orinoco
W: http://www.nongnu.org/orinoco/
S: Orphan
F: drivers/net/wireless/orinoco/
@ -5220,7 +5210,7 @@ PCI SUBSYSTEM
M: Bjorn Helgaas <bhelgaas@google.com>
L: linux-pci@vger.kernel.org
Q: http://patchwork.ozlabs.org/project/linux-pci/list/
T: git git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/linux.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git
S: Supported
F: Documentation/PCI/
F: drivers/pci/
@ -5772,7 +5762,7 @@ F: net/rose/
RTL8180 WIRELESS DRIVER
M: "John W. Linville" <linville@tuxdriver.com>
L: linux-wireless@vger.kernel.org
W: http://linuxwireless.org/
W: http://wireless.kernel.org/
T: git git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.git
S: Maintained
F: drivers/net/wireless/rtl818x/rtl8180/
@ -5782,7 +5772,7 @@ M: Herton Ronaldo Krzesinski <herton@canonical.com>
M: Hin-Tak Leung <htl10@users.sourceforge.net>
M: Larry Finger <Larry.Finger@lwfinger.net>
L: linux-wireless@vger.kernel.org
W: http://linuxwireless.org/
W: http://wireless.kernel.org/
T: git git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.git
S: Maintained
F: drivers/net/wireless/rtl818x/rtl8187/
@ -5791,7 +5781,7 @@ RTL8192CE WIRELESS DRIVER
M: Larry Finger <Larry.Finger@lwfinger.net>
M: Chaoming Li <chaoming_li@realsil.com.cn>
L: linux-wireless@vger.kernel.org
W: http://linuxwireless.org/
W: http://wireless.kernel.org/
T: git git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.git
S: Maintained
F: drivers/net/wireless/rtlwifi/
@ -6230,6 +6220,15 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
F: include/linux/srcu*
F: kernel/srcu*
SMACK SECURITY MODULE
M: Casey Schaufler <casey@schaufler-ca.com>
L: linux-security-module@vger.kernel.org
W: http://schaufler-ca.com
T: git git://git.gitorious.org/smack-next/kernel.git
S: Maintained
F: Documentation/security/Smack.txt
F: security/smack/
SMC91x ETHERNET DRIVER
M: Nicolas Pitre <nico@fluxnic.net>
S: Odd Fixes
@ -6243,9 +6242,9 @@ F: Documentation/hwmon/smm665
F: drivers/hwmon/smm665.c
SMSC EMC2103 HARDWARE MONITOR DRIVER
M: Steve Glendinning <steve.glendinning@smsc.com>
M: Steve Glendinning <steve.glendinning@shawell.net>
L: lm-sensors@lm-sensors.org
S: Supported
S: Maintained
F: Documentation/hwmon/emc2103
F: drivers/hwmon/emc2103.c
@ -6264,22 +6263,22 @@ F: Documentation/hwmon/smsc47b397
F: drivers/hwmon/smsc47b397.c
SMSC911x ETHERNET DRIVER
M: Steve Glendinning <steve.glendinning@smsc.com>
M: Steve Glendinning <steve.glendinning@shawell.net>
L: netdev@vger.kernel.org
S: Supported
S: Maintained
F: include/linux/smsc911x.h
F: drivers/net/ethernet/smsc/smsc911x.*
SMSC9420 PCI ETHERNET DRIVER
M: Steve Glendinning <steve.glendinning@smsc.com>
M: Steve Glendinning <steve.glendinning@shawell.net>
L: netdev@vger.kernel.org
S: Supported
S: Maintained
F: drivers/net/ethernet/smsc/smsc9420.*
SMSC UFX6000 and UFX7000 USB to VGA DRIVER
M: Steve Glendinning <steve.glendinning@smsc.com>
M: Steve Glendinning <steve.glendinning@shawell.net>
L: linux-fbdev@vger.kernel.org
S: Supported
S: Maintained
F: drivers/video/smscufx.c
SN-IA64 (Itanium) SUB-PLATFORM
@ -6766,9 +6765,11 @@ F: include/linux/tifm.h
TI LM49xxx FAMILY ASoC CODEC DRIVERS
M: M R Swami Reddy <mr.swami.reddy@ti.com>
M: Vishwas A Deshpande <vishwas.a.deshpande@ti.com>
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
S: Maintained
F: sound/soc/codecs/lm49453*
F: sound/soc/codecs/isabelle*
TI TWL4030 SERIES SOC CODEC DRIVER
M: Peter Ujfalusi <peter.ujfalusi@ti.com>
@ -6862,10 +6863,11 @@ F: include/linux/shmem_fs.h
F: mm/shmem.c
TPM DEVICE DRIVER
M: Debora Velarde <debora@linux.vnet.ibm.com>
M: Rajiv Andrade <srajiv@linux.vnet.ibm.com>
M: Kent Yoder <key@linux.vnet.ibm.com>
M: Rajiv Andrade <mail@srajiv.net>
W: http://tpmdd.sourceforge.net
M: Marcel Selhorst <m.selhorst@sirrix.com>
M: Marcel Selhorst <tpmdd@selhorst.net>
M: Sirrix AG <tpmdd@sirrix.com>
W: http://www.sirrix.com
L: tpmdd-devel@lists.sourceforge.net (moderated for non-subscribers)
S: Maintained
@ -6965,6 +6967,13 @@ S: Maintained
F: Documentation/filesystems/ufs.txt
F: fs/ufs/
UHID USERSPACE HID IO DRIVER:
M: David Herrmann <dh.herrmann@googlemail.com>
L: linux-input@vger.kernel.org
S: Maintained
F: drivers/hid/uhid.c
F: include/linux/uhid.h
ULTRA-WIDEBAND (UWB) SUBSYSTEM:
L: linux-usb@vger.kernel.org
S: Orphan
@ -7225,9 +7234,9 @@ S: Supported
F: drivers/usb/serial/whiteheat*
USB SMSC95XX ETHERNET DRIVER
M: Steve Glendinning <steve.glendinning@smsc.com>
M: Steve Glendinning <steve.glendinning@shawell.net>
L: netdev@vger.kernel.org
S: Supported
S: Maintained
F: drivers/net/usb/smsc95xx.*
USB SN9C1xx DRIVER
@ -7596,6 +7605,7 @@ W: http://opensource.wolfsonmicro.com/content/linux-drivers-wolfson-devices
S: Supported
F: Documentation/hwmon/wm83??
F: arch/arm/mach-s3c64xx/mach-crag6410*
F: drivers/clk/clk-wm83*.c
F: drivers/leds/leds-wm83*.c
F: drivers/hwmon/wm83??-hwmon.c
F: drivers/input/misc/wm831x-on.c

17
arch/alpha/kernel/pci.c
View File

@ -59,15 +59,13 @@ struct pci_controller *pci_isa_hose;
* Quirks.
*/
static void __init
quirk_isa_bridge(struct pci_dev *dev)
static void __devinit quirk_isa_bridge(struct pci_dev *dev)
{
dev->class = PCI_CLASS_BRIDGE_ISA << 8;
}
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82378, quirk_isa_bridge);
static void __init
quirk_cypress(struct pci_dev *dev)
static void __devinit quirk_cypress(struct pci_dev *dev)
{
/* The Notorious Cy82C693 chip. */
@ -106,8 +104,7 @@ quirk_cypress(struct pci_dev *dev)
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_CONTAQ, PCI_DEVICE_ID_CONTAQ_82C693, quirk_cypress);
/* Called for each device after PCI setup is done. */
static void __init
pcibios_fixup_final(struct pci_dev *dev)
static void __devinit pcibios_fixup_final(struct pci_dev *dev)
{
unsigned int class = dev->class >> 8;
@ -198,12 +195,6 @@ pcibios_init(void)
subsys_initcall(pcibios_init);
char * __devinit
pcibios_setup(char *str)
{
return str;
}
#ifdef ALPHA_RESTORE_SRM_SETUP
static struct pdev_srm_saved_conf *srm_saved_configs;
@ -359,7 +350,7 @@ common_init_pci(void)
hose, &resources);
hose->bus = bus;
hose->need_domain_info = need_domain_info;
next_busno = bus->subordinate + 1;
next_busno = bus->busn_res.end + 1;
/* Don't allow 8-bit bus number overflow inside the hose -
reserve some space for bridges. */
if (next_busno > 224) {

8
arch/arm/Kconfig
View File

@ -273,8 +273,8 @@ config ARCH_INTEGRATOR
bool "ARM Ltd. Integrator family"
select ARM_AMBA
select ARCH_HAS_CPUFREQ
select CLKDEV_LOOKUP
select HAVE_MACH_CLKDEV
select COMMON_CLK
select CLK_VERSATILE
select HAVE_TCM
select ICST
select GENERIC_CLOCKEVENTS
@ -336,6 +336,7 @@ config ARCH_VEXPRESS
select ICST
select NO_IOPORT
select PLAT_VERSATILE
select PLAT_VERSATILE_CLOCK
select PLAT_VERSATILE_CLCD
select REGULATOR_FIXED_VOLTAGE if REGULATOR
help
@ -372,6 +373,7 @@ config ARCH_HIGHBANK
select ARM_TIMER_SP804
select CACHE_L2X0
select CLKDEV_LOOKUP
select COMMON_CLK
select CPU_V7
select GENERIC_CLOCKEVENTS
select HAVE_ARM_SCU
@ -929,7 +931,7 @@ config ARCH_U300
select ARM_VIC
select GENERIC_CLOCKEVENTS
select CLKDEV_LOOKUP
select HAVE_MACH_CLKDEV
select COMMON_CLK
select GENERIC_GPIO
select ARCH_REQUIRE_GPIOLIB
help

91
arch/arm/boot/dts/highbank.dts
View File

@ -1,5 +1,5 @@
/*
* Copyright 2011 Calxeda, Inc.
* Copyright 2011-2012 Calxeda, Inc.
*
* This program is free software; you can redistribute it and/or modify it
* under the terms and conditions of the GNU General Public License,
@ -24,6 +24,7 @@
compatible = "calxeda,highbank";
#address-cells = <1>;
#size-cells = <1>;
clock-ranges;
cpus {
#address-cells = <1>;
@ -33,24 +34,32 @@
compatible = "arm,cortex-a9";
reg = <0>;
next-level-cache = <&L2>;
clocks = <&a9pll>;
clock-names = "cpu";
};
cpu@1 {
compatible = "arm,cortex-a9";
reg = <1>;
next-level-cache = <&L2>;
clocks = <&a9pll>;
clock-names = "cpu";
};
cpu@2 {
compatible = "arm,cortex-a9";
reg = <2>;
next-level-cache = <&L2>;
clocks = <&a9pll>;
clock-names = "cpu";
};
cpu@3 {
compatible = "arm,cortex-a9";
reg = <3>;
next-level-cache = <&L2>;
clocks = <&a9pll>;
clock-names = "cpu";
};
};
@ -75,12 +84,14 @@
compatible = "arm,cortex-a9-twd-timer";
reg = <0xfff10600 0x20>;
interrupts = <1 13 0xf01>;
clocks = <&a9periphclk>;
};
watchdog@fff10620 {
compatible = "arm,cortex-a9-twd-wdt";
reg = <0xfff10620 0x20>;
interrupts = <1 14 0xf01>;
clocks = <&a9periphclk>;
};
intc: interrupt-controller@fff11000 {
@ -116,12 +127,15 @@
compatible = "calxeda,hb-sdhci";
reg = <0xffe0e000 0x1000>;
interrupts = <0 90 4>;
clocks = <&eclk>;
};
ipc@fff20000 {
compatible = "arm,pl320", "arm,primecell";
reg = <0xfff20000 0x1000>;
interrupts = <0 7 4>;
clocks = <&pclk>;
clock-names = "apb_pclk";
};
gpioe: gpio@fff30000 {
@ -130,6 +144,8 @@
gpio-controller;
reg = <0xfff30000 0x1000>;
interrupts = <0 14 4>;
clocks = <&pclk>;
clock-names = "apb_pclk";
};
gpiof: gpio@fff31000 {
@ -138,6 +154,8 @@
gpio-controller;
reg = <0xfff31000 0x1000>;
interrupts = <0 15 4>;
clocks = <&pclk>;
clock-names = "apb_pclk";
};
gpiog: gpio@fff32000 {
@ -146,6 +164,8 @@
gpio-controller;
reg = <0xfff32000 0x1000>;
interrupts = <0 16 4>;
clocks = <&pclk>;
clock-names = "apb_pclk";
};
gpioh: gpio@fff33000 {
@ -154,24 +174,32 @@
gpio-controller;
reg = <0xfff33000 0x1000>;
interrupts = <0 17 4>;
clocks = <&pclk>;
clock-names = "apb_pclk";
};
timer {
compatible = "arm,sp804", "arm,primecell";
reg = <0xfff34000 0x1000>;
interrupts = <0 18 4>;
clocks = <&pclk>;
clock-names = "apb_pclk";
};
rtc@fff35000 {
compatible = "arm,pl031", "arm,primecell";
reg = <0xfff35000 0x1000>;
interrupts = <0 19 4>;
clocks = <&pclk>;
clock-names = "apb_pclk";
};
serial@fff36000 {
compatible = "arm,pl011", "arm,primecell";
reg = <0xfff36000 0x1000>;
interrupts = <0 20 4>;
clocks = <&pclk>;
clock-names = "apb_pclk";
};
smic@fff3a000 {
@ -186,12 +214,73 @@
sregs@fff3c000 {
compatible = "calxeda,hb-sregs";
reg = <0xfff3c000 0x1000>;
clocks {
#address-cells = <1>;
#size-cells = <0>;
osc: oscillator {
#clock-cells = <0>;
compatible = "fixed-clock";
clock-frequency = <33333000>;
};
ddrpll: ddrpll {
#clock-cells = <0>;
compatible = "calxeda,hb-pll-clock";
clocks = <&osc>;
reg = <0x108>;
};
a9pll: a9pll {
#clock-cells = <0>;
compatible = "calxeda,hb-pll-clock";
clocks = <&osc>;
reg = <0x100>;
};
a9periphclk: a9periphclk {
#clock-cells = <0>;
compatible = "calxeda,hb-a9periph-clock";
clocks = <&a9pll>;
reg = <0x104>;
};
a9bclk: a9bclk {
#clock-cells = <0>;
compatible = "calxeda,hb-a9bus-clock";
clocks = <&a9pll>;
reg = <0x104>;
};
emmcpll: emmcpll {
#clock-cells = <0>;
compatible = "calxeda,hb-pll-clock";
clocks = <&osc>;
reg = <0x10C>;
};
eclk: eclk {
#clock-cells = <0>;
compatible = "calxeda,hb-emmc-clock";
clocks = <&emmcpll>;
reg = <0x114>;
};
pclk: pclk {
#clock-cells = <0>;
compatible = "fixed-clock";
clock-frequency = <150000000>;
};
};
};
dma@fff3d000 {
compatible = "arm,pl330", "arm,primecell";
reg = <0xfff3d000 0x1000>;
interrupts = <0 92 4>;
clocks = <&pclk>;
clock-names = "apb_pclk";
};
ethernet@fff50000 {

4
arch/arm/kernel/bios32.c
View File

@ -253,7 +253,7 @@ static void __devinit pci_fixup_cy82c693(struct pci_dev *dev)
}
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_CONTAQ, PCI_DEVICE_ID_CONTAQ_82C693, pci_fixup_cy82c693);
static void __init pci_fixup_it8152(struct pci_dev *dev)
static void __devinit pci_fixup_it8152(struct pci_dev *dev)
{
int i;
/* fixup for ITE 8152 devices */
@ -461,7 +461,7 @@ static void __init pcibios_init_hw(struct hw_pci *hw, struct list_head *head)
if (!sys->bus)
panic("PCI: unable to scan bus!");
busnr = sys->bus->subordinate + 1;
busnr = sys->bus->busn_res.end + 1;
list_add(&sys->node, head);
} else {

6
arch/arm/mach-davinci/Kconfig
View File

@ -62,7 +62,6 @@ config MACH_DAVINCI_EVM
bool "TI DM644x EVM"
default ARCH_DAVINCI_DM644x
depends on ARCH_DAVINCI_DM644x
select MISC_DEVICES
select EEPROM_AT24
select I2C
help
@ -72,7 +71,6 @@ config MACH_DAVINCI_EVM
config MACH_SFFSDR
bool "Lyrtech SFFSDR"
depends on ARCH_DAVINCI_DM644x
select MISC_DEVICES
select EEPROM_AT24
select I2C
help
@ -106,7 +104,6 @@ config MACH_DAVINCI_DM6467_EVM
default ARCH_DAVINCI_DM646x
depends on ARCH_DAVINCI_DM646x
select MACH_DAVINCI_DM6467TEVM
select MISC_DEVICES
select EEPROM_AT24
select I2C
help
@ -120,7 +117,6 @@ config MACH_DAVINCI_DM365_EVM
bool "TI DM365 EVM"
default ARCH_DAVINCI_DM365
depends on ARCH_DAVINCI_DM365
select MISC_DEVICES
select EEPROM_AT24
select I2C
help
@ -132,7 +128,6 @@ config MACH_DAVINCI_DA830_EVM
default ARCH_DAVINCI_DA830
depends on ARCH_DAVINCI_DA830
select GPIO_PCF857X
select MISC_DEVICES
select EEPROM_AT24
select I2C
help
@ -219,7 +214,6 @@ config MACH_TNETV107X
config MACH_MITYOMAPL138
bool "Critical Link MityDSP-L138/MityARM-1808 SoM"
depends on ARCH_DAVINCI_DA850
select MISC_DEVICES
select EEPROM_AT24
select I2C
help

2
arch/arm/mach-highbank/Makefile
View File

@ -1,4 +1,4 @@
obj-y := clock.o highbank.o system.o smc.o
obj-y := highbank.o system.o smc.o
plus_sec := $(call as-instr,.arch_extension sec,+sec)
AFLAGS_smc.o :=-Wa,-march=armv7-a$(plus_sec)

62
arch/arm/mach-highbank/clock.c
View File

@ -1,62 +0,0 @@
/*
* Copyright 2011 Calxeda, Inc.
*
* This program is free software; you can redistribute it and/or modify it
* under the terms and conditions of the GNU General Public License,
* version 2, as published by the Free Software Foundation.
*
* This program is distributed in the hope it will be useful, but WITHOUT
* ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
* FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
* more details.
*
* You should have received a copy of the GNU General Public License along with
* this program. If not, see <http://www.gnu.org/licenses/>.
*/
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/errno.h>
#include <linux/clk.h>
#include <linux/clkdev.h>
struct clk {
unsigned long rate;
};
int clk_enable(struct clk *clk)
{
return 0;
}
void clk_disable(struct clk *clk)
{}
unsigned long clk_get_rate(struct clk *clk)
{
return clk->rate;
}
long clk_round_rate(struct clk *clk, unsigned long rate)
{
return clk->rate;
}
int clk_set_rate(struct clk *clk, unsigned long rate)
{
return 0;
}
static struct clk eclk = { .rate = 200000000 };
static struct clk pclk = { .rate = 150000000 };
static struct clk_lookup lookups[] = {
{ .clk = &pclk, .con_id = "apb_pclk", },
{ .clk = &pclk, .dev_id = "sp804", },
{ .clk = &eclk, .dev_id = "ffe0e000.sdhci", },
{ .clk = &pclk, .dev_id = "fff36000.serial", },
};
void __init highbank_clocks_init(void)
{
clkdev_add_table(lookups, ARRAY_SIZE(lookups));
}

7
arch/arm/mach-highbank/highbank.c
View File

@ -105,6 +105,11 @@ static void __init highbank_init_irq(void)
#endif
}
static struct clk_lookup lookup = {
.dev_id = "sp804",
.con_id = NULL,
};
static void __init highbank_timer_init(void)
{
int irq;
@ -122,6 +127,8 @@ static void __init highbank_timer_init(void)
irq = irq_of_parse_and_map(np, 0);
highbank_clocks_init();
lookup.clk = of_clk_get(np, 0);
clkdev_add(&lookup);
sp804_clocksource_and_sched_clock_init(timer_base + 0x20, "timer1");
sp804_clockevents_init(timer_base, irq, "timer0");

55
arch/arm/mach-integrator/core.c
View File

@ -21,7 +21,6 @@
#include <linux/amba/bus.h>
#include <linux/amba/serial.h>
#include <linux/io.h>
#include <linux/clkdev.h>
#include <mach/hardware.h>
#include <mach/platform.h>
@ -41,17 +40,17 @@ static struct amba_pl010_data integrator_uart_data;
#define KMI0_IRQ { IRQ_KMIINT0 }
#define KMI1_IRQ { IRQ_KMIINT1 }
static AMBA_APB_DEVICE(rtc, "mb:15", 0,
static AMBA_APB_DEVICE(rtc, "rtc", 0,
INTEGRATOR_RTC_BASE, INTEGRATOR_RTC_IRQ, NULL);
static AMBA_APB_DEVICE(uart0, "mb:16", 0,
static AMBA_APB_DEVICE(uart0, "uart0", 0,
INTEGRATOR_UART0_BASE, INTEGRATOR_UART0_IRQ, &integrator_uart_data);
static AMBA_APB_DEVICE(uart1, "mb:17", 0,
static AMBA_APB_DEVICE(uart1, "uart1", 0,
INTEGRATOR_UART1_BASE, INTEGRATOR_UART1_IRQ, &integrator_uart_data);
static AMBA_APB_DEVICE(kmi0, "mb:18", 0, KMI0_BASE, KMI0_IRQ, NULL);
static AMBA_APB_DEVICE(kmi1, "mb:19", 0, KMI1_BASE, KMI1_IRQ, NULL);
static AMBA_APB_DEVICE(kmi0, "kmi0", 0, KMI0_BASE, KMI0_IRQ, NULL);
static AMBA_APB_DEVICE(kmi1, "kmi1", 0, KMI1_BASE, KMI1_IRQ, NULL);
static struct amba_device *amba_devs[] __initdata = {
&rtc_device,
@ -61,50 +60,6 @@ static struct amba_device *amba_devs[] __initdata = {
&kmi1_device,
};
/*
* These are fixed clocks.
*/
static struct clk clk24mhz = {
.rate = 24000000,
};
static struct clk uartclk = {
.rate = 14745600,
};
static struct clk dummy_apb_pclk;
static struct clk_lookup lookups[] = {
{ /* Bus clock */
.con_id = "apb_pclk",
.clk = &dummy_apb_pclk,
}, {
/* Integrator/AP timer frequency */
.dev_id = "ap_timer",
.clk = &clk24mhz,
}, { /* UART0 */
.dev_id = "mb:16",
.clk = &uartclk,
}, { /* UART1 */
.dev_id = "mb:17",
.clk = &uartclk,
}, { /* KMI0 */
.dev_id = "mb:18",
.clk = &clk24mhz,
}, { /* KMI1 */
.dev_id = "mb:19",
.clk = &clk24mhz,
}, { /* MMCI - IntegratorCP */
.dev_id = "mb:1c",
.clk = &uartclk,
}
};
void __init integrator_init_early(void)
{
clkdev_add_table(lookups, ARRAY_SIZE(lookups));
}
static int __init integrator_init(void)
{
int i;

26
arch/arm/mach-integrator/include/mach/clkdev.h
View File

@ -1,26 +0,0 @@
#ifndef __ASM_MACH_CLKDEV_H
#define __ASM_MACH_CLKDEV_H
#include <linux/module.h>
#include <plat/clock.h>
struct clk {
unsigned long rate;
const struct clk_ops *ops;
struct module *owner;
const struct icst_params *params;
void __iomem *vcoreg;
void *data;
};
static inline int __clk_get(struct clk *clk)
{
return try_module_get(clk->owner);
}
static inline void __clk_put(struct clk *clk)
{
module_put(clk->owner);
}
#endif

8
arch/arm/mach-integrator/integrator_ap.c
View File

@ -33,6 +33,7 @@
#include <linux/io.h>
#include <linux/mtd/physmap.h>
#include <linux/clk.h>
#include <linux/platform_data/clk-integrator.h>
#include <video/vga.h>
#include <mach/hardware.h>
@ -174,6 +175,7 @@ static void __init ap_init_irq(void)
fpga_irq_init(VA_IC_BASE, "SC", IRQ_PIC_START,
-1, INTEGRATOR_SC_VALID_INT, NULL);
integrator_clk_init(false);
}
#ifdef CONFIG_PM
@ -440,6 +442,10 @@ static void integrator_clockevent_init(unsigned long inrate)
0xffffU);
}
void __init ap_init_early(void)
{
}
/*
* Set up timer(s).
*/
@ -471,7 +477,7 @@ MACHINE_START(INTEGRATOR, "ARM-Integrator")
.reserve = integrator_reserve,
.map_io = ap_map_io,
.nr_irqs = NR_IRQS_INTEGRATOR_AP,
.init_early = integrator_init_early,
.init_early = ap_init_early,
.init_irq = ap_init_irq,
.handle_irq = fpga_handle_irq,
.timer = &ap_timer,

69
arch/arm/mach-integrator/integrator_cp.c
View File

@ -21,8 +21,8 @@
#include <linux/amba/mmci.h>
#include <linux/io.h>
#include <linux/gfp.h>
#include <linux/clkdev.h>
#include <linux/mtd/physmap.h>
#include <linux/platform_data/clk-integrator.h>
#include <mach/hardware.h>
#include <mach/platform.h>
@ -171,64 +171,9 @@ static void __init intcp_init_irq(void)
fpga_irq_init(INTCP_VA_SIC_BASE, "SIC", IRQ_SIC_START,
IRQ_CP_CPPLDINT, sic_mask, NULL);
integrator_clk_init(true);
}
/*
* Clock handling
*/
#define CM_LOCK (__io_address(INTEGRATOR_HDR_BASE)+INTEGRATOR_HDR_LOCK_OFFSET)
#define CM_AUXOSC (__io_address(INTEGRATOR_HDR_BASE)+0x1c)
static const struct icst_params cp_auxvco_params = {
.ref = 24000000,
.vco_max = ICST525_VCO_MAX_5V,
.vco_min = ICST525_VCO_MIN,
.vd_min = 8,
.vd_max = 263,
.rd_min = 3,
.rd_max = 65,
.s2div = icst525_s2div,
.idx2s = icst525_idx2s,
};
static void cp_auxvco_set(struct clk *clk, struct icst_vco vco)
{
u32 val;
val = readl(clk->vcoreg) & ~0x7ffff;
val |= vco.v | (vco.r << 9) | (vco.s << 16);
writel(0xa05f, CM_LOCK);
writel(val, clk->vcoreg);
writel(0, CM_LOCK);
}
static const struct clk_ops cp_auxclk_ops = {
.round = icst_clk_round,
.set = icst_clk_set,
.setvco = cp_auxvco_set,
};
static struct clk cp_auxclk = {
.ops = &cp_auxclk_ops,
.params = &cp_auxvco_params,
.vcoreg = CM_AUXOSC,
};
static struct clk sp804_clk = {
.rate = 1000000,
};
static struct clk_lookup cp_lookups[] = {
{ /* CLCD */
.dev_id = "mb:c0",
.clk = &cp_auxclk,
}, { /* SP804 timers */
.dev_id = "sp804",
.clk = &sp804_clk,
},
};
/*
* Flash handling.
*/
@ -336,10 +281,10 @@ static struct mmci_platform_data mmc_data = {
#define INTEGRATOR_CP_MMC_IRQS { IRQ_CP_MMCIINT0, IRQ_CP_MMCIINT1 }
#define INTEGRATOR_CP_AACI_IRQS { IRQ_CP_AACIINT }
static AMBA_APB_DEVICE(mmc, "mb:1c", 0, INTEGRATOR_CP_MMC_BASE,
static AMBA_APB_DEVICE(mmc, "mmci", 0, INTEGRATOR_CP_MMC_BASE,
INTEGRATOR_CP_MMC_IRQS, &mmc_data);
static AMBA_APB_DEVICE(aaci, "mb:1d", 0, INTEGRATOR_CP_AACI_BASE,
static AMBA_APB_DEVICE(aaci, "aaci", 0, INTEGRATOR_CP_AACI_BASE,
INTEGRATOR_CP_AACI_IRQS, NULL);
@ -393,7 +338,7 @@ static struct clcd_board clcd_data = {
.remove = versatile_clcd_remove_dma,
};
static AMBA_AHB_DEVICE(clcd, "mb:c0", 0, INTCP_PA_CLCD_BASE,
static AMBA_AHB_DEVICE(clcd, "clcd", 0, INTCP_PA_CLCD_BASE,
{ IRQ_CP_CLCDCINT }, &clcd_data);
static struct amba_device *amba_devs[] __initdata = {
@ -406,10 +351,6 @@ static struct amba_device *amba_devs[] __initdata = {
static void __init intcp_init_early(void)
{
clkdev_add_table(cp_lookups, ARRAY_SIZE(cp_lookups));
integrator_init_early();
#ifdef CONFIG_PLAT_VERSATILE_SCHED_CLOCK
versatile_sched_clock_init(REFCOUNTER, 24000000);
#endif

2
arch/arm/mach-omap2/board-apollon.c
View File

@ -311,7 +311,7 @@ static void __init omap_apollon_init(void)
/* LCD PWR_EN */
omap_mux_init_signal("mcbsp2_dr.gpio_11", OMAP_PULL_ENA | OMAP_PULL_UP);
/* Use Interal loop-back in MMC/SDIO Module Input Clock selection */
/* Use Internal loop-back in MMC/SDIO Module Input Clock selection */
v = omap_ctrl_readl(OMAP2_CONTROL_DEVCONF0);
v |= (1 << 24);
omap_ctrl_writel(v, OMAP2_CONTROL_DEVCONF0);

2
arch/arm/mach-omap2/board-omap4panda.c
View File

@ -106,7 +106,7 @@ static struct platform_device leds_gpio = {
static struct omap_abe_twl6040_data panda_abe_audio_data = {
/* Audio out */
.has_hs = ABE_TWL6040_LEFT | ABE_TWL6040_RIGHT,
/* HandsFree through expasion connector */
/* HandsFree through expansion connector */
.has_hf = ABE_TWL6040_LEFT | ABE_TWL6040_RIGHT,
/* PandaBoard: FM TX, PandaBoardES: can be connected to audio out */
.has_aux = ABE_TWL6040_LEFT | ABE_TWL6040_RIGHT,

2
arch/arm/mach-omap2/omap-mpuss-lowpower.c
View File

@ -313,7 +313,7 @@ int __cpuinit omap4_hotplug_cpu(unsigned int cpu, unsigned int power_state)
scu_pwrst_prepare(cpu, power_state);
/*
* CPU never retuns back if targetted power state is OFF mode.
* CPU never retuns back if targeted power state is OFF mode.
* CPU ONLINE follows normal CPU ONLINE ptah via
* omap_secondary_startup().
*/

2
arch/arm/mach-omap2/sr_device.c
View File

@ -131,7 +131,7 @@ static int __init sr_dev_init(struct omap_hwmod *oh, void *user)
omap_voltage_get_volttable(sr_data->voltdm, &volt_data);
if (!volt_data) {
pr_warning("%s: No Voltage table registerd fo VDD%d."
pr_warning("%s: No Voltage table registered fo VDD%d."
"Something really wrong\n\n", __func__, i + 1);
goto exit;
}

2
arch/arm/mach-omap2/twl-common.c
View File

@ -96,7 +96,7 @@ void __init omap4_pmic_init(const char *pmic_type,
void __init omap_pmic_late_init(void)
{
/* Init the OMAP TWL parameters (if PMIC has been registerd) */
/* Init the OMAP TWL parameters (if PMIC has been registered) */
if (pmic_i2c_board_info.irq)
omap3_twl_init();
if (omap4_i2c1_board_info[0].irq)

2
arch/arm/mach-u300/Makefile
View File

@ -2,7 +2,7 @@
# Makefile for the linux kernel, U300 machine.
#
obj-y := core.o clock.o timer.o
obj-y := core.o timer.o
obj-m :=
obj-n :=
obj- :=

1504
arch/arm/mach-u300/clock.c
View File

File diff suppressed because it is too large Load Diff

50
arch/arm/mach-u300/clock.h
View File

@ -1,50 +0,0 @@
/*
* arch/arm/mach-u300/include/mach/clock.h
*
* Copyright (C) 2004 - 2005 Nokia corporation
* Written by Tuukka Tikkanen <tuukka.tikkanen@elektrobit.com>
* Based on clocks.h by Tony Lindgren, Gordon McNutt and RidgeRun, Inc
* Copyright (C) 2007-2009 ST-Ericsson AB
* Adopted to ST-Ericsson U300 platforms by
* Jonas Aaberg <jonas.aberg@stericsson.com>
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*
*/
#ifndef __MACH_CLOCK_H
#define __MACH_CLOCK_H
#include <linux/clk.h>
struct clk {
struct list_head node;
struct module *owner;
struct device *dev;
const char *name;
struct clk *parent;
spinlock_t lock;
unsigned long rate;
bool reset;
__u16 clk_val;
__s8 usecount;
void __iomem * res_reg;
__u16 res_mask;
bool hw_ctrld;
void (*recalc) (struct clk *);
int (*set_rate) (struct clk *, unsigned long);
unsigned long (*get_rate) (struct clk *);
unsigned long (*round_rate) (struct clk *, unsigned long);
void (*init) (struct clk *);
void (*enable) (struct clk *);
void (*disable) (struct clk *);
};
int u300_clock_init(void);
#endif

21
arch/arm/mach-u300/core.c
View File

@ -30,6 +30,7 @@
#include <linux/pinctrl/consumer.h>
#include <linux/pinctrl/pinconf-generic.h>
#include <linux/dma-mapping.h>
#include <linux/platform_data/clk-u300.h>
#include <asm/types.h>
#include <asm/setup.h>
@ -44,7 +45,6 @@
#include <mach/dma_channels.h>
#include <mach/gpio-u300.h>
#include "clock.h"
#include "spi.h"
#include "i2c.h"
#include "u300-gpio.h"
@ -1658,12 +1658,20 @@ void __init u300_init_irq(void)
int i;
/* initialize clocking early, we want to clock the INTCON */
u300_clock_init();
u300_clk_init(U300_SYSCON_VBASE);
/* Bootstrap EMIF and SEMI clocks */
clk = clk_get_sys("pl172", NULL);
BUG_ON(IS_ERR(clk));
clk_prepare_enable(clk);
clk = clk_get_sys("semi", NULL);
BUG_ON(IS_ERR(clk));
clk_prepare_enable(clk);
/* Clock the interrupt controller */
clk = clk_get_sys("intcon", NULL);
BUG_ON(IS_ERR(clk));
clk_enable(clk);
clk_prepare_enable(clk);
for (i = 0; i < U300_VIC_IRQS_END; i++)
set_bit(i, (unsigned long *) &mask[0]);
@ -1811,13 +1819,6 @@ void __init u300_init_devices(void)
/* Check what platform we run and print some status information */
u300_init_check_chip();
/* Set system to run at PLL208, max performance, a known state. */
val = readw(U300_SYSCON_VBASE + U300_SYSCON_CCR);
val &= ~U300_SYSCON_CCR_CLKING_PERFORMANCE_MASK;
writew(val, U300_SYSCON_VBASE + U300_SYSCON_CCR);
/* Wait for the PLL208 to lock if not locked in yet */
while (!(readw(U300_SYSCON_VBASE + U300_SYSCON_CSR) &
U300_SYSCON_CSR_PLL208_LOCK_IND));
/* Initialize SPI device with some board specifics */
u300_spi_init(&pl022_device);

2
arch/arm/mach-u300/timer.c
View File

@ -354,7 +354,7 @@ static void __init u300_timer_init(void)
/* Clock the interrupt controller */
clk = clk_get_sys("apptimer", NULL);
BUG_ON(IS_ERR(clk));
clk_enable(clk);
clk_prepare_enable(clk);
rate = clk_get_rate(clk);
setup_sched_clock(u300_read_sched_clock, 32, rate);

14
arch/arm/mach-ux500/board-mop500.c
View File

@ -25,6 +25,7 @@
#include <linux/mfd/tc3589x.h>
#include <linux/mfd/tps6105x.h>
#include <linux/mfd/abx500/ab8500-gpio.h>
#include <linux/mfd/abx500/ab8500-codec.h>
#include <linux/leds-lp5521.h>
#include <linux/input.h>
#include <linux/smsc911x.h>
@ -97,6 +98,18 @@ static struct ab8500_gpio_platform_data ab8500_gpio_pdata = {
0x7A, 0x00, 0x00},
};
/* ab8500-codec */
static struct ab8500_codec_platform_data ab8500_codec_pdata = {
.amics = {
.mic1_type = AMIC_TYPE_DIFFERENTIAL,
.mic2_type = AMIC_TYPE_DIFFERENTIAL,
.mic1a_micbias = AMIC_MICBIAS_VAMIC1,
.mic1b_micbias = AMIC_MICBIAS_VAMIC1,
.mic2_micbias = AMIC_MICBIAS_VAMIC2
},
.ear_cmv = EAR_CMV_0_95V
};
static struct gpio_keys_button snowball_key_array[] = {
{
.gpio = 32,
@ -195,6 +208,7 @@ static struct ab8500_platform_data ab8500_platdata = {
.regulator = ab8500_regulators,
.num_regulator = ARRAY_SIZE(ab8500_regulators),
.gpio = &ab8500_gpio_pdata,
.codec = &ab8500_codec_pdata,
};
static struct resource ab8500_resources[] = {

2
arch/arm/plat-samsung/include/plat/gpio-cfg.h
View File

@ -24,7 +24,7 @@
#ifndef __PLAT_GPIO_CFG_H
#define __PLAT_GPIO_CFG_H __FILE__
#include<linux/types.h>
#include <linux/types.h>
typedef unsigned int __bitwise__ samsung_gpio_pull_t;
typedef unsigned int __bitwise__ s5p_gpio_drvstr_t;

16
arch/blackfin/Kconfig
View File

@ -352,6 +352,11 @@ config MEM_MT48H32M16LFCJ_75
depends on (BFIN526_EZBRD)
default y
config MEM_MT47H64M16
bool
depends on (BFIN609_EZKIT)
default y
source "arch/blackfin/mach-bf518/Kconfig"
source "arch/blackfin/mach-bf527/Kconfig"
source "arch/blackfin/mach-bf533/Kconfig"
@ -399,8 +404,9 @@ config ROM_BASE
hex "Kernel ROM Base"
depends on ROMKERNEL
default "0x20040040"
range 0x20000000 0x20400000 if !(BF54x || BF561)
range 0x20000000 0x20400000 if !(BF54x || BF561 || BF60x)
range 0x20000000 0x30000000 if (BF54x || BF561)
range 0xB0000000 0xC0000000 if (BF60x)
help
Make sure your ROM base does not include any file-header
information that is prepended to the kernel.
@ -1009,6 +1015,12 @@ config HAVE_PWM
choice
prompt "Uncached DMA region"
default DMA_UNCACHED_1M
config DMA_UNCACHED_32M
bool "Enable 32M DMA region"
config DMA_UNCACHED_16M
bool "Enable 16M DMA region"
config DMA_UNCACHED_8M
bool "Enable 8M DMA region"
config DMA_UNCACHED_4M
bool "Enable 4M DMA region"
config DMA_UNCACHED_2M
@ -1038,7 +1050,7 @@ config BFIN_EXTMEM_ICACHEABLE
config BFIN_L2_ICACHEABLE
bool "Enable ICACHE for L2 SRAM"
depends on BFIN_ICACHE
depends on BF54x || BF561
depends on (BF54x || BF561 || BF60x) && !SMP
default n
config BFIN_DCACHE

2
arch/blackfin/configs/BF609-EZKIT_defconfig
View File

@ -90,6 +90,7 @@ CONFIG_INPUT_BFIN_ROTARY=y
# CONFIG_SERIO is not set
# CONFIG_LEGACY_PTYS is not set
CONFIG_BFIN_SIMPLE_TIMER=m
# CONFIG_BFIN_CRC is not set
CONFIG_BFIN_LINKPORT=y
# CONFIG_DEVKMEM is not set
CONFIG_SERIAL_BFIN=y
@ -153,3 +154,4 @@ CONFIG_CRYPTO_MD4=y
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_ARC4=y
# CONFIG_CRYPTO_ANSI_CPRNG is not set
CONFIG_CRYPTO_DEV_BFIN_CRC=y

8
arch/blackfin/include/asm/bfin-global.h
View File

@ -14,7 +14,13 @@
#include <linux/linkage.h>
#include <linux/types.h>
#if defined(CONFIG_DMA_UNCACHED_4M)
#if defined(CONFIG_DMA_UNCACHED_32M)
# define DMA_UNCACHED_REGION (32 * 1024 * 1024)
#elif defined(CONFIG_DMA_UNCACHED_16M)
# define DMA_UNCACHED_REGION (16 * 1024 * 1024)
#elif defined(CONFIG_DMA_UNCACHED_8M)
# define DMA_UNCACHED_REGION (8 * 1024 * 1024)
#elif defined(CONFIG_DMA_UNCACHED_4M)
# define DMA_UNCACHED_REGION (4 * 1024 * 1024)
#elif defined(CONFIG_DMA_UNCACHED_2M)
# define DMA_UNCACHED_REGION (2 * 1024 * 1024)

14
arch/blackfin/include/asm/bfin_crc.h
View File

@ -79,20 +79,6 @@ struct crc_register {
u32 revid;
};
struct bfin_crc {
struct miscdevice mdev;
struct list_head list;
int irq;
int dma_ch_src;
int dma_ch_dest;
volatile struct crc_register *regs;
struct crc_info *info;
struct mutex mutex;
struct completion c;
unsigned short opmode;
char name[20];
};
/* CRC_STATUS Masks */
#define CMPERR 0x00000002 /* Compare error */
#define DCNTEXP 0x00000010 /* datacnt register expired */

2
arch/blackfin/include/asm/bfin_serial.h
View File

@ -282,7 +282,7 @@ struct bfin_uart_regs {
#define UART_GET_GCTL(p) UART_GET_CTL(p)
#define UART_GET_LCR(p) UART_GET_CTL(p)
#define UART_GET_MCR(p) UART_GET_CTL(p)
#if ANOMALY_05001001
#if ANOMALY_16000030
#define UART_GET_STAT(p) \
({ \
u32 __ret; \

6
arch/blackfin/include/asm/bfin_simple_timer.h
View File

@ -17,5 +17,11 @@
#define BFIN_SIMPLE_TIMER_START _IO(BFIN_SIMPLE_TIMER_IOCTL_MAGIC, 6)
#define BFIN_SIMPLE_TIMER_STOP _IO(BFIN_SIMPLE_TIMER_IOCTL_MAGIC, 8)
#define BFIN_SIMPLE_TIMER_READ _IO(BFIN_SIMPLE_TIMER_IOCTL_MAGIC, 10)
#define BFIN_SIMPLE_TIMER_READ_COUNTER _IO(BFIN_SIMPLE_TIMER_IOCTL_MAGIC, 11)
#define BFIN_SIMPLE_TIMER_MODE_PWM_ONESHOT 0
#define BFIN_SIMPLE_TIMER_MODE_PWMOUT_CONT 1
#define BFIN_SIMPLE_TIMER_MODE_WDTH_CAP 2
#define BFIN_SIMPLE_TIMER_MODE_PWMOUT_CONT_NOIRQ 3
#endif

10
arch/blackfin/include/asm/bfin_twi.h
View File

@ -66,9 +66,9 @@ struct bfin_twi_iface {
#define DEFINE_TWI_REG(reg_name, reg) \
static inline u16 read_##reg_name(struct bfin_twi_iface *iface) \
{ return iface->regs_base->reg; } \
{ return bfin_read16(&iface->regs_base->reg); } \
static inline void write_##reg_name(struct bfin_twi_iface *iface, u16 v) \
{ iface->regs_base->reg = v; }
{ bfin_write16(&iface->regs_base->reg, v); }
DEFINE_TWI_REG(CLKDIV, clkdiv)
DEFINE_TWI_REG(CONTROL, control)
@ -84,7 +84,7 @@ DEFINE_TWI_REG(FIFO_CTL, fifo_ctl)
DEFINE_TWI_REG(FIFO_STAT, fifo_stat)
DEFINE_TWI_REG(XMT_DATA8, xmt_data8)
DEFINE_TWI_REG(XMT_DATA16, xmt_data16)
#if !ANOMALY_05001001
#if !ANOMALY_16000030
DEFINE_TWI_REG(RCV_DATA8, rcv_data8)
DEFINE_TWI_REG(RCV_DATA16, rcv_data16)
#else
@ -94,7 +94,7 @@ static inline u16 read_RCV_DATA8(struct bfin_twi_iface *iface)
unsigned long flags;
flags = hard_local_irq_save();
ret = iface->regs_base->rcv_data8;
ret = bfin_read16(&iface->regs_base->rcv_data8);
hard_local_irq_restore(flags);
return ret;
@ -106,7 +106,7 @@ static inline u16 read_RCV_DATA16(struct bfin_twi_iface *iface)
unsigned long flags;
flags = hard_local_irq_save();
ret = iface->regs_base->rcv_data16;
ret = bfin_read16(&iface->regs_base->rcv_data16);
hard_local_irq_restore(flags);
return ret;

9
arch/blackfin/include/asm/context.S
View File

@ -396,3 +396,12 @@
call \func;
#endif
.endm
#if defined(CONFIG_BFIN_SCRATCH_REG_RETN)
# define EX_SCRATCH_REG RETN
#elif defined(CONFIG_BFIN_SCRATCH_REG_RETE)
# define EX_SCRATCH_REG RETE
#else
# define EX_SCRATCH_REG CYCLES
#endif

2
arch/blackfin/include/asm/dpmc.h
View File

@ -280,7 +280,7 @@
PM_POP_SYNC(9)
#endif
#ifdef EBIU_AMBCTL
#ifdef EBIU_AMGCTL
PM_SYS_POP(9, EBIU_AMBCTL1)
PM_SYS_POP(8, EBIU_AMBCTL0)
PM_SYS_POP16(7, EBIU_AMGCTL)

2
arch/blackfin/include/asm/gpio.h
View File

@ -141,6 +141,8 @@ static inline void bfin_pm_standby_restore(void)
void bfin_gpio_pm_hibernate_restore(void);
void bfin_gpio_pm_hibernate_suspend(void);
void bfin_pint_suspend(void);
void bfin_pint_resume(void);
# if !BFIN_GPIO_PINT
int gpio_pm_wakeup_ctrl(unsigned gpio, unsigned ctrl);

10
arch/blackfin/include/asm/irq.h
View File

@ -20,6 +20,16 @@
/* SYS_IRQS and NR_IRQS are defined in <mach-bf5xx/irq.h> */
#include <mach/irq.h>
/*
* pm save bfin pint registers
*/
struct bfin_pm_pint_save {
u32 mask_set;
u32 assign;
u32 edge_set;
u32 invert_set;
};
#if ANOMALY_05000244 && defined(CONFIG_BFIN_ICACHE)
# define NOP_PAD_ANOMALY_05000244 "nop; nop;"
#else

212
arch/blackfin/include/asm/mem_init.h
View File

@ -6,6 +6,9 @@
* Licensed under the GPL-2 or later.
*/
#ifndef __MEM_INIT_H__
#define __MEM_INIT_H__
#if defined(EBIU_SDGCTL)
#if defined(CONFIG_MEM_MT48LC16M16A2TG_75) || \
defined(CONFIG_MEM_MT48LC64M4A2FB_7E) || \
@ -277,3 +280,212 @@
#else
#define PLL_BYPASS 0
#endif
#ifdef CONFIG_BF60x
/* DMC status bits */
#define IDLE 0x1
#define MEMINITDONE 0x4
#define SRACK 0x8
#define PDACK 0x10
#define DPDACK 0x20
#define DLLCALDONE 0x2000
#define PENDREF 0xF0000
#define PHYRDPHASE 0xF00000
#define PHYRDPHASE_OFFSET 20
/* DMC control bits */
#define LPDDR 0x2
#define INIT 0x4
#define SRREQ 0x8
#define PDREQ 0x10
#define DPDREQ 0x20
#define PREC 0x40
#define ADDRMODE 0x100
#define RDTOWR 0xE00
#define PPREF 0x1000
#define DLLCAL 0x2000
/* DMC DLL control bits */
#define DLLCALRDCNT 0xFF
#define DATACYC 0xF00
#define DATACYC_OFFSET 8
/* CGU Divisor bits */
#define CSEL_OFFSET 0
#define S0SEL_OFFSET 5
#define SYSSEL_OFFSET 8
#define S1SEL_OFFSET 13
#define DSEL_OFFSET 16
#define OSEL_OFFSET 22
#define ALGN 0x20000000
#define UPDT 0x40000000
#define LOCK 0x80000000
/* CGU Status bits */
#define PLLEN 0x1
#define PLLBP 0x2
#define PLOCK 0x4
#define CLKSALGN 0x8
/* CGU Control bits */
#define MSEL_MASK 0x7F00
#define DF_MASK 0x1
struct ddr_config {
u32 ddr_clk;
u32 dmc_ddrctl;
u32 dmc_ddrcfg;
u32 dmc_ddrtr0;
u32 dmc_ddrtr1;
u32 dmc_ddrtr2;
u32 dmc_ddrmr;
u32 dmc_ddrmr1;
};
#if defined(CONFIG_MEM_MT47H64M16)
static struct ddr_config ddr_config_table[] __attribute__((section(".data_l1"))) = {
[0] = {
.ddr_clk = 125,
.dmc_ddrctl = 0x00000904,
.dmc_ddrcfg = 0x00000422,
.dmc_ddrtr0 = 0x20705212,
.dmc_ddrtr1 = 0x201003CF,
.dmc_ddrtr2 = 0x00320107,
.dmc_ddrmr = 0x00000422,
.dmc_ddrmr1 = 0x4,
},
[1] = {
.ddr_clk = 133,
.dmc_ddrctl = 0x00000904,
.dmc_ddrcfg = 0x00000422,
.dmc_ddrtr0 = 0x20806313,
.dmc_ddrtr1 = 0x2013040D,
.dmc_ddrtr2 = 0x00320108,
.dmc_ddrmr = 0x00000632,
.dmc_ddrmr1 = 0x4,
},
[2] = {
.ddr_clk = 150,
.dmc_ddrctl = 0x00000904,
.dmc_ddrcfg = 0x00000422,
.dmc_ddrtr0 = 0x20A07323,
.dmc_ddrtr1 = 0x20160492,
.dmc_ddrtr2 = 0x00320209,
.dmc_ddrmr = 0x00000632,
.dmc_ddrmr1 = 0x4,
},
[3] = {
.ddr_clk = 166,
.dmc_ddrctl = 0x00000904,
.dmc_ddrcfg = 0x00000422,
.dmc_ddrtr0 = 0x20A07323,
.dmc_ddrtr1 = 0x2016050E,
.dmc_ddrtr2 = 0x00320209,
.dmc_ddrmr = 0x00000632,
.dmc_ddrmr1 = 0x4,
},
[4] = {
.ddr_clk = 200,
.dmc_ddrctl = 0x00000904,
.dmc_ddrcfg = 0x00000422,
.dmc_ddrtr0 = 0x20a07323,
.dmc_ddrtr1 = 0x2016050f,
.dmc_ddrtr2 = 0x00320509,
.dmc_ddrmr = 0x00000632,
.dmc_ddrmr1 = 0x4,
},
[5] = {
.ddr_clk = 225,
.dmc_ddrctl = 0x00000904,
.dmc_ddrcfg = 0x00000422,
.dmc_ddrtr0 = 0x20E0A424,
.dmc_ddrtr1 = 0x302006DB,
.dmc_ddrtr2 = 0x0032020D,
.dmc_ddrmr = 0x00000842,
.dmc_ddrmr1 = 0x4,
},
[6] = {
.ddr_clk = 250,
.dmc_ddrctl = 0x00000904,
.dmc_ddrcfg = 0x00000422,
.dmc_ddrtr0 = 0x20E0A424,
.dmc_ddrtr1 = 0x3020079E,
.dmc_ddrtr2 = 0x0032020D,
.dmc_ddrmr = 0x00000842,
.dmc_ddrmr1 = 0x4,
},
};
#endif
static inline void dmc_enter_self_refresh(void)
{
if (bfin_read_DMC0_STAT() & MEMINITDONE) {
bfin_write_DMC0_CTL(bfin_read_DMC0_CTL() | SRREQ);
while (!(bfin_read_DMC0_STAT() & SRACK))
continue;
}
}
static inline void dmc_exit_self_refresh(void)
{
if (bfin_read_DMC0_STAT() & MEMINITDONE) {
bfin_write_DMC0_CTL(bfin_read_DMC0_CTL() & ~SRREQ);
while (bfin_read_DMC0_STAT() & SRACK)
continue;
}
}
static inline void init_cgu(u32 cgu_div, u32 cgu_ctl)
{
dmc_enter_self_refresh();
/* Don't set the same value of MSEL and DF to CGU_CTL */
if ((bfin_read32(CGU0_CTL) & (MSEL_MASK | DF_MASK))
!= cgu_ctl) {
bfin_write32(CGU0_DIV, cgu_div);
bfin_write32(CGU0_CTL, cgu_ctl);
while ((bfin_read32(CGU0_STAT) & (CLKSALGN | PLLBP)) ||
!(bfin_read32(CGU0_STAT) & PLOCK))
continue;
}
bfin_write32(CGU0_DIV, cgu_div | UPDT);
while (bfin_read32(CGU0_STAT) & CLKSALGN)
continue;
dmc_exit_self_refresh();
}
static inline void init_dmc(u32 dmc_clk)
{
int i, dlldatacycle, dll_ctl;
for (i = 0; i < 7; i++) {
if (ddr_config_table[i].ddr_clk == dmc_clk) {
bfin_write_DMC0_CFG(ddr_config_table[i].dmc_ddrcfg);
bfin_write_DMC0_TR0(ddr_config_table[i].dmc_ddrtr0);
bfin_write_DMC0_TR1(ddr_config_table[i].dmc_ddrtr1);
bfin_write_DMC0_TR2(ddr_config_table[i].dmc_ddrtr2);
bfin_write_DMC0_MR(ddr_config_table[i].dmc_ddrmr);
bfin_write_DMC0_EMR1(ddr_config_table[i].dmc_ddrmr1);
bfin_write_DMC0_CTL(ddr_config_table[i].dmc_ddrctl);
break;
}
}
while (!(bfin_read_DMC0_STAT() & MEMINITDONE))
continue;
dlldatacycle = (bfin_read_DMC0_STAT() & PHYRDPHASE) >> PHYRDPHASE_OFFSET;
dll_ctl = bfin_read_DMC0_DLLCTL();
dll_ctl &= ~DATACYC;
bfin_write_DMC0_DLLCTL(dll_ctl | (dlldatacycle << DATACYC_OFFSET));
while (!(bfin_read_DMC0_STAT() & DLLCALDONE))
continue;
}
#endif
#endif /*__MEM_INIT_H__*/

2
arch/blackfin/include/asm/traps.h
View File

@ -125,5 +125,7 @@
level " for Supervisor use: Supervisor only registers, all MMRs, and Supervisor\n" \
level " only instructions.\n"
extern void double_fault_c(struct pt_regs *fp);
#endif /* __ASSEMBLY__ */
#endif /* _BFIN_TRAPS_H */

4
arch/blackfin/kernel/bfin_dma.c
View File

@ -45,7 +45,7 @@ static int __init blackfin_dma_init(void)
atomic_set(&dma_ch[i].chan_status, 0);
dma_ch[i].regs = dma_io_base_addr[i];
}
#ifdef CH_MEM_STREAM3_SRC
#if defined(CH_MEM_STREAM3_SRC) && defined(CONFIG_BF60x)
/* Mark MEMDMA Channel 3 as requested since we're using it internally */
request_dma(CH_MEM_STREAM3_DEST, "Blackfin dma_memcpy");
request_dma(CH_MEM_STREAM3_SRC, "Blackfin dma_memcpy");
@ -361,7 +361,7 @@ void __init early_dma_memcpy_done(void)
__builtin_bfin_ssync();
}
#ifdef CH_MEM_STREAM3_SRC
#if defined(CH_MEM_STREAM3_SRC) && defined(CONFIG_BF60x)
#define bfin_read_MDMA_S_CONFIG bfin_read_MDMA_S3_CONFIG
#define bfin_write_MDMA_S_CONFIG bfin_write_MDMA_S3_CONFIG
#define bfin_write_MDMA_S_START_ADDR bfin_write_MDMA_S3_START_ADDR

8
arch/blackfin/kernel/cplb-nompu/cplbinit.c
View File

@ -58,11 +58,19 @@ void __init generate_cplb_tables_cpu(unsigned int cpu)
#ifdef CONFIG_ROMKERNEL
/* Cover kernel XIP flash area */
#ifdef CONFIG_BF60x
addr = CONFIG_ROM_BASE & ~(16 * 1024 * 1024 - 1);
d_tbl[i_d].addr = addr;
d_tbl[i_d++].data = SDRAM_DGENERIC | PAGE_SIZE_16MB;
i_tbl[i_i].addr = addr;
i_tbl[i_i++].data = SDRAM_IGENERIC | PAGE_SIZE_16MB;
#else
addr = CONFIG_ROM_BASE & ~(4 * 1024 * 1024 - 1);
d_tbl[i_d].addr = addr;
d_tbl[i_d++].data = SDRAM_DGENERIC | PAGE_SIZE_4MB;
i_tbl[i_i].addr = addr;
i_tbl[i_i++].data = SDRAM_IGENERIC | PAGE_SIZE_4MB;
#endif
#endif
/* Cover L1 memory. One 4M area for code and data each is enough. */

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