- May 16, 2014
-
-
Stefan Agner authored
This patch adds the device tree to support Toradex Colibri T30, a computer on module which can be used on different carrier boards. The module consists of a Tegra 30 SoC, two PMIC, DDR3L RAM, eMMC, a LM95245 temperature sensor and an AX88772B USB Ethernet Controller. Furthermore, there is a STMPE811 and SGTL5000 audio codec which are not yet supported. Anything that is not self contained on the module is disabled by default. The device tree for the Evaluation Board includes the modules device tree and enables the supported pheripherials of the carrier board (the Evaluation Board supports almost all of them). Signed-off-by: Stefan Agner <stefan@agner.ch> Signed-off-by: Stephen Warren <swarren@nvidia.com>
-
- May 13, 2014
-
-
Alexandre Courbot authored
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>
-
- May 07, 2014
-
-
Stephen Warren authored
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>
-
- May 03, 2014
-
-
Alexandre Courbot authored
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>
-
- Apr 30, 2014
-
-
Stephen Warren authored
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>
-
Stephen Warren authored
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>
-
- Apr 28, 2014
-
-
Stephen Warren authored
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>
-
Thierry Reding authored
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>
-
Thierry Reding authored
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>
-
Thierry Reding authored
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>
-
Thierry Reding authored
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>
-
Thierry Reding authored
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>
-
Thierry Reding authored
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>
-
Thierry Reding authored
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>
-
- Apr 17, 2014
-
-
Andrew Bresticker authored
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>
-
Stephen Warren authored
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>
-
Stephen Warren authored
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>
-
- Apr 16, 2014
-
-
Stephen Warren authored
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>
-
Stephen Warren authored
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>
-
- Apr 13, 2014
-
-
Paul Mackerras authored
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>
-
- Apr 12, 2014
-
-
Steven Miao authored
using IS_ENABLED() macro instead of defined(CONFIG_XXX) || defined(CONFIG_XXX_MODULE) Signed-off-by: Steven Miao <realmz6@gmail.com>
-
Steven Miao authored
Signed-off-by: Steven Miao <realmz6@gmail.com>
-
Paul Bolle authored
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>
-
Paul Bolle authored
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>
-
Paul Bolle authored
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>
-
Paul Bolle authored
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>
-
Sonic Zhang authored
Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
-
Sonic Zhang authored
Signed-off-by: Sonic Zhang <sonic.zhang@analog.com> Signed-off-by: Steven Miao <realmz6@gmail.com>
-
Steven Miao authored
Signed-off-by: Steven Miao <realmz6@gmail.com>
-
Steven Miao authored
drop unused head file change pinmux request/free macro for backward compatiblity add function declaration Signed-off-by: Steven Miao <realmz6@gmail.com>
-
H. Peter Anvin authored
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>
-
- Apr 11, 2014
-
-
Paul Bolle authored
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>
-
Paul Bolle authored
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>
-
Thomas Gleixner authored
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>
-
Paul Bolle authored
Signed-off-by: Paul Bolle <pebolle@tiscali.nl> Signed-off-by: Steven Miao <realmz6@gmail.com>
-
Russell King authored
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
WANG Chao authored
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>
-
Matt Fleming authored
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>
-
Matt Fleming authored
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>
-
Matt Fleming authored
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>
-