Adds AM33XX MMC support for am335x-bone, am335x-evm and am335x-evmsk boards.

Also added is the DMA binding definitions based on the generic DMA request
binding.

Additional changes made to DTS:
* Interrupt, reg and compatible properties added
* ti,needs-special-hs-handling added
Signed-off-by: NMatt Porter <mporter@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NJoel Fernandes <joelf@ti.com>
Signed-off-by: NBenoit Cousson <bcousson@baylibre.com>

Adds DMA resources to the AM33XX SPI nodes.
Signed-off-by: NMatt Porter <mporter@ti.com>
Signed-off-by: NJoel A Fernandes <joelagnel@ti.com>
Signed-off-by: NBenoit Cousson <bcousson@baylibre.com>

Adds AM33XX EDMA support to the am33xx.dtsi as documented in
Documentation/devicetree/bindings/dma/ti-edma.txt

[Joel Fernandes <joelf@ti.com>]
Drop DT entries that are non-hardware-description as discussed in [1]

[1] https://patchwork.kernel.org/patch/2226761/Signed-off-by: NMatt Porter <mporter@ti.com>
Signed-off-by: NJoel A Fernandes <joelagnel@ti.com>
Signed-off-by: NBenoit Cousson <bcousson@baylibre.com>

Without this node, there will be no palmas driver to notify
dwc3 that a cable has been connected and, without that, dwc3
will never initialize.
Signed-off-by: NFelipe Balbi <balbi@ti.com>
[kishon@ti.com: added dt properties for enabling vbus/id interrupts
and fixed vbus-supply value after SMPS10 is modeled as 2 regulators]
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NBenoit Cousson <bcousson@baylibre.com>

Use a common naming scheme "mode0name.modename flags" for the
USB host pins to be consistent.
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NBenoit Cousson <bcousson@baylibre.com>

This adds devicetree for gta04 (Openmoko next generation board) with necessary
support for mmc, usb, leds and button.
Signed-off-by: NMarek Belisko <marek@goldelico.com>
Signed-off-by: NBenoit Cousson <bcousson@baylibre.com>

Populate uarts, timers, rtc, wdt, gpio, i2c, spi, cpsw & pwm nodes.

Reason for adding these nodes early - hwmod code required address
space of peripherals corresponding to these nodes (as address space
details are removed from hwmod database).

uart0, timers - 1 & 2 and synctimer were already present, so here the
remaining uarts & timers are added.

All properties as per the existing binding has been added for uart,
timer, rtc, wdt & gpio. Even though that was not the current scope
of work, felt adding those would reduce or require no effort later
to get these peripherals working.

For i2c, spi, cpsw & pwm - only the properties that were sure to be
correct has been added (main intention is to make hwmod happy and
avoid any later modification to here added properties).

While at it add "ti,hwmod" property to already existing nodes.
Signed-off-by: NAfzal Mohammed <afzal@ti.com>
Signed-off-by: NBenoit Cousson <bcousson@baylibre.com>

Update AM4372 cpu node to the latest cpus/cpu bindings for ARM.
Signed-off-by: NAfzal Mohammed <afzal@ti.com>
Acked-by: NMark Rutland <mark.rutland@arm.com>
Signed-off-by: NBenoit Cousson <bcousson@baylibre.com>

Add minimal device tree source needed for DRA7 based SoCs.
Also add a board dts file for the dra7-evm (based on dra752)
which contains 1.5G of memory with 1G interleaved and 512MB
non-interleaved. Also added in the board file are pin configuration
details for i2c, mcspi and uart devices on board.
Signed-off-by: NR Sricharan <r.sricharan@ti.com>
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
Signed-off-by: NSourav Poddar <sourav.poddar@ti.com>
Signed-off-by: NBenoit Cousson <bcousson@baylibre.com>

The OMAP4 SoC family uses specially-designed PMIC (power management IC)
companion chip for power management needs: TWL6030/TWL6032.
Therefore there is a typical connection of PMIC to OMAP4 so we can
move it into separate .dtsi file and do not duplicate over
board-specific files.

