The pogoplug differs from the SheevaPlug only by a
few details, but especially in the led assignments.
This patch was tested under Gentoo Linux and is
based on dts files from Arch Linux ARM and OpenWrt.

Suggested-by: Felix Kaechele <heffer@fedoraproject.org>
Suggested-by: Oleg Rakhmanov <moonman.ca@gmail.com>
Signed-off-by: Christoph Junghans <ottxor@gentoo.org>
[Andrew Lunn <andrew@lunn.ch>: Fixed subject line]
Signed-off-by: Andrew Lunn <andrew@lunn.ch>

Due to the special handling of window 13 on Armada 375 and Armada 38x
(similar to Armada XP), the MBus hardware block is *not* compatible
with the one used on Armada 370. Using the Armada 370 compatible
string on Armada 375 and 38x will lead to a non-working device if
window 13 ends up being used.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>

The A388-GP is a board produced by Marvell that holds

- 1 PCIe slot
- 2 mini PCIe slot (one of them is multiplexed with the PCIe slot,
  muxing is selected through the GPIO expander)
- 1 16MB SPI-NOR
- 2 Gigabit Ethernet ports
- 4 SATA ports (2 of them are multiplexed with the mini PCIe slots,
  muxing is selected through the GPIO expander)
- 1 SDIO slot
- 1 USB3 port
- 2 USB2 port
- 2 GPIO/interrupts expander on I2C

Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>

This SoC belongs to the Armada 38x family. The main difference with
the Armada 385 is that the 388 can handle two more SATA
ports. Currently the consequence is the use of a different compatible
string for the pinctrl node, in order to be able to use the pins
associated to this 2 new SATA ports. The second SATA controller has
also been moved from the armada38x.dtsi as it it specific to the
Armada388 version.

In the same time the Armada385 DB and Armada 385 RD board have been
renamed in the 388 one and now include the armada-388.dtsi file. AS
both of them have 4 SATA ports the SoC used on them were wrongly
described.

Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>

The pintcrl label was missing. Adding it allowed referring it from the
root of the device tree. Also add the uart0 label used by the
bootloader.

Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>

With the Armada 385 GP board more pinctrl functions depending of the
SoC are needed. Add them to the DTSI to avoid duplication.

Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>

The A385-AP is a board produced by Marvell that holds 3 mPCIe slot, a 16MB
SPI-NOR, 3 Gigabit Ethernet ports, USB3 and NAND flash storage.

[gregory.clement@free-electrons.com: switch the license to the dual
X11/GPL with the agreement of the author]

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>

Some pinctrl functions can be shared with all DTS out there, since they are
generic, SoC-wide muxing options. Add a number of these to the DTSI to avoid
duplication.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>

The compatible set in the armada-38x DTSI is always overridden, and the reg
defined in there is duplicated in the armada-380 and armada-385 DTSIs.

Remove these useless items.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>

Some nodes in the DTs have a reg property but no unit name in their node name.

This contradicts the way the ePAPR defines the node names. Fix this.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>

This patch adds support for Seagate BlackArmor NAS220.

The Seagate BlackArmor NAS 220 is a NAS system based on Marvell 88f6192. It has
32MB NAND and 128MB DRAM. It has two SATA slots, one Gigabit Ethernet port, two
USB 2.0 ports, two buttons and three LEDs. There is a serial port available on
the CN5 connector on the board (1 - TX, 4 - RX, 6 - GND).

The only functionality still not implemented is the bi-color led on the front
panel (status). Pins mpp22 and mpp23 control this led. Setting mpp22 to high and
mpp23 to low results in orange color. Setting mpp22 to low and mpp23 to high
results in blue color.

The third led is wired to show the SATA activity on the two drives.

Signed-off-by: Evgeni Dobrev <evgeni@studio-punkt.com>
Acked-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>

This patch enables the phy drivers for the SATA controller on Marvell's 88f6192.
Without them it is not possible to use SATA drives attached to this processor.

Signed-off-by: Evgeni Dobrev <evgeni@studio-punkt.com>
Acked-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>

Iomega ix2-200 can be powered off via GPIO 0 pin 17,
this patch wires up the gpio-poweroff driver to do it.

Signed-off-by: Richard Kunze <richard.kunze@web.de>
Acked-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>

The original MTD partition layout for the Iomega ix2-200 leaves most of the
available space unused. This patch changes the layout to use all remaining
MTD space after the partitions for u-boot/u-boot-env and the kernel uimage
as a "rootfs" partition.

