summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-11-18reset: rzg2l-usbphy-ctrl: Add support for USB PWRRDYClaudiu Beznea
On the Renesas RZ/G3S SoC, the USB PHY block has an input signal called PWRRDY. This signal is managed by the system controller and must be de-asserted after powering on the area where USB PHY resides and asserted before powering it off. On power-on/resume the USB PWRRDY signal need to be de-asserted before enabling clock and switching the module to normal state (through MSTOP support). The power-on/resume configuration sequence must be: 1/ PWRRDY=0 2/ CLK_ON=1 3/ MSTOP=0 On power-off/suspend the configuration sequence should be: 1/ MSTOP=1 2/ CLK_ON=0 3/ PWRRDY=1 The CLK_ON and MSTOP functionalities are controlled by clock drivers. The suspend/resume support will be handled by different patches. After long discussions with the internal HW team, it has been confirmed that the HW connection b/w USB PHY block, the USB channels, the system controller, clock, MSTOP, PWRRDY signal is as follows: ┌──────────────────────────────┐ │ │◄── CPG_CLKON_USB.CLK0_ON │ USB CH0 │ ┌──────────────────────────┐ │┌───────────────────────────┐ │◄── CPG_CLKON_USB.CLK2_ON │ ┌────────┐ ││host controller registers │ │ │ │ │ ││function controller registers│ │ │ PHY0 │◄──┤└───────────────────────────┘ │ │ USB PHY │ │ └────────────▲─────────────────┘ │ └────────┘ │ │ │ CPG_BUS_PERI_COM_MSTOP.MSTOP{6, 5}_ON │┌──────────────┐ ┌────────┐ ││USHPHY control│ │ │ ││ registers │ │ PHY1 │ ┌──────────────────────────────┐ │└──────────────┘ │ │◄──┤ USB CH1 │ │ └────────┘ │┌───────────────────────────┐ │◄── CPG_CLKON_USB.CLK1_ON └─▲───────▲─────────▲──────┘ ││ host controller registers │ │ │ │ │ │└───────────────────────────┘ │ │ │ │ └────────────▲─────────────────┘ │ │ │ │ │ │ │ CPG_BUS_PERI_COM_MSTOP.MSTOP7_ON │PWRRDY │ │ │ │ CPG_CLK_ON_USB.CLK3_ON │ │ │ CPG_BUS_PERI_COM_MSTOP.MSTOP4_ON │ ┌────┐ │SYSC│ └────┘ where: - CPG_CLKON_USB.CLK.CLKX_ON is the register bit controlling the clock X of different USB blocks, X in {0, 1, 2, 3} - CPG_BUS_PERI_COM_MSTOP.MSTOPX_ON is the register bit controlling the MSTOP of different USB blocks, X in {4, 5, 6, 7} - USB PHY is the USB PHY block exposing 2 ports, port0 and port1, used by the USB CH0, USB CH1 - SYSC is the system controller block controlling the PWRRDY signal - USB CHx are individual USB block with host and function capabilities (USB CH0 have both host and function capabilities, USB CH1 has only host capabilities) The USBPHY control registers are controlled though the reset-rzg2l-usbphy-ctrl driver. The USB PHY ports are controlled by phy_rcar_gen3_usb2 (drivers/phy/renesas/phy-rcar-gen3-usb2.c file). The USB PHY ports request resets from the reset-rzg2l-usbphy-ctrl driver. The connection b/w the system controller and the USB PHY CTRL driver is implemented through the renesas,sysc-pwrrdy device tree property proposed in this patch. This property specifies the register offset and the bitmask required to control the PWRRDY signal. Since the USB PHY CTRL driver needs to be probed before any other USB-specific driver on RZ/G3S, control of PWRRDY is passed exclusively to it. This guarantees the correct configuration sequence between clocks, MSTOP bits, and the PWRRDY bit on probe/resume and remove/suspend. At the same time, changes are kept minimal by avoiding modifications to the USB PHY driver to also handle the PWRRDY itself. Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2025-11-18dt-bindings: reset: renesas,rzg2l-usbphy-ctrl: Document RZ/G3S supportClaudiu Beznea
The Renesas USB PHY hardware block needs to have the PWRRDY bit in the system controller set before applying any other settings. The PWRRDY bit must be controlled during power-on, power-off, and system suspend/resume sequences as follows: - during power-on/resume, it must be set to zero before enabling clocks and modules - during power-off/suspend, it must be set to one after disabling clocks and modules Add the renesas,sysc-pwrrdy device tree property, which allows the reset-rzg2l-usbphy-ctrl driver to parse, map, and control the system controller PWRRDY bit at the appropriate time. Along with it add a new compatible for the RZ/G3S SoC. Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2025-11-18reset: eswin: Add eic7700 reset driverXuyang Dong
Add support for reset controller in eic7700 series chips. Provide functionality for asserting and deasserting resets on the chip. Signed-off-by: Yifeng Huang <huangyifeng@eswincomputing.com> Signed-off-by: Xuyang Dong <dongxuyang@eswincomputing.com> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2025-11-18dt-bindings: reset: eswin: Documentation for eic7700 SoCXuyang Dong
Add device tree binding documentation and header file for the ESWIN eic7700 reset controller module. Signed-off-by: Yifeng Huang <huangyifeng@eswincomputing.com> Signed-off-by: Xuyang Dong <dongxuyang@eswincomputing.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2025-11-18reset: sparx5: add LAN969x supportRobert Marko
LAN969x uses the same reset configuration as LAN966x, but we need to allow compiling it when ARCH_LAN969X is selected. A fallback compatible to LAN966x will be used. Signed-off-by: Robert Marko <robert.marko@sartura.hr> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2025-11-18dt-bindings: reset: microchip: Add LAN969x supportRobert Marko
LAN969x also uses the Microchip reset driver, it reuses the LAN966x support so use a fallback compatible. Signed-off-by: Robert Marko <robert.marko@sartura.hr> Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2025-11-18KVM: SVM: Fix redundant updates of LBR MSR interceptsYosry Ahmed
Don't update the LBR MSR intercept bitmaps if they're already up-to-date, as unconditionally updating the intercepts forces KVM to recalculate the MSR bitmaps for vmcb02 on every nested VMRUN. The redundant updates are functionally okay; however, they neuter an optimization in Hyper-V nested virtualization enlightenments and this manifests as a self-test failure. In particular, Hyper-V lets L1 mark "nested enlightenments" as clean, i.e. tell KVM that no changes were made to the MSR bitmap since the last VMRUN. The hyperv_svm_test KVM selftest intentionally changes the MSR bitmap "without telling KVM about it" to verify that KVM honors the clean hint, correctly fails because KVM notices the changed bitmap anyway: ==== Test Assertion Failure ==== x86/hyperv_svm_test.c:120: vmcb->control.exit_code == 0x081 pid=193558 tid=193558 errno=4 - Interrupted system call 1 0x0000000000411361: assert_on_unhandled_exception at processor.c:659 2 0x0000000000406186: _vcpu_run at kvm_util.c:1699 3 (inlined by) vcpu_run at kvm_util.c:1710 4 0x0000000000401f2a: main at hyperv_svm_test.c:175 5 0x000000000041d0d3: __libc_start_call_main at libc-start.o:? 6 0x000000000041f27c: __libc_start_main_impl at ??:? 7 0x00000000004021a0: _start at ??:? vmcb->control.exit_code == SVM_EXIT_VMMCALL Do *not* fix this by skipping svm_hv_vmcb_dirty_nested_enlightenments() when svm_set_intercept_for_msr() performs a no-op change. changes to the L0 MSR interception bitmap are only triggered by full CPUID updates and MSR filter updates, both of which should be rare. Changing svm_set_intercept_for_msr() risks hiding unintended pessimizations like this one, and is actually more complex than this change. Fixes: fbe5e5f030c2 ("KVM: nSVM: Always recalculate LBR MSR intercepts in svm_update_lbrv()") Cc: stable@vger.kernel.org Signed-off-by: Yosry Ahmed <yosry.ahmed@linux.dev> Link: https://patch.msgid.link/20251112013017.1836863-1-yosry.ahmed@linux.dev [Rewritten commit message based on mailing list discussion. - Paolo] Reviewed-by: Sean Christopherson <seanjc@google.com> Tested-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-11-18drm/amd/display: Prevent Gating DTBCLK before It Is Properly LatchedFangzhi Zuo
[why] 1. With allow_0_dtb_clk enabled, the time required to latch DTBCLK to 600 MHz depends on the SMU. If DTBCLK is not latched to 600 MHz before set_mode completes, gating DTBCLK causes the DP2 sink to lose its clock source. 2. The existing DTBCLK gating sequence ungates DTBCLK based on both pix_clk and ref_dtbclk, but gates DTBCLK when either pix_clk or ref_dtbclk is zero. pix_clk can be zero outside the set_mode sequence before DTBCLK is properly latched, which can lead to DTBCLK being gated by mistake. [how] Consider both pixel_clk and ref_dtbclk when determining when it is safe to gate DTBCLK; this is more accurate. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4701 Fixes: 5949e7c4890c ("drm/amd/display: Enable Dynamic DTBCLK Switch") Reviewed-by: Charlene Liu <charlene.liu@amd.com> Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Fangzhi Zuo <Jerry.Zuo@amd.com> Signed-off-by: Roman Li <roman.li@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit d04eb0c402780ca037b62a6aecf23b863545ebca) Cc: stable@vger.kernel.org
2025-11-18Merge tag 'kvmarm-fixes-6.18-3' of ↵Paolo Bonzini
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into HEAD KVM/arm64 fixes for 6.18, take #3 - Only adjust the ID registers when no irqchip has been created once per VM run, instead of doing it once per vcpu, as this otherwise triggers a pretty bad conbsistency check failure in the sysreg code. - Make sure the per-vcpu Fine Grain Traps are computed before we load the system registers on the HW, as we otherwise start running without anything set until the first preemption of the vcpu.
2025-11-18PNP: Fix ISAPNP to generate uevents to auto-load modulesRené Rebe
Currently ISAPNP devices do not generate an uevent for udev to auto-load the driver modules for Creative SoundBlaster or Gravis UltraSound to just work. Signed-off-by: René Rebe <rene@exactco.de> [ rjw: Subject edits ] Link: https://patch.msgid.link/20251118.145942.1445519082574147037.rene@exactco.de Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-11-18clk: qcom: ecpricc-qdu100: Add mem_enable_mask to the clock memory branchTaniya Das
The ECPRI clock controller’s mem_ops clocks used the mem_enable_ack_mask directly for both setting and polling. Add the newly introduced 'mem_enable_mask' to the memory control branch clocks of ECPRI clock controller to align to the new mem_ops handling. Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com> Reviewed-by: Imran Shaik <imran.shaik@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251118-sm8750-videocc-v2-v4-2-049882a70c9f@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-11-18clk: qcom: clk_mem_branch: add enable mask and invert flagsTaniya Das
Introduce mem_enable_mask and mem_enable_invert in clk_mem_branch to describe memory gating implementations that use a separate mask and/or inverted enable logic. This documents hardware behavior in data instead of code and will be used by upcoming platform descriptions. Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com> Reviewed-by: Imran Shaik <imran.shaik@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251118-sm8750-videocc-v2-v4-1-049882a70c9f@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-11-18clk: qcom: mmcc-sdm660: Add missing MDSS resetAlexey Minnekhanov
Add offset for display subsystem reset in multimedia clock controller block, which is necessary to reset display when there is some configuration in display controller left by previous stock (Android) bootloader to provide continuous splash functionaluty. Before 6.17 power domains were turned off for long enough to clear registers, now this is not the case and a proper reset is needed to have functioning display. Fixes: 0e789b491ba0 ("pmdomain: core: Leave powered-on genpds on until sync_state") Cc: stable@vger.kernel.org # 6.17 Signed-off-by: Alexey Minnekhanov <alexeymin@postmarketos.org> Reviewed-by: Taniya Das <taniya.das@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251116-sdm660-mdss-reset-v2-2-6219bec0a97f@postmarketos.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-11-18dt-bindings: clock: mmcc-sdm660: Add missing MDSS resetAlexey Minnekhanov
Add definition for display subsystem reset control, so display driver can reset display controller properly, clearing any configuration left there by bootloader. Since 6.17 after PM domains rework it became necessary for display to function. Fixes: 0e789b491ba0 ("pmdomain: core: Leave powered-on genpds on until sync_state") Cc: stable@vger.kernel.org # 6.17 Signed-off-by: Alexey Minnekhanov <alexeymin@postmarketos.org> Acked-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20251116-sdm660-mdss-reset-v2-1-6219bec0a97f@postmarketos.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-11-18Merge branch 'python-modules' into docs-mwJonathan Corbet
scripts/lib was always a bit of an awkward place for Python libraries; give them a proper home under tools/lib/python. Put the modules from tools/docs/lib there for good measure. The second patch ties them into a single package namespace. It would be more aesthetically pleasing to add a kernel layer, so we could say: from kernel.kdoc import kdoc_parser ...and have the kernel-specific stuff clearly marked, but that means adding an empty directory in the hierarchy, which isn't as pleasing. There are some other "Python library" directories hidden in the kernel tree; we may eventually want to encourage them to move as well.
2025-11-18docs: bring some order to our Python module hierarchyJonathan Corbet
Now that we have tools/lib/python for our Python modules, turn them into proper packages with a single namespace so that everything can just use tools/lib/python in sys.path. No functional change. Signed-off-by: Jonathan Corbet <corbet@lwn.net> Message-ID: <20251110220430.726665-3-corbet@lwn.net>
2025-11-18docs: Move the python libraries to tools/lib/pythonJonathan Corbet
"scripts/lib" was always a bit of an awkward place for Python modules. We already have tools/lib; create a tools/lib/python, move the libraries there, and update the users accordingly. While at it, move the contents of tools/docs/lib. Rather than make another directory, just put these documentation-oriented modules under "kdoc". Signed-off-by: Jonathan Corbet <corbet@lwn.net> Message-ID: <20251110220430.726665-2-corbet@lwn.net>
2025-11-18mm/huge_memory: Fix initialization of huge zero folioLinus Torvalds
The recent fix to properly initialize the tags of the huge zero folio had an unfortunate not-so-subtle side effect: it caused the actual *contents* of the huge zero folio to not be initialized at all when the hardware didn't support the memory tagging. The reason was the unfortunate semantics of tag_clear_highpage(): on hardware that didn't do the tagging, it would silently just not do anything at all. And since this is done only on arm64 with MTE support, that basically meant most hardware. It wasn't necessarily immediately obvious since the huge zero page isn't necessarily very heavily used - or because it might already be zero because all-zeroes is the most common pattern. But it ends up causing random odd user space failures when you do hit it. The unfortunate semantics have been around for a while, but became a real bug only when we started actively using __GFP_ZEROTAGS in the generic get_huge_zero_folio() function - before that, it had only ever been used in code that checked that the hardware supported it. Fix this by simply changing the semantics of tag_clear_highpage() to return whether it actually successfully did something or not. While at it, also make it initialize multiple pages in one go, since that's actually what the only caller wants it to do and it simplifies the whole logic. Fixes: adfb6609c680 ("mm/huge_memory: initialise the tags of the huge zero folio") Link: https://lore.kernel.org/all/20251117082023.90176-1-00107082@163.com/ Reviewed-by: David Hildenbrand (Red Hat) <david@kernel.org> Reported-and-tested-by: David Wang <00107082@163.com> Reported-and-tested-by: Carlos Llamas <cmllamas@google.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2025-11-18Documentation/kernel-parameters: Move the kernel build optionsBorislav Petkov (AMD)
Move the kernel build options abbreviations to the .txt file so that they are together instead of one having to go hunt them in the .rst file. Tweak the formatting so that the inclusion of kernel-parameters.txt still keeps the whole thing somewhat presentable in the html output too. Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Tested-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Message-ID: <20251112114641.8230-1-bp@kernel.org>
2025-11-18docs: parse-headers.rst: Fix a typoAnkit Khushwaha
Replace "vantage" with "advantage" in the description of userspace API cross-references. Signed-off-by: Ankit Khushwaha <ankitkhushwaha.linux@gmail.com> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Message-ID: <20251115114233.32239-1-ankitkhushwaha.linux@gmail.com>
2025-11-18Documentation/kernel-parameters: fix typo in retbleed= kernel parameter ↵Xie Yuanbin
description Fixes a typo in the retbleed= parameter description, changing "migitation" to "mitigation". Fixes: 7fbf47c7ce50 ("x86/bugs: Add AMD retbleed= boot parameter") Signed-off-by: Xie Yuanbin <qq570070308@gmail.com> Acked-by: Borislav Petkov (AMD) <bp@alien8.de> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Message-ID: <20251116145302.3681-1-qq570070308@gmail.com>
2025-11-18drm/amd/display: Move analog check to dce110_hwseqTimur Kristóf
Instead of checking that the signal is analog before calling the HWSS disable_audio_stream() function to disable audio, move the check inside the HWSS function. Suggested-by: Ray Wu <Ray.Wu@amd.com> Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Link: https://lore.kernel.org/r/20251113163348.137315-5-timur.kristof@gmail.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-18drm/amd/display: Cleanup early return in construct_phyTimur Kristóf
Match pre-existing patterns in the DC code base. Instead of returning early from the construct_phy() function, add a label at the end and use goto to jump there. Additionally, respect the DC logger and let it log the function even when it returns early. Suggested-by: Ray Wu <Ray.Wu@amd.com> Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Link: https://lore.kernel.org/r/20251113163348.137315-4-timur.kristof@gmail.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-18drm/amd/display: Cleanup uses of the analog flagTimur Kristóf
In the detect_link_and_local_sink() function, do not modify the EDID capabilities of the display based on the connector. Instead, respect the analog flag better and when the analog flag is set, check that the connector indeed supports analog displays. Suggested-by: Ray Wu <Ray.Wu@amd.com> Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Link: https://lore.kernel.org/r/20251113163348.137315-3-timur.kristof@gmail.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-18drm/amd/display: Fix warning for analog stream encodersTimur Kristóf
Fixes the following warning that some users are reporting with some kernel configurations: "positional initialization of field in 'struct' declared with 'designated_init' attribute" Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Acked-by: Kees Cook <kees@kernel.org> Link: https://lore.kernel.org/r/20251113163348.137315-2-timur.kristof@gmail.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-18drm/radeon: delete radeon_fence_process in is_signaled, no deadlockRobert McClinton
Delete the attempt to progress the queue when checking if fence is signaled. This avoids deadlock. dma-fence_ops::signaled can be called with the fence lock in unknown state. For radeon, the fence lock is also the wait queue lock. This can cause a self deadlock when signaled() tries to make forward progress on the wait queue. But advancing the queue is unneeded because incorrectly returning false from signaled() is perfectly acceptable. Link: https://github.com/brave/brave-browser/issues/49182 Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4641 Cc: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Robert McClinton <rbmccav@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-18drm/amd/display: dc_hw_sequencer.c: remove kernel-doc commentsRandy Dunlap
Change comments from kernel-doc style "/**" to normal C comments "/*" since the comments are not in kernel-doc format. This fixes around 39 kernel-doc warnings like this one: drivers/gpu/drm/amd/display/dc/core/dc_hw_sequencer.c:1322: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202511062036.Ry8Z2APc-lkp@intel.com/ Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-18drm/amdgpu: Unregister mce notifierLijo Lazar
Unregister mce notifier on unload. Signed-off-by: Lijo Lazar <lijo.lazar@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-18drm/amd/display: Promote DC to 3.2.359Taimur Hassan
This version brings along the following updates: - Add interface to capture expected HW state from SW state - Add panel Replay capability detection, DPCD reading, and enablement logic - Re-check seamless boot enablement on subsequent dc_commit_streams - Improve DPCD link capability retrieval with increased retries and per-retry delays - Add HPD filter for HDMI - Add pipe topology history tracking to DC - Fix MST initialization on resume when switching from SST to MST during suspend - Fix double cursor on DCN20 & DCN30 in non-native scaling - Check DCCG_AUDIO_DTO2 register mask before access - Fix pbn to kbps conversion Reviewed-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Taimur Hassan <Syed.Hassan@amd.com> Signed-off-by: Ivan Lipski <ivan.lipski@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-18drm/amd/display: Ignore Coverity false positiveTaimur Hassan
[Why&How] Ignore Coverity false positive analysis in the dmub_cmd.h Reviewed-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Taimur Hassan <Syed.Hassan@amd.com> Signed-off-by: Ivan Lipski <ivan.lipski@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-18drm/amd/display: Fix pbn to kbps ConversionFangzhi Zuo
[Why] Existing routine has two conversion sequence, pbn_to_kbps and kbps_to_pbn with margin. Non of those has without-margin calculation. kbps_to_pbn with margin conversion includes fec overhead which has already been included in pbn_div calculation with 0.994 factor considered. It is a double counted fec overhead factor that causes potential bw loss. [How] Add without-margin calculation. Fix fec overhead double counted issue. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3735 Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Fangzhi Zuo <Jerry.Zuo@amd.com> Signed-off-by: Ivan Lipski <ivan.lipski@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-18drm/amd/display: Check DCCG_AUDIO_DTO2 register mask existCharlene Liu
[Why&How] Check DCCG_AUDIO_DTO2 register mask exist before access. Also, add a existing DIO_CLOCK_control register for later use. Reviewed-by: Roman Li <roman.li@amd.com> Signed-off-by: Charlene Liu <Charlene.Liu@amd.com> Signed-off-by: Ivan Lipski <ivan.lipski@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-18drm/amd/display: Add null pointer check in link_dpmsCharlene Liu
[why] Check that the stream exists to add link->local_sink null pointer access protection. Reviewed-by: Harold Sun <harold.sun@amd.com> Reviewed-by: Ethan Cheung <ethan.cheung@amd.com> Signed-off-by: Charlene Liu <Charlene.Liu@amd.com> Signed-off-by: Ivan Lipski <ivan.lipski@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-18drm/amd/display: Clear the CUR_ENABLE register on DCN20 on DPP5Ivan Lipski
[Why] On DCN20 & DCN30, the 6th DPP's & HUBP's are powered on permanently and cannot be power gated. Thus, when dpp_reset() is invoked for the DPP5, while it's still powered on, the cached cursor_state (dpp_base->pos.cur0_ctl.bits.cur0_enable) and the actual state (CUR0_ENABLE) bit are unsycned. This can cause a double cursor in full screen with non-native scaling. [How] Force disable cursor on DPP5 on plane powerdown for ASICs w/ 6 DPPs/HUBPs. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4673 Reviewed-by: Aric Cyr <aric.cyr@amd.com> Signed-off-by: Ivan Lipski <ivan.lipski@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-18drm/amd/display: Add pipe topology history to dcNicholas Carbones
[Why] There is no way to check pipe topology update history through a dump. [How] Add a topology history structure to dc with snapshots of the most recent pipe topology updates. Reviewed-by: George Shen <george.shen@amd.com> Signed-off-by: Nicholas Carbones <ncarbone@amd.com> Signed-off-by: Ivan Lipski <ivan.lipski@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-18drm/amd/display: Add an HPD filter for HDMIIvan Lipski
[Why] Some monitors perform rapid “autoscan” HPD re‑assertions right after a disconnect or powersaving mode enablement. These appear as a quick disconnect→reconnect with an identical EDID. Since Linux has no HDMI hotplug detection (HPD) filter, these quick reconnects are seen as hotplug events, which can unintentionally wake a system with DPMS off. An example: https://gitlab.freedesktop.org/drm/amd/-/issues/2876 Such 'fake reconnects' are considered when the interval between a disconnect and a connect is within 1500ms (experimentally chosen using several monitors), and the two connections have the same EDID. [How] Implement a time-based debounce mechanism: 1. On HDMI disconnect detection, instead of immediately processing the HPD event, save the current sink and schedule delayed work (default 1500ms) 2. If another HDMI disconnect HPD event arrives during the debounce period, it reschedules the pending work, ensuring only the final state is processed. 3. When the debounce timer expires, re-detect the display and compare the new sink with the cached one using EDID comparison. 4. If sinks match (same EDID), this was a spontaneous HPD toggle: - Update connector state internally - Skip hotplug event to prevent desktop rearrangement If sinks differ, this was a real display change: - Process normally with the hotplug event The debounce delay is configurable via module parameter 'hdmi_hpd_debounce_delay_ms'. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/2876 Reviewed-by: Sun peng (Leo) Li <sunpeng.li@amd.com> Signed-off-by: Ivan Lipski <ivan.lipski@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-18drm/amd/display: Increase DPCD read retriesMario Limonciello (AMD)
[Why] Empirical measurement of some monitors that fail to read EDID while booting shows that the number of retries with a 30ms delay between tries is as high as 16. [How] Increase number of retries to 20. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4672 Reviewed-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: Ivan Lipski <ivan.lipski@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-18EDAC/ghes: Replace deprecated strcpy() in ghes_edac_report_mem_error()Thorsten Blum
strcpy() has been deprecated¹ because it performs no bounds checking on the destination buffer, which can lead to buffer overflows. Use the safer strscpy() instead. ¹ https://www.kernel.org/doc/html/latest/process/deprecated.html#strcpy Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com> Link: https://patch.msgid.link/20251118135621.101148-2-thorsten.blum@linux.dev
2025-11-18drm/amd/display: Move sleep into each retry for retrieve_link_cap()Mario Limonciello (AMD)
[Why] When a monitor is booting it's possible that it isn't ready to retrieve link caps and this can lead to an EDID read failure: ``` [drm:retrieve_link_cap [amdgpu]] *ERROR* retrieve_link_cap: Read receiver caps dpcd data failed. amdgpu 0000:c5:00.0: [drm] *ERROR* No EDID read. ``` [How] Rather than msleep once and try a few times, msleep each time. Should be no changes for existing working monitors, but should correct reading caps on a monitor that is slow to boot. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4672 Reviewed-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: Ivan Lipski <ivan.lipski@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-18drm/amd/display: Re-check seamless boot can be enabled or notPaul Hsieh
[Why] If the seamless boot feature has already been enabled, and dc_commit_streams is called again before receiving a flip, the driver will adjust the engine clock without turning off the screen, which will cause garbage to occur. However, in reality, the Pixel Clock from the first dc_commit_streams and the second dc_commit_streams are different. [How] If the apply seamless boot flag in the previous stream has not been cleared, and dc_commit_streams is received again, we need to recheck whether seamless boot should be disabled Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Paul Hsieh <Paul.Hsieh@amd.com> Signed-off-by: Ivan Lipski <ivan.lipski@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-18drm/amd/display: Get panel replay capability from DPCDJack Chang
[Why&How] Read Panel replay caps from DPCD when retrieving link capability Reviewed-by: Robin Chen <robin.chen@amd.com> Signed-off-by: Jack Chang <jack.chang@amd.com> Signed-off-by: Leon Huang <Leon.Huang1@amd.com> Signed-off-by: Ivan Lipski <ivan.lipski@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-18drm/amd/display: Add panel replay enablement option and logicJack Chang
[Why&How] 1.Add flow to enable and configure panel replay enablement and configuration 2.Add registry key for enable option 3.Add replay version check to be compatible with freesync replay 4.Add AC/DC switch function to notify ac/dc change. 5.Add flow in set event function to check and decide Replay enable/disable Reviewed-by: Robin Chen <robin.chen@amd.com> Signed-off-by: Jack Chang <jack.chang@amd.com> Signed-off-by: Leon Huang <Leon.Huang1@amd.com> Signed-off-by: Ivan Lipski <ivan.lipski@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-18drm/amd/display: Add panel replay capability detectionJack Chang
[Why&How] For supporting VESA PR, add flow to determine the support capability Reviewed-by: Robin Chen <robin.chen@amd.com> Signed-off-by: Jack Chang <jack.chang@amd.com> Signed-off-by: Leon Huang <Leon.Huang1@amd.com> Signed-off-by: Ivan Lipski <ivan.lipski@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-18drm/amd/display: Add interface to capture expected HW state from SW stateGeorge Shen
[Why] To debug certain issues, such as underflow, it is common practice to dump the HW state of all registers for analysis. The first thing to check with the dump is to ensure all values are programmed as expected according to SW state. [How] Add interface to DC to capture expected HW register values based on SW state. Reviewed-by: Dillon Varone <dillon.varone@amd.com> Signed-off-by: George Shen <george.shen@amd.com> Signed-off-by: Ivan Lipski <ivan.lipski@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-11-18drm/msm/adreno: Add MMU fault handler to adreno_gpu_funcAkhil P Oommen
Move MMU fault handler for each generation to adreno function list. This will help to use common code for mmu pagefault handler registration between a6x/a7x and a8x layer. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/689007/ Message-ID: <20251118-kaana-gpu-support-v4-8-86eeb8e93fb6@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2025-11-18drm/msm/adreno: Move gbif_halt() to adreno_gpu_funcAkhil P Oommen
Move the gbif halt fn to adreno_gpu_func so that we can call different implementation from common code. This will come handy when we implement A8x layer. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/689005/ Message-ID: <20251118-kaana-gpu-support-v4-7-86eeb8e93fb6@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2025-11-18drm/msm/adreno: Move adreno_gpu_func to catalogueAkhil P Oommen
In A6x family (which is a pretty big one), there are separate adreno_func definitions for each sub-generations. To streamline the identification of the correct struct for a gpu, move it to the catalogue and move the gpu_init routine to struct adreno_gpu_funcs. Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/689003/ Message-ID: <20251118-kaana-gpu-support-v4-6-86eeb8e93fb6@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2025-11-18drm/msm/adreno: Common-ize PIPE definitionsAkhil P Oommen
Newer gen's introduce pipe enums which do not exist on older gens, but the numeric values do not conflict. IOW, they are backward compatible. So move its definition to adreno_common.xml. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/689001/ Message-ID: <20251118-kaana-gpu-support-v4-5-86eeb8e93fb6@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2025-11-18drm/msm/a6xx: Skip dumping SCRATCH registersAkhil P Oommen
Crashdec doesn't require SCRATCH registers anymore for a6xx and newer architectures. So skip dumping them during recovery. Suggested-by: Rob Clark <rob.clark@oss.qualcomm.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/689000/ Message-ID: <20251118-kaana-gpu-support-v4-4-86eeb8e93fb6@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2025-11-18drm/msm/a6xx: Fix the gemnoc workaroundAkhil P Oommen
Correct the register offset and enable this workaround for all A7x and newer GPUs to match the recommendation. Also, downstream does this w/a after moving the fence to allow mode. So do the same. Fixes: dbfbb376b50c ("drm/msm/a6xx: Add A621 support") Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/688997/ Message-ID: <20251118-kaana-gpu-support-v4-3-86eeb8e93fb6@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>