mirror of
https://github.com/linux-msm/laptops-kernel.git
synced 2026-08-13 14:19:53 -07:00
Merge tag 'v4.3-rc3' into x86/mm, to pick up fixes before applying new changes
Signed-off-by: Ingo Molnar <mingo@kernel.org>
This commit is contained in:
Ingo Molnar
@@ -57,6 +57,8 @@ used to route Message Signalled Interrupts (MSI) to the CPUs.
|
||||
These nodes must have the following properties:
|
||||
- compatible : Should at least contain "arm,gic-v3-its".
|
||||
- msi-controller : Boolean property. Identifies the node as an MSI controller
|
||||
- #msi-cells: Must be <1>. The single msi-cell is the DeviceID of the device
|
||||
which will generate the MSI.
|
||||
- reg: Specifies the base physical address and size of the ITS
|
||||
registers.
|
||||
|
||||
@@ -83,6 +85,7 @@ Examples:
|
||||
gic-its@2c200000 {
|
||||
compatible = "arm,gic-v3-its";
|
||||
msi-controller;
|
||||
#msi-cells = <1>;
|
||||
reg = <0x0 0x2c200000 0 0x200000>;
|
||||
};
|
||||
};
|
||||
@@ -107,12 +110,14 @@ Examples:
|
||||
gic-its@2c200000 {
|
||||
compatible = "arm,gic-v3-its";
|
||||
msi-controller;
|
||||
#msi-cells = <1>;
|
||||
reg = <0x0 0x2c200000 0 0x200000>;
|
||||
};
|
||||
|
||||
gic-its@2c400000 {
|
||||
compatible = "arm,gic-v3-its";
|
||||
msi-controller;
|
||||
#msi-cells = <1>;
|
||||
reg = <0x0 0x2c400000 0 0x200000>;
|
||||
};
|
||||
};
|
||||
|
||||
@@ -497,7 +497,7 @@ cpus {
|
||||
};
|
||||
|
||||
idle-states {
|
||||
entry-method = "arm,psci";
|
||||
entry-method = "psci";
|
||||
|
||||
CPU_RETENTION_0_0: cpu-retention-0-0 {
|
||||
compatible = "arm,idle-state";
|
||||
|
||||
@@ -16,7 +16,9 @@ properties, each containing a 'gpio-list':
|
||||
GPIO properties should be named "[<name>-]gpios", with <name> being the purpose
|
||||
of this GPIO for the device. While a non-existent <name> is considered valid
|
||||
for compatibility reasons (resolving to the "gpios" property), it is not allowed
|
||||
for new bindings.
|
||||
for new bindings. Also, GPIO properties named "[<name>-]gpio" are valid and old
|
||||
bindings use it, but are only supported for compatibility reasons and should not
|
||||
be used for newer bindings since it has been deprecated.
|
||||
|
||||
GPIO properties can contain one or more GPIO phandles, but only in exceptional
|
||||
cases should they contain more than one. If your device uses several GPIOs with
|
||||
|
||||
@@ -1,10 +1,11 @@
|
||||
* Bosch BMA180 triaxial acceleration sensor
|
||||
* Bosch BMA180 / BMA250 triaxial acceleration sensor
|
||||
|
||||
http://omapworld.com/BMA180_111_1002839.pdf
|
||||
http://ae-bst.resource.bosch.com/media/products/dokumente/bma250/bst-bma250-ds002-05.pdf
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : should be "bosch,bma180"
|
||||
- compatible : should be "bosch,bma180" or "bosch,bma250"
|
||||
- reg : the I2C address of the sensor
|
||||
|
||||
Optional properties:
|
||||
@@ -13,6 +14,9 @@ Optional properties:
|
||||
|
||||
- interrupts : interrupt mapping for GPIO IRQ, it should by configured with
|
||||
flags IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_EDGE_RISING
|
||||
For the bma250 the first interrupt listed must be the one
|
||||
connected to the INT1 pin, the second (optional) interrupt
|
||||
listed must be the one connected to the INT2 pin.
|
||||
|
||||
Example:
|
||||
|
||||
|
||||
@@ -7,7 +7,8 @@ OHCI and EHCI controllers.
|
||||
|
||||
Required properties:
|
||||
- compatible: "renesas,pci-r8a7790" for the R8A7790 SoC;
|
||||
"renesas,pci-r8a7791" for the R8A7791 SoC.
|
||||
"renesas,pci-r8a7791" for the R8A7791 SoC;
|
||||
"renesas,pci-r8a7794" for the R8A7794 SoC.
|
||||
- reg: A list of physical regions to access the device: the first is
|
||||
the operational registers for the OHCI/EHCI controllers and the
|
||||
second is for the bridge configuration and control registers.
|
||||
|
||||
@@ -2,7 +2,12 @@ PBIAS internal regulator for SD card dual voltage i/o pads on OMAP SoCs.
|
||||
|
||||
Required properties:
|
||||
- compatible:
|
||||
- "ti,pbias-omap" for OMAP2, OMAP3, OMAP4, OMAP5, DRA7.
|
||||
- should be "ti,pbias-dra7" for DRA7
|
||||
- should be "ti,pbias-omap2" for OMAP2
|
||||
- should be "ti,pbias-omap3" for OMAP3
|
||||
- should be "ti,pbias-omap4" for OMAP4
|
||||
- should be "ti,pbias-omap5" for OMAP5
|
||||
- "ti,pbias-omap" is deprecated
|
||||
- reg: pbias register offset from syscon base and size of pbias register.
|
||||
- syscon : phandle of the system control module
|
||||
- regulator-name : should be
|
||||
|
||||
@@ -15,17 +15,18 @@ Required properties:
|
||||
- interrupts: Should contain spi interrupt
|
||||
|
||||
- clocks: phandles to input clocks.
|
||||
The first should be <&topckgen CLK_TOP_SPI_SEL>.
|
||||
The second should be one of the following.
|
||||
The first should be one of the following. It's PLL.
|
||||
- <&clk26m>: specify parent clock 26MHZ.
|
||||
- <&topckgen CLK_TOP_SYSPLL3_D2>: specify parent clock 109MHZ.
|
||||
It's the default one.
|
||||
- <&topckgen CLK_TOP_SYSPLL4_D2>: specify parent clock 78MHZ.
|
||||
- <&topckgen CLK_TOP_UNIVPLL2_D4>: specify parent clock 104MHZ.
|
||||
- <&topckgen CLK_TOP_UNIVPLL1_D8>: specify parent clock 78MHZ.
|
||||
The second should be <&topckgen CLK_TOP_SPI_SEL>. It's clock mux.
|
||||
The third is <&pericfg CLK_PERI_SPI0>. It's clock gate.
|
||||
|
||||
- clock-names: shall be "spi-clk" for the controller clock, and
|
||||
"parent-clk" for the parent clock.
|
||||
- clock-names: shall be "parent-clk" for the parent clock, "sel-clk" for the
|
||||
muxes clock, and "spi-clk" for the clock gate.
|
||||
|
||||
Optional properties:
|
||||
- mediatek,pad-select: specify which pins group(ck/mi/mo/cs) spi
|
||||
@@ -44,8 +45,11 @@ spi: spi@1100a000 {
|
||||
#size-cells = <0>;
|
||||
reg = <0 0x1100a000 0 0x1000>;
|
||||
interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_LOW>;
|
||||
clocks = <&topckgen CLK_TOP_SPI_SEL>, <&topckgen CLK_TOP_SYSPLL3_D2>;
|
||||
clock-names = "spi-clk", "parent-clk";
|
||||
clocks = <&topckgen CLK_TOP_SYSPLL3_D2>,
|
||||
<&topckgen CLK_TOP_SPI_SEL>,
|
||||
<&pericfg CLK_PERI_SPI0>;
|
||||
clock-names = "parent-clk", "sel-clk", "spi-clk";
|
||||
|
||||
mediatek,pad-select = <0>;
|
||||
status = "disabled";
|
||||
};
|
||||
|
||||
@@ -55,19 +55,11 @@ of heat dissipation). For example a fan's cooling states correspond to
|
||||
the different fan speeds possible. Cooling states are referred to by
|
||||
single unsigned integers, where larger numbers mean greater heat
|
||||
dissipation. The precise set of cooling states associated with a device
|
||||
(as referred to be the cooling-min-state and cooling-max-state
|
||||
(as referred to by the cooling-min-level and cooling-max-level
|
||||
properties) should be defined in a particular device's binding.
|
||||
For more examples of cooling devices, refer to the example sections below.
|
||||
|
||||
Required properties:
|
||||
- cooling-min-state: An integer indicating the smallest
|
||||
Type: unsigned cooling state accepted. Typically 0.
|
||||
Size: one cell
|
||||
|
||||
- cooling-max-state: An integer indicating the largest
|
||||
Type: unsigned cooling state accepted.
|
||||
Size: one cell
|
||||
|
||||
- #cooling-cells: Used to provide cooling device specific information
|
||||
Type: unsigned while referring to it. Must be at least 2, in order
|
||||
Size: one cell to specify minimum and maximum cooling state used
|
||||
@@ -77,6 +69,15 @@ Required properties:
|
||||
See Cooling device maps section below for more details
|
||||
on how consumers refer to cooling devices.
|
||||
|
||||
Optional properties:
|
||||
- cooling-min-level: An integer indicating the smallest
|
||||
Type: unsigned cooling state accepted. Typically 0.
|
||||
Size: one cell
|
||||
|
||||
- cooling-max-level: An integer indicating the largest
|
||||
Type: unsigned cooling state accepted.
|
||||
Size: one cell
|
||||
|
||||
* Trip points
|
||||
|
||||
The trip node is a node to describe a point in the temperature domain
|
||||
@@ -225,8 +226,8 @@ cpus {
|
||||
396000 950000
|
||||
198000 850000
|
||||
>;
|
||||
cooling-min-state = <0>;
|
||||
cooling-max-state = <3>;
|
||||
cooling-min-level = <0>;
|
||||
cooling-max-level = <3>;
|
||||
#cooling-cells = <2>; /* min followed by max */
|
||||
};
|
||||
...
|
||||
@@ -240,8 +241,8 @@ cpus {
|
||||
*/
|
||||
fan0: fan@0x48 {
|
||||
...
|
||||
cooling-min-state = <0>;
|
||||
cooling-max-state = <9>;
|
||||
cooling-min-level = <0>;
|
||||
cooling-max-level = <9>;
|
||||
#cooling-cells = <2>; /* min followed by max */
|
||||
};
|
||||
};
|
||||
|
||||
@@ -6,6 +6,7 @@ Required properties:
|
||||
"lsi,zevio-usb"
|
||||
"qcom,ci-hdrc"
|
||||
"chipidea,usb2"
|
||||
"xlnx,zynq-usb-2.20a"
|
||||
- reg: base address and length of the registers
|
||||
- interrupts: interrupt for the USB controller
|
||||
|
||||
|
||||
@@ -203,6 +203,7 @@ sitronix Sitronix Technology Corporation
|
||||
skyworks Skyworks Solutions, Inc.
|
||||
smsc Standard Microsystems Corporation
|
||||
snps Synopsys, Inc.
|
||||
socionext Socionext Inc.
|
||||
solidrun SolidRun
|
||||
solomon Solomon Systech Limited
|
||||
sony Sony Corporation
|
||||
|
||||
@@ -0,0 +1,96 @@
|
||||
Virtual Routing and Forwarding (VRF)
|
||||
====================================
|
||||
The VRF device combined with ip rules provides the ability to create virtual
|
||||
routing and forwarding domains (aka VRFs, VRF-lite to be specific) in the
|
||||
Linux network stack. One use case is the multi-tenancy problem where each
|
||||
tenant has their own unique routing tables and in the very least need
|
||||
different default gateways.
|
||||
|
||||
Processes can be "VRF aware" by binding a socket to the VRF device. Packets
|
||||
through the socket then use the routing table associated with the VRF
|
||||
device. An important feature of the VRF device implementation is that it
|
||||
impacts only Layer 3 and above so L2 tools (e.g., LLDP) are not affected
|
||||
(ie., they do not need to be run in each VRF). The design also allows
|
||||
the use of higher priority ip rules (Policy Based Routing, PBR) to take
|
||||
precedence over the VRF device rules directing specific traffic as desired.
|
||||
|
||||
In addition, VRF devices allow VRFs to be nested within namespaces. For
|
||||
example network namespaces provide separation of network interfaces at L1
|
||||
(Layer 1 separation), VLANs on the interfaces within a namespace provide
|
||||
L2 separation and then VRF devices provide L3 separation.
|
||||
|
||||
Design
|
||||
------
|
||||
A VRF device is created with an associated route table. Network interfaces
|
||||
are then enslaved to a VRF device:
|
||||
|
||||
+-----------------------------+
|
||||
| vrf-blue | ===> route table 10
|
||||
+-----------------------------+
|
||||
| | |
|
||||
+------+ +------+ +-------------+
|
||||
| eth1 | | eth2 | ... | bond1 |
|
||||
+------+ +------+ +-------------+
|
||||
| |
|
||||
+------+ +------+
|
||||
| eth8 | | eth9 |
|
||||
+------+ +------+
|
||||
|
||||
Packets received on an enslaved device and are switched to the VRF device
|
||||
using an rx_handler which gives the impression that packets flow through
|
||||
the VRF device. Similarly on egress routing rules are used to send packets
|
||||
to the VRF device driver before getting sent out the actual interface. This
|
||||
allows tcpdump on a VRF device to capture all packets into and out of the
|
||||
VRF as a whole.[1] Similiarly, netfilter [2] and tc rules can be applied
|
||||
using the VRF device to specify rules that apply to the VRF domain as a whole.
|
||||
|
||||
[1] Packets in the forwarded state do not flow through the device, so those
|
||||
packets are not seen by tcpdump. Will revisit this limitation in a
|
||||
future release.
|
||||
|
||||
[2] Iptables on ingress is limited to NF_INET_PRE_ROUTING only with skb->dev
|
||||
set to real ingress device and egress is limited to NF_INET_POST_ROUTING.
|
||||
Will revisit this limitation in a future release.
|
||||
|
||||
|
||||
Setup
|
||||
-----
|
||||
1. VRF device is created with an association to a FIB table.
|
||||
e.g, ip link add vrf-blue type vrf table 10
|
||||
ip link set dev vrf-blue up
|
||||
|
||||
2. Rules are added that send lookups to the associated FIB table when the
|
||||
iif or oif is the VRF device. e.g.,
|
||||
ip ru add oif vrf-blue table 10
|
||||
ip ru add iif vrf-blue table 10
|
||||
|
||||
Set the default route for the table (and hence default route for the VRF).
|
||||
e.g, ip route add table 10 prohibit default
|
||||
|
||||
3. Enslave L3 interfaces to a VRF device.
|
||||
e.g, ip link set dev eth1 master vrf-blue
|
||||
|
||||
Local and connected routes for enslaved devices are automatically moved to
|
||||
the table associated with VRF device. Any additional routes depending on
|
||||
the enslaved device will need to be reinserted following the enslavement.
|
||||
|
||||
4. Additional VRF routes are added to associated table.
|
||||
e.g., ip route add table 10 ...
|
||||
|
||||
|
||||
Applications
|
||||
------------
|
||||
Applications that are to work within a VRF need to bind their socket to the
|
||||
VRF device:
|
||||
|
||||
setsockopt(sd, SOL_SOCKET, SO_BINDTODEVICE, dev, strlen(dev)+1);
|
||||
|
||||
or to specify the output device using cmsg and IP_PKTINFO.
|
||||
|
||||
|
||||
Limitations
|
||||
-----------
|
||||
VRF device currently only works for IPv4. Support for IPv6 is under development.
|
||||
|
||||
Index of original ingress interface is not available via cmsg. Will address
|
||||
soon.
|
||||
@@ -54,13 +54,15 @@ default_qdisc
|
||||
--------------
|
||||
|
||||
The default queuing discipline to use for network devices. This allows
|
||||
overriding the default queue discipline of pfifo_fast with an
|
||||
alternative. Since the default queuing discipline is created with the
|
||||
no additional parameters so is best suited to queuing disciplines that
|
||||
work well without configuration like stochastic fair queue (sfq),
|
||||
CoDel (codel) or fair queue CoDel (fq_codel). Don't use queuing disciplines
|
||||
like Hierarchical Token Bucket or Deficit Round Robin which require setting
|
||||
up classes and bandwidths.
|
||||
overriding the default of pfifo_fast with an alternative. Since the default
|
||||
queuing discipline is created without additional parameters so is best suited
|
||||
to queuing disciplines that work well without configuration like stochastic
|
||||
fair queue (sfq), CoDel (codel) or fair queue CoDel (fq_codel). Don't use
|
||||
queuing disciplines like Hierarchical Token Bucket or Deficit Round Robin
|
||||
which require setting up classes and bandwidths. Note that physical multiqueue
|
||||
interfaces still use mq as root qdisc, which in turn uses this default for its
|
||||
leaves. Virtual devices (like e.g. lo or veth) ignore this setting and instead
|
||||
default to noqueue.
|
||||
Default: pfifo_fast
|
||||
|
||||
busy_read
|
||||
|
||||
@@ -4,7 +4,7 @@ Power allocator governor tunables
|
||||
Trip points
|
||||
-----------
|
||||
|
||||
The governor requires the following two passive trip points:
|
||||
The governor works optimally with the following two passive trip points:
|
||||
|
||||
1. "switch on" trip point: temperature above which the governor
|
||||
control loop starts operating. This is the first passive trip
|
||||
|
||||
+25
-13
@@ -615,9 +615,8 @@ F: Documentation/hwmon/fam15h_power
|
||||
F: drivers/hwmon/fam15h_power.c
|
||||
|
||||
AMD GEODE CS5536 USB DEVICE CONTROLLER DRIVER
|
||||
M: Thomas Dahlmann <dahlmann.thomas@arcor.de>
|
||||
L: linux-geode@lists.infradead.org (moderated for non-subscribers)
|
||||
S: Supported
|
||||
S: Orphan
|
||||
F: drivers/usb/gadget/udc/amd5536udc.*
|
||||
|
||||
AMD GEODE PROCESSOR/CHIPSET SUPPORT
|
||||
@@ -808,6 +807,13 @@ S: Maintained
|
||||
F: drivers/video/fbdev/arcfb.c
|
||||
F: drivers/video/fbdev/core/fb_defio.c
|
||||
|
||||
ARCNET NETWORK LAYER
|
||||
M: Michael Grzeschik <m.grzeschik@pengutronix.de>
|
||||
L: netdev@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/net/arcnet/
|
||||
F: include/uapi/linux/if_arcnet.h
|
||||
|
||||
ARM MFM AND FLOPPY DRIVERS
|
||||
M: Ian Molton <spyro@f2s.com>
|
||||
S: Maintained
|
||||
@@ -3394,7 +3400,6 @@ F: drivers/staging/dgnc/
|
||||
|
||||
DIGI EPCA PCI PRODUCTS
|
||||
M: Lidza Louina <lidza.louina@gmail.com>
|
||||
M: Mark Hounschell <markh@compro.net>
|
||||
M: Daeseok Youn <daeseok.youn@gmail.com>
|
||||
L: driverdev-devel@linuxdriverproject.org
|
||||
S: Maintained
|
||||
@@ -8500,7 +8505,6 @@ F: Documentation/networking/LICENSE.qla3xxx
|
||||
F: drivers/net/ethernet/qlogic/qla3xxx.*
|
||||
|
||||
QLOGIC QLCNIC (1/10)Gb ETHERNET DRIVER
|
||||
M: Shahed Shaikh <shahed.shaikh@qlogic.com>
|
||||
M: Dept-GELinuxNICDev@qlogic.com
|
||||
L: netdev@vger.kernel.org
|
||||
S: Supported
|
||||
@@ -9904,8 +9908,8 @@ F: drivers/staging/media/lirc/
|
||||
STAGING - LUSTRE PARALLEL FILESYSTEM
|
||||
M: Oleg Drokin <oleg.drokin@intel.com>
|
||||
M: Andreas Dilger <andreas.dilger@intel.com>
|
||||
L: HPDD-discuss@lists.01.org (moderated for non-subscribers)
|
||||
W: http://lustre.opensfs.org/
|
||||
L: lustre-devel@lists.lustre.org (moderated for non-subscribers)
|
||||
W: http://wiki.lustre.org/
|
||||
S: Maintained
|
||||
F: drivers/staging/lustre
|
||||
|
||||
@@ -10338,6 +10342,16 @@ F: include/uapi/linux/thermal.h
|
||||
F: include/linux/cpu_cooling.h
|
||||
F: Documentation/devicetree/bindings/thermal/
|
||||
|
||||
THERMAL/CPU_COOLING
|
||||
M: Amit Daniel Kachhap <amit.kachhap@gmail.com>
|
||||
M: Viresh Kumar <viresh.kumar@linaro.org>
|
||||
M: Javi Merino <javi.merino@arm.com>
|
||||
L: linux-pm@vger.kernel.org
|
||||
S: Supported
|
||||
F: Documentation/thermal/cpu-cooling-api.txt
|
||||
F: drivers/thermal/cpu_cooling.c
|
||||
F: include/linux/cpu_cooling.h
|
||||
|
||||
THINGM BLINK(1) USB RGB LED DRIVER
|
||||
M: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
|
||||
S: Maintained
|
||||
@@ -11187,7 +11201,7 @@ F: drivers/vlynq/vlynq.c
|
||||
F: include/linux/vlynq.h
|
||||
|
||||
VME SUBSYSTEM
|
||||
M: Martyn Welch <martyn.welch@ge.com>
|
||||
M: Martyn Welch <martyn@welchs.me.uk>
|
||||
M: Manohar Vanga <manohar.vanga@gmail.com>
|
||||
M: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
||||
L: devel@driverdev.osuosl.org
|
||||
@@ -11239,7 +11253,6 @@ VOLTAGE AND CURRENT REGULATOR FRAMEWORK
|
||||
M: Liam Girdwood <lgirdwood@gmail.com>
|
||||
M: Mark Brown <broonie@kernel.org>
|
||||
L: linux-kernel@vger.kernel.org
|
||||
W: http://opensource.wolfsonmicro.com/node/15
|
||||
W: http://www.slimlogic.co.uk/?p=48
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
|
||||
S: Supported
|
||||
@@ -11253,6 +11266,7 @@ L: netdev@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/net/vrf.c
|
||||
F: include/net/vrf.h
|
||||
F: Documentation/networking/vrf.txt
|
||||
|
||||
VT1211 HARDWARE MONITOR DRIVER
|
||||
M: Juerg Haefliger <juergh@gmail.com>
|
||||
@@ -11368,17 +11382,15 @@ WM97XX TOUCHSCREEN DRIVERS
|
||||
M: Mark Brown <broonie@kernel.org>
|
||||
M: Liam Girdwood <lrg@slimlogic.co.uk>
|
||||
L: linux-input@vger.kernel.org
|
||||
T: git git://opensource.wolfsonmicro.com/linux-2.6-touch
|
||||
W: http://opensource.wolfsonmicro.com/node/7
|
||||
W: https://github.com/CirrusLogic/linux-drivers/wiki
|
||||
S: Supported
|
||||
F: drivers/input/touchscreen/*wm97*
|
||||
F: include/linux/wm97xx.h
|
||||
|
||||
WOLFSON MICROELECTRONICS DRIVERS
|
||||
L: patches@opensource.wolfsonmicro.com
|
||||
T: git git://opensource.wolfsonmicro.com/linux-2.6-asoc
|
||||
T: git git://opensource.wolfsonmicro.com/linux-2.6-audioplus
|
||||
W: http://opensource.wolfsonmicro.com/content/linux-drivers-wolfson-devices
|
||||
T: git https://github.com/CirrusLogic/linux-drivers.git
|
||||
W: https://github.com/CirrusLogic/linux-drivers/wiki
|
||||
S: Supported
|
||||
F: Documentation/hwmon/wm83??
|
||||
F: arch/arm/mach-s3c64xx/mach-crag6410*
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
VERSION = 4
|
||||
PATCHLEVEL = 3
|
||||
SUBLEVEL = 0
|
||||
EXTRAVERSION = -rc2
|
||||
EXTRAVERSION = -rc3
|
||||
NAME = Hurr durr I'ma sheep
|
||||
|
||||
# *DOCUMENTATION*
|
||||
|
||||
@@ -242,7 +242,12 @@ pci_restore_srm_config(void)
|
||||
|
||||
void pcibios_fixup_bus(struct pci_bus *bus)
|
||||
{
|
||||
struct pci_dev *dev;
|
||||
struct pci_dev *dev = bus->self;
|
||||
|
||||
if (pci_has_flag(PCI_PROBE_ONLY) && dev &&
|
||||
(dev->class >> 8) == PCI_CLASS_BRIDGE_PCI) {
|
||||
pci_read_bridge_bases(bus);
|
||||
}
|
||||
|
||||
list_for_each_entry(dev, &bus->devices, bus_list) {
|
||||
pdev_save_srm_config(dev);
|
||||
|
||||
@@ -252,10 +252,10 @@
|
||||
};
|
||||
|
||||
vdd1_reg: regulator@2 {
|
||||
/* VDD_MPU voltage limits 0.95V - 1.26V with +/-4% tolerance */
|
||||
/* VDD_MPU voltage limits 0.95V - 1.325V with +/-4% tolerance */
|
||||
regulator-name = "vdd_mpu";
|
||||
regulator-min-microvolt = <912500>;
|
||||
regulator-max-microvolt = <1312500>;
|
||||
regulator-max-microvolt = <1378000>;
|
||||
regulator-boot-on;
|
||||
regulator-always-on;
|
||||
};
|
||||
|
||||
@@ -98,13 +98,6 @@
|
||||
pinctrl-0 = <&extcon_usb1_pins>;
|
||||
};
|
||||
|
||||
extcon_usb2: extcon_usb2 {
|
||||
compatible = "linux,extcon-usb-gpio";
|
||||
id-gpio = <&gpio7 24 GPIO_ACTIVE_HIGH>;
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&extcon_usb2_pins>;
|
||||
};
|
||||
|
||||
hdmi0: connector {
|
||||
compatible = "hdmi-connector";
|
||||
label = "hdmi";
|
||||
@@ -326,12 +319,6 @@
|
||||
>;
|
||||
};
|
||||
|
||||
extcon_usb2_pins: extcon_usb2_pins {
|
||||
pinctrl-single,pins = <
|
||||
0x3e8 (PIN_INPUT_PULLUP | MUX_MODE14) /* uart1_ctsn.gpio7_24 */
|
||||
>;
|
||||
};
|
||||
|
||||
tpd12s015_pins: pinmux_tpd12s015_pins {
|
||||
pinctrl-single,pins = <
|
||||
0x3b0 (PIN_OUTPUT | MUX_MODE14) /* gpio7_10 CT_CP_HPD */
|
||||
@@ -432,7 +419,7 @@
|
||||
};
|
||||
|
||||
ldo3_reg: ldo3 {
|
||||
/* VDDA_1V8_PHY */
|
||||
/* VDDA_1V8_PHYA */
|
||||
regulator-name = "ldo3";
|
||||
regulator-min-microvolt = <1800000>;
|
||||
regulator-max-microvolt = <1800000>;
|
||||
@@ -440,6 +427,15 @@
|
||||
regulator-boot-on;
|
||||
};
|
||||
|
||||
ldo4_reg: ldo4 {
|
||||
/* VDDA_1V8_PHYB */
|
||||
regulator-name = "ldo4";
|
||||
regulator-min-microvolt = <1800000>;
|
||||
regulator-max-microvolt = <1800000>;
|
||||
regulator-always-on;
|
||||
regulator-boot-on;
|
||||
};
|
||||
|
||||
ldo9_reg: ldo9 {
|
||||
/* VDD_RTC */
|
||||
regulator-name = "ldo9";
|
||||
@@ -495,6 +491,14 @@
|
||||
gpio-controller;
|
||||
#gpio-cells = <2>;
|
||||
};
|
||||
|
||||
extcon_usb2: tps659038_usb {
|
||||
compatible = "ti,palmas-usb-vid";
|
||||
ti,enable-vbus-detection;
|
||||
ti,enable-id-detection;
|
||||
id-gpios = <&gpio7 24 GPIO_ACTIVE_HIGH>;
|
||||
};
|
||||
|
||||
};
|
||||
|
||||
tmp102: tmp102@48 {
|
||||
@@ -517,7 +521,8 @@
|
||||
mcp_rtc: rtc@6f {
|
||||
compatible = "microchip,mcp7941x";
|
||||
reg = <0x6f>;
|
||||
interrupts = <GIC_SPI 2 IRQ_TYPE_EDGE_RISING>; /* IRQ_SYS_1N */
|
||||
interrupts-extended = <&crossbar_mpu GIC_SPI 2 IRQ_TYPE_EDGE_RISING>,
|
||||
<&dra7_pmx_core 0x424>;
|
||||
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&mcp79410_pins_default>;
|
||||
@@ -579,7 +584,6 @@
|
||||
pinctrl-0 = <&mmc1_pins_default>;
|
||||
|
||||
vmmc-supply = <&ldo1_reg>;
|
||||
vmmc_aux-supply = <&vdd_3v3>;
|
||||
bus-width = <4>;
|
||||
cd-gpios = <&gpio6 27 0>; /* gpio 219 */
|
||||
};
|
||||
@@ -623,6 +627,14 @@
|
||||
};
|
||||
|
||||
&usb2 {
|
||||
/*
|
||||
* Stand alone usage is peripheral only.
|
||||
* However, with some resistor modifications
|
||||
* this port can be used via expansion connectors
|
||||
* as "host" or "dual-role". If so, provide
|
||||
* the necessary dr_mode override in the expansion
|
||||
* board's DT.
|
||||
*/
|
||||
dr_mode = "peripheral";
|
||||
};
|
||||
|
||||
@@ -681,7 +693,7 @@
|
||||
|
||||
&hdmi {
|
||||
status = "ok"
|
||||
vdda-supply = <&ldo3_reg>;
|
||||
vdda-supply = <&ldo4_reg>;
|
||||
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&hdmi_pins>;
|
||||
|
||||
@@ -19,10 +19,10 @@
|
||||
|
||||
&cpsw_emac0 {
|
||||
phy_id = <&davinci_mdio>, <0>;
|
||||
phy-mode = "mii";
|
||||
phy-mode = "rgmii";
|
||||
};
|
||||
|
||||
&cpsw_emac1 {
|
||||
phy_id = <&davinci_mdio>, <1>;
|
||||
phy-mode = "mii";
|
||||
phy-mode = "rgmii";
|
||||
};
|
||||
|
||||
@@ -8,7 +8,7 @@
|
||||
#include "dm814x.dtsi"
|
||||
|
||||
/ {
|
||||
model = "DM8148 EVM";
|
||||
model = "HP t410 Smart Zero Client";
|
||||
compatible = "hp,t410", "ti,dm8148";
|
||||
|
||||
memory {
|
||||
@@ -19,10 +19,10 @@
|
||||
|
||||
&cpsw_emac0 {
|
||||
phy_id = <&davinci_mdio>, <0>;
|
||||
phy-mode = "mii";
|
||||
phy-mode = "rgmii";
|
||||
};
|
||||
|
||||
&cpsw_emac1 {
|
||||
phy_id = <&davinci_mdio>, <1>;
|
||||
phy-mode = "mii";
|
||||
phy-mode = "rgmii";
|
||||
};
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user