summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2025-11-17drm/mediatek: Fix probe resource leaksJohan Hovold
Make sure to unmap and release the component iomap and clock on probe failure (e.g. probe deferral) and on driver unbind. Note that unlike of_iomap(), devm_of_iomap() also checks whether the region is already mapped. Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.") Cc: stable@vger.kernel.org # 4.7 Cc: CK Hu <ck.hu@mediatek.com> Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://patchwork.kernel.org/project/dri-devel/patch/20250923152340.18234-2-johan@kernel.org/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2025-11-17drm/mediatek: mtk_hdmi_common: Defer probe when ddc i2c bus isn't available yetSjoerd Simons
The i2c adapter for ddc might not be available yet due to e.g. its module not yet being loaded. To handle that defer probing rather then returning a fatal error when probing. Signed-off-by: Sjoerd Simons <sjoerd@collabora.com> Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com> Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2025-11-17drm/mediatek: mtk_hdmi_v2: Add debugfs ops and implement ABISTAngeloGioacchino Del Regno
Implement the Automated Built-In Self-Test ABIST functionality provided by the HDMIv2 IP and expose it through the "hdmi_abist" debugfs file. Write "1" to this file to activate ABIST, or "0" to deactivate. The ABIST functionality can be used to validate that the HDMI Transmitter itself works and that can output a valid image to the HDMI Display that is connected. This is especially useful when trying to rule out any possible issue that is related to the display pipeline, as the HDMI Tx is always the last component; this means that HDMI ABIST can be used even without prior display controller pipeline configuration. The expected output is a 100% color bar (rainbow) test pattern. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: CK Hu <ck.hu@mediatek.com> Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com> Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20251023-mediatek-drm-hdmi-v2-v11-10-7873ec4a1edf@collabora.com/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2025-11-17drm/mediatek: Introduce HDMI/DDC v2 for MT8195/MT8188AngeloGioacchino Del Regno
Add support for the newer HDMI-TX (Encoder) v2 and DDC v2 IPs found in MediaTek's MT8195, MT8188 SoC and their variants, and including support for display modes up to 4k60 and for HDMI Audio, as per the HDMI 2.0 spec. HDCP and CEC functionalities are also supported by this hardware, but are not included in this commit and that also poses a slight difference between the V2 and V1 controllers in how they handle Hotplug Detection (HPD). While the v1 controller was using the CEC controller to check HDMI cable connection and disconnection, in this driver the v2 one does not. This is due to the fact that on parts with v2 designs, like the MT8195 SoC, there is one CEC controller shared between the HDMI Transmitter (HDMI-TX) and Receiver (HDMI-RX): before eventually adding support to use the CEC HW to wake up the HDMI controllers it is necessary to have support for one TX, one RX *and* for both at the same time. Reviewed-by: CK Hu <ck.hu@mediatek.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com> Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20251023-mediatek-drm-hdmi-v2-v11-9-7873ec4a1edf@collabora.com/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org> ddc_v2 ddc_v2
2025-11-17drm/mediatek: mtk_hdmi_common: Add var to enable interlaced modesAngeloGioacchino Del Regno
Add an interlace_allowed bool member to struct mtk_hdmi_ver_conf which will be used to signal whether interlaced modes are supported by the bridge (in our case, the HDMI IP), and enable it for HDMIv2. Reviewed-by: CK Hu <ck.hu@mediatek.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com> Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20251023-mediatek-drm-hdmi-v2-v11-8-7873ec4a1edf@collabora.com/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2025-11-17drm/mediatek: mtk_hdmi_common: Add OP_HDMI if helper funcs assignedAngeloGioacchino Del Regno
In preparation for adding the HDMI TX v2 driver, and to allow a future modernization of the HDMI v1 one, perform changes that enable the usage of the HDMI Helpers provided by DRM. Check if the HDMI driver provides the function pointers to hdmi_{clear,write}_infoframe used by the HDMI Helper API and, if present, add DRM_BRIDGE_OP_HDMI to the drm_bridge ops, enabling the drm API to register the bridge as HDMI and to use the HDMI Helper functions. If the hdmi_{write,clear}_infoframe pointers are not assigned, vendor and product strings and HDMI helpers will not be used, hence this commit brings no functional changes to drivers that have not been refactored to use the new helpers. This also means that, in the current state, there is effectively no functional change to mtk_hdmi and its other components. Reviewed-by: CK Hu <ck.hu@mediatek.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com> Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20251023-mediatek-drm-hdmi-v2-v11-7-7873ec4a1edf@collabora.com/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2025-11-17drm/mediatek: mtk_hdmi_common: Assign DDC adapter pointer to bridgeAngeloGioacchino Del Regno
In preparation for adding the new HDMI TX v2 IP driver, assign the pointer to the DDC adapter to struct drm_bridge during probe. This commit brings no functional changes. Reviewed-by: CK Hu <ck.hu@mediatek.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com> Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20251023-mediatek-drm-hdmi-v2-v11-6-7873ec4a1edf@collabora.com/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2025-11-17drm/mediatek: mtk_hdmi_common: Make CEC support optionalAngeloGioacchino Del Regno
In preparation for adding a new driver for HDMIv2, for which CEC is not strictly required, change the of_get_compatible_child() failure error to -EOPNOTSUPP to be able to differentiate between error conditions in mtk_hdmi_dt_parse_pdata(). In that case, if -EOPNOTSUPP is returned, this driver will print an informative message saying that CEC support is unavailable, as the devicetree node for that was not found, but after that, function mtk_hdmi_dt_parse_pdata() will not return error to the caller. This will not change functionality of the mtk_hdmi (v1) driver as that is still checking whether CEC is present and, if not, will fail probing with an error saying that CEC is required by HDMIv1. Reviewed-by: CK Hu <ck.hu@mediatek.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com> Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20251023-mediatek-drm-hdmi-v2-v11-5-7873ec4a1edf@collabora.com/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2025-11-17drm/mediatek: mtk_hdmi: Split driver and add common probe functionAngeloGioacchino Del Regno
In preparation for adding a new driver for the HDMI TX v2 IP, split out the functions that will be common between the already present mtk_hdmi (v1) driver and the new one. Since the probe flow for both drivers is 90% similar, add a common probe function that will be called from each driver's .probe() callback, avoiding lots of code duplication. Reviewed-by: CK Hu <ck.hu@mediatek.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com> Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20251023-mediatek-drm-hdmi-v2-v11-4-7873ec4a1edf@collabora.com/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2025-11-17drm/mediatek: mtk_hdmi: Add HDMI IP version configuration to pdataAngeloGioacchino Del Regno
In preparation for adding a driver for the HDMIv2 IP and before moving the common bits out of this driver, add a new structure `mtk_hdmi_ver_conf`, holding pointers to HDMI IP version specific drm_bridge_funcs, hdmi_codec_ops and clock array used for probe, and nest it into the mtk_hdmi_conf platform data structure. While at it, also convert all of the direct users of mtk_hdmi_bridge_funcs, mtk_hdmi_audio_codec_ops, mtk_hdmi_clk_names to use pointers from the ver_conf platform data. In order to do so, it was also necessary to fill a new version 1 specific const `mtk_hdmi_v1_ver_conf` and assign it to all of the currently supported compatibles for this driver. This commit brings no functional change. Reviewed-by: CK Hu <ck.hu@mediatek.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com> Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20251023-mediatek-drm-hdmi-v2-v11-3-7873ec4a1edf@collabora.com/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2025-11-17drm/mediatek: mtk_hdmi: Improve mtk_hdmi_get_all_clk() flexibilityAngeloGioacchino Del Regno
In preparation for splitting common bits of this driver and for introducing a new version of the MediaTek HDMI Encoder IP, improve the flexibility of function mtk_hdmi_get_all_clk() by adding a pointer to the clock names array and size of it to its parameters. Also change the array of struct clock pointers in the mtk_hdmi structure to be dynamically allocated, and allocate it in probe. Reviewed-by: CK Hu <ck.hu@mediatek.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com> Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20251023-mediatek-drm-hdmi-v2-v11-2-7873ec4a1edf@collabora.com/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2025-11-17drm/mediatek: mtk_hdmi: Drop redundant clock retrieval in mtk_hdmi_get_cec_devLouis-Alexis Eyraud
In mtk_hdmi driver, when the CEC device parsing logic was moved from mtk_hdmi_dt_parse_pdata function to the new mtk_hdmi_get_cec_dev sub function, the call to mtk_hdmi_get_all_clk was kept in both functions, whereas it was only called once in the original mtk_hdmi_dt_parse_pdata code and does not need to be called a second time. So, remove this call from mtk_hdmi_get_cec_dev to keep the same sequence as previously. Fixes: 7485be967f7f ("drm/mediatek: mtk_hdmi: Move CEC device parsing in new function") Reviewed-by: CK Hu <ck.hu@mediatek.com> Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com> Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20251023-mediatek-drm-hdmi-v2-v11-1-7873ec4a1edf@collabora.com/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2025-11-17drm/mediatek: mtk_hdmi: Fix probe device leaksJohan Hovold
Make sure to drop the references to the DDC adapter and CEC device taken during probe on probe failure (e.g. probe deferral) and on driver unbind. Fixes: 8f83f26891e1 ("drm/mediatek: Add HDMI support") Cc: stable@vger.kernel.org # 4.8 Cc: Jie Qiu <jie.qiu@mediatek.com> Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://patchwork.kernel.org/project/dri-devel/patch/20250923152340.18234-5-johan@kernel.org/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2025-11-17gpu: nova-core: make formatting compatible with rust treeAlice Ryhl
Commit 38b7cc448a5b ("gpu: nova-core: implement Display for Spec") in drm-rust-next introduced some usage of the Display trait, but the Display trait is being modified in the rust tree this cycle. Thus, to avoid conflicts with the Rust tree, tweak how the formatting machinery is used in a way where it works both with and without the changes in the Rust tree. Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Tested-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20251117-nova-fmt-rust-v1-1-651ca28cd98f@google.com Signed-off-by: Alice Ryhl <aliceryhl@google.com>
2025-11-17Merge tag 'drm-misc-next-2025-11-14-1' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-next drm-misc-next for v6.19: UAPI Changes: - Add sysfs entries, coredump support and uevents to QAIC. - Add fdinfo memory statistics to ivpu. Cross-subsystem Changes: - Handle stub fence initialization during module init. - Stop using system_wq in scheduler and drivers. Core Changes: - Documentation updates to ttm, vblank. - Add EDID quirk for sharp panel. - Use drm_crtc_vblank_(crtc,waitqueue) more in core and drivers. Driver Changes: - Small updates and fixes to panfrost, amdxdna, vmwgfx, ast, ivpu. - Handle preemption in amdxdna. - Add PM support to qaic. - Huge refactor of sun4i's layer code to decouple plane code from output and improve support for DE33. - Add larger page and compression support to nouveau. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patch.msgid.link/1ad3ea69-d029-4a21-8b3d-6b264b1b2a30@linux.intel.com
2025-11-17Merge tag 'drm-xe-next-2025-11-14' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/xe/kernel into drm-next Driver Changes: Avoid TOCTOU when montoring throttle reasons (Lucas) Add/extend workaround (Nitin) SRIOV migration work / plumbing (Michal Wajdeczko, Michal Winiarski, Lukasz) Drop debug flag requirement for VF resource fixup Fix MTL vm_max_level (Rodrigo) Changes around TILE_ADDR_RANGE for platform compatibility (Fei, Lucas) Add runtime registers for GFX ver >= 35 (Piotr) Kerneldoc fix (Kriish) Rework pcode error mapping (Lucas) Allow lockdown the PF (Michal) Eliminate GUC code caching of some frequency values (Sk) Improvements around forcewake referencing (Matt Roper) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Hellstrom <thomas.hellstrom@linux.intel.com> Link: https://patch.msgid.link/aRcJOrisG2qPbucE@fedora
2025-11-17Merge tag 'drm-xe-next-2025-11-05' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/xe/kernel into drm-next UAPI Changes: Limit number of jobs per exec queue (Shuicheng) Add sriov_admin sysfs tree (Michal) Driver Changes: Fix an uninitialized value (Thomas) Expose a residency counter through debugfs (Mohammed Thasleem) Workaround enabling and improvement (Tapani, Tangudu) More Crescent Island-specific support (Sk Anirban, Lucas) PAT entry dump imprement (Xin) Inline gt_reset in the worker (Lucas) Synchronize GT reset with device unbind (Balasubramani) Do clean shutdown also when using flr (Jouni) Fix serialization on burst of unbinds (Matt Brost) Pagefault Refactor (Matt Brost) Remove some unused code (Gwan-gyeong) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Hellstrom <thomas.hellstrom@linux.intel.com> Link: https://patch.msgid.link/aQuBECxNOhudc0Bz@fedora
2025-11-16drm/bridge: simple: add the Parade PS185HDM DP-to-HDMI bridgeMaud Spierings
The Parade PS185HDM is a transparent Displayport to HDMI bridge. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Maud Spierings <maud_spierings@hotmail.com> Link: https://patch.msgid.link/20251116-asus_usbc_dp-v2-2-cc8f51136c9f@hotmail.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2025-11-15drm/msm/a6xx: Add support for Adreno 612Jie Zhang
Add support for Adreno 612 GPU found in SM6150/QCS615 chipsets. A612 falls under ADRENO_6XX_GEN1 family and is a cut down version of A615 GPU. A612 has a new IP called Reduced Graphics Management Unit or RGMU which is a small state machine which helps to toggle GX GDSC (connected to CX rail) to implement IFPC feature. It doesn't support any other features of a full fledged GMU like clock control, resource voting to rpmh etc. So we need linux clock driver support like other gmu-wrapper implementations to control gpu core clock and gpu GX gdsc. This patch skips RGMU core initialization and act more like a gmu-wrapper case. Signed-off-by: Jie Zhang <quic_jiezh@quicinc.com> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/686212/ Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2025-11-15drm/msm: Add NULL check in vm_op_enqueue()Gopi Krishna Menon
vm_op_enqueue() allocates an msm_vm_op struct with kmalloc, but the return value is not checked for NULL value which can be returned by kmalloc under low-memory conditions. This can result in NULL pointer dereference when the pointer is dereferenced. Add NULL check after the allocation and propagate -ENOMEM back to the caller in case of a failure. Signed-off-by: Gopi Krishna Menon <krishnagopi487@gmail.com> Patchwork: https://patchwork.freedesktop.org/patch/678416/ Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2025-11-15gpu: nova-core: provide a clear error report for unsupported GPUsJohn Hubbard
Pass in a PCI device to Spec::new(), and provide a Display implementation for boot42, in order to provide a clear, concise report of what happened: the driver read NV_PMC_BOOT42, and found that the GPU is not supported. For very old GPUs (older than Fermi), the driver still returns ENODEV, but it does so without a driver-specific dmesg report. That is exactly appropriate, because if such a GPU is installed, it can only be supported by Nouveau. And if so, the user is not helped by additional error messages from Nova. Here's the full dmesg output for a Blackwell (not yet supported) GPU: NovaCore 0000:01:00.0: Probe Nova Core GPU driver. NovaCore 0000:01:00.0: Unsupported chipset: boot42 = 0x1b2a1000 (architecture 0x1b, implementation 0x2) NovaCore 0000:01:00.0: probe with driver NovaCore failed with error -524 Cc: Alexandre Courbot <acourbot@nvidia.com> Cc: Danilo Krummrich <dakr@kernel.org> Cc: Timur Tabi <ttabi@nvidia.com> Cc: Joel Fernandes <joelagnelf@nvidia.com> Signed-off-by: John Hubbard <jhubbard@nvidia.com> [acourbot@nvidia.com: fix commit log with ENODEV (not ENOTSUPP) error code for unsupported GPUs.] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Message-ID: <20251115010923.1192144-5-jhubbard@nvidia.com>
2025-11-15gpu: nova-core: add boot42 support for next-gen GPUsJohn Hubbard
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 Hubbard
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 Hubbard
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 Popple
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 Popple
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 Fernandes
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 Fernandes
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 Fernandes
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 Fernandes
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 Fernandes
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 Fernandes
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 Fernandes
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 Fernandes
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 Fernandes
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 Fernandes
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 Fernandes
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/rockchip: vop2: Use OVL_LAYER_SEL configuration instead of use win_mask ↵Andy Yan
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 Osipenko
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-14drm/rockchip: dw_hdmi_qp: Add high color depth supportCristian Ciocaltea
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-14drm/rockchip: dw_hdmi_qp: Use bit macros for RK3576 regsCristian Ciocaltea
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-14drm/rockchip: dw_hdmi_qp: Switch to phy_configure()Cristian Ciocaltea
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-14drm/bridge: dw-hdmi-qp: Handle platform supported formats and color depthCristian Ciocaltea
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-14drm/rockchip: vop2: Check bpc before switching DCLK sourceCristian Ciocaltea
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-14drm/rockchip: analogix_dp: Use dev_err_probe() instead of DRM_DEV_ERROR() ↵Damon Ding
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-14drm/rockchip: dw_hdmi_qp: Fixup usage of enable_gpio member in main structCristian Ciocaltea
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/tegra: Add NVJPG driverDiogo Ivo
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ärvinen
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ärvinen
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ärvinen
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