NVIDIA SHIELD is a portable Android console containing a Tegra 4 SoC with
2GB RAM and a 720p panel.

The following hardware is enabled by this device tree: UART, eMMC, USB
(needs external power), PMIC, backlight, joystick, SD card, GPIO keys.

DSI panel, HDMI output, charger, self-powered USB, audio, wifi bluetooth
are not supported yet but might be by future patches (likely in that
order).

Touch panel and sensors will probably never be supported.

Initrd addresses are hardcoded to match the static values used by the
bootloader, since it won't add them for us. All the same, a kernel
command-line is provided to replace the one passed by the
bootloader which is filled with garbage.

NVIDIA SHIELD is typically booted with an appended DTB to avoid
modifications made by the bootloader.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
[swarren, fixed gpio-keys child node sort order, patch description]
Signed-off-by: Stephen Warren <swarren@nvidia.com>

Venice2 can detect write-protect on the SD card. Add the required
DT entries to allow this.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
[swarren: fixed GPIO polarity per Thierry's testing]
Tested-by: Thierry Reding <treding@nvidia.com>

Tegra Note 7 is a consumer tablet embedding a Tegra 4 SoC with 1GB RAM
and a 720p panel.

The following hardware is enabled by this device tree: UART, eMMC, USB
(needs external power), PMIC, backlight, DSI panel, keys.

SD card, HDMI, charger, self-powered USB, audio, wifi, bluetooth are not
yet supported but might be by future patches (likely in that order).

Touch panel, sensors & cameras will probably never be supported.

Pinctrl is not set yet, as the bootloader-provided values allow us to
use the currently supported hardware.

Initrd addresses are hardcoded to match the static values used by the
bootloader, since it won't add them for us. All the same, a kernel
command-line is provided to replace the one passed by the bootloader
which is filled with garbage.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
[treding@nvidia.com: DT fixes, DSI panel support]
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>

Dalmore can detect write-protect on the SD card. Add the required
DT entries to allow this.

Signed-off-by: Stephen Warren <swarren@nvidia.com>

Jetson TK1 can detect write-protect on the SD card. Add the required
DT entries to allow this.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>

Jetson TK1 contains an RT5639 not an RT5640. While the two are extremely
similar and mostly compatible, we should still use the correct device
name in the device tree. I had meant to fix this before applying the
initial DT, but this issue slipped my mind.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>

The 1.2V supply for CSI and DSI was previously marked always-on. This is
suboptimal because it prevents the supply from being disabled when there
is no activity in the display or capture paths that it powers.

Hook up the regulator to the DSI output and mark it as not always-on, so
that it will only be enabled when DSI actually needs it.

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

This supply controls the +5V pin on the HDMI connector, which in turn is
used by attached sinks to return the hotplug detect signal.

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

This supply controls the +5V pin on the HDMI connector, which in turn is
used by attached sinks to return the hotplug detect signal.

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

This supply controls the +5V pin on the HDMI connector, which in turn is
used by attached sinks to return the hotplug detect signal.

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

Add HDMI +5V, VDD and PLL regulators and enable the DDC I2C controller.
Enable the HDMI device, provide the power supplies as well as the DDC
adapter and use pin the standard pin (PN7) for hotplug detection.

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

Add HDMI +5V, VDD and PLL regulators and enable the DDC I2C controller.
Enable the HDMI device, provide the power supplies as well as the DDC
adapter and use the standard pin (PN7) for hotplug detection.

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

Add a device node for the HDMI controller found on Tegra124.

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

VDDIO_SDMMC3 is the VQMMC (I/O) supply, not the VMMC (core) supply,
for the SD slot on Venice2.

Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Signed-off-by: Stephen Warren <swarren@nvidia.com>

This regulator supplies power to pretty much everything on the board, so
it doesn't make sense to allow it to turn off. Mark it boot-on and
always-on so it doesn't get turned off. Without this, I see issues with
the eMMC device; it can't be correctly detected during boot.

Signed-off-by: Stephen Warren <swarren@nvidia.com>

Regulator vddio_sdmmc3 provides the Tegra<->SD IO voltage, not the card
core supply voltage. That is, it provides vqmmc, not vmmc. Fix the DT to
correctly reflect this.

Reported-by: Andrew Bresticker <abrestic@chromium.org>
Signed-off-by: Stephen Warren <swarren@nvidia.com>

These are mostly identical to the Venice2 regulator definitions, since
the board designs are very similar. Differences are:

- Jetson TK1 doesn't have a built-in LCD panel, so on-board regulators
  are not present for the backlight, touchscreen, or panel.
- +3.3V_RUN needs to be boot-on/always-on, since it's widely used. This
  change should likely be propagated to Venice2 for completeness,
  although it will have no practical effect there since various other
  regulators use +3.3V_RUN as their supply and are always-on.
- +3.3V_LP0 needs to be boot-on as well as always-on. One reason
  is because it's used to driver the UART level-shifter; without this, I
  see a brief period of UART corruption during cold boots.I suspect this
  change needs to be propagated to Venice2, and we simply haven't noticed
  the need since there's no UART level-shifter on Venice2.
- A few rails have different names in the schematics.

Signed-off-by: Stephen Warren <swarren@nvidia.com>

Jetson TK1 is an NVIDIA Tegra124 development board, containing Tegra124,
2GB RAM, eMMC, SD card, SPI flash, serial port, PCIe Ethernet, HDMI,
audio, mini PCIe, JTAG, SATA, and an expansion IO connector containing
GPIOs, I2C, SPI, CSI, eDP, etc.

The following features work with this device tree: UART, SD card, eMMC,
SPI flash, USB (full-size jack, and mini-PCIe), audio, AS3722 RTC, system
power-off, suspend/resume (LP1) with wake via RTC alarm.

The following features should work with this device tree, but are not
validated: Expansion I2C, expansion SPI, expansion GPIO, gpio-key for the
power button.

The following features are not yet implemented in this device tree: Most
voltage regulators, expansion UART, HDMI, eDP, PCIe (Ethernet, and mini-
PCIe connector), CSI, SATA.

Signed-off-by: Stephen Warren <swarren@nvidia.com>

Commit 8f619b54

 ("powerpc/ppc64: Do not turn AIL (reloc-on
interrupts) too early") added code to set the AIL bit in the LPCR
without checking whether the kernel is running in hypervisor mode.  The
result is that when the kernel is running as a guest (i.e., under
PowerKVM or PowerVM), the processor takes a privileged instruction
interrupt at that point, causing a panic.  The visible result is that
the kernel hangs after printing "returning from prom_init".

This fixes it by checking for hypervisor mode being available before
setting LPCR.  If we are not in hypervisor mode, we enable relocation-on
interrupts later in pSeries_setup_arch using the H_SET_MODE hcall.

Signed-off-by: Paul Mackerras <paulus@samba.org>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

using IS_ENABLED() macro instead of defined(CONFIG_XXX) || defined(CONFIG_XXX_MODULE)

Signed-off-by: Steven Miao <realmz6@gmail.com>

Signed-off-by: Steven Miao <realmz6@gmail.com>

In v3.2 the Analog Devices ADT75 temperature sensor driver was removed
as an IIO driver and support for it was added to the LM75 HWMON driver.
But it was apparently overlooked to rename one reference to CONFIG_ADT75
to CONFIG_SENSORS_LM75. Do so now. Use the IS_ENABLED() macro, while
we're at it.

Signed-off-by: Paul Bolle <pebolle@tiscali.nl>

In v3.2 the Analog Devices AD7314 temperature sensor driver was removed
as an IIO driver and added as a HWMON driver. But it was apparently
overlooked to rename two references to CONFIG_AD7314 to
CONFIG_SENSORS_AD7314. Do so now. Use the IS_ENABLED() macro, while
we're at it.

Signed-off-by: Paul Bolle <pebolle@tiscali.nl>

In v3.2 the Analog Devices ad2s1200/ad2s1205 driver was renamed from
ad2s120x to ad2s1200. But it apparently forgot to rename the references
to this driver in the BF537-STAMP code. Rename these now, and use the
IS_ENABLED() macro, while we're at it.

Signed-off-by: Paul Bolle <pebolle@tiscali.nl>

There's a (rather subtle) typo in "CONFIG_SND_SOC_ADV80X_MODULE". Fix it
once and for all by using IS_ENABLED(), which is designed to avoid
issues like this.

Signed-off-by: Paul Bolle <pebolle@tiscali.nl>

Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>

Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
Signed-off-by: Steven Miao <realmz6@gmail.com>

Signed-off-by: Steven Miao <realmz6@gmail.com>

drop unused head file
change pinmux request/free macro for backward compatiblity
add function declaration

Signed-off-by: Steven Miao <realmz6@gmail.com>

The IRET instruction, when returning to a 16-bit segment, only
restores the bottom 16 bits of the user space stack pointer.  We have
a software workaround for that ("espfix") for the 32-bit kernel, but
it relies on a nonzero stack segment base which is not available in
32-bit mode.

Since 16-bit support is somewhat crippled anyway on a 64-bit kernel
(no V86 mode), and most (if not quite all) 64-bit processors support
virtualization for the users who really need it, simply reject
attempts at creating a 16-bit segment when running on top of a 64-bit
kernel.

Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Link: http://lkml.kernel.org/n/tip-kicdm89kzw9lldryb1br9od0@git.kernel.org
Cc: <stable@vger.kernel.org>

The only user of Kconfig symbol IP_CHECKSUM_L1 got removed in v2.6.33,
with commit ddf9ddac

 ("Blackfin: convert
to generic checksum code"). We can remove the Kconfig entry for this
unused symbol now.

Signed-off-by: Paul Bolle <pebolle@tiscali.nl>

The Kconfig symbol GENERIC_GPIO was removed in v3.10. Nothing cares
about it anymore. It popped up somehow in v3.13, so it can be removed
again.

Signed-off-by: Paul Bolle <pebolle@tiscali.nl>

There is nothing special in that blackfin code. Use the core
implementation.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Steven Miao <realmz6@gmail.com>
Cc: bfin <adi-buildroot-devel@lists.sourceforge.net>

Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Steven Miao <realmz6@gmail.com>

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

New kexec-tools wants to pass kdump kernel needed memmap via E820
directly, instead of memmap=exactmap. This makes saved_max_pfn not
be passed down to 2nd kernel. To keep 1st kernel and 2nd kernel using
the same TCE table size, Muli suggest to hard code the size to max (8M).

We can't get rid of saved_max_pfn this time, for backward compatibility
with old first kernel and new second kernel. However new first kernel
and old second kernel can not work unfortunately.

v2->v1:
- retain saved_max_pfn so new 2nd kernel can work with old 1st kernel
  from Vivek

Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Acked-by: Muli Ben-Yehuda <mulix@mulix.org>
Acked-by: Jon Mason <jdmason@kudzu.us>
Link: http://lkml.kernel.org/r/1394463120-26999-1-git-send-email-chaowang@redhat.com


Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>

We're currently passing the file handle for the root file system to
efi_file_read() and efi_file_close(), instead of the file handle for the
file we wish to read/close.

While this has worked up until now, it seems that it has only been by
pure luck. Olivier explains,

 "The issue is the UEFI Fat driver might return the same function for
  'fh->read()' and 'h->read()'. While in our case it does not work with
  a different implementation of EFI_SIMPLE_FILE_SYSTEM_PROTOCOL. In our
  case, we return a different pointer when reading a directory and
  reading a file."

Fixing this actually clears up the two functions because we can drop one
of the arguments, and instead only pass a file 'handle' argument.

Reported-by: Olivier Martin <olivier.martin@arm.com>
Reviewed-by: Olivier Martin <olivier.martin@arm.com>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>

code32_start should point at the start of the protected mode code, and
*not* at the beginning of the bzImage. This is much easier to do in
assembly so document that callers of make_boot_params() need to fill out
code32_start.

The fallout from this bug is that we would end up relocating the image
but copying the image at some offset, resulting in what appeared to be
memory corruption.

Reported-by: Thomas Bächler <thomas@archlinux.org>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>

commit 54b52d87

 ("x86/efi: Build our own EFI services pointer
table") introduced a regression because the 64-bit file_size()
implementation passed a pointer to a 32-bit data object, instead of a
pointer to a 64-bit object.

Because the firmware treats the object as 64-bits regardless it was
reading random values from the stack for the upper 32-bits.

This resulted in people being unable to boot their machines, after
seeing the following error messages,

    Failed to get file info size
    Failed to alloc highmem for files

Reported-by: Dzmitry Sledneu <dzmitry.sledneu@gmail.com>
Reported-by: Koen Kooi <koen@dominion.thruhere.net>
Tested-by: Koen Kooi <koen@dominion.thruhere.net>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>

Protect more options for x86 with cc-option so that we don't get errors when
using clang instead of gcc.  Add more or different options when using clang as
well. Also need to enforce that SSE is off for clang and the stack is 8-byte
aligned.

Signed-off-by: Jan-Simon Möller <dl9pf@gmx.de>
Signed-off-by: Behan Webster <behanw@converseincode.com>
Signed-off-by: Mark Charlebois <charlebm@gmail.com>