Signed-off-by: Richard Kunze <richard.kunze@web.de>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>

Drop the vendor-prefix from the "ti,system-power-controller" device-tree
property name.

It has been agreed to make "system-power-controller" a standard property
and to drop the vendor-prefix that is currently used by several drivers.

Note that drivers that have used "<vendor>,system-power-controller" in a
released kernel will need to support both versions.

Signed-off-by: Johan Hovold <johan@kernel.org>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Benot Cousson <bcousson@baylibre.com>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Felipe Balbi <balbi@ti.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Configure the RTC as system-power controller, which allows the system to
be powered off as well as woken up again on subsequent RTC alarms.

Note that the PMIC needs to be put in SLEEP (rather than OFF) mode to
maintain RTC power.  Specifically, this means that the PMIC
ti,pmic-shutdown-controller property must be left unset in order to be
able to wake up on RTC alarms.

Tested on BeagleBone Black (rev A5).

Signed-off-by: Johan Hovold <johan@kernel.org>
Reviewed-by: Felipe Balbi <balbi@ti.com>
Tested-by: Felipe Balbi <balbi@ti.com>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Benot Cousson <bcousson@baylibre.com>
Cc: Lokesh Vutla <lokeshvutla@ti.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Sekhar Nori <nsekhar@ti.com>
Cc: Tero Kristo <t-kristo@ti.com>
Cc: Keerthy J <j-keerthy@ti.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Enable am33xx specific RTC features (e.g. PMIC control) by adding
"ti,am3352-rtc" to the compatible property of the rtc node.

Signed-off-by: Johan Hovold <johan@kernel.org>
Reviewed-by: Felipe Balbi <balbi@ti.com>
Tested-by: Felipe Balbi <balbi@ti.com>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Benot Cousson <bcousson@baylibre.com>
Cc: Lokesh Vutla <lokeshvutla@ti.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Sekhar Nori <nsekhar@ti.com>
Cc: Tero Kristo <t-kristo@ti.com>
Cc: Keerthy J <j-keerthy@ti.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

The lcd0 node for am437x-sk-evm.dts contains bad LCD timings, and while
they seem to work with a quick test, doing for example blank/unblank
will give you a black display.

This patch updates the timings to the 'typical' values from the LCD spec
sheet.

Also, the compatible string is completely bogus, as
"osddisplays,osd057T0559-34ts" is _not_ a 480x272 panel. The panel on
the board is a newhaven one. Update the compatible string to reflect
this. Note that this hasn't caused any issues, as the "panel-dpi"
matches the driver.

Cc: <stable@vger.kernel.org> # v3.17+
Tested-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

As per the latest Data Manual, for newer samples,
the nominal voltage required for VDD_CORE at OPP_NOM can be
upto 1.06V which was 1.03V earlier.

Update the regulator max voltage constraint for SMPS7,
connected to VDD_CORE, to meet this requirement.

Document reference:
DRA74 Data Manual, SPRS857M - Dec 2012, Revised Oct 2014.
DRA72 Data Manual, SPRS906G - Dec 2012, revised Oct 2014.

Signed-off-by: Ravikumar Kattekola <rk@ti.com>
Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

The max expected voltage for VDD_GPU, connected to SMPS6, is 1.25V.
Correct regulator max voltage constraint to meet this requirement.

Document reference: DRA74 Data Manual, SPRS857M - Dec 2012,
		    Revised Oct 2014.

Fixes: c56a831c

 ("ARM: dts: DRA7: Add TPS659038 PMIC nodes")

Signed-off-by: Ravikumar Kattekola <rk@ti.com>
Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

Caused by a copy & paste error. Note that even with
this bug AM437x SK display still works because GPIO
mux mode is always enabled. It's still wrong to mux
somebody else's pin.

Luckily ball D25 (offset 0x238 - gpio5_8) on AM437x
isn't used for anything.

While at that, also replace a pullup with a pulldown
as that gpio should be normally low, not high.

Cc: <stable@vger.kernel.org> # v3.17+
Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

Commit f4d809ec55b6 ("ARM: dts: Fix gpmc timings for omap 2430sdp")
added GPMC timings for 2430sdp. This however broke the Ethernet
for some versions of u-boot using a different L3 clock frequency:

set_gpmc_timing_reg: GPMC error! CS5: cs_rd_off: 233 ns, 39 ticks > 31
omap-gpmc 6e000000.gpmc: failed to set gpmc timings for: ethernet

