summaryrefslogtreecommitdiff
path: root/arch/arm/boot/dts/tegra124-jetson-tk1.dts
AgeCommit message (Collapse)Author
2015-01-23ARM: tegra: Add PMC thermtrip programming to Jetson TK1 device treeMikko Perttunen
This adds the required information to reset the board during an overheating situation to the Jetson TK1 device tree. The thermal reset is handled by the PMC by sending an I2C message to the PMIC. The entries specify the I2C message to be sent. Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2014-12-09Merge branch 'linus' of ↵Zhang Rui
git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal into eduardo-soc-thermal
2014-11-20ARM: tegra: Add thermal trip points for Jetson TK1Mikko Perttunen
This adds critical trip points to the Jetson TK1 device tree. The device will do a controlled shutdown when either the CPU, GPU or MEM thermal zone reaches 101 degrees Celsius. Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2014-11-13ARM: dts: tegra: move serial aliases to per-boardOlof Johansson
There are general changes pending to make the /aliases/serial* entries number the serial ports on the system. On Tegra, so far the ports have been just numbered dynamically as they are configured so that makes them change. To avoid this, add specific aliases per board to keep the old numbers. This allows us to change the numbering by default on future SoCs while keeping the numbering on existing boards. Signed-off-by: Olof Johansson <olof@lixom.net> Signed-off-by: Thierry Reding <treding@nvidia.com>
2014-09-17ARM: tegra: enable PCIe in Jetson TK1 DTThierry Reding
Enable both PCIe ports, one of which is connected to an onboard ethernet chip, whereas the other goes to a miniPCIe slot. Signed-off-by: Thierry Reding <treding@nvidia.com> [swarren, fixed PCIe supply property names in DT] Signed-off-by: Stephen Warren <swarren@nvidia.com>
2014-09-05ARM: tegra: rely on bootloader pinmux programming on Tegra124Stephen Warren
The defined mechanism for programming the Tegra pinmux is to perform all of the following at once in order, before using any I/O controller that is affected by the pinmux: - Set the CLAMP_INPUTS_WHEN_TRISTATED PMC register bit. - Set up any GPIO pins to their "initial" state. - Program all pinmux settings in one go. Other methods such as: - Not setting CLAMP_INPUTS_WHEN_TRISTATED. - Not setting GPIOs to their "initial" state before programming the pinmux settings of the related pin, in particular the mux function. - Not programming the entire pinmux at once, in order to avoid possible conflicting settings. ... are not qualified or supported by NVIDIA ASIC/syseng. They could cause glitches or undesired output levels on some pins, or controller malfunction. While we've been getting away with doing something different on many Tegra boards without issue, I believe we've just been getting lucky. I'd like to switch all Tegra124 systems to the correct scheme now so they provide the right example to follow, and require that any new boards we support upstream work in the same fashion. While it would be nice to update boards containing older SoCs for consistency, I don't anticipate doing so. It's too much churn to change at this time. At least with all Tegra124 boards converted, the most recent boards provide the correct example. Since the bootloader needs to reprogram the pinmux to access certain peripherals, it must program the entire pinmux due to the supported rules above. As such, there is no need to program any part of the pinmux from the kernel, unless dynamic pinmuxing is used. Given this, we couuld simply remove the pinmux "default" state from the DT entirely. However, some bootloaders parse the DT to perform their initial pinmux setup, so it's useful to keep the pinmux data in DT. To allow this while avoiding redundant work in the kernel, rename the "default" state to "boot". The kernel won't apply this, but bootloaders can still look for this state name and apply it. Note however that the DT provides zero information about the required initial GPIO setup, so bootloaders using this approach are not likely to operate correctly without an additional GPIO initialization table somewhere. Previous discussions on the DT mailing list have rejected adding such a table to DT... The following U-Boot commits fully initialize the pinmux: Jetson TK1: 4ff213b8e478 ARM: tegra: clamp inputs on Jetson TK1 Venice2: 3365479ce78a ARM: tegra: Venice2 pinmux spreadsheet updates Both are part of U-Boot v2014.07 and later. Without those commits, the only fallout I see from this change is that HDMI on Venice2 no longer works. Given the very small user-base of this platform, I feel that requiring a bootloader update is reasonable. Signed-off-by: Stephen Warren <swarren@nvidia.com>
2014-08-26ARM: tegra: add PCIe-related pins to the Jetson TK1 pinmux tablesStephen Warren
This pinmux tables currently omit any configuration for PCIe clk_req, wake, and rst pins, which in turn causes intermittent failures in U-Boot's PCIe support. Import an updated version of the pinmux tables which rectifies this. (While I'm still hoping to remove the pinmux tables from DTs for Tegra124+ devices, while they're still here, they may as well be complete and correct). Signed-off-by: Stephen Warren <swarren@nvidia.com>
2014-08-26ARM: tegra: Add SATA and SATA power to Jetson TK1 device treeMikko Perttunen
This enables the integrated SATA controller on the Tegra124 system-on-chip on the Jetson TK1 board and adds regulators for the onboard Molex connector commonly used to power SATA devices. The regulators are marked always-on since they can be used for other purposes than powering SATA devices. Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com> [swarren, fixed node sort order] Signed-off-by: Stephen Warren <swarren@nvidia.com>
2014-07-17ARM: tegra: Fix typoed ams,ext-control propertiesTuomas Tynkkynen
The property for enabling external rail control on the AS3722 is ams,ext-control, not ams,external-control. Since the external rail control property was previously being ignored, LP1 suspend on these boards wasn't actually turning the CPU rail off at all. Signed-off-by: Tuomas Tynkkynen <ttynkkynen@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2014-07-17ARM: tegra: jetson-tk1: Add XUSB pad controllerThierry Reding
Assign lanes to the XUSB pads as used on the Jetson TK1. Tested-by: Mikko Perttunen <mperttunen@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2014-07-17ARM: tegra: jetson-tk1: mark eMMC as non-removableLucas Stach
The eMMC is soldered to the board, reflect this in the DT. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com>
2014-04-29ARM: tegra: add SD wp-gpios to Jetson TK1 DTStephen Warren
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>
2014-04-28ARM: tegra: use correct audio CODEC on Jetson TK1Stephen Warren
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>
2014-04-28ARM: tegra: jetson-tk1 - Enable HDMI supportThierry Reding
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>
2014-04-16ARM: tegra: fix Jetson TK1 SD card supplyStephen Warren
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>
2014-04-15ARM: tegra: define Jetson TK1 regulatorsStephen Warren
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>
2014-04-15ARM: tegra: add Jetson TK1 device treeStephen Warren
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>