aboutsummaryrefslogtreecommitdiffstats
path: root/arch/arm64
AgeCommit message (Collapse)AuthorFilesLines
2020-07-16arm64: tegra: Add #{address,size}-cells for VI I2C on Tegra210Thierry Reding1-0/+3
The VI I2C controller provides an I2C bus and therefore needs to define the #address-cells and #size-cells properties. Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-07-16arm64: tegra: Add missing clocks and power-domains to Tegra210 VI I2CSowjanya Komatineni1-0/+6
Tegra210 VI I2C is in VE power domain and i2c-vi node should have power-domains property. Current Tegra210 i2c-vi device node is missing both VI I2C clocks and power-domains property. This patch adds them. Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-07-16arm64: Use test_tsk_thread_flag() for checking TIF_SINGLESTEPWill Deacon1-2/+2
Rather than open-code test_tsk_thread_flag() at each callsite, simply replace the couple of offenders with calls to test_tsk_thread_flag() directly. Signed-off-by: Will Deacon <will@kernel.org>
2020-07-16arm64: ptrace: Use NO_SYSCALL instead of -1 in syscall_trace_enter()Will Deacon1-2/+2
Setting a system call number of -1 is special, as it indicates that the current system call should be skipped. Use NO_SYSCALL instead of -1 when checking for this scenario, which is different from the -1 returned due to a seccomp failure. Cc: Mark Rutland <mark.rutland@arm.com> Cc: Keno Fischer <keno@juliacomputing.com> Cc: Luis Machado <luis.machado@linaro.org> Signed-off-by: Will Deacon <will@kernel.org>
2020-07-16arm64: syscall: Expand the comment about ptrace and syscall(-1)Will Deacon1-1/+15
If a task executes syscall(-1), we intercept this early and force x0 to be -ENOSYS so that we don't need to distinguish this scenario from one where the scno is -1 because a tracer wants to skip the system call using ptrace. With the return value set, the return path is the same as the skip case. Although there is a one-line comment noting this in el0_svc_common(), it misses out most of the detail. Expand the comment to describe a bit more about what is going on. Cc: Mark Rutland <mark.rutland@arm.com> Cc: Keno Fischer <keno@juliacomputing.com> Cc: Luis Machado <luis.machado@linaro.org> Signed-off-by: Will Deacon <will@kernel.org>
2020-07-16arm64: ptrace: Add a comment describing our syscall entry/exit trap ABIWill Deacon1-2/+14
Our tracehook logic for syscall entry/exit raises a SIGTRAP back to the tracer following a ptrace request such as PTRACE_SYSCALL. As part of this procedure, we clobber the reported value of one of the tracee's general purpose registers (x7 for native tasks, r12 for compat) to indicate whether the stop occurred on syscall entry or exit. This is a slightly unfortunate ABI, as it prevents the tracer from accessing the real register value and is at odds with other similar stops such as seccomp traps. Since we're stuck with this ABI, expand the comment in our tracehook logic to acknowledge the issue and describe the behaviour in more detail. Cc: Mark Rutland <mark.rutland@arm.com> Cc: Luis Machado <luis.machado@linaro.org> Reported-by: Keno Fischer <keno@juliacomputing.com> Signed-off-by: Will Deacon <will@kernel.org>
2020-07-16arm64: compat: Ensure upper 32 bits of x0 are zero on syscall returnWill Deacon2-1/+14
Although we zero the upper bits of x0 on entry to the kernel from an AArch32 task, we do not clear them on the exception return path and can therefore expose 64-bit sign extended syscall return values to userspace via interfaces such as the 'perf_regs' ABI, which deal exclusively with 64-bit registers. Explicitly clear the upper 32 bits of x0 on return from a compat system call. Cc: <stable@vger.kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Keno Fischer <keno@juliacomputing.com> Cc: Luis Machado <luis.machado@linaro.org> Signed-off-by: Will Deacon <will@kernel.org>
2020-07-16arm64: ptrace: Override SPSR.SS when single-stepping is enabledWill Deacon3-6/+20
Luis reports that, when reverse debugging with GDB, single-step does not function as expected on arm64: | I've noticed, under very specific conditions, that a PTRACE_SINGLESTEP | request by GDB won't execute the underlying instruction. As a consequence, | the PC doesn't move, but we return a SIGTRAP just like we would for a | regular successful PTRACE_SINGLESTEP request. The underlying problem is that when the CPU register state is restored as part of a reverse step, the SPSR.SS bit is cleared and so the hardware single-step state can transition to the "active-pending" state, causing an unexpected step exception to be taken immediately if a step operation is attempted. In hindsight, we probably shouldn't have exposed SPSR.SS in the pstate accessible by the GPR regset, but it's a bit late for that now. Instead, simply prevent userspace from configuring the bit to a value which is inconsistent with the TIF_SINGLESTEP state for the task being traced. Cc: <stable@vger.kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Keno Fischer <keno@juliacomputing.com> Link: https://lore.kernel.org/r/1eed6d69-d53d-9657-1fc9-c089be07f98c@linaro.org Reported-by: Luis Machado <luis.machado@linaro.org> Tested-by: Luis Machado <luis.machado@linaro.org> Signed-off-by: Will Deacon <will@kernel.org>
2020-07-16arm64: ptrace: Consistently use pseudo-singlestep exceptionsWill Deacon4-16/+23
Although the arm64 single-step state machine can be fast-forwarded in cases where we wish to generate a SIGTRAP without actually executing an instruction, this has two major limitations outside of simply skipping an instruction due to emulation. 1. Stepping out of a ptrace signal stop into a signal handler where SIGTRAP is blocked. Fast-forwarding the stepping state machine in this case will result in a forced SIGTRAP, with the handler reset to SIG_DFL. 2. The hardware implicitly fast-forwards the state machine when executing an SVC instruction for issuing a system call. This can interact badly with subsequent ptrace stops signalled during the execution of the system call (e.g. SYSCALL_EXIT or seccomp traps), as they may corrupt the stepping state by updating the PSTATE for the tracee. Resolve both of these issues by injecting a pseudo-singlestep exception on entry to a signal handler and also on return to userspace following a system call. Cc: <stable@vger.kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Tested-by: Luis Machado <luis.machado@linaro.org> Reported-by: Keno Fischer <keno@juliacomputing.com> Signed-off-by: Will Deacon <will@kernel.org>
2020-07-16arm64: dts: renesas: Restructure MakefileGeert Uytterhoeven1-24/+45
Make the Makefile for building Renesas DTB files easier to read and maintain: - Get rid of line continuations, - Use a single entry per line, - Sort SoCs and boards alphabetically, - Separate SoCs by blank lines. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Link: https://lore.kernel.org/r/20200706154015.29257-1-geert+renesas@glider.be
2020-07-16arm64: dts: renesas: cat875: Drop superfluous phy-modeGeert Uytterhoeven1-1/+0
The PHY mode already defaults to RGMII in the RZ/G2E base SoC DTS file, so there is no need to specify the same value in board files. Fixes: 6b170cd3ed02949f ("arm64: dts: renesas: cat875: Add ethernet support") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Link: https://lore.kernel.org/r/20200706151400.23105-1-geert+renesas@glider.be
2020-07-16arm64: dts: allwinner: h6: Fix Cedrus IOMMU usageMaxime Ripard1-0/+1
Now that the IOMMU driver has been introduced, it prevents any access from a DMA master going through it that hasn't properly mapped the pages, and that link is set up through the iommus property. Unfortunately we forgot to add that property to the video engine node when adding the IOMMU node, so now any DMA access is broken. Fixes: b3a0a2f910c7 ("arm64: dts: allwinner: h6: Add IOMMU") Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20200628180804.79026-1-maxime@cerno.tech
2020-07-15arm64: dts: qcom: msm8916-samsung-a2015: Add accelerometer/magnetometerStephan Gerhold3-0/+39
A3U/A5U both use a Bosch BMC150 accelerometer/magnetometer combo. The chip provides two separate I2C devices for the accelerometer and magnetometer that are already supported by the bmc150-accel and bmc150-magn driver. The only difference between A3U/A5U is the way the sensor is mounted on the mainboard - set the mount-matrix in the device-specific device tree part to handle that difference. Co-developed-by: Michael Srba <michael.srba@seznam.cz> Signed-off-by: Michael Srba <michael.srba@seznam.cz> Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20200622151751.408995-5-stephan@gerhold.net Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-07-15arm64: dts: qcom: msm8916: Use higher I2C drive-strength only on DB410cStephan Gerhold2-3/+19
Commit c240f29e75e6 ("arm64: dts: set the default i2c pin drive strength to 16mA") changed the default drive-strength for I2C pins in msm8916-pins.dtsi to the maximum possible (16 mA). While this makes sense for apq8016-sbc (DB410c) where you can connect an arbitrary amount of I2C devices with level shifters etc, there is no need to use a higher drive strength for other MSM8916 devices. The minimum drive strength (2 mA) seems to be totally sufficient to have everything work there. With the short pinctrl nodes introduced earlier we can easily override the drive-strength only for apq8016-sbc now. Use that and change the default back to 2 mA. i2c1_default/i2c5_default are already using 2 mA because they were added separately later and are not used in apq8016-sbc. Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20200622151751.408995-4-stephan@gerhold.net Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-07-15arm64: dts: qcom: msm8916: Simplify pinctrl configurationStephan Gerhold6-745/+426
So far we have been separating pinctrl entries into pinmux/pinconf. It turns out it is also possible to combine them: The advantage is that the device tree is overall more concise because the "pins" to configure just need to be specified once, not separately for pinmux/pinconf. Using the simpler form only for new entries would be rather confusing. This commit makes all MSM8916 device trees use the simplfied form. Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20200622151751.408995-3-stephan@gerhold.net Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-07-15arm64: dts: msm8916-samsung/longcheer: Move pinctrl/regulators to end of fileStephan Gerhold2-104/+104
It is helpful to be able to see all hardware components in one part of the device tree, without having to scroll over the large amount of regulator/pinctrl nodes. Keep those separated at the end of the file to make navigation a bit easier. This also makes it consistent with the order used in apq8016-sbc.dtsi. Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20200622151751.408995-2-stephan@gerhold.net Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-07-15arm64: dts: qcom: sm8250: Drop tcsr_mutex sysconBjorn Andersson1-8/+3
Now that we don't need the intermediate syscon to represent the TCSR mutexes, update the dts to describe the TCSR mutex directly under /soc. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Link: https://lore.kernel.org/r/20200622075956.171058-5-bjorn.andersson@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-07-15arm64: dts: qcom: sc7180: Add missing properties for Wifi nodeRakesh Pillai1-0/+3
The wlan firmware memory is statically mapped in the Trusted Firmware, hence the wlan driver does not need to map/unmap this region dynamically. Hence add the property to indicate the wlan driver to not map/unamp the firmware memory region dynamically. Also add the chain1 voltage supply for wlan. Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Rakesh Pillai <pillair@codeaurora.org> Link: https://lore.kernel.org/r/1594615586-17055-1-git-send-email-pillair@codeaurora.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-07-15arm64: dts: qcom: Fix WiFi supplies on sc7180-idpDouglas Anderson1-4/+4
The WiFi supplies that were added recently can't have done anything useful because they were missing the "-supply" suffix. Booting without the "-supply" suffix would give these messages: ath10k_snoc 18800000.wifi: 18800000.wifi supply vdd-0.8-cx-mx not found, using dummy regulator ath10k_snoc 18800000.wifi: 18800000.wifi supply vdd-1.8-xo not found, using dummy regulator ath10k_snoc 18800000.wifi: 18800000.wifi supply vdd-1.3-rfa not found, using dummy regulator ath10k_snoc 18800000.wifi: 18800000.wifi supply vdd-3.3-ch0 not found, using dummy regulator Let's add the "-supply" suffix. Tested-by: Rakesh Pillai <pillair@codeaurora.org> Reviewed-by: Rakesh Pillai <pillair@codeaurora.org> Fixes: 1e7594a38f37 ("arm64: dts: qcom: sc7180: Add WCN3990 WLAN module device node") Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20200625131658.REPOST.1.I32960cd32bb84d6db4127c906d7e371fa29caebf@changeid Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-07-15arm64: dts: spcfpga: Align GIC, NAND and UART nodenames with dtschemaKrzysztof Kozlowski1-4/+4
Fix dtschema validator warnings like: intc@fffc1000: $nodename:0: 'intc@fffc1000' does not match '^interrupt-controller(@[0-9a-f,]+)*$' Fixes: 78cd6a9d8e15 ("arm64: dts: Add base stratix 10 dtsi") Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2020-07-15arm64: dts: stratix10: increase QSPI reg address in nand dts fileDinh Nguyen1-3/+3
Match the QSPI reg address in the socfpga_stratix10_socdk.dts file. Fixes: 80f132d73709 ("arm64: dts: increase the QSPI reg address for Stratix10 and Agilex") Cc: linux-stable <stable@vger.kernel.org> # >= v5.6 Signed-off-by: Dinh Nguyen <dinh.nguyen@intel.com>
2020-07-15arm64: dts: stratix10: add status to qspi dts nodeDinh Nguyen2-0/+2
Add status = "okay" to QSPI node. Fixes: 0cb140d07fc75 ("arm64: dts: stratix10: Add QSPI support for Stratix10") Cc: linux-stable <stable@vger.kernel.org> # >= v5.6 Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2020-07-15arm64: dts: agilex: add status to qspi dts nodeDinh Nguyen1-0/+1
Add status = "okay" to QSPI node. Fixes: c4c8757b2d895 ("arm64: dts: agilex: add QSPI support for Intel Agilex") Cc: linux-stable <stable@vger.kernel.org> # >= v5.5 Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2020-07-15arm64: tlb: Use the TLBI RANGE feature in arm64Zhenyu Ye2-29/+131
Add __TLBI_VADDR_RANGE macro and rewrite __flush_tlb_range(). When cpu supports TLBI feature, the minimum range granularity is decided by 'scale', so we can not flush all pages by one instruction in some cases. For example, when the pages = 0xe81a, let's start 'scale' from maximum, and find right 'num' for each 'scale': 1. scale = 3, we can flush no pages because the minimum range is 2^(5*3 + 1) = 0x10000. 2. scale = 2, the minimum range is 2^(5*2 + 1) = 0x800, we can flush 0xe800 pages this time, the num = 0xe800/0x800 - 1 = 0x1c. Remaining pages is 0x1a; 3. scale = 1, the minimum range is 2^(5*1 + 1) = 0x40, no page can be flushed. 4. scale = 0, we flush the remaining 0x1a pages, the num = 0x1a/0x2 - 1 = 0xd. However, in most scenarios, the pages = 1 when flush_tlb_range() is called. Start from scale = 3 or other proper value (such as scale = ilog2(pages)), will incur extra overhead. So increase 'scale' from 0 to maximum, the flush order is exactly opposite to the example. Signed-off-by: Zhenyu Ye <yezhenyu2@huawei.com> Link: https://lore.kernel.org/r/20200715071945.897-4-yezhenyu2@huawei.com [catalin.marinas@arm.com: removed unnecessary masks in __TLBI_VADDR_RANGE] [catalin.marinas@arm.com: __TLB_RANGE_NUM subtracts 1] [catalin.marinas@arm.com: minor adjustments to the comments] [catalin.marinas@arm.com: introduce system_supports_tlb_range()] Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2020-07-15arm64: enable tlbi range instructionsZhenyu Ye2-0/+21
TLBI RANGE feature instoduces new assembly instructions and only support by binutils >= 2.30. Add necessary Kconfig logic to allow this to be enabled and pass '-march=armv8.4-a' to KBUILD_CFLAGS. Signed-off-by: Zhenyu Ye <yezhenyu2@huawei.com> Link: https://lore.kernel.org/r/20200715071945.897-3-yezhenyu2@huawei.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2020-07-15arm64: tlb: Detect the ARMv8.4 TLBI RANGE featureZhenyu Ye3-1/+15
ARMv8.4-TLBI provides TLBI invalidation instruction that apply to a range of input addresses. This patch detect this feature. Signed-off-by: Zhenyu Ye <yezhenyu2@huawei.com> Link: https://lore.kernel.org/r/20200715071945.897-2-yezhenyu2@huawei.com [catalin.marinas@arm.com: some renaming for consistency] Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2020-07-15arm64/hugetlb: Reserve CMA areas for gigantic pages on 16K and 64K configsAnshuman Khandual3-2/+42
Currently 'hugetlb_cma=' command line argument does not create CMA area on ARM64_16K_PAGES and ARM64_64K_PAGES based platforms. Instead, it just ends up with the following warning message. Reason being, hugetlb_cma_reserve() never gets called for these huge page sizes. [ 64.255669] hugetlb_cma: the option isn't supported by current arch This enables CMA areas reservation on ARM64_16K_PAGES and ARM64_64K_PAGES configs by defining an unified arm64_hugetlb_cma_reseve() that is wrapped in CONFIG_CMA. Call site for arm64_hugetlb_cma_reserve() is also protected as <asm/hugetlb.h> is conditionally included and hence cannot contain stub for the inverse config i.e !(CONFIG_HUGETLB_PAGE && CONFIG_CMA). Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com> Cc: Will Deacon <will@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Mike Kravetz <mike.kravetz@oracle.com> Cc: Barry Song <song.bao.hua@hisilicon.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Link: https://lore.kernel.org/r/1593578521-24672-1-git-send-email-anshuman.khandual@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2020-07-15arm64: tegra: Add clocks and resets for ISP on Tegra210Thierry Reding1-0/+6
The ISP blocks take a clock and a reset as inputs, so add those to the device tree nodes. Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-07-15arm64: tegra: Fix compatible string for DPAUX on Tegra210Thierry Reding1-1/+1
The Tegra210 DPAUX controller is not compatible with that found on Tegra124, so it must have a separate compatible string. Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-07-15arm64: tegra: Add i2c-bus subnode for DPAUX controllersThierry Reding1-0/+5
The DPAUX controller device tree bindings require the bus to have an i2c-bus subnode to distinguish between I2C clients and pinmux groups. Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-07-15arm64: tegra: Sort aliases alphabeticallyThierry Reding2-6/+6
Most device tree files already do this, so update the remaining ones for consistency. Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-07-15arm64: tegra: Remove spurious tabsThierry Reding1-12/+12
Remove tabs in places where they don't belong (i.e. where a single space is sufficient). Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-07-15arm64: tegra: Populate VBUS for USB3 on Jetson TX2Jon Hunter1-0/+1
The VBUS for USB3 connector on the Jetson TX2 is connected to the vdd_usb1 supply and although this is populated for the USB2 port on the USB3 connector it is not populated for the USB3 port and causes the following warning to be seen on boot ... usb3-0: supply vbus not found, using dummy regulator Fix this by also adding the VBUS supply to the USB3 port. Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-07-15arm64: tegra: Enable DFLL support on Jetson NanoJon Hunter1-0/+37
Populate the DFLL node and corresponding PWM pin nodes in order to enable CPUFREQ support on the Jetson Nano platform. Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-07-15arm64: tegra: Add support for Jetson Xavier NXJon Hunter3-0/+622
Add the device-tree source files for the Tegra194 Jetson Xavier NX Developer Kit. The Xavier NX Developer Kit consists of a small form factor system-on-module (SOM) board (part number p3668-0000) and a carrier board (part number p3509-0000). The Xavier NX Developer Kit SOM features a micro-SD card slot, however, there is also a variant of the SOM available that features a 16GB eMMC. Given that the carrier board can be used with the different SOM variants, that have different part numbers, both the compatible string and file name of the device-tree source file for the Developer Kit is a concatenation of the SOM and carrier board part numbers. Based on some initial work by Thierry Reding <treding@nvidia.com>. Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-07-15arm64: tegra: Re-order PCIe aperture mappingsVidya Sagar1-18/+18
Re-order Tegra194's PCIe aperture mappings to have IO window moved to 64-bit aperture and have the entire 32-bit aperture used for accessing the configuration space. This makes it to use the entire 32MB of the 32-bit aperture for ECAM purpose while booting through ACPI. Signed-off-by: Vidya Sagar <vidyas@nvidia.com> Acked-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-07-15arm64: tegra: Enable Tegra VI CSI support for Jetson NanoSowjanya Komatineni1-0/+10
This patch enables VI and CSI in device tree for Jetson Nano. Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-07-15arm64: tegra: jetson-tx1: Add camera suppliesSowjanya Komatineni1-0/+38
Jetson TX1 development board has a camera expansion connector which has 2V8, 1V8 and 1V2 supplies to power up the camera sensor on the supported camera modules. Camera module designed as per Jetson TX1 camera expansion connector may use these supplies for camera sensor avdd 2V8, digital core 1V8, and digital interface 1V2 voltages. These supplies are from fixed regulators on TX1 carrier board with enable control signals from I2C GPIO expanders. This patch adds these camera supplies to Jetson TX1 device tree to allow using these when a camera module is used. Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-07-15arm64: tegra: Fix order of XUSB controller clocksThierry Reding1-2/+2
This is purely to make the json-schema validation tools happy because they cannot deal with string arrays that may be in arbitrary order. Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-07-15arm64: tegra: Rename cbb@0 to bus@0 on Tegra194Thierry Reding3-17/+17
The control backbone is a simple-bus and hence its device tree node should be named "bus@<unit-address>" according to the bindings. Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-07-15arm64: tegra: Sort nodes by unit-address on Jetson NanoThierry Reding1-8/+8
Move the usb@700d0000 node to the correct place in the device tree, ordered by unit-address. Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-07-15arm64: tegra: Various fixes for PMICsThierry Reding2-26/+25
Standardize on "pmic" as the node name for the PMIC on Tegra210 systems and use consistent names for pinmux and GPIO hog nodes. Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-07-15arm64: tegra: Rename agic -> interrupt-controllerThierry Reding3-3/+3
Device tree nodes for interrupt controllers should be named "interrupt- controller", so rename the AGIC accordingly. Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-07-15arm64: tegra: Fix indentation in Tegra194 device treeThierry Reding1-1/+1
Properly indent subsequent lines so that they align with the first line. Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-07-15arm64: tegra: Fix indentation in Tegra132 device treeThierry Reding1-1/+1
Properly indent subsequent lines so that they align with the first line. Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-07-15arm64: tegra: Remove unused interrupts from Tegra194 AON GPIOThierry Reding1-4/+1
The AON GPIO controller on Tegra194 currently only uses a single interrupt, so remove the extra ones. Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-07-15arm64: tegra: Use standard names for SRAM nodesThierry Reding2-10/+6
SRAM nodes should be named sram@<unit-address> to match the bindings. While at it, also remove the unneeded, custom compatible string for SRAM partition nodes. Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-07-15arm64: tegra: Do not mark display hub as simple busThierry Reding2-2/+2
The display hub on Tegra186 and Tegra194 is not a simple bus, so drop the corresponding compatible string. Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-07-15arm64: tegra: Fix {clock,reset}-names orderingThierry Reding1-6/+6
It's very difficult to describe string lists that can be in arbitrary order using the json-schema based validation tooling. Since the OS is not going to care either way, take the easy way out and reorder these entries to match the order defined in the bindings. Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-07-15arm64: tegra: Remove XUSB pad controller interrupt from XUSB nodeThierry Reding2-4/+2
The XUSB controller doesn't need the XUSB pad controller's interrupt, so remove it. Signed-off-by: Thierry Reding <treding@nvidia.com>
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.