This is because the smsc91x timings from 1.1.4 u-boot overflow the
GPMC registers when booted with 1.1.3 version of u-boot.

Let's fix this issue by using the better timings from u-boot 1.1.3
as they also work on 1.1.4 and are faster.

Note that so far the attempts over the years to calculate the GPMC
timings on the SDP boards have failed probably because of the
unknown latencies added by the FPGA on the debug boards.

Reported-by: Nishanth Menon <nm@ti.com>
Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

This will enable use of physical arch timers on rk3288, where each
core comes out of reset with a different virtual offset.  Using
physical timers will help with SMP booting on coreboot and older
u-boot and should also allow suspend-resume and cpu-hotplug to work on
all firmwares.

Firmware which does initialize the cpu registers properly at boot and
cpu-hotplug can remove this property from the device tree.

Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Signed-off-by: Olof Johansson <olof@lixom.net>

We now have the physical-timers patches lined up as a dependency in this same
branch, so we can revert the temporary disablement.

This reverts commit b77d4394

.

Signed-off-by: Olof Johansson <olof@lixom.net>

Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>

Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>

Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>

Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>

Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>

Add iommus properties to the device tree nodes for the two display
controllers found on Tegra124. This will allow the display controllers
to map physically non-contiguous buffers to I/O virtual contiguous
address spaces so that they can be used for scan-out.

Signed-off-by: Thierry Reding <treding@nvidia.com>

Add iommus properties to the device tree nodes for the two display
controllers found on Tegra114. This will allow the display controllers
to map physically non-contiguous buffers to I/O virtual contiguous
address spaces so that they can be used for scan-out.

Signed-off-by: Thierry Reding <treding@nvidia.com>

Add iommus properties to the device tree nodes for the two display
controllers found on Tegra30. This will allow the display controllers to
map physically non-contiguous buffers to I/O virtual contiguous address
spaces so that they can be used for scan-out.

Signed-off-by: Thierry Reding <treding@nvidia.com>

Add the memory controller and wire up the interrupt that is used to
report errors. Provide a reference to the memory controller clock and
mark the device as being an IOMMU by adding an #iommu-cells property.

Signed-off-by: Thierry Reding <treding@nvidia.com>

Add the device tree node for the memory controller found on Tegra114
SoCs. The memory controller integrates an IOMMU (called SMMU) as well as
various knobs to tweak memory accesses by the various clients.

The old IOMMU device tree node is collapsed into the memory controller
node to more accurately describe the hardware. While this change is
incompatible, the IOMMU driver has never had any users so the change is
not going to cause any breakage.

Signed-off-by: Thierry Reding <treding@nvidia.com>

Collapses the old memory-controller and IOMMU device tree nodes into a
single node to more accurately describe the hardware.

While this is an incompatible change there are no users of the IOMMU on
Tegra, even though a driver has existed for some time.

Signed-off-by: Thierry Reding <treding@nvidia.com>

This patch adds the APB_MISC_GP_MIPI_PAD_CTRL_0 as a pin-control bank on
Tegra124 so the new MIPI pad control group can be muxed between CSI and
DSI_B.

Signed-off-by: Sean Paul <seanpaul@chromium.org>
Acked-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>

vsys is the core always-on supply of the Marsboard.

Signed-off-by: Romain Perier <romain.perier@gmail.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>

IRQ support for Broadcom's bus-axi driver bcma was merged into John
Linville's wireless tree and will show up in 3.19. This patch makes use
of this feature in the DTS file for the the BCM5301X SoCs. I left the
PCIe controller out, because this still needs some discussion.

Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>

Add a DTS describing the Digilent ZYBO board. Similar to ZED but with
a 50MHz crystal instead of 33MHz.

Acked-by: Soren Brinkmann <soren.brinkmann@xilinx.com>
Signed-off-by: Peter Crosthwaite <crosthwaite.peter@gmail.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>

The fact that all supported boards use the same 33MHz crystal is a
co-incidence. The Zynq PS support a range of crystal freqs so the
hardcoded setting should be removed from the dtsi. Re-implement it
on the board level.

This prepares support for Zynq boards with different crystal
frequencies (e.g. the Digilent ZYBO).

Acked-by: Soren Brinkmann <soren.brinkmann@xilinx.com>
Signed-off-by: Peter Crosthwaite <crosthwaite.peter@gmail.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>