[linux-nvidia-6.17] Backport i2c patches for Tegra256, Tegra264, and Tegra410 #274
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
BugLink: https://bugs.launchpad.net/bugs/2119656 Add CONFIG_NVGRACE_EGM with policy 'm' for arm64 architecture. Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Matt Ochs <mochs@nvidia.com> Acked-by: Noah Wager <noah.wager@canonical.com> Acked-by: Jacob Martin <jacob.martin@canonical.com> Signed-off--by: Brad Figg <bfigg@nvidia.com> (cherry picked from commit ddf68d0 noble:linux-nvidia-6.14) Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2119656 On platforms without the mig HW bug (e.g. Grace-Blackwell) there is not a requirement to create the resmem region. Accordingly, this region is not configured on these platforms, which leads to the following print when the device is closed: resource: Trying to free nonexistent resource <0x0000000000000000-0x000000000000ffff> Avoid calling unregister_pfn_address_space for resmem when the region is not being used. Fixes: 2d21b7b ("vfio/nvgrace-gpu: register device memory for poison handling") Signed-off-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Carol L. Soto <csoto@nvidia.com> Acked-by: Nirmoy Das <nirmoyd@nvidia.com> Signed-off-by: Matthew R. Ochs <mochs@nvidia.com> (cherry picked from commit bd0187d https://github.com/NVIDIA/NV-Kernels/tree/24.04_linux-nvidia-adv-6.11-next) Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Matt Ochs <mochs@nvidia.com> Acked-by: Noah Wager <noah.wager@canonical.com> Acked-by: Jacob Martin <jacob.martin@canonical.com> Signed-off--by: Brad Figg <bfigg@nvidia.com> (cherry picked from commit 87b2a68 noble:linux-nvidia-6.14) Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2119656 Commit 222675c ("irqchip: Have CONFIG_IRQ_MSI_IOMMU be selected by irqchips that need it") changed the behavior of CONFIG_IRQ_MSI_IOMMU to a dynamic selection, so it might not always be needed by amd64 builds. Signed-off-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Matt Ochs <mochs@nvidia.com> Acked-by: Noah Wager <noah.wager@canonical.com> Acked-by: Jacob Martin <jacob.martin@canonical.com> Signed-off--by: Brad Figg <bfigg@nvidia.com> (cherry picked from commit c7c7b21 noble:linux-nvidia-6.14) Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com>
…DEFAULT_DMA_LAZY BugLink: https://bugs.launchpad.net/bugs/2119661 Nvidia CPU SMMU supports passthrough and lazy IOMMU mode so set lazy mode as default for better performance. Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Noah Wager <noah.wager@canonical.com> Acked-by: Jacob Martin <jacob.martin@canonical.com> Signed-off--by: Brad Figg <bfigg@nvidia.com> (cherry picked from commit 6318c8c noble:linux-nvidia-6.14) Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com>
…on amd64 BugLink: https://bugs.launchpad.net/bugs/2028576 The bug indicates NVIDIA wanted to enable the performance governor by default on all arches for the NVIDIA kernels. However, this was mistakenly only configured for arm64 systems. Fix this by also using the performance CPU frequency governor as the default on amd64 systems. Signed-off-by: Jacob Martin <jacob.martin@canonical.com> (cherry picked from commit a530411) (cherry picked from commit a530411 noble:linux-nvidia-6.14) Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2121451 pci_acpi_preserve_config() leaks memory by returning early without freeing the ACPI object on success. Fix that by always freeing the obj, which is not needed by the caller. Fixes: 9d7d5db ("PCI: Move PRESERVE_BOOT_CONFIG _DSM evaluation to pci_register_host_bridge()") Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20250825214642.142135-1-nirmoyd@nvidia.com (cherry picked from commit dab2c5f9399591a50f9e9746fca6bb47f6ac04ae pci/misc) Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Noah Wager <noah.wager@canonical.com> Acked-by: Jacob Martin <jacob.martin@canonical.com> Signed-off--by: Brad Figg <bfigg@nvidia.com> (cherry picked from commit a1e5234 noble:linux-nvidia-6.14) Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2121544 GB300 is NVIDIA's Grace Blackwell Ultra Superchips with B300 GPU. Add the B300 SKU device-id to nvgrace_gpu_vfio_pci_table. Signed-off-by: Tushar Dave <tdave@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Jacob Martin <jacob.martin@canonical.com> Acked-by: Abdur Rahman <abdur.rahman@canonical.com> Signed-off--by: Brad Figg <bfigg@nvidia.com> (cherry picked from commit 47c8566 noble:linux-nvidia-6.14) Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2123861 In nvidia_ffa_create_notifications(), it invokes nvidia_ffa_fill_notification_map(), which fills the virtual notification IDs array supported by the current FFA device. This function updates notification_count after traversing the notification array in the _DSD method. For FFA devices without an entry in the _DSD method, notification_count is assumed to be zero initialized. However, nvidia_ffa_ec_service_probe() uses kmalloc() instead of kzalloc(), so notification_count may contain random values. This causes FFA device probe failures. This patch fixes this by using kzalloc() to zero initialize the nvidia_ec_ffa_device structure. Fixes: ae87187 ("NVIDIA: SAUCE: Add support for notifications from secure EC services") Signed-off-by: Abhishek Sahu <abhsahu@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Jacob Martin <jacob.martin@canonical.com> Acked-by: Abdur Rahman <abdur.rahman@canonical.com> Signed-off--by: Brad Figg <bfigg@nvidia.com> (cherry picked from commit 518a89b noble:linux-nvidia-6.14) Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com>
…PORTLI value BugLink: https://bugs.launchpad.net/bugs/2125126 For DIGITS GB10, USB SuperSpeed Plus Gen2x1 device enumeration speed is being shown as Gen2x2 in the dmesg log. usb 4-1: new SuperSpeed Plus Gen 2x2 USB device number 2 using xhci-hcd The USB3 link lanes count is recorded in the read-only TLC and RLC fields of the PORTLI register. In MT89xx SoCs (used by GB10), the lane count can be wrongly set to 2 instead of 1 for USB Gen2x1 devices due to HW Bug. As per Table 7-13 in USB xHCI revision 1.2 specification, the value 0x5 is for SuperSpeedPlus Gen2x1. This patch adds a SW WAR to read the port speed in PORTSC register. If port speed value is 0x5, then the lane count can be updated to 1. Signed-off-by: Us Chien <us.chien@mediatek.com> Signed-off-by: Abhishek Sahu <abhsahu@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Kai-Heng Feng <kaihengf@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Jacob Martin <jacob.martin@canonical.com> Acked-by: Abdur Rahman <abdur.rahman@canonical.com> Signed-off--by: Brad Figg <bfigg@nvidia.com> (cherry picked from commit b5b3a58 noble:linux-nvidia-6.14) Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com>
Ignore: yes Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/1786013 Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
Ignore: yes Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2127212 Properties: no-test-build Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
As of 6.17 this flag is unused, so drop references to it to satisfy the cranky close linter. Ignore: yes Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
…backport Ignore: yes Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2112600 iommu/io-pgtable-arm: Support contiguous bit in translation tables The contiguous bit in translation table entries can be used as a hint to SMMU that a group of adjacent translation table entries have consistent attributes and point to a contiguous and properly aligned output address range. This enables SMMU to predict the properties of the remaining translation table entries in the same group without accessing them. It also allows an SMMU implementation to make more efficient use of its TLB by using a single TLB entry to cover all translation table entries in the same group. In the case of 4KB granule size, there are 16 translation table entries in one group. This change sets the contiguous bit for such groups of entries that are completely covered by a single call to map_pages. As it stands, the code wouldn't set the contiguous bit if a group of adjacent descriptors is completed by separate calls to map_pages. Signed-off-by: Daniel Mentz <danielmentz@google.com> Link: https://lore.kernel.org/linux-iommu/20250430231924.1481493-1-danielmentz@google.com/ [aritger: For the backport: updated the __arm_lpae_init_pte() callsite in arm_lpae_split_blk_unmap() (arm_lpae_split_blk_unmap() is no longer present at top of tree where the original commit was written).] Signed-off-by: Andy Ritger <aritger@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Abdur Rahman <abdur.rahman@canonical.com> Acked-by: Noah Wager <noah.wager@canonical.com> Signed-off--by: Brad Figg <bfigg@nvidia.com> (backported from commit 990fa55 linux-nvidia-6.11) [kobak: arm_lpae_split_blk_unmap is removed since https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=33729a5fc0caf7a97d20507acbeee6b012e7e519 iommu/io-pgtable-arm: Remove split on unmap behavior so modify as per functions] Signed-off-by: Koba Ko <kobak@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Jacob Martin <jacob.martin@canonical.com> Acked-by: Abdur Rahman <abdur.rahman@canonical.com> Signed-off-by: Ian May <ianm@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2129209 Add CSA (Channel Switch Announcement) related implementation in collaboration with mac80211 to deal with dynamic channel switching. Signed-off-by: Leon Yen <leon.yen@mediatek.com> Signed-off-by: Ming Yen Hsieh <mingyen.hsieh@mediatek.com> Conflicts: - drivers/net/wireless/mediatek/mt76/mt7925/main.c Code is different in mt7925_add_interface() - drivers/net/wireless/mediatek/mt76/mt792x_core.c Code organization is different Signed-off-by: Abhishek Sahu <abhsahu@nvidia.com> [Backported from https://patchwork.kernel.org/project/linux-wireless/patch/20250926053447.4036650-1-mingyen.hsieh@mediatek.com/] Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Abdur Rahman <abdur.rahman@canonical.com> Acked-by: Jacob Martin <jacob.martin@canonical.com> Signed-off-by: Ian May <ianm@nvidia.com>
…ype to DMA BugLink: https://bugs.launchpad.net/bugs/2129776 Force DGX Spark systems to use DMA translation as current drivers require this. Suggested-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Abdur Rahman <abdur.rahman@canonical.com> Acked-by: Jacob Martin <jacob.martin@canonical.com> Signed-off-by: Ian May <ianm@nvidia.com>
…DEFAULT_PASSTHROUGH BugLink: https://bugs.launchpad.net/bugs/2129776 Default to CONFIG_IOMMU_DEFAULT_PASSTHROUGH on NVIDIA CPU on kernel above 6.11 as suggested by perf team. x86 always defaults to CONFIG_IOMMU_DEFAULT_DMA_LAZY so remove redundant amd64 setting. Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Abdur Rahman <abdur.rahman@canonical.com> Acked-by: Jacob Martin <jacob.martin@canonical.com> Signed-off-by: Ian May <ianm@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2131047 The NVIDIA Olympus core supports BBML2 without conflict abort. Add its MIDR to the allow list to enable FEAT_BBM. Signed-off-by: Shanker Donthineni <sdonthineni@nvidia.com> Signed-off-by: Will Deacon <will@kernel.org> (cherry picked from commit cc80537) Signed-off-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Ian May <ian.may@canonical.com> Acked-by: Noah Wager <noah.wager@canonical.com> Acked-by: Jacob Martin <jacob.martin@canonical.com> Signed-off--by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2126589 When the CPU that the QSPI interrupt handler runs on (typically CPU 0) is excessively busy, it can lead to rare cases of the IRQ thread not running before the transfer timeout is reached. While handling the timeouts, any pending transfers are cleaned up and the message that they correspond to is marked as failed, which leaves the curr_xfer field pointing at stale memory. To avoid this, clear curr_xfer to NULL upon timeout and check for this condition when the IRQ thread is finally run. While at it, also make sure to clear interrupts on failure so that new interrupts can be run. A better, more involved, fix would move the interrupt clearing into a hard IRQ handler. Ideally we would also want to signal that the IRQ thread no longer needs to be run after the timeout is hit to avoid the extra check for a valid transfer. Fixes: 921fc18 ("spi: tegra210-quad: Add support for Tegra210 QSPI controller") Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Vishwaroop A <va@nvidia.com> Link: https://patch.msgid.link/20251028155703.4151791-2-va@nvidia.com Signed-off-by: Mark Brown <broonie@kernel.org> (cherry picked from commit b4e002d linux-next) Signed-off-by: Carol L Soto <csoto@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Ian May <ian.may@canonical.com> Acked-by: Noah Wager <noah.wager@canonical.com> Acked-by: Jacob Martin <jacob.martin@canonical.com> Signed-off--by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2126589 Extract common cleanup code into dedicated helper functions to simplify the code and improve readability. This refactoring includes: - tegra_qspi_reset(): Device reset and interrupt cleanup - tegra_qspi_dma_stop(): DMA termination and disable - tegra_qspi_pio_stop(): PIO mode disable No functional changes. This is purely a code reorganization to prepare for improved timeout handling in subsequent patches. Signed-off-by: Vishwaroop A <va@nvidia.com> Acked-by: Thierry Reding <treding@nvidia.com> Link: https://patch.msgid.link/20251028155703.4151791-3-va@nvidia.com Signed-off-by: Mark Brown <broonie@kernel.org> (cherry picked from commit 6022eac linux-next) Signed-off-by: Carol L Soto <csoto@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Ian May <ian.may@canonical.com> Acked-by: Noah Wager <noah.wager@canonical.com> Acked-by: Jacob Martin <jacob.martin@canonical.com> Signed-off--by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2126589 Under high system load, QSPI interrupts can be delayed or blocked on the target CPU, causing wait_for_completion_timeout() to report failure even though the hardware successfully completed the transfer. When a timeout occurs, check the QSPI_RDY bit in QSPI_TRANS_STATUS to determine if the hardware actually completed the transfer. If so, manually invoke the completion handler to process the transfer successfully instead of failing it. This distinguishes lost/delayed interrupts from real hardware timeouts, preventing unnecessary failures of transfers that completed successfully. Signed-off-by: Vishwaroop A <va@nvidia.com> Acked-by: Thierry Reding <treding@nvidia.com> Link: https://patch.msgid.link/20251028155703.4151791-4-va@nvidia.com Signed-off-by: Mark Brown <broonie@kernel.org> (cherry picked from commit 380fd29 linux-next) Signed-off-by: Carol L Soto <csoto@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Ian May <ian.may@canonical.com> Acked-by: Noah Wager <noah.wager@canonical.com> Acked-by: Jacob Martin <jacob.martin@canonical.com> Signed-off--by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2130445 The call to cat registers2 will acquire rtnl_lock and dump all mapped mmio. Due to acquire rtnl_lock too long, it will cause a kernel panic "not syncing: SBSA Generic Watchdog timeout". Fix this issue by acquiring rtnl_lock every 16 byte when dump all mapped mmio. Signed-off-by: ChunHao Lin <hau@realtek.com> Signed-off-by: Abhishek Sahu <abhsahu@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Ian May <ian.may@canonical.com> Acked-by: Noah Wager <noah.wager@canonical.com> Acked-by: Abdur Rahman <abdur.rahman@canonical.com> Signed-off--by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2130445 Use following command to do the test. cat /proc/net/r8127/<devname>/test/cdt Signed-off-by: ChunHao Lin <hau@realtek.com> Signed-off-by: Abhishek Sahu <abhsahu@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Ian May <ian.may@canonical.com> Acked-by: Noah Wager <noah.wager@canonical.com> Acked-by: Abdur Rahman <abdur.rahman@canonical.com> Signed-off--by: Brad Figg <bfigg@nvidia.com>
…l in SRCPKGNAME-tools-$(abi_release) BugLink: https://bugs.launchpad.net/bugs/2127953 The tools perf and bpftool are not built on Noble HWE 6.14 kernels because the kernel packaging rules introduced in Plucky on which Noble HWE 6.14 kernels are based expect perf and bpftool to be split out into their own packages linux-perf and bpftool, which are only built by the primary kernel. Resolve this by adding a flag `do_tools_noble_hwe` to return to building perf and bpftool into the SRCPKGNAME-tools-$(abi_release) package, which are exec'd by the wrapper scripts provided by the linux-tools-common package produced by the Noble primary kernel. Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2127953 Enable do_tools_noble_hwe to build bpftool and perf tools into the linux-nvidia-6.14-tools-$(abi_release) package so they can be used by the linux-tools-common wrapper scripts in Noble. Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
Ignore: yes Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2131581 Properties: no-test-build Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
… work with a set of CPUs BugLink: https://bugs.launchpad.net/bugs/2122432 mpam_resctrl_offline_domain_hdr() expects to take a single CPU that is going offline. Once all CPUs are offline, the domain header is removed from its parent list, and the structure can be freed. This doesn't work for NUMA nodes. Change the CPU passed to mpam_resctrl_offline_domain_hdr() and mpam_resctrl_domain_hdr_init to be a cpumask. This allows a single CPU to be passed for CPUs going offline, and cpu_possible_mask to be passed for a NUMA node going offline. Signed-off-by: James Morse <james.morse@arm.com> (cherry picked from commit 093483e5bca0aef546208b32eedf59f3aac665ff https://git.kernel.org/pub/scm/linux/kernel/git/morse/linux.git) Signed-off-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Noah Wager <noah.wager@canonical.com>
…domain() to have CPU and node BugLink: https://bugs.launchpad.net/bugs/2122432 mpam_resctrl_alloc_domain() brings a domain with CPUs online. To allow for domains that don't have any CPUs, split it into a CPU and NUMA node version. Signed-off-by: James Morse <james.morse@arm.com> (cherry picked from commit 817d04bd296871b61dd70f68d160b85837dfe9a8 https://git.kernel.org/pub/scm/linux/kernel/git/morse/linux.git) Signed-off-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Noah Wager <noah.wager@canonical.com>
…nline/offline BugLink: https://bugs.launchpad.net/bugs/2122432 To expose resctrl resources that contain CPU-less NUMA domains, resctrl needs to be told when a CPU-less NUMA domain comes online. This can't be done with the cpuhp callbacks. Add a memory hotplug notifier, and use this to create and destroy resctrl domains. Signed-off-by: James Morse <james.morse@arm.com> (cherry picked from commit caf4034229d8df2c306658c2ddbe3c1ab73df109 https://git.kernel.org/pub/scm/linux/kernel/git/morse/linux.git) Signed-off-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Noah Wager <noah.wager@canonical.com>
…UMA nid as MB domain-id BugLink: https://bugs.launchpad.net/bugs/2122432 Enable resctrl's use of NUMA nid as the domain-id for the MB resource. Changing this state involves changing the IDs of all the domains visible to resctrl. Writing to this list means preventing CPU and memory hotplug. Signed-off-by: James Morse <james.morse@arm.com> (cherry picked from commit a795ac909c6c050daaf095abc9043217ddf5e746 https://git.kernel.org/pub/scm/linux/kernel/git/morse/linux.git) Signed-off-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Noah Wager <noah.wager@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2122432 Modified for latest MPAM. Signed-off-by: Brad Figg <bfigg@nvidia.com> Signed-off-by: Koba Ko <kobak@nvidia.com> Signed-off-by: Fenghua Yu <fenghuay@nvidia.com> (forward ported from commit 77bd02c https://github.com/NVIDIA/NV-Kernels/tree/24.04_linux-nvidia-6.14-next) [fenghuay: change 6.14 path to 6.17] Signed-off-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Matt Ochs <mochs@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Jacob Martin <jacob.martin@canonical.com> Acked-by: Abdur Rahman <abdur.rahman@canonical.com> Acked-by: Koba Ko <kobak@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Noah Wager <noah.wager@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2122432 Define the missing SHIFT definitions to fix build errors. Fixes: a76ea20 ("NVIDIA: SAUCE: arm_mpam: Add quirk framework") Signed-off-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Noah Wager <noah.wager@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2122432 partid is from 0 to partid_max, inclusively. partid_max + 1 is out of valid partid range. Accessing partid_max + 1 will generate error interrupt and cause MPAM disabled. Signed-off-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Noah Wager <noah.wager@canonical.com>
…ed in mbm_event mode BugLink: https://bugs.launchpad.net/bugs/2122432 The following NULL pointer dereference is encountered on mount of resctrl fs after booting a system that supports assignable counters with the "rdt=!mbmtotal,!mbmlocal" kernel parameters: BUG: kernel NULL pointer dereference, address: 0000000000000008 RIP: 0010:mbm_cntr_get Call Trace: rdtgroup_assign_cntr_event rdtgroup_assign_cntrs rdt_get_tree Specifying the kernel parameter "rdt=!mbmtotal,!mbmlocal" effectively disables the legacy X86_FEATURE_CQM_MBM_TOTAL and X86_FEATURE_CQM_MBM_LOCAL features and the MBM events they represent. This results in the per-domain MBM event related data structures to not be allocated during early initialization. resctrl fs initialization follows by implicitly enabling both MBM total and local events on a system that supports assignable counters (mbm_event mode), but this enabling occurs after the per-domain data structures have been created. After booting, resctrl fs assumes that an enabled event can access all its state. This results in NULL pointer dereference when resctrl attempts to access the un-allocated structures of an enabled event. Remove the late MBM event enabling from resctrl fs. This leaves a problem where the X86_FEATURE_CQM_MBM_TOTAL and X86_FEATURE_CQM_MBM_LOCAL features may be disabled while assignable counter (mbm_event) mode is enabled without any events to support. Switching between the "default" and "mbm_event" mode without any events is not practical. Create a dependency between the X86_FEATURE_{CQM_MBM_TOTAL,CQM_MBM_LOCAL} and X86_FEATURE_ABMC (assignable counter) hardware features. An x86 system that supports assignable counters now requires support of X86_FEATURE_CQM_MBM_TOTAL or X86_FEATURE_CQM_MBM_LOCAL. This ensures all needed MBM related data structures are created before use and that it is only possible to switch between "default" and "mbm_event" mode when the same events are available in both modes. This dependency does not exist in the hardware but this usage of these feature settings work for known systems. [ bp: Massage commit message. ] Fixes: 1339086 ("x86,fs/resctrl: Detect Assignable Bandwidth Monitoring feature details") Co-developed-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: Babu Moger <babu.moger@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Reinette Chatre <reinette.chatre@intel.com> Link: https://patch.msgid.link/a62e6ac063d0693475615edd213d5be5e55443e6.1760560934.git.babu.moger@amd.com (cherry picked from commit 19de711) Signed-off-by: Tushar Dave <tdave@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Noah Wager <noah.wager@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2122432 Add 'CONFIG_ARM64_MPAM_RESCTRL_FS' to annotations. No code yet exits for 'CONFIG_CGROUP_RESCTRL' and 'CONFIG_RESCTRL_PMU', remove them from annotations. Signed-off-by: Tushar Dave <tdave@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Noah Wager <noah.wager@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2122432 KUNIT_CASE_PARAM macro's parameter generator function expects signature 'const void* gen_params(const void *prev, char *desc)' but function test_all_bwa_wd_gen_params() has wrong signature, causing compilation failure. Signed-off-by: Tushar Dave <tdave@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Noah Wager <noah.wager@canonical.com>
…it alignment fault BugLink: https://bugs.launchpad.net/bugs/2122432 KUnit builds pack struct mpam_props, which can misalign its DECLARE_BITMAP (features). On arm64, bitops perform unsigned long accesses that fault on misaligned addresses, causing mpam_resctrl KUnit tests to abort (EC=0x25 DABT, FSC=0x21 alignment fault). Keep the struct packed (to preserve padding-sanitization intent) but force its alignment to __alignof__(unsigned long) so bitmap operations are naturally aligned. No functional change outside tests. Signed-off-by: Tushar Dave <tdave@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Noah Wager <noah.wager@canonical.com>
…ytes of mpam_props BugLink: https://bugs.launchpad.net/bugs/2122432 Aligning struct mpam_props introduces potential tail padding beyond the last field. The test previously used memcmp over the entire struct, which now fails due to padding differences rather than content. Compare only up to the last meaningful field (via offsetof + sizeof) to avoid false negatives. No behavioral change to driver logic. Signed-off-by: Tushar Dave <tdave@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Noah Wager <noah.wager@canonical.com>
Ignore: yes Signed-off-by: Ian May <ianm@nvidia.com> Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
Add compatible and the hardware struct for Tegra256. Tegra256 controllers use a different parent clock. Hence the timing parameters are different from the previous generations to meet the expected frequencies. Signed-off-by: Akhil R <akhilrajeev@nvidia.com> Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> (cherry picked from commit 6e3cb25) Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>
On Tegra264, not all I2C controllers have the necessary interface to GPC DMA, this causes failures when function tegra_i2c_init_dma() is called. Ensure that "dmas" device-tree property is present before initializing DMA in function tegra_i2c_init_dma(). Signed-off-by: Kartik Rajput <kkartik@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Acked-by: Thierry Reding <treding@nvidia.com> (backported from https://lore.kernel.org/linux-tegra/20251118140620.549-1-akhilrajeev@nvidia.com/) Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>
…stplus The current implementation uses a single value of THIGH, TLOW and setup hold time for both fast and fastplus. But these values can be different for each speed mode and should be using separate variables. Split the variables used for fast and fast plus mode. Signed-off-by: Akhil R <akhilrajeev@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Acked-by: Thierry Reding <treding@nvidia.com> (backported from https://lore.kernel.org/linux-tegra/20251118140620.549-1-akhilrajeev@nvidia.com/) Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>
Update the timing parameters of Tegra256 so that the signals are complaint with the I2C specification for SCL low time. Signed-off-by: Akhil R <akhilrajeev@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Acked-by: Thierry Reding <treding@nvidia.com> (backported from https://lore.kernel.org/linux-tegra/20251118140620.549-1-akhilrajeev@nvidia.com/) Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>
Add support for High Speed (HS) mode transfers for Tegra194 and later chips. While HS mode has been documented in the technical reference manuals since Tegra20, the hardware implementation appears to be broken on all chips prior to Tegra194. When HS mode is not supported, set the frequency to FM+ instead. Signed-off-by: Akhil R <akhilrajeev@nvidia.com> Signed-off-by: Kartik Rajput <kkartik@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Acked-by: Thierry Reding <treding@nvidia.com> (backported from https://lore.kernel.org/linux-tegra/20251118140620.549-1-akhilrajeev@nvidia.com/) Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>
Add support for SW mutex register introduced in Tegra264 to provide an option to share the interface between multiple firmwares and/or VMs. This involves following steps: - A firmware/OS writes its unique ID to the mutex REQUEST field. - Ownership is established when reading the GRANT field returns the same ID. - If GRANT shows a different non-zero ID, the firmware/OS retries until timeout. - After completing access, it releases the mutex by writing 0. However, the hardware does not ensure any protection based on the values. The driver/firmware should honor the peer who already holds the mutex. Signed-off-by: Kartik Rajput <kkartik@nvidia.com> Signed-off-by: Akhil R <akhilrajeev@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Acked-by: Thierry Reding <treding@nvidia.com> (backported from https://lore.kernel.org/linux-tegra/20251118140620.549-1-akhilrajeev@nvidia.com/) Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>
Add support for Tegra264 SoC which supports 17 generic I2C controllers, two of which are in the AON (always-on) partition of the SoC. In addition to the features supported by Tegra194 it also supports a SW mutex register to allow sharing the same I2C instance across multiple firmware. Signed-off-by: Akhil R <akhilrajeev@nvidia.com> Signed-off-by: Kartik Rajput <kkartik@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Acked-by: Thierry Reding <treding@nvidia.com> (backported from https://lore.kernel.org/linux-tegra/20251118140620.549-1-akhilrajeev@nvidia.com/) Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>
…y DVC and VI Replace the per-instance boolean flags with an enum tegra_i2c_variant since DVC and VI are mutually exclusive. Update IS_DVC/IS_VI and variant initialization accordingly. Suggested-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Kartik Rajput <kkartik@nvidia.com> (backported from https://lore.kernel.org/all/20260107142649.14917-1-kkartik@nvidia.com/) Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>
Move the variant field into tegra_i2c_hw_feature and populate it for all SoCs. Add dedicated SoC data for "nvidia,tegra20-i2c-dvc" and "nvidia,tegra210-i2c-vi" compatibles. Drop the compatible-string checks from tegra_i2c_parse_dt to initialize the Tegra I2C variant. Signed-off-by: Kartik Rajput <kkartik@nvidia.com> (backported from https://lore.kernel.org/all/20260107142649.14917-1-kkartik@nvidia.com/) Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>
…r offsets Tegra410 use different offsets for existing I2C registers, update the logic to use appropriate offsets per SoC. As the registers offsets are now also defined for dvc and vi, following function are not required and they are removed: - tegra_i2c_reg_addr(): No translation required. - dvc_writel(): Replaced with i2c_writel() with DVC check. - dvc_readl(): Replaced with i2c_readl(). Signed-off-by: Kartik Rajput <kkartik@nvidia.com> (backported from https://lore.kernel.org/all/20260107142649.14917-1-kkartik@nvidia.com/) Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>
Add support for the Tegra410 SoC, which has 4 I2C controllers. The controllers are feature-equivalent to Tegra264; only the register offsets differ. Signed-off-by: Kartik Rajput <kkartik@nvidia.com> (backported from https://lore.kernel.org/all/20260107142649.14917-1-kkartik@nvidia.com/) Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>
Collaborator
|
|
clsotog
approved these changes
Jan 10, 2026
Collaborator
clsotog
left a comment
clsotog
left a comment
There was a problem hiding this comment.
Acked-by: Carol L Soto <csoto@nvidia.com>
nirmoy
approved these changes
Jan 12, 2026
Collaborator
nirmoy
left a comment
nirmoy
left a comment
There was a problem hiding this comment.
Acked-by: Nirmoy Das <nirmoyd@nvidia.com>
nvidia-bfigg
force-pushed
the
24.04_linux-nvidia-6.17-next
branch
from
021c218 to
899b59a
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This content is needed for the VR platform. The Tegra256 patch is taken from upstream to enable clean picks of the other patches, which are from mature series taken from LKML. Both of these series are targeting the v6.20 upstream kernel.
For testing, I verified i2c was functional on a VR system:
LP: https://bugs.launchpad.net/ubuntu/+source/linux-nvidia/+bug/2138238