Most if not all boards we've seen have a fixed 5V regulator, which is
the main power supply and/or fixed output of the PMIC.

Add this one to the common regulators DTSI.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

The current GPL only licensing on the DTSI makes it very impractical for other
software components licensed under another license.

In order to make it easier for them to reuse our device trees, relicense our
DTSI first under a GPL/X11 dual-license. Hopefully, the DTS will follow soon.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>

The current GPL only licensing on the DTSI makes it very impractical for other
software components licensed under another license.

In order to make it easier for them to reuse our device trees, relicense our
DTSI first under a GPL/X11 dual-license. Hopefully, the DTS will follow soon.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Alexander Bersenev <bay@hackerdom.ru>
Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Acked-by: Carlo Caione <carlo@caione.org>
Acked-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Emilio López <emilio@elopez.com.ar>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Acked-by: Oliver Schinagl <oliver@schinagl.nl>
Acked-by: Roman Byshko <rbyshko@gmail.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>

The current GPL only licensing on the DTSI makes it very impractical for other
software components licensed under another license.

In order to make it easier for them to reuse our device trees, relicense our
DTSI first under a GPL/X11 dual-license. Hopefully, the DTS will follow soon.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Boris BREZILLON <boris.brezillon@free-electrons.com>
Acked-by: Carlo Caione <carlo@caione.org>
Acked-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>

This patch adds support for Olimex A20-OLinuXino-LIME board.

Signed-off-by: FUKAUMI Naoki <naobsd@gmail.com>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

This adds support for the A20 Hummingbird:
http://www.merrii.com/en/pla_d.asp?id=171



This patch enable most on-board peripherals supported on current kernel,
such as uart, i2c, spi, pwm, ohci/ehci, gmac and mmc.

Reviewed-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Wills Wang <wills.wang.open@gmail.com>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

This patch add generic dts node for uart3/4/5, i2c3 and spi2.

Reviewed-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Wills Wang <wills.wang.open@gmail.com>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

The clock-frequency values of the i2c controller nodes match the
defaults of the driver. Remove the properties to use the defaults,
and be consistent with sun8i.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

i2c0 is connected to the gsl1680 capacitive touch panel controller.
i2c1 is connected to an mma7660 3-axis accelerometer.
i2c2 is connected to the front and back gc0309 camera sensors.
The camera sensors require additional regulators be enabled before
they are available.

All these peripherals are not supported by the kernel yet.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

Add nodes for the 3 i2c controllers found on A23 SoCs to the sun8i DTSI.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

This adds pin-muxing info for the i2c controller / port combinations
which are known to be used on actual boards.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

The card detect pin setting was taken from the original fex file,
and is confirmed to work.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

Add nodes for the 3 mmc controllers found on A23 SoCs to the sun8i DTSI.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

This adds pin-muxing info for the mmc controller / port combinations
which are known to be used on actual boards.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

The MMC module clocks on sun8i are the same as those found on
previous Allwinner SoCs, module 0 clocks.

This patch adds the clocks nodes to the dtsi with existing drivers.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

Now that we have R_PIO controller support and the pinmux for R_UART,
add the correct pinctrl properties to the R_UART node.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

R_UART is available on extra pads on certain tablets, which makes it
ideal for use as a console. Here we add the pins for it.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

uart0 on sun8i is only muxed with mmc0, which makes it a poor choice
for the console. However, some tablets only have pads for uart0
available on the circuit board.

Here we add the uart0 pinmux set for people who need it.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

Now that we have a driver for the R_PIO controller,
add the corresponding device node to the dtsi.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

Now that we have a driver for the sun8i PIO controller,
add the corresponding device node to the dtsi.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

All of our SPI controllers support DMA transfers, so let's add the
properties here so they can be used when it's best to do so.

Signed-off-by: Emilio López <emilio@elopez.com.ar>
Reviewed-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

All of our SPI controllers support DMA transfers, so let's add the
properties here so they can be used when it's best to do so.

Signed-off-by: Emilio López <emilio@elopez.com.ar>
Reviewed-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

All of our SPI controllers support DMA transfers, so let's add the
properties here so they can be used when it's best to do so.

Signed-off-by: Emilio López <emilio@elopez.com.ar>
Reviewed-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

The A20 SoC has a sun4i-compatible DMA controller. Let's add a node to
represent it on the device tree.

Signed-off-by: Emilio López <emilio@elopez.com.ar>
Reviewed-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