Tested on OMAP4 SDP board and Pandaboard ES2.
Signed-off-by: NRuslan Bilovol <ruslan.bilovol@ti.com>
Signed-off-by: NBenoit Cousson <bcousson@baylibre.com>

Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NBenoit Cousson <bcousson@baylibre.com>

Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NBenoit Cousson <bcousson@baylibre.com>

Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NBenoit Cousson <bcousson@baylibre.com>

Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NBenoit Cousson <bcousson@baylibre.com>

Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NBenoit Cousson <bcousson@baylibre.com>

Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NBenoit Cousson <bcousson@baylibre.com>

Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NBenoit Cousson <bcousson@baylibre.com>

SMPS10 has two outputs OUT1 and OUT2. Hence SMPS10 is modeled as
two regulators. The DT node is split to reflect it.
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NBenoit Cousson <bcousson@baylibre.com>

Following commit ff5c9059 and therefore other omap platforms using
the gpio-omap driver correct the #interrupt-cells property on am33xx
too. The omap gpio binding documentaion also states that
the #interrupt-cells property should be 2.
Signed-off-by: NLars Poeschel <poeschel@lemonage.de>
Reviewed-by: NJavier Martinez Canillas <javier@dowhile0.org>
Acked-by: NMark Rutland <mark.rutland@arm.com>
Signed-off-by: NBenoit Cousson <bcousson@baylibre.com>

ARM Performance Monitor Units are available on the am33xx,
add the support in the dtsi.

Tested with perf and oprofile on a regular beaglebone.
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: NBenoit Cousson <bcousson@baylibre.com>

The IGEP COM MOdule has a GPIO LED connected to OMAP
pins. Configure this pin as output GPIO.
Signed-off-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
Tested-by: NEnric Balletbo i Serra <eballetbo@iseebcn.com>
Signed-off-by: NBenoit Cousson <bcousson@baylibre.com>

The IGEPv2 has a number of GPIO LED connected to OMAP
pins. Configure these pins as output GPIO.
Signed-off-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
Tested-by: NEnric Balletbo i Serra <eballetbo@iseebcn.com>
Signed-off-by: NBenoit Cousson <bcousson@baylibre.com>

IGEP boards have a number of LED connected to OMAP or TWL GPIO
lines. The actual wiring is different on each board so each board
DT has need to configure the mux correctly.

Even though it works with the current DT, the kernel complains with:

[2.305023] leds-gpio leds.18: pins are not configured from the driver

Add an empty pinmux_leds_pins pinctrl child node so boards can
override with the correct mux configuration and not depend on
default values for the GPIO LEDs to work.
Signed-off-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: NBenoit Cousson <bcousson@baylibre.com>

This adds device tree with necessary support to boot with functional
video (on both emulator and real N900 device).
Signed-off-by: NPavel Machek <pavel@ucw.cz>
Signed-off-by: NAaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: NBenoit Cousson <bcousson@baylibre.com>

This reverts commit 07f9b61c.

07f9b61c was intended to be a cleanup that didn't change anything, but in
fact, for systems without _CBA (which is almost everything), it broke
extended config space for domain 0 and all config space for other domains.

Reference: http://lkml.kernel.org/r/20131004011806.GE20450@dangermouse.emea.sgi.comReported-by: NHedi Berriche <hedi@sgi.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

When we do a treclaim or trecheckpoint we end up running with userspace
PPR and DSCR values.  Currently we don't do anything special to avoid
running with user values which could cause a severe performance
degradation.

This patch moves the PPR and DSCR save and restore around treclaim and
trecheckpoint so that we run with user values for a much shorter period.
More care is taken with the PPR as it's impact is greater than the DSCR.

This is similar to user exceptions, where we run HTM_MEDIUM early to
ensure that we don't run with a userspace PPR values in the kernel.
Signed-off-by: NMichael Neuling <mikey@neuling.org>
Cc: <stable@vger.kernel.org> # 3.9+
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

We can't take IRQs in tm_reclaim as we might have a bogus r13 and r1.

This turns IRQs hard off in this function.
Signed-off-by: NMichael Neuling <mikey@neuling.org>
Cc: <stable@vger.kernel.org> # 3.9+
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Commit 4df48999 "Add power8 EBB support" included a bug in the handling
of the FAB_CRESP_MATCH and FAB_TYPE_MATCH fields.

These values are pulled out of the event code using EVENT_THR_CTL_SHIFT,
however we were then or'ing that value directly into MMCR1.

