summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2025-11-15gpu: nova-core: add boot42 support for next-gen GPUsJohn Hubbard2-12/+45
NVIDIA GPUs are moving away from using NV_PMC_BOOT_0 to contain architecture and revision details, and will instead use NV_PMC_BOOT_42 in the future. NV_PMC_BOOT_0 will contain a specific set of values that will mean "go read NV_PMC_BOOT_42 instead". Change the selection logic in Nova so that it will claim Turing and later GPUs. This will work for the foreseeable future, without any further code changes here, because all NVIDIA GPUs are considered, from the oldest supported on Linux (NV04), through the future GPUs. Add some comment documentation to explain, chronologically, how boot0 and boot42 change with the GPU eras, and how that affects the selection logic. Cc: Alexandre Courbot <acourbot@nvidia.com> Cc: Danilo Krummrich <dakr@kernel.org> Cc: Timur Tabi <ttabi@nvidia.com> Reviewed-by: Joel Fernandes <joelagnelf@nvidia.com> Signed-off-by: John Hubbard <jhubbard@nvidia.com> [acourbot@nvidia.com: remove unneeded `From<BOOT_0> for Revision` implementation.] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Message-ID: <20251115010923.1192144-4-jhubbard@nvidia.com>
2025-11-15gpu: nova-core: make Architecture behave as a u8 typeJohn Hubbard1-1/+14
This allows Architecture to be passed into register!() and bitfield!() macro calls. That in turn requires a default implementation for Architecture. This simplifies transforming BOOT0 (and later, BOOT42) register values into GPU architectures. Cc: Danilo Krummrich <dakr@kernel.org> Cc: Timur Tabi <ttabi@nvidia.com> Suggested-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Joel Fernandes <joelagnelf@nvidia.com> Signed-off-by: John Hubbard <jhubbard@nvidia.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Message-ID: <20251115010923.1192144-3-jhubbard@nvidia.com>
2025-11-15gpu: nova-core: prepare Spec and Revision types for boot0/boot42John Hubbard1-5/+12
Allow a both Revision and Spec to be constructed directly from a NV_PMC_BOOT_0 register. Also, slightly enhance the comment about Spec, to be more precise. Cc: Alexandre Courbot <acourbot@nvidia.com> Cc: Danilo Krummrich <dakr@kernel.org> Cc: Timur Tabi <ttabi@nvidia.com> Reviewed-by: Joel Fernandes <joelagnelf@nvidia.com> Signed-off-by: John Hubbard <jhubbard@nvidia.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Message-ID: <20251115010923.1192144-2-jhubbard@nvidia.com>
2025-11-15gpu: nova-core: gsp: Retrieve GSP static info to gather GPU informationAlistair Popple6-0/+266
After GSP initialization is complete, retrieve the static configuration information from GSP-RM. This information includes GPU name, capabilities, memory configuration, and other properties. On some GPU variants, it is also required to do this for initialization to complete. Signed-off-by: Alistair Popple <apopple@nvidia.com> Co-developed-by: Joel Fernandes <joelagnelf@nvidia.com> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com> Reviewed-by: Lyude Paul <lyude@redhat.com> [acourbot@nvidia.com: properly abstract the command's bindings, add relevant methods, make str_from_null_terminated return an Option, fix size of GPU name array.] Co-developed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Message-ID: <20251114195552.739371-14-joelagnelf@nvidia.com>
2025-11-15gpu: nova-core: gsp: Wait for gsp initialization to completeAlistair Popple2-3/+48
This adds the GSP init done command to wait for GSP initialization to complete. Once this command has been received the GSP is fully operational and will respond properly to normal RPC commands. Signed-off-by: Alistair Popple <apopple@nvidia.com> Co-developed-by: Joel Fernandes <joelagnelf@nvidia.com> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com> Reviewed-by: Lyude Paul <lyude@redhat.com> [acourbot@nvidia.com: move new definitions to end of commands.rs, rename to `wait_gsp_init_done` and remove timeout argument.] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Message-ID: <20251114195552.739371-13-joelagnelf@nvidia.com>
2025-11-15gpu: nova-core: sequencer: Implement core resume operationJoel Fernandes2-3/+42
Implement core resume operation. This is the last step of the sequencer resulting in resume of the GSP and proceeding to INIT_DONE stage of GSP boot. Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Message-ID: <20251114195552.739371-12-joelagnelf@nvidia.com>
2025-11-15gpu: nova-core: sequencer: Implement basic core operationsJoel Fernandes1-0/+19
These opcodes implement various falcon-related boot operations: reset, start, wait-for-halt. Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Message-ID: <20251114195552.739371-11-joelagnelf@nvidia.com>
2025-11-15gpu: nova-core: sequencer: Add delay opcode supportJoel Fernandes2-3/+18
Implement a sequencer opcode for delay operations. Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Message-ID: <20251114195552.739371-10-joelagnelf@nvidia.com>
2025-11-15gpu: nova-core: sequencer: Add register opcodesJoel Fernandes2-15/+107
These opcodes are used for register write, modify, poll and store (save) sequencer operations. Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> [acourbot@nvidia.com: apply Lyude's suggested fixes.] Message-ID: <20251114195552.739371-9-joelagnelf@nvidia.com>
2025-11-15gpu: nova-core: Implement the GSP sequencerJoel Fernandes6-3/+252
Implement the GSP sequencer which culminates in INIT_DONE message being received from the GSP indicating that the GSP has successfully booted. This is just initial sequencer support, the actual commands will be added in the next patches. Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com> [acourbot@nvidia.com: move GspSequencerInfo definition before its impl blocks and rename it to GspSequence, adapt imports in sequencer.rs to new formatting rules, remove `timeout` argument to harmonize with other commands.] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Message-ID: <20251114195552.739371-8-joelagnelf@nvidia.com>
2025-11-15gpu: nova-core: Add bindings required by GSP sequencerJoel Fernandes2-0/+407
Add several firmware bindings required by GSP sequencer code. Co-developed-by: Alistair Popple <apopple@nvidia.com> Signed-off-by: Alistair Popple <apopple@nvidia.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com> [acourbot@nvidia.com: remove a couple stray lines/unwanted comment changes.] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Message-ID: <20251114195552.739371-7-joelagnelf@nvidia.com>
2025-11-15gpu: nova-core: gsp: Add support for checking if GSP reloadedJoel Fernandes2-0/+24
During the sequencer process, we need to check if GSP was successfully reloaded. Add functionality to check for the same. Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Message-ID: <20251114195552.739371-6-joelagnelf@nvidia.com>
2025-11-15gpu: nova-core: falcon: Move dma_reset functionality into helperJoel Fernandes1-2/+7
Move dma_reset so we can use it for the upcoming sequencer functionality. Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Message-ID: <20251114195552.739371-5-joelagnelf@nvidia.com>
2025-11-15gpu: nova-core: falcon: Move mbox functionalities into helperJoel Fernandes1-19/+35
Move falcon reading/writing to mbox functionality into helper so we can use it from the sequencer resume flow. Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com> [acourbot@nvidia.com: make write/read mailbox methods unfallible.] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Message-ID: <20251114195552.739371-4-joelagnelf@nvidia.com>
2025-11-15gpu: nova-core: falcon: Move start functionality into separate helperJoel Fernandes1-10/+16
Move start functionality into a separate helper so we can use it from the sequencer. Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Message-ID: <20251114195552.739371-3-joelagnelf@nvidia.com>
2025-11-15gpu: nova-core: falcon: Move waiting until halted to a helperJoel Fernandes1-7/+14
Move the "waiting until halted" functionality into a helper so that we can use it in the sequencer, which is a separate sequencer operation. Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Message-ID: <20251114195552.739371-2-joelagnelf@nvidia.com>
2025-11-15drm/xe/irq: Handle msix vector0 interruptVenkata Ramana Nayana1-17/+1
Current gu2host handler registered as MSI-X vector 0 and as per bspec for a msix vector 0 interrupt, the driver must check the legacy registers 190008(TILE_INT_REG), 190060h (GT INTR Identity Reg 0) and other registers mentioned in "Interrupt Service Routine Pseudocode" otherwise it will block the next interrupts. To overcome this issue replacing guc2host handler with legacy xe_irq_handler. Fixes: da889070be7b2 ("drm/xe/irq: Separate MSI and MSI-X flows") Bspec: 62357 Signed-off-by: Venkata Ramana Nayana <venkata.ramana.nayana@intel.com> Reviewed-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Link: https://patch.msgid.link/20251107083141.2080189-1-venkata.ramana.nayana@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-11-15drm/rockchip: vop2: Use OVL_LAYER_SEL configuration instead of use win_mask ↵Andy Yan1-7/+42
calculate used layers When there are multiple Video Ports, and only one of them is working (for example, VP1 is working while VP0 is not), in this case, the win_mask of VP0 is 0. However, we have already set the port mux for VP0 according to vp0->nlayers, and at the same time, in the OVL_LAYER_SEL register, there are windows will also be assigned to layers which will map to the inactive VPs. In this situation, vp0->win_mask is zero as it now working, it is more reliable to calculate the used layers based on the configuration of the OVL_LAYER_SEL register. Note: as the configuration of OVL_LAYER_SEL is take effect when the vsync is come, so we use the value backup in vop2->old_layer_sel instead of read OVL_LAYER_SEL directly. Fixes: 3e89a8c68354 ("drm/rockchip: vop2: Fix the update of LAYER/PORT select registers when there are multi display output on rk3588/rk3568") Cc: stable@vger.kernel.org Reported-by: Diederik de Haas <diederik@cknow-tech.com> Closes: https://bugs.kde.org/show_bug.cgi?id=511274 Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Tested-by: Dang Huynh <dang.huynh@mainlining.org> Tested-by: Diederik de Haas <diederik@cknow-tech.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20251112085024.2480111-1-andyshrk@163.com
2025-11-15drm/rockchip: Set VOP for the DRM DMA deviceDmitry Osipenko1-0/+3
Use VOP for DMA operations performed by DRM core. Rockchip DRM driver is backed by a virtual device that isn't IOMMU-capable, while VOP is the actual display controller device backed by IOMMU. Fixes "swiotlb buffer is full" warning messages originated from GEM prime code paths. Note, that backporting is non-trivial as this depends on commit 143ec8d3f9396 ("drm/prime: Support dedicated DMA device for dma-buf imports"), which landed in v6.16 and commit 421be3ee36a4 ("drm/rockchip: Refactor IOMMU initialisation"), which landed in v5.19. Reported-by: Daniel Stone <daniels@collabora.com> Fixes: 2048e3286f34 ("drm: rockchip: Add basic drm driver") Cc: stable@vger.kernel.org # v6.16+ Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Tested-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20251022161948.199731-1-dmitry.osipenko@collabora.com
2025-11-15drm/rockchip: dw_hdmi_qp: Add high color depth supportCristian Ciocaltea1-3/+51
Since both RK3576 and RK3588 SoCs are capable of handling 10 bpc color depth, introduce a pair of new helpers to program the necessary registers, as well as passing bpc at PHY configuration level. Note max_bpc is unconditionally set to 10 before initializing the QP bridge library, as there is no need to adjust it dynamically, i.e. per SoC variant, for now. While setting up .enc_init() callbacks of rockchip_hdmi_qp_ctrl_ops, also replace the unnecessary whitespace chars before .irq_callback() assignments. Acked-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20251021-rk3588-10bpc-v3-5-3d3eed00a6db@collabora.com
2025-11-15drm/rockchip: dw_hdmi_qp: Use bit macros for RK3576 regsCristian Ciocaltea1-13/+8
For consistency and improved readability, redefine a few RK3576 specific register configurations by relying on GENMASK() and unshifted values for color depth and output format. Those are not used at the moment, but will be needed soon to support the related features. While at it, drop a few other defines which are unlikely to be ever required. Acked-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20251021-rk3588-10bpc-v3-4-3d3eed00a6db@collabora.com
2025-11-15drm/rockchip: dw_hdmi_qp: Switch to phy_configure()Cristian Ciocaltea1-18/+19
Stop relying on phy_set_bus_width() based workaround to setup the TMDS character rate and, instead, use the recently introduced HDMI PHY configuration API. This is also a prerequisite to enable high color depth and FRL support. Additionally, move the logic to ->atomic_check() callback where the current mode rate is already provided by the connector state. As a matter of fact this is actually necessary to ensure the link rate is configured before VOP2 attempts to use the PHY PLL as a DCLK source in vop2_crtc_atomic_enable(). The rationale is to restrict any changes of the PHY rate via CCF and, instead, prefer the PHY configuration API for this purpose. Acked-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20251021-rk3588-10bpc-v3-3-3d3eed00a6db@collabora.com
2025-11-15drm/bridge: dw-hdmi-qp: Handle platform supported formats and color depthCristian Ciocaltea1-2/+9
Extend struct dw_hdmi_qp_plat_data to include the supported display output formats and maximum bits per color channel. When provided by the platform driver, use them to setup the HDMI bridge accordingly. Additionally, improve debug logging in dw_hdmi_qp_bridge_atomic_enable() to also show the current HDMI output format and bpc. Acked-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20251021-rk3588-10bpc-v3-2-3d3eed00a6db@collabora.com
2025-11-15drm/rockchip: vop2: Check bpc before switching DCLK sourceCristian Ciocaltea1-26/+32
When making use of the HDMI PHY PLL as a VOP2 DCLK source, it's output rate does normally match the mode clock. But this is only applicable for default color depth of 8 bpc. For higher depths, the output clock is further divided by the hardware according to the formula: output rate = PHY PLL rate * 8 / bpc Hence there is no need for VOP2 to compensate for bpc when adjusting DCLK, but it is required to do so when computing its maximum operating frequency. Take color depth into consideration before deciding to switch DCLK source. Reviewed-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20251021-rk3588-10bpc-v3-1-3d3eed00a6db@collabora.com
2025-11-15drm/rockchip: analogix_dp: Use dev_err_probe() instead of DRM_DEV_ERROR() ↵Damon Ding1-17/+14
during probing The DRM_DEV_ERROR() has been deprecated, and use dev_err_probe() can be better. The other reason is that dev_err_probe() help avoid unexpected repeated err logs during defered probing. Signed-off-by: Damon Ding <damon.ding@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20251110075817.1159857-1-damon.ding@rock-chips.com
2025-11-15drm/rockchip: dw_hdmi_qp: Fixup usage of enable_gpio member in main structCristian Ciocaltea1-7/+7
The name of the enable_gpio member in struct rockchip_hdmi_qp is too generic, as initially "borrowed" from downstream BSP code. Moreover, this hasn't been really in use so far, since there is neither a DT providing an "enable-gpios" property to any of the "hdmi" nodes, nor a binding documenting it. The actual purpose of this GPIO line is to control the voltage bias for the HDMI TX data lines when switching between TMDS and FRL operating modes. A previous patch introduced the "frl-enable-gpios" property of the RK3588 HDMI TX Controller binding, hence pass the updated string to devm_gpiod_get_optional(), rename the struct member accordingly and set it to a low level. Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20251027222641.25066-3-laurent.pinchart@ideasonboard.com
2025-11-14drm/xe/pf: Check for fence error on VRAM save/restoreMichał Winiarski1-0/+9
The code incorrectly assumes that the VRAM save/restore fence is valid. Fix it by checking for error. Fixes: 49cf1b9b609fe ("drm/xe/pf: Handle VRAM migration data as part of PF control") Suggested-by: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patch.msgid.link/20251114122339.1791026-1-michal.winiarski@intel.com Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
2025-11-14drm/xe/pf: Drop the VF VRAM BO reference on successful restoreMichał Winiarski1-0/+2
The reference is only dropped on error. Fix it by adding the missing xe_bo_put(). Fixes: 49cf1b9b609fe ("drm/xe/pf: Handle VRAM migration data as part of PF control") Reported-by: Adam Miszczak <adam.miszczak@linux.intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20251114100713.1776073-1-michal.winiarski@intel.com Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
2025-11-14drm/tegra: Add NVJPG driverDiogo Ivo4-0/+334
Add support for booting and using NVJPG on Tegra210 to the Host1x and TegraDRM drivers. This driver only supports the new TegraDRM uAPI. Acked-by: Mikko Perttunen <mperttunen@nvidia.com> Signed-off-by: Diogo Ivo <diogo.ivo@tecnico.ulisboa.pt> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patch.msgid.link/20250630-diogo-nvjpg-v3-1-a553c7e91354@tecnico.ulisboa.pt
2025-11-14PCI: Convert BAR sizes bitmasks to u64Ilpo Järvinen1-1/+1
PCIe r7.0, sec 7.8.6, defines resizable BAR sizes beyond the currently supported maximum of 128TB, which will require more than u32 to store the entire bitmask. Convert Resizable BAR related functions to use u64 bitmask for BAR sizes to make the typing more future-proof. The support for the larger BAR sizes themselves is not added at this point. Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patch.msgid.link/20251113180053.27944-12-ilpo.jarvinen@linux.intel.com
2025-11-14drm/amdgpu: Use pci_rebar_get_max_size()Ilpo Järvinen1-3/+5
Use pci_rebar_get_max_size() to simplify amdgpu_device_resize_fb_bar(). Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patch.msgid.link/20251113180053.27944-11-ilpo.jarvinen@linux.intel.com
2025-11-14drm/xe/vram: Use pci_rebar_get_max_size()Ilpo Järvinen1-8/+7
Use pci_rebar_get_max_size() from PCI core in resize_vram_bar() to simplify code. Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Christian König <christian.koenig@amd.com> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/20251113180053.27944-10-ilpo.jarvinen@linux.intel.com
2025-11-14drm/xe/vram: Use PCI rebar helpers in resize_vram_bar()Ilpo Järvinen1-12/+7
PCI core provides pci_rebar_size_supported() and pci_rebar_size_to_bytes(); use them in resize_vram_bar() to simplify code. Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Christian König <christian.koenig@amd.com> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/20251113180053.27944-8-ilpo.jarvinen@linux.intel.com
2025-11-14drm/i915/gt: Use pci_rebar_size_supported()Ilpo Järvinen1-7/+3
PCI core provides pci_rebar_size_supported() that helps in checking if an encoded BAR Size is supported for the BAR or not. Use it in i915_resize_lmem_bar() to simplify code. Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Acked-by: Christian König <christian.koenig@amd.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patch.msgid.link/20251113180053.27944-7-ilpo.jarvinen@linux.intel.com
2025-11-14drm/amdgpu: Remove driver side BAR release before resizeIlpo Järvinen1-7/+1
PCI core handles releasing device's resources and their rollback in case of failure of a BAR resizing operation. Releasing resource prior to calling pci_resize_resource() prevents PCI core from restoring the BARs as they were. Remove driver-side release of BARs from the amdgpu driver. Also remove the driver initiated assignment as pci_resize_resource() should try to assign as much as possible. If the driver side call manages to get more required resources assigned in some scenario, such a problem should be fixed inside pci_resize_resource() instead. Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Alex Bennée <alex.bennee@linaro.org> # AVA, AMD GPU Link: https://patch.msgid.link/20251113162628.5946-11-ilpo.jarvinen@linux.intel.com
2025-11-14drm/i915: Remove driver side BAR release before resizeIlpo Järvinen1-12/+0
PCI core handles releasing device's resources and their rollback in case of failure of a BAR resizing operation. Releasing resource prior to calling pci_resize_resource() prevents PCI core from restoring the BARs as they were. Remove driver-side release of BARs from the i915 driver. Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patch.msgid.link/20251113162628.5946-10-ilpo.jarvinen@linux.intel.com
2025-11-14drm/xe: Remove driver side BAR release before resizeIlpo Järvinen1-3/+0
PCI core handles releasing device's resources and their rollback in case of failure of a BAR resizing operation. Releasing resource prior to calling pci_resize_resource() prevents PCI core from restoring the BARs as they were. Remove driver-side release of BARs from the xe driver. Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patch.msgid.link/20251113162628.5946-9-ilpo.jarvinen@linux.intel.com
2025-11-14PCI: Fix restoring BARs on BAR resize rollback pathIlpo Järvinen3-3/+5
BAR resize operation is implemented in the pci_resize_resource() and pbus_reassign_bridge_resources() functions. pci_resize_resource() can be called either from __resource_resize_store() from sysfs or directly by the driver for the Endpoint Device. The pci_resize_resource() requires that caller has released the device resources that share the bridge window with the BAR to be resized as otherwise the bridge window is pinned in place and cannot be changed. pbus_reassign_bridge_resources() rolls back resources if the resize operation fails, but rollback is performed only for the bridge windows. Because releasing the device resources are done by the caller of the BAR resize interface, these functions performing the BAR resize do not have access to the device resources as they were before the resize. pbus_reassign_bridge_resources() could try __pci_bridge_assign_resources() after rolling back the bridge windows as they were, however, it will not guarantee the resource are assigned due to differences in how FW and the kernel assign the resources (alignment of the start address and tail). To perform rollback robustly, the BAR resize interface has to be altered to also release the device resources that share the bridge window with the BAR to be resized. Also, remove restoring from the entries failed list as saved list should now contain both the bridge windows and device resources so the extra restore is duplicated work. Some drivers (currently only amdgpu) want to prevent releasing some resources. Add exclude_bars param to pci_resize_resource() and make amdgpu pass its register BAR (BAR 2 or 5), which should never be released during resize operation. Normally 64-bit prefetchable resources do not share a bridge window with the 32-bit only register BAR, but there are various fallbacks in the resource assignment logic which may make the resources share the bridge window in rare cases. This change (together with the driver side changes) is to counter the resource releases that had to be done to prevent resource tree corruption in the ("PCI: Release assigned resource before restoring them") change. As such, it likely restores functionality in cases where device resources were released to avoid resource tree conflicts which appeared to be "working" when such conflicts were not correctly detected by the kernel. Reported-by: Simon Richter <Simon.Richter@hogyros.de> Link: https://lore.kernel.org/linux-pci/f9a8c975-f5d3-4dd2-988e-4371a1433a60@hogyros.de/ Reported-by: Alex Bennée <alex.bennee@linaro.org> Link: https://lore.kernel.org/linux-pci/874irqop6b.fsf@draig.linaro.org/ Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> [bhelgaas: squash amdgpu BAR selection from https://lore.kernel.org/r/20251114103053.13778-1-ilpo.jarvinen@linux.intel.com] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Alex Bennée <alex.bennee@linaro.org> # AVA, AMD GPU Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patch.msgid.link/20251113162628.5946-7-ilpo.jarvinen@linux.intel.com
2025-11-14drm/tegra: dsi: Calculate packet parameters for video modeSvyatoslav Ryhel1-3/+10
Calculate packet parameters for video mode same way it is done for command mode, by halving timings plugged into equations. Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patch.msgid.link/20250909073335.91531-3-clamor95@gmail.com
2025-11-14drm/tegra: dsi: Make SOL delay calculation mode independentSvyatoslav Ryhel1-24/+18
Move SOL delay calculation outside of video mode conditions. Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patch.msgid.link/20250909073335.91531-2-clamor95@gmail.com
2025-11-14gpu: host1x: Syncpoint interrupt performance optimizationMikko Perttunen3-9/+59
Optimize performance of syncpoint interrupt handling by reading the status register in 64-bit chunks when possible, and skipping processing when the read value is zero. Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patch.msgid.link/20250917-host1x-syncpt-irq-perf-v2-1-736ef69b1347@nvidia.com
2025-11-14Revert "drm/tegra: dsi: Clear enable register if powered by bootloader"Diogo Ivo1-9/+0
Commit b6bcbce33596 ("soc/tegra: pmc: Ensure power-domains are in a known state") was introduced so that all power domains get initialized to a known working state when booting and it does this by shutting them down (including asserting resets and disabling clocks) before registering each power domain with the genpd framework, leaving it to each driver to later on power its needed domains. This caused the Google Pixel C to hang when booting due to a workaround in the DSI driver introduced in commit b22fd0b9639e ("drm/tegra: dsi: Clear enable register if powered by bootloader") meant to handle the case where the bootloader enabled the DSI hardware module. The workaround relies on reading a hardware register to determine the current status and after b6bcbce33596 that now happens in a powered down state thus leading to the boot hang. Fix this by reverting b22fd0b9639e since currently we are guaranteed that the hardware will be fully reset by the time we start enabling the DSI module. Fixes: b6bcbce33596 ("soc/tegra: pmc: Ensure power-domains are in a known state") Cc: stable@vger.kernel.org Signed-off-by: Diogo Ivo <diogo.ivo@tecnico.ulisboa.pt> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patch.msgid.link/20251103-diogo-smaug_ec_typec-v1-1-be656ccda391@tecnico.ulisboa.pt
2025-11-14drm/tegra: Add call to put_pid()Prateek Agarwal1-2/+5
Add a call to put_pid() corresponding to get_task_pid(). host1x_memory_context_alloc() does not take ownership of the PID so we need to free it here to avoid leaking. Signed-off-by: Prateek Agarwal <praagarwal@nvidia.com> Fixes: e09db97889ec ("drm/tegra: Support context isolation") [mperttunen@nvidia.com: reword commit message] Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patch.msgid.link/20250919-host1x-put-pid-v1-1-19c2163dfa87@nvidia.com
2025-11-14drm/xe: Remove duplicate DRM_EXEC selection from KconfigShuicheng Lin1-1/+0
There are 2 identical "select DRM_EXEC" lines for DRM_XE. Remove one to clean up the configuration. Fixes: d490ecf57790 ("drm/xe: Rework xe_exec and the VM rebind worker to use the drm_exec helper") Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com> Reviewed-by: Nitin Gote <nitin.r.gote@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patch.msgid.link/20251110232657.1807998-2-shuicheng.lin@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-11-14drm/tegra: dc: Fix reference leak in tegra_dc_couple()Ma Ke1-0/+1
driver_find_device() calls get_device() to increment the reference count once a matching device is found, but there is no put_device() to balance the reference count. To avoid reference count leakage, add put_device() to decrease the reference count. Found by code review. Cc: stable@vger.kernel.org Fixes: a31500fe7055 ("drm/tegra: dc: Restore coupling of display controllers") Signed-off-by: Ma Ke <make24@iscas.ac.cn> Acked-by: Mikko Perttunen <mperttunen@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patch.msgid.link/20251022114720.24937-1-make24@iscas.ac.cn
2025-11-14drm/xe/kunit: Fix forcewake assertion in mocs testMatt Roper1-1/+1
The MOCS kunit test calls KUNIT_ASSERT_TRUE_MSG() with a condition of 'true;' this prevents the assertion from ever failing. Replace KUNIT_ASSERT_TRUE_MSG with KUNIT_FAIL_AND_ABORT to get the intended failure behavior in cases where forcewake was not acquired successfully. Fixes: 51c0ee84e4dc ("drm/xe/tests/mocs: Hold XE_FORCEWAKE_ALL for LNCF regs") Cc: Tejas Upadhyay <tejas.upadhyay@intel.com> Cc: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patch.msgid.link/20251113234038.2256106-2-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-11-14drm/amdgpu: Use amdgpu by default on SI dedicated GPUs (v2)Timur Kristóf3-6/+10
Now that the DC analog connector support and VCE1 support landed, amdgpu is at feature parity with the old radeon driver on SI dGPUs. Enabling the amdgpu driver by default for SI dGPUs has the following benefits: - More stable OpenGL support through RadeonSI - Vulkan support through RADV - Improved performance - Better display features through DC Users who want to keep using the old driver can do so using: amdgpu.si_support=0 radeon.si_support=1 v2: - Update documentation in Kconfig file Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-14drm/amdgpu: Use amdgpu by default on CIK dedicated GPUsTimur Kristóf1-3/+9
The amdgpu driver has been working well on CIK dGPUs for years. Now that the DC analog connector support landed, amdgpu is at feature parity with the old radeon driver on CIK dGPUs. Enabling the amdgpu driver by default for CIK dGPUs has the following benefits: - More stable OpenGL support through RadeonSI - Vulkan support through RADV - Improved performance - Better display features through DC Users who want to keep using the old driver can do so using: amdgpu.cik_support=0 radeon.cik_support=1 v2: - Update documentation in Kconfig file v3: - Rebase documentation updates (Alex) Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-14drm/amdgpu: Fix the issue of missing ras message on sriov hostYiPeng Chai2-15/+10
This code only applies to amdgpu processing poison consumption after uniras is enabled, but not to sriov. Signed-off-by: YiPeng Chai <YiPeng.Chai@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-14drm/amdgpu: Add lock to serialize sriov command executionYiPeng Chai3-5/+15
Add lock to serialize sriov command execution. Signed-off-by: YiPeng Chai <YiPeng.Chai@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
generated by cgit v1.2.3 (git 2.39.0) at 2026-06-03 08:49:34 +0300