- Nov 09, 2016
-
-
Dinh Nguyen authored
Enable the QSPI node and add the flash chip. Signed-off-by: Dinh Nguyen <dinguyen@opensource.altera.com>
-
Dinh Nguyen authored
Add the QSPI device node for Arria10 SOC. Signed-off-by: Dinh Nguyen <dinguyen@opensource.altera.com>
-
Dinh Nguyen authored
Enable the qspi controller on the devkit and add the flash chip. Signed-off-by: Dinh Nguyen <dinguyen@opensource.altera.com>
-
Dinh Nguyen authored
Add a more specific board compatible entry for all of the SOCFPGA Cyclone 5 based boards. Signed-off-by: Dinh Nguyen <dinguyen@kernel.org> --- v3: Be a bit more specific with the c5 dk and sockit, use "altr,socfpga-cyclone5-socdk" and "terasic,socfpga-cyclone5-sockit" v2: remove extra space and add a comma between compatible entries
-
- Oct 19, 2016
-
-
Steffen Trumtrar authored
Enable the qspi controller on the socrates and add the flash chip. Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de> Signed-off-by: Dinh Nguyen <dinguyen@opensource.altera.com>
-
Steffen Trumtrar authored
Add the qspi node to the socfpga dtsi file. Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de> Signed-off-by: Dinh Nguyen <dinguyen@opensource.altera.com>
-
Thor Thayer authored
Add the LED framework to the Arria10 System Resource chip GPIO hooks. Signed-off-by: Thor Thayer <tthayer@opensource.altera.com> Signed-off-by: Dinh Nguyen <dinguyen@opensource.altera.com>
-
Thor Thayer authored
Enable the Altera Arria10 GPIO parent for MFD operation. Signed-off-by: Thor Thayer <tthayer@opensource.altera.com> Signed-off-by: Dinh Nguyen <dinguyen@opensource.altera.com>
-
Thor Thayer authored
Add the Altera Arria10 System Resource node. This is a Multi-Function device with GPIO expander support. Signed-off-by: Thor Thayer <tthayer@opensource.altera.com> Signed-off-by: Dinh Nguyen <dinguyen@opensource.altera.com>
-
Thor Thayer authored
Add the Altera Arria10 SPI Master Node in preparation for the A10SR MFD node. Signed-off-by: Thor Thayer <tthayer@opensource.altera.com> Signed-off-by: Dinh Nguyen <dinguyen@opensource.altera.com>
-
Dinh Nguyen authored
Enable the bit(22) shared-override bit for the SoCFPGA family. While at it, enable the prefetch-data and prefetch-instr settings for the Arria10. Signed-off-by: Dinh Nguyen <dinguyen@opensource.altera.com>
-
Nobuhiro Iwamatsu authored
Add support for board based on the Altera Cyclone V SoC. This board has the following functions: - 1 GiB of DRAM - 1 Gigabit ethernet - 1 SD card slot - 1 USB gadget port - QSPI NOR Flash - I2C EEPROMs and I2C RTC - DVI output - Audio port This commit supports without QSPI, DVI and Audio. Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org> Signed-off-by: Dinh Nguyen <dinguyen@opensource.altera.com>
-
Marek Vasut authored
The board is now manufactured by Aries Embedded GmbH, update compat string. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Dinh Nguyen <dinguyen@opensource.altera.com> Signed-off-by: Dinh Nguyen <dinguyen@opensource.altera.com>
-
- Oct 12, 2016
-
-
Masahiro Yamada authored
Kernel source files need not include <linux/kconfig.h> explicitly because the top Makefile forces to include it with: -include $(srctree)/include/linux/kconfig.h This commit removes explicit includes except the following: * arch/s390/include/asm/facilities_src.h * tools/testing/radix-tree/linux/kernel.h These two are used for host programs. Link: http://lkml.kernel.org/r/1473656164-11929-1-git-send-email-yamada.masahiro@socionext.com Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Jason Cooper authored
Currently, all callers to randomize_range() set the length to 0 and calculate end by adding a constant to the start address. We can simplify the API to remove a bunch of needless checks and variables. Use the new randomize_addr(start, range) call to set the requested address. Link: http://lkml.kernel.org/r/20160803233913.32511-4-jason@lakedaemon.net Signed-off-by: Jason Cooper <jason@lakedaemon.net> Acked-by: Kees Cook <keescook@chromium.org> Cc: "Russell King - ARM Linux" <linux@arm.linux.org.uk> Cc: "Theodore Ts'o" <tytso@mit.edu> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will.deacon@arm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
- Oct 08, 2016
-
-
Chris Metcalf authored
When doing an nmi backtrace of many cores, most of which are idle, the output is a little overwhelming and very uninformative. Suppress messages for cpus that are idling when they are interrupted and just emit one line, "NMI backtrace for N skipped: idling at pc 0xNNN". We do this by grouping all the cpuidle code together into a new .cpuidle.text section, and then checking the address of the interrupted PC to see if it lies within that section. This commit suitably tags x86 and tile idle routines, and only adds in the minimal framework for other architectures. Link: http://lkml.kernel.org/r/1472487169-14923-5-git-send-email-cmetcalf@mellanox.com Signed-off-by: Chris Metcalf <cmetcalf@mellanox.com> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Tested-by: Peter Zijlstra (Intel) <peterz@infradead.org> Tested-by: Daniel Thompson <daniel.thompson@linaro.org> [arm] Tested-by: Petr Mladek <pmladek@suse.com> Cc: Aaron Tomlin <atomlin@redhat.com> Cc: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> Cc: Russell King <linux@arm.linux.org.uk> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Chris Metcalf authored
Currently on arm there is code that checks whether it should call dump_stack() explicitly, to avoid trying to raise an NMI when the current context is not preemptible by the backtrace IPI. Similarly, the forthcoming arch/tile support uses an IPI mechanism that does not support generating an NMI to self. Accordingly, move the code that guards this case into the generic mechanism, and invoke it unconditionally whenever we want a backtrace of the current cpu. It seems plausible that in all cases, dump_stack() will generate better information than generating a stack from the NMI handler. The register state will be missing, but that state is likely not particularly helpful in any case. Or, if we think it is helpful, we should be capturing and emitting the current register state in all cases when regs == NULL is passed to nmi_cpu_backtrace(). Link: http://lkml.kernel.org/r/1472487169-14923-3-git-send-email-cmetcalf@mellanox.com Signed-off-by: Chris Metcalf <cmetcalf@mellanox.com> Tested-by: Daniel Thompson <daniel.thompson@linaro.org> [arm] Reviewed-by: Petr Mladek <pmladek@suse.com> Acked-by: Aaron Tomlin <atomlin@redhat.com> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> Cc: Russell King <linux@arm.linux.org.uk> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Chris Metcalf authored
Patch series "improvements to the nmi_backtrace code" v9. This patch series modifies the trigger_xxx_backtrace() NMI-based remote backtracing code to make it more flexible, and makes a few small improvements along the way. The motivation comes from the task isolation code, where there are scenarios where we want to be able to diagnose a case where some cpu is about to interrupt a task-isolated cpu. It can be helpful to see both where the interrupting cpu is, and also an approximation of where the cpu that is being interrupted is. The nmi_backtrace framework allows us to discover the stack of the interrupted cpu. I've tested that the change works as desired on tile, and build-tested x86, arm, mips, and sparc64. For x86 I confirmed that the generic cpuidle stuff as well as the architecture-specific routines are in the new cpuidle section. For arm, mips, and sparc I just build-tested it and made sure the generic cpuidle routines were in the new cpuidle section, but I didn't attempt to figure out which the platform-specific idle routines might be. That might be more usefully done by someone with platform experience in follow-up patches. This patch (of 4): Currently you can only request a backtrace of either all cpus, or all cpus but yourself. It can also be helpful to request a remote backtrace of a single cpu, and since we want that, the logical extension is to support a cpumask as the underlying primitive. This change modifies the existing lib/nmi_backtrace.c code to take a cpumask as its basic primitive, and modifies the linux/nmi.h code to use the new "cpumask" method instead. The existing clients of nmi_backtrace (arm and x86) are converted to using the new cpumask approach in this change. The other users of the backtracing API (sparc64 and mips) are converted to use the cpumask approach rather than the all/allbutself approach. The mips code ignored the "include_self" boolean but with this change it will now also dump a local backtrace if requested. Link: http://lkml.kernel.org/r/1472487169-14923-2-git-send-email-cmetcalf@mellanox.com Signed-off-by: Chris Metcalf <cmetcalf@mellanox.com> Tested-by: Daniel Thompson <daniel.thompson@linaro.org> [arm] Reviewed-by: Aaron Tomlin <atomlin@redhat.com> Reviewed-by: Petr Mladek <pmladek@suse.com> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> Cc: Russell King <linux@arm.linux.org.uk> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: David Miller <davem@davemloft.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Vineet Gupta authored
This came to light when implementing native 64-bit atomics for ARCv2. The atomic64 self-test code uses CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE to check whether atomic64_dec_if_positive() is available. It seems it was needed when not every arch defined it. However as of current code the Kconfig option seems needless - for CONFIG_GENERIC_ATOMIC64 it is auto-enabled in lib/Kconfig and a generic definition of API is present lib/atomic64.c - arches with native 64-bit atomics select it in arch/*/Kconfig and define the API in their headers So I see no point in keeping the Kconfig option Compile tested for: - blackfin (CONFIG_GENERIC_ATOMIC64) - x86 (!CONFIG_GENERIC_ATOMIC64) - ia64 Link: http://lkml.kernel.org/r/1473703083-8625-3-git-send-email-vgupta@synopsys.com Signed-off-by: Vineet Gupta <vgupta@synopsys.com> Cc: Richard Henderson <rth@twiddle.net> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: Matt Turner <mattst88@gmail.com> Cc: Russell King <linux@armlinux.org.uk> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will.deacon@arm.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: "James E.J. Bottomley" <jejb@parisc-linux.org> Cc: Helge Deller <deller@gmx.de> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: Chris Metcalf <cmetcalf@mellanox.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Vineet Gupta <vgupta@synopsys.com> Cc: Zhaoxiu Zeng <zhaoxiu.zeng@gmail.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Alexander Potapenko <glider@google.com> Cc: Andrey Ryabinin <aryabinin@virtuozzo.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: Ming Lin <ming.l@ssi.samsung.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Borislav Petkov <bp@suse.de> Cc: Andi Kleen <ak@linux.intel.com> Cc: Boqun Feng <boqun.feng@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
- Oct 06, 2016
-
-
Russell King authored
Commit 215e362d ("ARM: 8306/1: loop_udelay: remove bogomips value limitation") tried to increase the bogomips limitation, but in doing so messed up udelay such that it always gives about a 5% error in the delay, even if we use a timer. The calculation is: loops = UDELAY_MULT * us_delay * ticks_per_jiffy >> UDELAY_SHIFT Originally, UDELAY_MULT was ((UL(2199023) * HZ) >> 11) and UDELAY_SHIFT 30. Assuming HZ=100, us_delay of 1000 and ticks_per_jiffy of 1660000 (eg, 166MHz timer, 1ms delay) this would calculate: ((UL(2199023) * HZ) >> 11) * 1000 * 1660000 >> 30 => 165999 With the new values of 2047 * HZ + 483648 * HZ / 1000000 and 31, we get: (2047 * HZ + 483648 * HZ / 1000000) * 1000 * 1660000 >> 31 => 158269 which is incorrect. This is due to a typo - correcting it gives: (2147 * HZ + 483648 * HZ / 1000000) * 1000 * 1660000 >> 31 => 165999 i.o.w, the original value. Fixes: 215e362d ("ARM: 8306/1: loop_udelay: remove bogomips value limitation") Cc: <stable@vger.kernel.org> Reviewed-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
-
- Oct 03, 2016
-
-
Vladimir Zapolskiy authored
The change adds a new device node with description of generic SRAM on-chip memory found on NXP LPC32xx SoC series and connected to AHB matrix slave port 3. Note that NXP LPC3220 SoC has 128KiB of SRAM memory, the other LPC3230, LPC3240 and LPC3250 SoCs all have 256KiB SRAM space, in the shared DTSI file this change specifies 128KiB SRAM size. Also it's worth to mention that the SRAM area contains of 64KiB banks, 2 banks on LPC3220 and 4 banks on the other SoCs from the series, and all SRAM banks but the first one have independent power controls, the description of this feature will be added with the introduction of power domains for the SoC series. Signed-off-by: Vladimir Zapolskiy <vz@mleia.com> Cc: Sylvain Lemieux <slemieux.tyco@gmail.com> Signed-off-by: Olof Johansson <olof@lixom.net>
-
Srinivas Ramana authored
If the bootloader uses the long descriptor format and jumps to kernel decompressor code, TTBCR may not be in a right state. Before enabling the MMU, it is required to clear the TTBCR.PD0 field to use TTBR0 for translation table walks. The commit dbece458 ("ARM: 7501/1: decompressor: reset ttbcr for VMSA ARMv7 cores") does the reset of TTBCR.N, but doesn't consider all the bits for the size of TTBCR.N. Clear TTBCR.PD0 field and reset all the three bits of TTBCR.N to indicate the use of TTBR0 and the correct base address width. Fixes: dbece458 ("ARM: 7501/1: decompressor: reset ttbcr for VMSA ARMv7 cores") Acked-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Srinivas Ramana <sramana@codeaurora.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
- Sep 29, 2016
-
-
Roger Quadros authored
Since commit 6ce0d200 ("ARM: dma: Use dma_pfn_offset for dma address translation"), dma_to_pfn() already returns the PFN with the physical memory start offset so we don't need to add it again. This fixes USB mass storage lock-up problem on systems that can't do DMA over the entire physical memory range (e.g.) Keystone 2 systems with 4GB RAM can only do DMA over the first 2GB. [K2E-EVM]. What happens there is that without this patch SCSI layer sets a wrong bounce buffer limit in scsi_calculate_bounce_limit() for the USB mass storage device. dma_max_pfn() evaluates to 0x8fffff and bounce_limit is set to 0x8fffff000 whereas maximum DMA'ble physical memory on Keystone 2 is 0x87fffffff. This results in non DMA'ble pages being given to the USB controller and hence the lock-up. NOTE: in the above case, USB-SCSI-device's dma_pfn_offset was showing as 0. This should have really been 0x780000 as on K2e, LOWMEM_START is 0x80000000 and HIGHMEM_START is 0x800000000. DMA zone is 2GB so dma_max_pfn should be 0x87ffff. The incorrect dma_pfn_offset for the USB storage device is because USB devices are not correctly inheriting the dma_pfn_offset from the USB host controller. This will be fixed by a separate patch. Fixes: 6ce0d200 ("ARM: dma: Use dma_pfn_offset for dma address translation") Cc: stable@vger.kernel.org Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Santosh Shilimkar <santosh.shilimkar@oracle.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Olof Johansson <olof@lixom.net> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Linus Walleij <linus.walleij@linaro.org> Reported-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Robin Murphy authored
Whilst MPIDR values themselves are less than 32 bits, it is still perfectly valid for a DT to have #address-cells > 1 in the CPUs node, resulting in the "reg" property having leading zero cell(s). In that situation, the big-endian nature of the data conspires with the current behaviour of only reading the first cell to cause the kernel to think all CPUs have ID 0, and become resoundingly unhappy as a consequence. Take the full property length into account when parsing CPUs so as to be correct under any circumstances. Cc: Russell King <linux@armlinux.org.uk> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Jisheng Zhang authored
This patch fixes the following DTC warning with W=1: "Node /memory has a reg or ranges property, but no unit name" Signed-off-by: Jisheng Zhang <jszhang@marvell.com> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
-
Jisheng Zhang authored
This patch fixes the following DTC warning with W=1: "Node /memory has a reg or ranges property, but no unit name" Signed-off-by: Jisheng Zhang <jszhang@marvell.com> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
-
Jisheng Zhang authored
This patch fixes the following DTC warning with W=1: "Node /memory has a reg or ranges property, but no unit name" Signed-off-by: Jisheng Zhang <jszhang@marvell.com> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
-
Jisheng Zhang authored
This patch fixes the following DTC warning with W=1: "Node /soc has a reg or ranges property, but no unit name" Signed-off-by: Jisheng Zhang <jszhang@marvell.com> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
-
Jisheng Zhang authored
This patch fixes the following DTC warning with W=1: "Node /soc has a reg or ranges property, but no unit name" Signed-off-by: Jisheng Zhang <jszhang@marvell.com> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
-
Jisheng Zhang authored
This patch fixes the following DTC warning with W=1: "Node /soc has a reg or ranges property, but no unit name" Signed-off-by: Jisheng Zhang <jszhang@marvell.com> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
-
Jisheng Zhang authored
As noted in [1], "there are a number of problems with skeleton.dtsi, and it would be prefereable to remove it entirely." This patch is to remove skeleton.dtsi inclusion from berlin2. [1] http://www.spinics.net/lists/arm-kernel/msg528080.html Signed-off-by: Jisheng Zhang <jszhang@marvell.com> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
-
Jisheng Zhang authored
As noted in [1], "there are a number of problems with skeleton.dtsi, and it would be prefereable to remove it entirely." This patch is to remove skeleton.dtsi inclusion from berlin2cd. [1] http://www.spinics.net/lists/arm-kernel/msg528080.html Signed-off-by: Jisheng Zhang <jszhang@marvell.com> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
-
Jisheng Zhang authored
As noted in [1], "there are a number of problems with skeleton.dtsi, and it would be prefereable to remove it entirely." This patch is to remove skeleton.dtsi inclusion from berlin2q. [1] http://www.spinics.net/lists/arm-kernel/msg528080.html Signed-off-by: Jisheng Zhang <jszhang@marvell.com> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
-
Jisheng Zhang authored
After commit f29a72c2 ("watchdog: dw_wdt: Convert to use watchdog infrastructure"), the dw_wdt driver can support multiple variants, so unconditionally enable all dw_wdt nodes now. Signed-off-by: Jisheng Zhang <jszhang@marvell.com> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
-
Jisheng Zhang authored
After commit f29a72c2 ("watchdog: dw_wdt: Convert to use watchdog infrastructure"), the dw_wdt driver can support multiple variants, so unconditionally enable all dw_wdt nodes now. Signed-off-by: Jisheng Zhang <jszhang@marvell.com> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
-
Linus Walleij authored
The HTC GPIO driver is a pure GPIO driver and I just can not see what it is doing inside MFD. Let's just move it to GPIO and take this opportunity to move the platform data to <linux/platform_data/gpio-htc-egpio.h> Cc: arm@kernel.org Cc: Russell King <linux@armlinux.org.uk> Acked-by: Lee Jones <lee.jones@linaro.org> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
- Sep 28, 2016
-
-
Al Viro authored
externs and defines for stuff that is never used Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
-
- Sep 27, 2016
-
-
Krzysztof Kozlowski authored
The Exynos MIPI driver does not work anymore (it is board file only) so it is removed. Remove also config options. Cc: Inki Dae <inki.dae@samsung.com> Cc: Donghwa Lee <dh09.lee@samsung.com> Cc: Kyungmin Park <kyungmin.park@samsung.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Wei Ni authored
Enable throttle function for SOC_THERM. Set "hot" trips for cpu and gpu thermal zones, which can trigger the SOC_THERM hardware throttle. Signed-off-by: Wei Ni <wni@nvidia.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
-
Wei Ni authored
Set general "critical" trip temperatures for cpu, gpu, mem and pllx thermal zones for all Tegra124 platform, these trips can trigger shut down or reset. Tegra124 Jetson TK1 was already set "critical" trips before, so it can overwrite the general values. Signed-off-by: Wei Ni <wni@nvidia.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
-