This meant we were failing to set the FAB fields correctly, and also
potentially corrupting the value for PMC4SEL. Leading to no counts for
the FAB events and incorrect counts for PMC4.

The fix is simply to shift left the FAB value correctly before or'ing it
with MMCR1.
Reported-by: NSooraj Ravindran Nair <soonair3@in.ibm.com>
Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
Cc: <stable@vger.kernel.org> # 3.10+
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

modalias_show() should return an empty string on error, not -ENODEV.

This causes the following false and annoying error:

> find /sys/devices -name modalias -print0 | xargs -0 cat >/dev/null
cat: /sys/devices/vio/4000/modalias: No such device
cat: /sys/devices/vio/4001/modalias: No such device
cat: /sys/devices/vio/4002/modalias: No such device
cat: /sys/devices/vio/4004/modalias: No such device
cat: /sys/devices/vio/modalias: No such device
Signed-off-by: NPrarit Bhargava <prarit@redhat.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
CC: <stable@vger.kernel.org>

Under heavy (DLPAR?) stress, we tripped this panic() in
arch/powerpc/kernel/iommu.c::iommu_init_table():

	page = alloc_pages_node(nid, GFP_ATOMIC, get_order(sz));
	if (!page)
		panic("iommu_init_table: Can't allocate %ld bytes\n", sz);

Before the panic() we got a page allocation failure for an order-2
allocation. There appears to be memory free, but perhaps not in the
ATOMIC context. I looked through all the call-sites of
iommu_init_table() and didn't see any obvious reason to need an ATOMIC
allocation. Most call-sites in fact have an explicit GFP_KERNEL
allocation shortly before the call to iommu_init_table(), indicating we
are not in an atomic context. There is some indirection for some paths,
but I didn't see any locks indicating that GFP_KERNEL is inappropriate.

With this change under the same conditions, we have not been able to
reproduce the panic.
Signed-off-by: NNishanth Aravamudan <nacc@us.ibm.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
CC: <stable@vger.kernel.org>

arch/powerpc/kernel/sysfs.c exports PURR with write permission.
This may be valid for kernel in phyp mode. But writing to
the file in guest mode causes crash due to a priviledge violation
Signed-off-by: NMadhavan Srinivasan <maddy@linux.vnet.ibm.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
CC: <stable@vger.kernel.org>

The csum_partial_copy_generic() function saves the PowerPC non-volatile
r14, r15, and r16 registers for the main checksum-and-copy loop.
Unfortunately, it fails to restore them upon error exit from this loop,
which results in silent corruption of these registers in the presumably
rare event of an access exception within that loop.

This commit therefore restores these register on error exit from the loop.
Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: NAnton Blanchard <anton@samba.org>
Cc: stable@vger.kernel.org
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

The csum_partial_copy_generic() uses register r7 to adjust the remaining
bytes to process.  Unfortunately, r7 also holds a parameter, namely the
address of the flag to set in case of access exceptions while reading
the source buffer.  Lacking a quantum implementation of PowerPC, this
commit instead uses register r9 to do the adjusting, leaving r7's
pointer uncorrupted.
Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: NAnton Blanchard <anton@samba.org>
Cc: stable@vger.kernel.org
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Previous commit 46723bfa... introduced a new config option
HAVE_BOOTMEM_INFO_NODE that ended up breaking memory hot-remove for ppc
when sparse vmemmap is not defined.

This patch defines HAVE_BOOTMEM_INFO_NODE for ppc and adds the call to
register_page_bootmem_info_node. Without this we get a BUG_ON for memory
hot remove in put_page_bootmem().

This also adds a stub for register_page_bootmem_memmap to allow ppc to build
with sparse vmemmap defined. Leaving this as a stub is fine since the same
vmemmap addresses are also handled in vmemmap_populate and as such are
properly mapped.
Signed-off-by: NNathan Fontenot <nfont@linux.vnet.ibm.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
CC: <stable@vger.kernel.org> [v3.9+]

IORESOURCE_BUSY is used to mark temporary driver mem-resources
instead of global regions. This suppresses warnings if regions
overlap with a region marked as BUSY.

This was always the case for VESA/VGA/EFI framebuffer regions so
do the same for simplefb regions. The reason we do this is to
allow device handover to real GPU drivers like
i915/radeon/nouveau which get the same regions via PCI BARs.

