Add initial device-tree support for NVIDIA Shield TV 2019 (a.k.a Sif)
based on the Tegra210B01 SoC with 2 GiB of LPDDR4 RAM.
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
This is based on 6f78a94, which enabled added the fan and thermal zones
for the Jetson Nano Devkit. The fan and thermal characteristics of the
two devices are similar, so using the same configuration.
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
The Tegra210B01 p2894 product has a BCM4356 module with wifi on pcie.
Enable the pcie port it is plugged into add a node for the wifi card,
and add a gpio-hog to enable power to the card. Attempts to tie the gpio
to power sequencing has not worked.
Change-Id: I7236fa1a3eabeb7fbb5b94af05f951b922955a38
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
The P2894 product has a Realtek r6168 PCIe ethernet adapter. Enable the
pcie port the adapter is attached to.
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
Enable the XUSB controller on P2894. One of the USB 3.0 lanes goes to a
switchable USB-A port, while the second USB 3.0 lane supports the normal
USB-A port.
The padctl layout is different between the Tegra210 and Tegra210B01
variants. The latter is overridden in the device specific dts.
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
This adds the gpu regulator and enables the gpu node.
Change-Id: I7d9580967edf9af4c31d500608f880eeb9d1e0b5
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
Add initial device-tree support for NVIDIA Shield TV Pro 2019 (a.k.a
MDarcy) based up the Tegra210B01 SoC with 3 GiB of LPDDR4 RAM.
This device is very similar to the Tegra210 p2894 device, so this shares
the p2894 dtsi with a few overrides to the pinmux and power tree.
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
In preparation for support of the Tegra210B01 p2894 variant, move the
arch dtsi include to the Tegra210 revision specific dts. This will allow
the p2894 dtsi to be shared across archs, as the variants share a
majority of the hardware design.
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
Also known as Tegra X1+, the Tegra210B01 has higher CPU and GPU clocks
than the original Tegra210.
Add a SoC-level device tree file that describes most of the hardware
available on the SoC. This is derived from the Tegra210 dtsi, as they
share a lot.
Co-developed-by: Thomas Makin <halorocker89@gmail.com>
Signed-off-by: Thomas Makin <halorocker89@gmail.com>
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
The Tegra210 soc supports bpmp offload for power management among other
things. This was considered insecure partway through the soc's lifecycle
and support was removed in the bootloader. However, Tegra210B01 returned
to using the bpmp. Plus old bootloaders on the original Tegra210 still
work with the existing driver. So add the node to the common Tegra210
soc dtsi, but disabled by default.
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
This covers a few differences:
* Lanes compared to the original Tegra210
* The soc has a different clock driver and thus callbacks
* The soc has an extra clock for uphy management
Co-developed-by: Thomas Makin <halorocker89@gmail.com>
Change-Id: I455358267b3a700461caa8f9f9963d33596dd189
Signed-off-by: Thomas Makin <halorocker89@gmail.com>
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
Previously, all supported SoCs only used the A major revision. The
Tegra210B01 SoC incremented the major revision. Add support for this.
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
This is based on the downstream Nvidia 5.10 kernel. That version was
semi-integrated into the Tegra210 clock driver. Looking at the existing
Tegra210 support, it made more sense to make this a fully independent
driver, so that is implemented here.
Co-authored-by: Thomas Makin <halorocker89@gmail.com>
Signed-off-by: Thomas Makin <halorocker89@gmail.com>
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
* Add the compatible string for Tegra210B01 clock and reset
* Add Tegra210B01 specific clock bindings
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
Since commit ece67f4758 ("soc/tegra: Make ARCH_TEGRA_SOC_FOO defaults
for NVIDIA Tegra"), all Tegra arm64 archs are enabled for GKI. Commit
eb5e5c1f62 ("ANDROID: gki_defconfig: Enable Tegra SoCs") disabled
options related to Tegra archs older than Tegra234 since that was the
only one supported at the time. Now that all archs are supported, these
options can be used.
* SERIAL_8250_TEGRA is used by Tegra210 and Tegra186 for UART serial
* TEGRA186_TIMER is used by Tegra186 and newer for watchdog timers
* TEGRA_IOMMU_SMMU is required by Tegra210 for mmu
* TEGRA210_EMC can be a module, but depends on an additional built-in
config; plus all other Tegra emc support is built-in already
* TEGRA_AHB is used by Tegra210
* ARM_TEGRA20_CPUFREQ and ARM_TEGRA124_CPUFREQ Kconfig changes are reset
to match mainline. New vendor snippets enabling CPUFREQ_DT can disable
as needed. The rockpi4 target is updated as an example of this.
Change-Id: I05541c6e1fc1ccd9ab430451a66f0d5cc3c7b0e1
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
These are generated by the Tegra210 Android bootloader. This is similar
to the Tegra124 handling, so the support is based on that and modified
to match Tegra210 by referencing the downstream Nvidia 4.9 kernel.
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
These entries are imported from the downstream Nvidia Linux4Tegra
kernel. They are expected to be updated with the trained values by the
bootloader. This is done by the Nvidia Android bootloader, which is
different from the handling by the Nvidia Linux bootloader which places
these values in a reserved memory location. P2180 is supported by both
bootloaders, so lets support initializing emc on both.
It should be noted that the bootloader will not create these nodes in
the kernel dtb if they do not exist. It will only set in place existing
properties.
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
Add support for booting and using NVENC on Tegra210+ to the Host1x
and TegraDRM drivers. This driver only supports the new TegraDRM uAPI.
Change-Id: I07e1386604d7638ba43381c3f289688d7c5cb12b
Add initial device-tree support for NVIDIA Shield TV (a.k.a. Foster)
based upon Tegra210 SoC with 3 GiB of LPDDR4 RAM. It is based on P2571.
Change-Id: Ideeeb15f835ebf7f7617d3989908d245aff4b316
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
Enable the XUSB controller on P2571. One of the USB 3.0 lanes goes to an
internal ethernet interface, while two other USB 3.0 lanes support the
the USB-A receptacles on the I/O board.
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
This is based on 6f78a94, which enabled added the fan and thermal zones
for the Jetson Nano Devkit. The fan and thermal characteristics of the
two devices are similar, so using the same configuration.
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
This adds the gpu regulator and enables the gpu node.
Change-Id: I8a0f580fa600d8f37fb3fa497cf657abf2905d5f
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
Based on the p2180 pmic config, modified to match p2530
Change-Id: Ic7baa787b8e9633da72622a4562258860c05fca6
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
The SHIELD TV 2015 is a consumer media Android device that is based on
P2571
Change-Id: Ib981728d277f7daca812223ec3534d98555d43a1
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
The p3310 som has a BCM4354 module with wifi on sdio.
Change-Id: Ie4b42165fb81a129a7afe58c1c632261d13eca53
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
This appears to be a typo. The voltage input to the wireless module is
expected to be 1.8V-3.3V, per the downstream device tree.
Fixes: 02df3f03a8 ("arm64: tegra: Add initial power tree for P3310")
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
Add OPP table and interconnects property to scale DDR frequency with
CPU frequency for better performance. Each operating point entry of
the OPP table has CPU freq to per MC channel bandwidth mapping.
One table is added for each cluster even though the table data is
same because the bandwidth request is per cluster. This is done
because the OPP framework creates a single icc path and hence single
bandwidth request if the table is marked as 'opp-shared' and shared
among all clusters. For us, the OPP table data is same but the MC
Client ID argument to interconnects property is different for each
cluster. So, having per cluster tables makes different icc paths for
each cluster and helps to make per cluster BW requests.
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
Add OPP table and interconnects property to scale DDR frequency with
CPU frequency for better performance. Each operating point entry of
the OPP table has CPU freq to per MC channel bandwidth mapping. One
table is added for each cluster because the different cpu types have
different scaling curves.
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
Add Interconnect framework support to dynamically set the DRAM
bandwidth from different clients. The MC driver is added as an ICC
provider and the EMC driver is already a provider.
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
Add Interconnect framework support to dynamically set the DRAM
bandwidth from different clients. The MC driver is added as an ICC
provider and the EMC driver is already a provider.
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
This adds support for dynamic frequency scaling of external memory on
devices with bpmp firmware that does not support bwmgr.
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
This will be used in the upcoming non-bpmp icc support, which will use
the common tegra emc rate support which uses the opp framework.
Change-Id: If4a3efaae0ad06de029ffd34c2b11faea5044d58
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
These are being referenced by actmon, but are not currently enabled.
Fixes: 654427e0b9 ("arm64: tegra: Add OPP tables on Tegra210")
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
Without the cmu, nvdisplay will display colors that are notably darker
than intended. The vendor bootloader and the downstream display driver
enable the cmu and sets a sRGB table. Loading that table here results in
the intended colors.
Co-developed-by: Kurt Kiefer <kekiefer@gmail.com>
Signed-off-by: Kurt Kiefer <kekiefer@gmail.com>
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
Tested-by: Jasper Korten <jja2000@gmail.com>
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 Tegra210 L4T bootloader RAM training will corrupt the in-RAM kernel
DT if no reserved-memory node exists. This prevents said bootloader from
being able to boot a kernel without this node, unless a chainloaded
bootloader loads the DT. Add the node to eliminate the requirement for
extra boot stages.
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The Tegra210 L4T bootloader RAM training will corrupt the in-RAM kernel
DT if no reserved-memory node exists. This prevents said bootloader from
being able to boot a kernel without this node, unless a chainloaded
bootloader loads the DT. Add the node to eliminate the requirement for
extra boot stages.
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The other engines are already enabled, finish filling out the media
engine nodes and power domains.
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
This adds OPP tables for ACTMON and EMC, enabling dynamic frequency
scaling for system memory.
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Add interconnect properties to the Memory Controller, External Memory
Controller and the Display Controller nodes in order to describe the
hardware interconnection.
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
This enables the action monitor to facilitate dynamic frequency scaling.
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The Jetson Nano series of modules only have 2 EMC table entries,
different from other SoC SKUs. As the EMC driver uses the SoC speedo ID
to populate the EMC OPP tables, add a new speedo ID to uniquely identify
this.
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
Reviewed-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Existing code only sets CPU and GPU speedo IDs 0 and 1. The CPU DVFS
code supports 11 IDs and nouveau supports 5. This aligns with what the
downstream vendor kernel supports. Align SKUs with the downstream list.
The Tegra210 CVB tables were added in the first referenced fixes commit.
Since then, all Tegra210 SoCs have tried to scale to 1.9 GHz, when the
supported devkits are only supposed to scale to 1.5 or 1.7 GHZ.
Overclocking should not be the default state.
Fixes: 2b2dbc2f94 ("clk: tegra: dfll: add CVB tables for Tegra210")
Fixes: 579db6e5d9 ("arm64: tegra: Enable DFLL support on Jetson Nano")
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
This devkit is very similar to P3450, except it has less RAM, no display
port, and only 3 USB host ports. Derive from P3450 and disable the
hardware that is unavailable.
GPIO PA6 is used to control the HDMI power rail and needs to be on for
hotplug detect to work. This is mapped to the 3.3V USB hub on P3450.
That USB rail is not used here, so delete the regulator to avoid
conflicts.
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Add the device tree nodes for the MAIN and AON pin controllers found on
the Tegra186 family of SoCs.
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Add support to use OPP table from DT in Tegra186 cpufreq driver.
Tegra SoC's receive the frequency lookup table (LUT) from BPMP-FW.
Cross check the OPP's present in DT against the LUT from BPMP-FW
and enable only those DT OPP's which are present in LUT also.
The OPP table in DT has CPU Frequency to bandwidth mapping where
the bandwidth value is per MC channel. DRAM bandwidth depends on the
number of MC channels which can vary as per the boot configuration.
This per channel bandwidth from OPP table will be later converted by
MC driver to final bandwidth value by multiplying with number of
channels before being handled in the EMC driver.
If OPP table is not present in DT, then use the LUT from BPMP-FW
directly as the CPU frequency table and not do the DRAM frequency
scaling which is same as the current behavior.
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
[ Viresh: Fix _free() definitions ]
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
During initialization, the EDVD_COREx_VOLT_FREQ registers for some cores
are still at reset values and not reflecting the actual frequency. This
causes get calls to fail. Set all cores to their respective max
frequency during probe to initialize the registers to working values.
Suggested-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
Reviewed-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
The original commit set all cores in a cluster to a shared policy, but
did not update set_target to apply a frequency change to all cores for
the policy. This caused most cores to remain stuck at their boot
frequency.
Fixes: be4ae8c194 ("cpufreq: tegra186: Share policy per cluster")
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
Reviewed-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Using pmu counters for usage stats. This enables dynamic frequency
scaling on all of the currently supported Tegra gpus.
The register offsets are valid for gk20a, gm20b, gp10b, and gv11b. If
support is added for ga10b, this will need rearchitected.
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
[fixed tab alignment in gk20a_devfreq_target()]
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://lore.kernel.org/r/20250906-gk20a-devfreq-v2-1-0217f53ee355@gmail.com
Starting with Tegra186, gpu clock handling is done by the bpmp and there
is little to be done by the kernel. The only thing necessary for
reclocking is to set the gpcclk to the desired rate and the bpmp handles
the rest. The pstate list is based on the downstream driver generates.
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
[added newline before gp10b_clk macro declaration for checkpatch error]
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://lore.kernel.org/r/20250823-gp10b-reclock-v2-1-90a1974a54e3@gmail.com
Since the related binding is being added, use that for the client ids
instead of hardcoded magic numbers.
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Aaron Kling