The A10S and A13 SoCs have sun4i-compatible DMA controllers. Let's add
the corresponding nodes to represent them on the device tree.

Signed-off-by: Emilio López <emilio@elopez.com.ar>
Reviewed-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

Let's add a node to represent the A10 DMA controller on the device tree.

Signed-off-by: Emilio López <emilio@elopez.com.ar>
Reviewed-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

Now that we have a driver for sun6i's rtc hardware, add a device node
for it so we can use it.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

sun8i shares the same rtc hardware as sun6i. Now that we have a driver
for it, add a device node to the DTSI for it so we can use it.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

Power efficiency improves on Baytrail (Intel Atom Processor E3000)
when Linux disables C6 auto-demotion.

Based on work by Srinidhi Kasagar <srinidhi.kasagar@intel.com>.

Signed-off-by: Len Brown <len.brown@intel.com>
Cc: x86@kernel.org

Signed-off-by: David S. Miller <davem@davemloft.net>

Perform a pci_claim_resource() on all valid resources discovered
during the OF device tree scan.

Based almost entirely upon the PCI OF bus probing code which does
the same thing there.

Signed-off-by: David S. Miller <davem@davemloft.net>

It seems that when a PCI Express bridge is not in use and has no devices
behind it, the ranges property is bogus.  Specifically the size property
is of the form [0xffffffff:...], and if you add this size to the resource
start address the 64-bit calculation will overflow.

Just check specifically for this size value signature and skip them.

Signed-off-by: David S. Miller <davem@davemloft.net>

Dump the various aspects of the PCI bridge probed at boot time, most
importantly the bridge number ranges, and the ranges property.

This helps diagnose PCI resource issues and other problems by giving
ofpci_debug=1 on the boot command line.

Signed-off-by: David S. Miller <davem@davemloft.net>

Add tracepoint to track hugepage invalidate. This help us
in debugging difficult to track bugs.

Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

On ppc64 we support 4K hash pte with 64K page size. That requires
us to track the hash pte slot information on a per 4k basis. We do that
by storing the slot details in the second half of pte page. The pte bit
_PAGE_COMBO is used to indicate whether the second half need to be
looked while building real_pte. We need to use read memory barrier while
doing that so that load of hidx is not reordered w.r.t _PAGE_COMBO
check. On the store side we already do a lwsync in __hash_page_4K

CC: <stable@vger.kernel.org>
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

We would get wrong results in compiler recomputed old_pmd. Avoid
that by using ACCESS_ONCE

CC: <stable@vger.kernel.org>
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

As per ISA, for 4k base page size we compare 14..65 bits of VA specified
with the entry_VA in tlb. That implies we need to make sure we do a
tlbie with all the possible 4k va we used to access the 16MB hugepage.
With 64k base page size we compare 14..57 bits of VA. Hence we cannot
ignore the lower 24 bits of va while tlbie .We also cannot tlb
invalidate a 16MB entry with just one tlbie instruction because
we don't track which va was used to instantiate the tlb entry.

CC: <stable@vger.kernel.org>
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

If we changed base page size of the segment, either via sub_page_protect
or via remap_4k_pfn, we do a demote_segment which doesn't flush the hash
table entries. We do a lazy hash page table flush for all mapped pages
in the demoted segment. This happens when we handle hash page fault for
these pages.

We use _PAGE_COMBO bit along with _PAGE_HASHPTE to indicate whether a
pte is backed by 4K hash pte. If we find _PAGE_COMBO not set on the pte,
that implies that we could possibly have older 64K hash pte entries in
the hash page table and we need to invalidate those entries.

Use _PAGE_COMBO to determine the page size with which we should
invalidate the hash table entries on unmap.

CC: <stable@vger.kernel.org>
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

If we changed base page size of the segment, either via sub_page_protect
or via remap_4k_pfn, we do a demote_segment which doesn't flush the hash
table entries. We do a lazy hash page table flush for all mapped pages
in the demoted segment. This happens when we handle hash page fault
for these pages.

We use _PAGE_COMBO bit along with _PAGE_HASHPTE to indicate whether a
pte is backed by 4K hash pte. If we find _PAGE_COMBO not set on the pte,
that implies that we could possibly have older 64K hash pte entries in
the hash page table and we need to invalidate those entries.

Handle this correctly for 16M pages

CC: <stable@vger.kernel.org>
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

The segment identifier and segment size will remain the same in
the loop, So we can compute it outside. We also change the
hugepage_invalidate interface so that we can use it the later patch

CC: <stable@vger.kernel.org>
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>