Maybe at some point we will be able to unregister platform
devices properly during the handover. In this case the simplefb
region would get removed before the new region is created.
However, this is currently not the case and would require rather
huge changes in remove_conflicting_framebuffers(). Add the BUSY
marker now and try to eventually rewrite the handover for a next release.

Also see kernel/resource.c for more information:

  /*
   * if a resource is "BUSY", it's not a hardware resource
   * but a driver mapping of such a resource; we don't want
   * to warn for those; some drivers legitimately map only
   * partial hardware resources. (example: vesafb)
   */

This suppresses warnings like:

  ------------[ cut here ]------------
  WARNING: CPU: 2 PID: 199 at arch/x86/mm/ioremap.c:171 __ioremap_caller+0x2e3/0x390()
  Info: mapping multiple BARs. Your kernel is fine.
  Call Trace:
    dump_stack+0x54/0x8d
    warn_slowpath_common+0x7d/0xa0
    warn_slowpath_fmt+0x4c/0x50
    iomem_map_sanity_check+0xac/0xe0
    __ioremap_caller+0x2e3/0x390
    ioremap_wc+0x32/0x40
    i915_driver_load+0x670/0xf50 [i915]
    ...
Reported-by: NTom Gundersen <teg@jklm.no>
Tested-by: NTom Gundersen <teg@jklm.no>
Tested-by: NPavel Roskin <proski@gnu.org>
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
Link: http://lkml.kernel.org/r/1380724864-1757-1-git-send-email-dh.herrmann@gmail.comSigned-off-by: NIngo Molnar <mingo@kernel.org>

Previously, when a signal was registered with SA_SIGINFO, parameters 2
and 3 of the signal handler were written to registers r1 and r2 before
the register set was saved. This led to corruption of these two
registers after returning from the signal handler (the wrong values were
restored).
With this patch, registers are now saved before any parameters are
passed, thus maintaining the processor state from before signal entry.
Signed-off-by: NChristian Ruppert <christian.ruppert@abilis.com>
Signed-off-by: NVineet Gupta <vgupta@synopsys.com>

Turn on SDHCI for i.MX support so machines can boot with local rootfs
on SD. Tested on a Wandboard Quad.
Signed-off-by: NOlof Johansson <olof@lixom.net>
Reviewed-by: NFabio Estevam <fabio.estevam@freescale.com>

Commit ebd97be6 ('PCI: remove ARCH_SUPPORTS_MSI kconfig option')
removes the ARCH_SUPPORTS_MSI Kconfig option that allowed
architectures to indicate whether they support PCI MSI or not. Now,
PCI MSI support can be compiled in on any architecture thanks to the
use of weak functions thanks to 4287d824 ('PCI: use weak functions
for MSI arch-specific functions').

So, architecture specific code is now responsible to ensure that its
PCI MSI code builds in all cases, or be appropriately conditionally
compiled.

On Sparc, the MSI support is only provided for Sparc64, so the
ARCH_SUPPORTS_MSI kconfig option was only selected for SPARC64, and
not for the Sparc architecture as a whole. Therefore, removing
ARCH_SUPPORTS_MSI broke Sparc32 configurations with CONFIG_PCI_MSI=y,
because the Sparc-specific MSI code is not designed to be built on
Sparc32.

To solve this, this commit ensures that the Sparc MSI code is only
built on Sparc64. This is done thanks to a new Kconfig Makefile helper
option SPARC64_PCI_MSI, modeled after the existing SPARC64_PCI. The
SPARC64_PCI_MSI option is an hidden option that is true when both
Sparc64 PCI support is enabled and MSI is enabled. The
arch/sparc/kernel/pci_msi.c file is now only built when
SPARC64_PCI_MSI is true.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reported-by: NGuenter Roeck <linux@roeck-us.net>
Tested-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch proposes to remove the IRQF_DISABLED flag from sparc architecture
code. It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: NMichael Opdenacker <michael.opdenacker@free-electrons.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The length argument to strlcpy was still wrong. It could overflow the end of
full_boot_str by 5 bytes. Instead of strcat and strlcpy, just use snprint.
Reported-by: NBrad Spengler <spender@grsecurity.net>
Signed-off-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>