There are two new mystery SoCs with very little public information
about them so far, Qualcomm's Cortex-A78C based "Shikra" and
Altera's Cortex-A720 based Agilex72 SOCFPGA.
We have also gained support for a couple of SoCs from the
2023/2024 timeframe that have been in the making for a while:
- The Apple platform gains support for M3 Pro, Max and Ultra SoC,
following the basic M3 support from 7.2.
- Samsung Exynos 1580 is a high-end mobile phone SoC from 2024
- Canaan K230 is a RISC-V based 64-bit AI SoC, based on the
earlier K210 chip
- Sophgo SG2000 is a mixed Arm/RISC-V chip that was already
supported using the Arm core but is now also added for RISC-V
along with several other variants of the cv18xx series
In terms of newly added machines we have reference platforms
for all the chips above, plus
- only four 32-bit Arm boards: two older phones and two
older industrial/embedded boards; using Allwinner, Qualcomm and
Rockchip SoCs
- Three laptops und three phones using Qualcomm SoCs
- Ten 64-bit Rockchips based single-board computers, along with one
NAS box and a game console.
- Seven industrial/embedded boards and modules using NXP i.MX8/9 SoCs.
- A Lenovo desktop box based on NVIDIA Jetson Xavier NX
- A few more single-board computers based on Allwinnner A133,
Spacemit K1 and TI AM62.
As usual, there is a constant stream of minor cleanups and fixes
towards addressing the 'dt-check-style --mode strict' warnings,
and everyone is expected to address those warnings for new
submissions now.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmqDZaMACgkQmmx57+YA
GNkkiRAAusVNTkNVcpq+QGDhd6DfLd+d4vcvTJkBZ5WyJuqKs1qZPFIMQ0iMW1cY
hahBeYoowRX1oaB7KZc/MBE0IkOna35CEwiL6dm553xq+P208auqpNLpXTSKWsvx
jW4eYpdA6Bt6SM9J/583Ix71b5UFsLV+W3YKT2CBUZYn9yilAEz6kPa/Hxxa1Sia
3841Fdy6jcqusw1alzLQvrR7FxdtPFCs1f/a/GzBmZI7fxnj/cBwVghinSF9F0XW
BzDaUjMDzBYqSlMb7auNH0IpDeVuTx2Pch+YLrE8YVVPVf3nawd48ziwXO6zRsGx
HccLDuHpBqwnHsAh+bWi9UdxUSzjGW4KQ/W8Fj6O2SNqxPqrK2hyRYMp+76Tl65x
2diQOajmnZ4m8E5ToWsxpRxrlo6TKo33W63HglGIA24vr0gEi9FpA3kYiaWP2ZBD
qZz5xMeRmO1son1vtWX1CzsWFdogqBuGdztOyMoY4viSeY/ltT1EvIC0AiTIeSOt
krOFFDxwHvu+HOPJJ15VCVwEutUnGytB2nwBc/krhNS6MSlwg9DpY53RAhBxl0Jh
KXpPqBUpbl0Flty2rxdPx2EAt7MqeLTNXSSdzP7tvvumsT1Ik+zlPk+MkgLZ0Y5u
71fJrcij+0LeFDCzw81jGLoYSCw+9aNaELcF+OluL6rK8YFaBOE=
=RQan
-----END PGP SIGNATURE-----
Merge tag 'soc-dt-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
Pull SoC devicetree updates from Arnd Bergmann:
"There are two new mystery SoCs with very little public information
about them so far, Qualcomm's Cortex-A78C based "Shikra" and Altera's
Cortex-A720 based Agilex72 SOCFPGA.
We have also gained support for a couple of SoCs from the 2023/2024
timeframe that have been in the making for a while:
- The Apple platform gains support for M3 Pro, Max and Ultra SoC,
following the basic M3 support from 7.2.
- Samsung Exynos 1580 is a high-end mobile phone SoC from 2024
- Canaan K230 is a RISC-V based 64-bit AI SoC, based on the earlier
K210 chip
- Sophgo SG2000 is a mixed Arm/RISC-V chip that was already supported
using the Arm core but is now also added for RISC-V along with
several other variants of the cv18xx series
In terms of newly added machines we have reference platforms for all
the chips above, plus
- Only four 32-bit Arm boards: two older phones and two older
industrial/embedded boards; using Allwinner, Qualcomm and Rockchip
SoCs
- Three laptops und three phones using Qualcomm SoCs
- Ten 64-bit Rockchips based single-board computers, along with one
NAS box and a game console.
- Seven industrial/embedded boards and modules using NXP i.MX8/9
SoCs.
- A Lenovo desktop box based on NVIDIA Jetson Xavier NX
- A few more single-board computers based on Allwinnner A133,
Spacemit K1 and TI AM62.
As usual, there is a constant stream of minor cleanups and fixes
towards addressing the 'dt-check-style --mode strict' warnings, and
everyone is expected to address those warnings for new submissions
now"
* tag 'soc-dt-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (864 commits)
Revert "riscv: dts: spacemit: k3: add i2s0-i2s5 nodes"
Documentation/process: maintainer-soc: Mention expectation about dt-check-style
ARM: dts: helios4: add SATA regulator supplies
ARM: dts: helios4: add vcc-supply to GPIO expander
ARM: dts: helios4: add vcc-supply to EEPROM
arm64: dts: turris-mox: fix usb3 phys
arm64: dts: ti: Correct white-space style
arm64: dts: ti: k3-am64: Fix MDIO clock reference for ICSSG0 node
arm64: dts: qcom: talos-evk: Fix swapped USB QMP PHY vdda-phy/vdda-pll supplies
arm64: dts: qcom: sa8155p-adp: Fix swapped USB and UFS QMP PHY vdda-phy/vdda-pll supplies
arm64: dts: qcom: eliza-mtp: Fix swapped USB QMP PHY vdda-phy/vdda-pll supplies
arm64: dts: qcom: lemans: Fix swapped USB QMP PHY vdda-phy/vdda-pll supplies
arm64: dts: qcom: glymur: Fix swapped USB QMP PHY vdda-phy/vdda-pll supplies
arm64: dts: qcom: kaanapali: Fix swapped USB QMP PHY vdda-phy/vdda-pll supplies
arm64: dts: qcom: sar2130p: Fix swapped USB QMP PHY vdda-phy/vdda-pll supplies
arm64: dts: qcom: sm8750: Fix swapped USB QMP PHY vdda-phy/vdda-pll supplies
arm64: dts: qcom: sm8650: Fix swapped USB QMP PHY vdda-phy/vdda-pll supplies
arm64: dts: qcom: purwa: Fix swapped USB QMP PHY vdda-phy/vdda-pll supplies
arm64: dts: qcom: hamoa: Fix swapped USB QMP PHY vdda-phy/vdda-pll supplies
arm64: dts: qcom: sc8180x: Fix swapped USB QMP PHY vdda-phy/vdda-pll supplies
...
Several non-functional (white-space and style) changes to match with DTS
coding style as reported by recent dt-check-style tool. Goal is to get
to no `dt-check-style --mode strict` warnings over time.
-----BEGIN PGP SIGNATURE-----
iQJEBAABCgAuFiEE3dJiKD0RGyM7briowTdm5oaLg9cFAmp0RMQQHGtyemtAa2Vy
bmVsLm9yZwAKCRDBN2bmhouD1wL5D/9pJn/QpXraZ9Mo6aY80EO6Ufun1uz+f2lM
Jp9V/O3cUFoc3+EgGcp4oh7JbwGdfEnad2pVm+CQjpSZL6uuBNCHO9WtIcGeL63t
k9xL1/7KttPmZBSCNfB2AUKFPPyhbUr+Fk3CjYUR5mAxsa5PgivJZSIE+JQ8RN6t
rByp6qip9cyfguuQLi7xVUou5n5nQcSJPqntCsgVm0Wk1nD/gyTxuyxDp2SGt9Rs
U9CobD6YuQi8TGpjFtBNALq98isZmuAF75mgYz2RHEtjYKmXGDl/a4TZ7K3295Qc
/ZkeLvnmWaLVnoQAaGKlb3cuEgvuuZumFThPj0jwmVQn153B6UPN/M9TVfrqgpG4
Scbh2+CEb3DGRCjsmEaDtT5qZnb+xv42wW79V/MDqVQaDN8kiUxAaT0/DNPaBCJN
A3J9BnJgEN6qXDt5ZTMo7OqQB2GUra4SOoWD+6F92zWBLHyAagfc39V9IlTA1I2b
i0kfmYPRr3ooqYf2eNQPnuftUqPqlvWeJKK+tczn1GPQnaDmcvIC6V0M8qTiW3CK
UJlogvgQqYfap2Cq9ZhjyYrVXZ0H+VqlSw2xCoezdggDQBmzP9K3JsvMe8DmCRXK
uOoKEXLrAJ5krINZuVbY0L9VYH4lYtV5Kof0WXPumyYmmpIObQrGtipJKdc4CFSQ
ymzW0L79Aw==
=GPP3
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmp59ekACgkQmmx57+YA
GNkT8RAAkONJBU/GkXcmT+RclfTwZ19FZO9Pq7p7gtOLkJg1GrE1//gIcG8stpp6
1Z9OPoF3PIonN36O8in7PARSmQlltqojSFdJ6lA26g9U8DwsMTQ9g7VKgewCxMDi
23zFVCOpKxSHsQlw8nGpIWKcrceUyTsZlyPG3mete95LeoJncxr63uf9NJOGTfWq
gYtC5/amVCyl2ZvXE8YTaWVXNZBa8D/9Ea4y5ZtoLT37vSqkRjE1bFo2qWfTLT5Q
Iex7iormr+jnIP+FSeMNWQomWpeKuE7O5NhkLrygCZsguPe5pgDDx11GYFZW541N
OKhtYe02A7PVnfkapwRG2vPchytSCWVVzcRnVfzNEqjIec2WjZQ+BkeSD3uLL+lu
DyZGAKmuWcMIdFQ6xsZolRpqkHb2CLnmMbiUDf5mNisa3uqJHqHyxv4jft7mRK2k
tNawkqFsOnf440yP8pPYB8FIP+79+LTaU4rIg54X8aC0SXpj8ImARG8ud10pwy7C
6Jj8nBGHqTFQgKrVfwC53MGw876/iW09ZK0ZFBdCwmH5MtKBX7cTA8Y1Tk8DYvdt
dVKUQFAKeK80J/M52ARQPcG+BPVagej6cSyvp2cMUvinhxGczrW3SpGn3nhG2iZK
QmPjhGUydB20d+Gah6e2YP7sH0MZn66E/FyodhuRgGTURqZjpKM=
=mVJT
-----END PGP SIGNATURE-----
Merge tag 'dt64-cleanup-7.3' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-dt into soc/dt
Minor improvements in arm64 DTS for v7.3
Several non-functional (white-space and style) changes to match with DTS
coding style as reported by recent dt-check-style tool. Goal is to get
to no `dt-check-style --mode strict` warnings over time.
* tag 'dt64-cleanup-7.3' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-dt:
arm64: dts: Correct white-space style
arm64: dts: amd: seattle: Remove useless xgbe DTSI include
arm64: dts: amd: seattle: Remove useless clocks DTSI include
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Correct a few white-space issues, like missing space before bracket '{'
character or spurious space, which will be flagged by dt-check-style
("redundant-whitespace" warning). No functional changes.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Michal Simek <michal.simek@amd.com> # Versal NET
Acked-by: Sven Peter <sven@kernel.org> # for apple dts
Link: https://patch.msgid.link/20260801210210.383417-4-krzysztof.kozlowski@oss.qualcomm.com
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
GPIO_ACTIVE_x flags are not correct in the context of interrupt flags.
These are simple defines so they could be used in DTS but they will not
have the same meaning:
1. GPIO_ACTIVE_HIGH = 0 => IRQ_TYPE_NONE
2. GPIO_ACTIVE_LOW = 1 => IRQ_TYPE_EDGE_RISING
Realtek RT5640 codec driver requests interrupt on rising edge, so correct
the interrupt flags, assuming the author of the code wanted the similar
logical behavior behind the name "ACTIVE_xxx", this is:
ACTIVE_HIGH => IRQ_TYPE_EDGE_RISING
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
GPIO_ACTIVE_x flags are not correct in the context of interrupt flags.
These are simple defines so they could be used in DTS but they will not
have the same meaning:
1. GPIO_ACTIVE_HIGH = 0 => IRQ_TYPE_NONE
2. GPIO_ACTIVE_LOW = 1 => IRQ_TYPE_EDGE_RISING
Realtek RT5640 codec driver requests interrupt on rising edge, so correct
the interrupt flags, assuming the author of the code wanted the similar
logical behavior behind the name "ACTIVE_xxx", this is:
ACTIVE_HIGH => IRQ_TYPE_EDGE_RISING
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
GPIO_ACTIVE_x flags are not correct in the context of interrupt flags.
These are simple defines so they could be used in DTS but they will not
have the same meaning:
1. GPIO_ACTIVE_HIGH = 0 => IRQ_TYPE_NONE
2. GPIO_ACTIVE_LOW = 1 => IRQ_TYPE_EDGE_RISING
Realtek RT5658 codec driver requests interrupt on both edges, so correct
the interrupt flags, assuming the author of the code wanted the similar
logical behavior behind the name "ACTIVE_xxx", this is:
ACTIVE_HIGH => IRQ_TYPE_EDGE_RISING
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Unlike older GIC variants, the GICv3 DT bindings do not support
specifying a CPU mask in PPI interrupt specifiers. Drop the masks.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Add initial device tree support for the Lenovo ThinkEdge SE70, an
industrial edge gateway based on the NVIDIA Jetson Xavier NX module
(P3668-0001) with a custom carrier board.
This initial submission includes:
- 40-pin expansion header pinmux configuration
- External Micro SD card slot with dedicated 3.3V regulator
- I2C bus for 40-pin header
Static verification passed: dt_binding_check and dtbs compilation
complete without errors.
Reviewed-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Jiqi Li <lijq9@lenovo.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Add the three pin controller (MAIN, UPHY, AON) device-tree nodes found on
Tegra264.
Signed-off-by: Prathamesh Shete <pshete@nvidia.com>
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The CMDQV interrupts on Tegra264 are described as level-triggered, but
per the hardware interrupt documentation these interrupts are actually
edge-triggered.
Correct the interrupt type for all CMDQV nodes from IRQ_TYPE_LEVEL_HIGH
to IRQ_TYPE_EDGE_RISING.
Fixes: fe57d0ac48 ("arm64: tegra: Add nodes for CMDQV")
Reported-by: Nicolin Chen <nicolinc@nvidia.com>
Signed-off-by: Ashish Mhetre <amhetre@nvidia.com>
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Acked-by: Nicolin Chen <nicolinc@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
We always sort by unit-address and fallback to alphanumeric sorting for
nodes that don't have a unit-address.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Tegra264 has a host1x instance with a VIC (video image compositor).
Other multimedia engines have moved outside host1x. Stream IDs are
now namespaced by device rather than being defined globally --
however, the only engine we have using context isolation is VIC so
we only define VIC's range of context devices.
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Add the remaining 12 CPU nodes and all 14 L2 cache nodes for the
Tegra264 CPU Complex, which comprises up to 14 ARM Neoverse V3AE
CPUs. Each CPU has its own private 1MB L2 cache.
Signed-off-by: Sumit Gupta <sumitg@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Enable GPCDMA in Tegra264 and add the iommu-map property so that each
channel uses a separate stream ID and gets its own IOMMU domain for
memory.
Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Commit d87773de9e ("clocksource/drivers/arm_arch_timer: Default to EL2
virtual timer when running VHE") updated the ARM arch timer driver to
use the virtual timer by default if the CPU is running at EL2 with VHE
enabled. If the CPU is running at EL2 with VHE enabled but there is no
interrupt provided for the virtual timer, then the following warning is
displayed:
arch_timer: [Firmware Bug]: VHE-capable CPU without EL2 virtual timer
interrupt
This warning is observed on Tegra194 platforms. Tegra194 SoC includes
NVIDIA Carmel ARM v8.2 CPUs and support an EL2 virtual timer. Fix the
above warning by adding the PPI for the EL2 virtual timer interrupt for
Tegra194.
Fixes: 5425fb15d8 ("arm64: tegra: Add Tegra194 chip device tree")
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Fix the unit-address of cpu1 node to match its reg property value.
Fixes: f6d1890e5f4d ("arm64: tegra: Add device tree for Tegra264")
Signed-off-by: Sumit Gupta <sumitg@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The Tegra234 SoC uses Cortex-A78AE cores, not Cortex-A78. Update the
compatible string for all CPU nodes to match the actual hardware.
Tegra234 hardware reports:
# head /proc/cpuinfo | egrep 'implementer|part'
CPU implementer : 0x41
CPU part : 0xd42
Which maps to (from arch/arm64/include/asm/cputype.h):
#define ARM_CPU_IMP_ARM 0x41
#define ARM_CPU_PART_CORTEX_A78AE 0xD42
Fixes: a12cf5c339 ("arm64: tegra: Describe Tegra234 CPU hierarchy")
Signed-off-by: Sumit Gupta <sumitg@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Remove the fallback compatible string "nvidia,tegra186-gpcdma" for GPCDMA
in Tegra264. Tegra186 compatible cannot work on Tegra264 because of the
register offset changes and absence of the reset property.
Fixes: 65ef237e48 ("arm64: tegra: Add Tegra264 support")
Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
These use a separate SMMU instance compared to everything else currently
enabled for the SoC.
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
This reverts commit ebea268ea5.
Mmu is now being enabled for the display controllers.
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Chromium/Depthcharge bootloaders may dynamically add a few device nodes
to a system's DTB under a /firmware node. A typical DT looks something
like the following:
/ {
firmware {
ranges;
coreboot {
compatible = "coreboot";
reg = <...>;
...;
};
};
};
Notably, the /firmware node has an empty 'ranges', but does not have
address/size-cells.
Commit 6e5773d52f ("of/address: Fix WARN when attempting translating
non-translatable addresses") started requiring #address-cells for a
device's parent if we want to use the reg resource in a device node.
This leads to errors like the following:
[ 7.763870] coreboot_table firmware:coreboot: probe with driver coreboot_table failed with error -22
Add appropriate #{address,size}-cells to work around the problem.
Note that Google has also patched the Depthcharge bootloader source to
add {address,size}-cells [1], but bootloader updates are typically
delivered only via Google OS updates. Not all users install Google
software updates, and even if they do, Google may not produce updated
binaries for all/older devices.
[1] https://lore.kernel.org/all/20241209092809.GA3246424@google.com/https://crrev.com/c/6051580 ("coreboot: Insert #address-cells and
#size-cells for firmware node")
Closes: https://lore.kernel.org/all/aeKlYzTiL0OB1y3g@google.com/
Fixes: 6e5773d52f ("of/address: Fix WARN when attempting translating non-translatable addresses")
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Register the MAX77620 PMIC as the system power controller on Pixel C so
the driver can install its sys-off handler.
This allows the PMIC poweroff sequence to override the non-working PSCI
SYSTEM_OFF implementation on this platform.
Signed-off-by: Diogo Ivo <diogo.ivo@tecnico.ulisboa.pt>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Enable the PCIe controllers on the Jetson AGX Thor Developer Kit that
are used for ethernet and NVMe.
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The 64-bit address of the main GPIO controller on Tegra264 is
0x810c300000. The main GPIO controller was incorrectly added under the
bus@0 node instead of the bus@8100000000 node breaking the boot on
Tegra264. Fix this by moving to main GPIO controller node under
bus@8100000000.
Fixes: c70e6bc11d ("arm64: tegra: Add Tegra264 GPIO controllers")
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Add the aspm-l1-entry-delay-ns device tree property to all PCIe Root Port
and PCIe Endpoint nodes in tegra194.dtsi and tegra234.dtsi so that ASPM L1
entrance latency is configured from device tree.
- Tegra194: 4000 ns (4 us) for both Root Port and Endpoint.
- Tegra234: 8000 ns (8 us) for Root Port, 16000 ns (16 us) for Endpoint.
Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The Tegra MGBE PTP clock is incorrectly named as 'ptp-ref' and not
'ptp_ref' and this causing the initialisation of the PTP clock to fail.
The device-tree binding doc for the device and the Tegra MGBE driver
have been updated to use the correct name and so update the device-tree
for Tegra234 as well.
Fixes: 610cdf3186 ("arm64: tegra: Add MGBE nodes on Tegra234")
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Add device tree nodes for MAIN, AON and UPHY GPIO controller instances.
Signed-off-by: Prathamesh Shete <pshete@nvidia.com>
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Add support for the SPI-NOR flash found in Pixel C devices.
Signed-off-by: Diogo Ivo <diogo.ivo@tecnico.ulisboa.pt>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Add basic support for the Jetson AGX Thor Developer Kit. It's quite
similar to the existing reference platform but has a slightly different
carrier board with different mass storage options and I/O.
Signed-off-by: Thierry Reding <treding@nvidia.com>
A total of six PCIe controllers can be found on Tegra264. One of them is
used internally for the integrated GPU while the other five can go to a
variety of connectors like full PCIe slots or M.2.
Signed-off-by: Thierry Reding <treding@nvidia.com>
The following warning is observed on the Tegra234 Jetson platforms ...
rtc-nvidia-vrs10 4-003c: /aliases ID 0 not available
This happens because the 'rtc@c2a0000' device is registered before the
vrs10 RTC and so is assigned the 'rtc0' alias. We want the vrs10 RTC to
be the default RTC because this RTC maintains time across power cycles.
Fix this by adding a 'rtc1' alias for the 'rtc@c2a0000' device.
Fixes: b1806f2b4e ("arm64: tegra: Add device-tree node for NVVRS RTC")
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The DT bindings don't allow the clock and reset names to be specified
since there is only a single entry for each.
Signed-off-by: Thierry Reding <treding@nvidia.com>
The snps,blen property of stmmac-axi-config nodes needs to have 7
entries in total, with unsupported burst lengths listed as 0.
Signed-off-by: Thierry Reding <treding@nvidia.com>
There are a handful of new SoCs this time, all of these are
more or less related to chips in a wider family:
- SpacemiT Key Stone K3 is an 8-core risc-v chip, and the first
widely available RVA23 implementation. Note that this is
entirely unrelated with the similarly named Texas Instruments
K3 chip family that follwed the TI Keystone2 SoC.
- The Realtek Kent family of SoCs contains three chip models
rtd1501s, rtd1861b and rtd1920s, and is related to their earlier
Set-top-box and NAS products such as rtd1619, but is built
on newer Arm Cortex-A78 cores.
- The Qualcomm Milos family includes the Snapdragon 7s Gen 3
(SM7635) mobile phone SoC built around Armv9 Kryo cores of the Arm
Cortex-A720 generation. This one is used in the Fairphone Gen 6
- Qualcomm Kaanapali is a new SoC based around eight high
performance Oryon CPU cores
- NXP i.MX8QP and i.MX952 are both feature reduced versions of
chips we already support, i.e. the i.MX8QM and i.MX952, with
fewer CPU cores and I/O interfaces.
As part of a cleanup, a number of SoC specific devicetree files got
removed because they did not have a single board using the .dtsi files
and they were never compile tested as a result: Samsung s3c6400,
ST spear320s, ST stm32mp21xc/stm32mp23xc/stm32mp25xc, Renesas
r8a779m0/r8a779m2/r8a779m4/r8a779m6/r8a779m7/r8a779m8/r8a779mb/
r9a07g044c1/r9a07g044l1/r9a07g054l1/r9a09g047e37, and TI am3703/am3715.
All of these could be restored easily if a new board gets merged.
Broadcom/Cavium/Marvell ThunderX2 gets removed along with its only
machine, as all remaining users are assumed to be using ACPI
based firmware.
A relatively small number of 43 boards get added this time, and
almost all of them for arm64. Aside from the reference boards for
the newly added SoCs, this includes:
- Three server boards use 32-bit ASpeed BMCs
- One more reference board for 32-bit Microchip LAN9668
- 64-bit Arm single-board computers based on Amlogic s905y4,
CIX sky1, NXP ls1028a/imx8mn/imx8mp/imx91/imx93/imx95,
Qualcomm qcs6490/qrb2210 and Rockchip rk3568/rk3588s
- Carrier board for SOMs using Intel agilex5, Marvell Armada 7020,
NXP iMX8QP, Mediatek mt8370/mt8390 and rockchip rk3588
- Two mobile phones using Snapdragon 845
- A gaming device and a NAS box, both based on Rockchips rk356x
On top of the newly added boards and SoCs, there is a lot of
background activity going into cleanups, in particular towards
getting a warning-free dtc build, and the usual work on adding
support for more hardware on the previously added machines.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmmLSTIACgkQmmx57+YA
GNk6xw//bn239Nn6XUSrmm3b7SGDf+9AvdrukrUEOsIYBYUM7fkulVSINpVOSzZU
DAxLSCY1qfE9zP4x+hrYv922w9Rt19zPuEwFVCslbbTk9NN8IhmhIOs06o2jrvN3
HS/AcESV2SCUe0EVjDIdBgisKMGdbN2t8bdrFFOmqUkQ+7EJ2GvNL0MoaKrdF+Sr
ilt5Hhkl6ixbGDq2KEB2QQHQhYKa/5GdKS0CLTY4et/dZbjHVg9o6/sfgIhLINCz
wNb9CKnt1Gv5L3RWW2LxQrrNe5qhLmHq1vmPbxSJGrzqnOwY9Tcg4s1Io9EcDtyW
LZlq4PkLJV9oPVHgi0mygZ3ONVhWhCMVhTXg6Osi1aHJeEERuIaYMfeU7WD0jHv8
ZcGboxfyiQmphRJumL0C74uIuuXgdoKrv7gqQvo9dy+HRxdHW/7p8TQi9SSfh7kF
Iysc2ePMmqLd4WJCMxV+7FrT8oZxOL+/KfisCu6n/Qdv65kTWmBlLCK6XZrmWYyk
YKg48F8xpQaSmgevWePwhcH0a/TmgmoT+6xOfTuyo88k65FLXXmrFp14th2Kg5sI
60W9ur6ujPI3s19H9C3IQp7ub5Ermvj+g893zEB1e2CR9blfqRARV9zFSv4OMkq+
hQmqe5cU9/17k7wchFke4Y/FsS8W2oFFJ9o6czOTnh5NhlpVSJw=
=IK23
-----END PGP SIGNATURE-----
Merge tag 'soc-dt-7.0' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
Pull SoC devicetree updates from Arnd Bergmann:
"There are a handful of new SoCs this time, all of these are more or
less related to chips in a wider family:
- SpacemiT Key Stone K3 is an 8-core risc-v chip, and the first
widely available RVA23 implementation. Note that this is entirely
unrelated with the similarly named Texas Instruments K3 chip family
that follwed the TI Keystone2 SoC.
- The Realtek Kent family of SoCs contains three chip models
rtd1501s, rtd1861b and rtd1920s, and is related to their earlier
Set-top-box and NAS products such as rtd1619, but is built on newer
Arm Cortex-A78 cores.
- The Qualcomm Milos family includes the Snapdragon 7s Gen 3 (SM7635)
mobile phone SoC built around Armv9 Kryo cores of the Arm
Cortex-A720 generation. This one is used in the Fairphone Gen 6
- Qualcomm Kaanapali is a new SoC based around eight high performance
Oryon CPU cores
- NXP i.MX8QP and i.MX952 are both feature reduced versions of chips
we already support, i.e. the i.MX8QM and i.MX952, with fewer CPU
cores and I/O interfaces.
As part of a cleanup, a number of SoC specific devicetree files got
removed because they did not have a single board using the .dtsi files
and they were never compile tested as a result: Samsung s3c6400, ST
spear320s, ST stm32mp21xc/stm32mp23xc/stm32mp25xc, Renesas
r8a779m0/r8a779m2/r8a779m4/r8a779m6/r8a779m7/r8a779m8/r8a779mb/
r9a07g044c1/r9a07g044l1/r9a07g054l1/r9a09g047e37, and TI
am3703/am3715. All of these could be restored easily if a new board
gets merged.
Broadcom/Cavium/Marvell ThunderX2 gets removed along with its only
machine, as all remaining users are assumed to be using ACPI based
firmware.
A relatively small number of 43 boards get added this time, and almost
all of them for arm64. Aside from the reference boards for the newly
added SoCs, this includes:
- Three server boards use 32-bit ASpeed BMCs
- One more reference board for 32-bit Microchip LAN9668
- 64-bit Arm single-board computers based on Amlogic s905y4, CIX
sky1, NXP ls1028a/imx8mn/imx8mp/imx91/imx93/imx95, Qualcomm
qcs6490/qrb2210 and Rockchip rk3568/rk3588s
- Carrier board for SOMs using Intel agilex5, Marvell Armada 7020,
NXP iMX8QP, Mediatek mt8370/mt8390 and rockchip rk3588
- Two mobile phones using Snapdragon 845
- A gaming device and a NAS box, both based on Rockchips rk356x
On top of the newly added boards and SoCs, there is a lot of
background activity going into cleanups, in particular towards getting
a warning-free dtc build, and the usual work on adding support for
more hardware on the previously added machines"
* tag 'soc-dt-7.0' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (757 commits)
dt-bindings: intel: Add Agilex eMMC support
arm64: dts: socfpga: agilex: add emmc support
arm64: dts: intel: agilex5: Add simple-bus node on top of dma controller node
ARM: dts: socfpga: fix dtbs_check warning for fpga-region
ARM: dts: socfpga: add #address-cells and #size-cells for sram node
dt-bindings: altera: document syscon as fallback for sys-mgr
arm64: dts: altera: Use lowercase hex
dt-bindings: arm: altera: combine Intel's SoCFPGA into altera.yaml
arm64: dts: socfpga: agilex5: Add IOMMUS property for ethernet nodes
arm64: dts: socfpga: agilex5: add support for modular board
dt-bindings: intel: Add Agilex5 SoCFPGA modular board
arm64: dts: socfpga: agilex5: Add dma-coherent property
arm64: dts: realtek: Add Kent SoC and EVB device trees
dt-bindings: arm: realtek: Add Kent Soc family compatibles
ARM: dts: samsung: Drop s3c6400.dtsi
ARM: dts: nuvoton: Minor whitespace cleanup
MAINTAINERS: Add Falcon DB
arm64: dts: a7k: add COM Express boards
ARM: dts: microchip: Drop usb_a9g20-dab-mmx.dtsi
arm64: dts: rockchip: Fix rk3588 PCIe range mappings
...
The USB2 port on Smaug is configured for OTG operation but lacked the
required 'usb-role-switch' property, leading to a failed probe and a
non-functioning USB port. Add the property along with setting the default
role to host.
Signed-off-by: Diogo Ivo <diogo.ivo@tecnico.ulisboa.pt>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Complete the missing properties in the tegra-udc node and enable it for
Smaug.
Signed-off-by: Diogo Ivo <diogo.ivo@tecnico.ulisboa.pt>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Enable both SOR and DPAUX modules allowing the USB-C port to transmit
video in DP altmode. Tested on several monitors with USB-C to HDMI
adapter.
Signed-off-by: Diogo Ivo <diogo.ivo@tecnico.ulisboa.pt>
Signed-off-by: Thierry Reding <treding@nvidia.com>
"arm,armv8" CPU compatible is only for software models and must not be
used in DTS for actual hardware. Replace them with Neoverse V3AE
compatible, based what is written on Wikipedia [1].
Link: https://en.wikipedia.org/wiki/Tegra#Thor [1]
Reported-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Closes: https://lore.kernel.org/all/59ae6b16-7866-413a-a1d2-4a735024c108@oss.qualcomm.com/
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Device nodes are enabled by default and this DTSI file does not include
anything else, thus it is impossible that nodes were disabled before and
need to be re-enabled. Adding redundant status=okay is just confusing
and suggests some other code flow. Verified with dtx_diff.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Device nodes are enabled by default and this DTSI file does not include
anything else, thus it is impossible that nodes were disabled before and
need to be re-enabled. Adding redundant status=okay is just confusing
and suggests some other code flow. Verified with dtx_diff.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Device nodes are enabled by default and this DTSI file does not include
anything else, thus it is impossible that nodes were disabled before and
need to be re-enabled. Adding redundant status=okay is just confusing
and suggests some other code flow. Verified with dtx_diff.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Device nodes are enabled by default and this DTSI file does not include
anything else, thus it is impossible that nodes were disabled before and
need to be re-enabled. Adding redundant status=okay is just confusing
and suggests some other code flow. Verified with dtx_diff.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The Command Queue Virtualization (CMDQV) hardware is part of the
SMMUv3 implementation on NVIDIA Tegra SoCs. It assists in
virtualizing the command queue for the SMMU.
Update SMMU compatible strings to use nvidia,tegra264-smmu to enable
CMDQV support. Add device tree nodes for the CMDQV hardware and enable
them on the tegra264-p3834 platform where SMMUs are enabled. Each SMMU
instance is paired with its corresponding CMDQV instance via the
nvidia,cmdqv property.
Acked-by: Nicolin Chen <nicolinc@nvidia.com>
Signed-off-by: Ashish Mhetre <amhetre@nvidia.com>
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Commit 59a42707a094 ("arm64: tegra: Add interconnect properties for
Tegra210") populated interconnect properties for Tegra210 and this is
preventing the Tegra DRM driver from probing successfully. The following
error is observed on boot ...
drm drm: failed to initialize 54240000.dc: -517
For now revert this change, until a fix is available.
Fixes: 59a42707a094 ("arm64: tegra: Add interconnect properties for Tegra210")
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
The P3509 carrier board does not connect the ID GPIO. Prior to this, the
GPIO role switch driver could not detect the mode of the OTG port.
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The USB Micro-B port on p3450 is capable of OTG and doesn't need to be
hardcoded to peripheral. No other supported Tegra device is set up like
this, so align for consistency.
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The Tegra X1 chip contains a NVJPG accelerator capable of
encoding/decoding JPEG files in hardware. Complete its DT node
and enable it.
Reviewed-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Diogo Ivo <diogo.ivo@tecnico.ulisboa.pt>
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
