summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2026-01-20drm/rockchip: dw_hdmi_qp: Optimize RK3588 HPD interrupt handlingCristian Ciocaltea
The threaded interrupt handler on RK3588 checks HPD IRQ status before deciding to continue with interrupt clearing and unmasking. However, this is not really necessary, since the hard interrupt handler already performs the very same verification before waking the handler thread. Get rid of the redundant verification of the HPD interrupt status in the threaded interrupt handler. Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patch.msgid.link/20260115-dw-hdmi-qp-hpd-v1-2-e59c166eaa65@collabora.com
2026-01-20drm/rockchip: dw_hdmi_qp: Fix RK3576 HPD interrupt handlingCristian Ciocaltea
The threaded interrupt handler on RK3576 checks HPD IRQ status before deciding to continue with interrupt clearing and unmasking. This is not only redundant, since a similar verification has been already performed by the hard IRQ handler before masking the interrupt, but is also error prone, because it might happen that hardware clears the status register right after the masking operation completes, and before the threaded handler reads its value. The consequence is that HPD IRQ gets never unmasked, which breaks hotplug detection until reloading the driver or rebooting the system. Drop the unnecessary verification of the HPD interrupt status from the threaded interrupt handler. Fixes: 36439120efbd ("drm/rockchip: dw_hdmi_qp: Add basic RK3576 HDMI output support") Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patch.msgid.link/20260115-dw-hdmi-qp-hpd-v1-1-e59c166eaa65@collabora.com
2026-01-20drm/tests: hdmi: fix build failureDmitry Baryshkov
The commit ca59e33f5a1f ("drm/atomic: add max_size check to drm_property_replace_blob_from_id()") added a new parameter to drm_property_replace_blob_from_id(), however commit 7436a87db99d ("drm/tests: hdmi: check the infoframes behaviour") was based on the older tree and used the old number of params (with me failing to run kunit tests when applying). Fix the build error by specifying -1 as the max_size (as expected). Fixes: 7436a87db99d ("drm/tests: hdmi: check the infoframes behaviour") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202601200306.dgF5deFm-lkp@intel.com/ Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Link: https://patch.msgid.link/20260119-fix-kunit-infoframe-v1-1-5f2f9b066594@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-01-20drm/hisilicon/hibmc: Adding reset colorbar cfg in dp init.Baihan Li
Add colorbar disable operation before reset chontroller, to make sure colorbar status is clear in the DP init, so if rmmod the driver and the previous colorbar configuration will not affect the next time insmod the driver. Fixes: 3c7623fb5bb6 ("drm/hisilicon/hibmc: Enable this hot plug detect of irq feature") Signed-off-by: Baihan Li <libaihan@huawei.com> Signed-off-by: Yongbang Shi <shiyongbang@huawei.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Tao Tian <tiantao6@hisilicon.com> Link: https://patch.msgid.link/20251210023759.3944834-5-shiyongbang@huawei.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-01-20drm/hisilicon/hibmc: fix no showing problem with loading hibmc manuallyBaihan Li
When using command rmmod and insmod, there is no showing in second time insmoding. Because DP controller won't send HPD signals, if connection doesn't change or controller isn't reset. So add reset before unreset in hibmc_dp_hw_init(). And also need to move the HDCP cfg after DP controller de-resets, so that HDCP configuration takes effect. Fixes: 3c7623fb5bb6 ("drm/hisilicon/hibmc: Enable this hot plug detect of irq feature") Signed-off-by: Baihan Li <libaihan@huawei.com> Signed-off-by: Yongbang Shi <shiyongbang@huawei.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Tao Tian <tiantao6@hisilicon.com> Link: https://patch.msgid.link/20251210023759.3944834-4-shiyongbang@huawei.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-01-20drm/hisilicon/hibmc: add dp mode valid checkBaihan Li
If DP is connected, check the DP BW in mode_valid_ctx() to ensure that DP's link rate supports high-resolution data transmission. Fixes: 0ab6ea261c1f ("drm/hisilicon/hibmc: add dp module in hibmc") Signed-off-by: Baihan Li <libaihan@huawei.com> Signed-off-by: Yongbang Shi <shiyongbang@huawei.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Tao Tian <tiantao6@hisilicon.com> Link: https://patch.msgid.link/20251210023759.3944834-3-shiyongbang@huawei.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-01-20drm/hisilicon/hibmc: fix dp probabilistical detect errors after HPD irqBaihan Li
The issue is that drm_connector_helper_detect_from_ddc() returns wrong status when plugging or unplugging the monitor, which may cause the link failed err.[0] Use HPD pin status in DP's detect_ctx() for real physical monitor in/out, and implement a complete DP detection including read DPCD, check if it's a branch device and its sink count for different situations. [0]: hibme-drm 0000:83:00.0: [drm] *ERROR* channel equalization failed 5 times hibme-drm 0000:83:00.0: [drm] *ERROR* channel equalization failed 5 times hibme-drm 0000:83:00.0: [drm] *ERROR* dp link training failed, ret: -16 hibmc-drm 0000:83:00.0: [drm] *ERROR* hibme dp mode set failed: -16 Fixes: 3c7623fb5bb6 ("drm/hisilicon/hibmc: Enable this hot plug detect of irq feature") Signed-off-by: Baihan Li <libaihan@huawei.com> Signed-off-by: Yongbang Shi <shiyongbang@huawei.com> Reviewed-by: Tao Tian <tiantao6@hisilicon.com> Link: https://patch.msgid.link/20251210023759.3944834-2-shiyongbang@huawei.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-01-20drm/i915/display: Remove .clock member from eDP/DP/HDMI pll tablesMika Kahola
PLL state structure has a member .clock. This is not needed as the port clock is possible to calculate from the pll dividers. Remove the encoder from being passed to the port clock calculation function. v2: Keep the pll_state->clock assignment in intel_snps_hdmi_pll_compute_mpllb(). Signed-off-by: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260119093757.2850233-16-mika.kahola@intel.com
2026-01-20drm/i915/lt_phy: Drop 27.2 MHz rateMika Kahola
Drop 27.2 MHz PLL table as with these PLL dividers the port clock will be incorrectly calculated to 27.0 MHz. For 27.2 MHz rate the PLl dividers are calculated algorithmically making PLL table for this rate redundant. Signed-off-by: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260119093757.2850233-15-mika.kahola@intel.com
2026-01-20drm/i915/cx0: Drop C20 25.175 MHz rateMika Kahola
Drop C20 25.175 MHz PLL table as with these PLL dividers the port clock will be incorrectly calculated to 25.2 MHz. For 25.175 MHz rate the PLl dividers are calculated algorithmically making PLL table for this rate redundant. Signed-off-by: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260119093757.2850233-14-mika.kahola@intel.com
2026-01-20drm/i915/lt_phy: Add verification for lt phy pll dividersMika Kahola
Add verification for lt phy pll dividers during boot. The port clock is calculated from pll dividers and compared against the requested port clock value. If there are a difference exceeding +-1 kHz an drm_warn() is thrown out to indicate possible pll divider mismatch. v2: - Move the LT_PHY_PLL_PARAMS -> LT_PHY_PLL_DP/HDMI_PARAMS change earlier. - Use tables[i].name != NULL as a terminating condition. - Use state vs. params term consistently in intel_c10pll_verify_clock() and intel_c20pll_verify_clock(). Signed-off-by: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260119093757.2850233-13-mika.kahola@intel.com
2026-01-20drm/i915/cx0: Verify C10/C20 pll dividersMika Kahola
Add verification for pll table dividers. The port clock is computed based on pll tables and, for hdmi case, the algorithmic model is applied to calculate pll dividers. If port clock differs more than +-1 kHz from expected value an drm_warn() is thrown and pll divider differences are printed out for debugging purposes. v2: - Move clock derivation from dividers in intel_cx0pll_enable() earlier in the patchset. - Keep intel_cx0_pll_power_save_wa() in intel_dpll_sanitize_state() - Use tables[i].name != NULL as a terminating condition. - Drop duplicate intel_cx0pll_clock_matches() declaration in header. - Use state vs. params term consistently in intel_c10pll_verify_clock() and intel_c20pll_verify_clock(). Signed-off-by: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260119093757.2850233-12-mika.kahola@intel.com
2026-01-20drm/i915/cx0: Add a fuzzy check for DP/HDMI clock rates during programmingMika Kahola
Since the clock rate is derived from the PLL divider values it can have a +-1kHz difference wrt. the reference rates in the comparison Signed-off-by: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260119093757.2850233-11-mika.kahola@intel.com
2026-01-20drm/i915/cx0: Fix HDMI FRL clock ratesMika Kahola
HDMI FRL clock rates are incorrectly defined. Fix these rates. Signed-off-by: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260119093757.2850233-10-mika.kahola@intel.com
2026-01-20drm/i915/display: Add helper function for fuzzy clock checkMika Kahola
The hard coded clock rate stored in the PLL state will be removed by a follow-up change. The clock is calculated instead of using clock from the PLL divider values. Since this calculated clock may vary due to fixed point rounding issues, a +-1 kHz variation is allowed with the request clock rate against the calculated clock rate. v2: - Use the stricter +-1 kHz allowed difference. - Derive the clock from PLL dividers in intel_cx0pll_enable(). - Move corresponding fuzzy check for LT PHY PLLs to this patch. v3: Reword commit message (Suraj) Move clock check to intel_dpll and rename it (Suraj) Signed-off-by: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260119093757.2850233-9-mika.kahola@intel.com
2026-01-20drm/i915/lt_phy: Create macro for LT PHY PLL stateMika Kahola
Create a macro for PLL state for LT PHY similar as for cx0 case. v2: - Move addition of LT_PHY_PLL_DP/HDMI_PARAMS() to this patch. - Fix end of table checking while looking up a table. Signed-off-by: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260119093757.2850233-8-mika.kahola@intel.com
2026-01-20drm/i915/cx0: Create macro around PLL tablesMika Kahola
Create macro for storing PLL dividers with table name and clock rate. v2: Preserve the terminating {} in each PLL table. Signed-off-by: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260119093757.2850233-7-mika.kahola@intel.com
2026-01-20drm/i915/cx0: Drop encoder from port clock calculationMika Kahola
For C10 and C20 we have unused encoder parameter passed to port clock calculation function. Remove the encoder from being passed to the port clock calculation function. Signed-off-by: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260119093757.2850233-6-mika.kahola@intel.com
2026-01-20drm/i915/lt_phy: Drop LT PHY crtc_state for port calculationMika Kahola
Drop crtc_state from intel_lt_phy_calc_port_clock() function call and replace it with pll state instead. Follow-up changes will call these functions without a crtc_state available. Signed-off-by: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260119093757.2850233-5-mika.kahola@intel.com
2026-01-20drm/i915/cx0: Drop Cx0 crtc_state from HDMI TMDS pll divider calculationMika Kahola
Drop crtc_state from HDMI TMDS calculation and replace with the parameters that are only required. Follow-up changes will call these functions without a crtc_state available. v2: Keep required crtc_state param for intel_c20_pll_tables_get() and other functions calling this one. Signed-off-by: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260119093757.2850233-4-mika.kahola@intel.com
2026-01-20drm/i915/cx0: Move C20 port clock calculationMika Kahola
Prepare removal of .clock member from the pll state structure by moving intel_c20pll_calc_port_clock() function. No functional change. Signed-off-by: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260119093757.2850233-3-mika.kahola@intel.com
2026-01-20drm/i915/cx0: Move C10 port clock calculationMika Kahola
Prepare removal of .clock member from pll state structures by moving intel_c10pll_calc_port_clock() function. No functional changes. Signed-off-by: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260119093757.2850233-2-mika.kahola@intel.com
2026-01-20drm/tyr: use read_poll_timeoutDeborah Brouwer
The L2 power-on sequence and soft reset in Tyr previously relied on fixed sleeps followed by a single register check, since polling helpers were not available in Rust at the time. Now that read_poll_timeout() is available, poll the relevant registers until the hardware reports readiness or a timeout is reached. This avoids unnecessary delays on start-up. Signed-off-by: Deborah Brouwer <deborah.brouwer@collabora.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://patch.msgid.link/20260119202645.362457-1-deborah.brouwer@collabora.com Signed-off-by: Alice Ryhl <aliceryhl@google.com>
2026-01-20drm/tyr: fix register name in error printDirk Behme
The `..IRQ..` register is printed here. Not the `..INT..` one. Correct this. Cc: stable@vger.kernel.org Fixes: cf4fd52e3236 ("rust: drm: Introduce the Tyr driver for Arm Mali GPUs") Link: https://lore.kernel.org/rust-for-linux/A04F0357-896E-4ACC-BC0E-DEE8608CE518@collabora.com/ Signed-off-by: Dirk Behme <dirk.behme@de.bosch.com> Link: https://patch.msgid.link/20260119070838.3219739-1-dirk.behme@de.bosch.com [aliceryhl: update commit message prefix] [aliceryhl: add cc stable as per Miguel's suggestion] Signed-off-by: Alice Ryhl <aliceryhl@google.com>
2026-01-20drm/buddy: release free_trees array on buddy mm teardownMichał Grzelak
During initialization of DRM buddy memory manager at drm_buddy_init, mm->free_trees array is allocated for both clear and dirty RB trees. During cleanup happening at drm_buddy_fini it is never freed, leading to following memory leaks observed on xe module load & unload cycles: kmemleak_alloc+0x4a/0x90 __kmalloc_cache_noprof+0x488/0x800 drm_buddy_init+0xc2/0x330 [drm_buddy] __xe_ttm_vram_mgr_init+0xc3/0x190 [xe] xe_ttm_stolen_mgr_init+0xf5/0x9d0 [xe] xe_device_probe+0x326/0x9e0 [xe] xe_pci_probe+0x39a/0x610 [xe] local_pci_probe+0x47/0xb0 pci_device_probe+0xf3/0x260 really_probe+0xf1/0x3c0 __driver_probe_device+0x8c/0x180 driver_probe_device+0x24/0xd0 __driver_attach+0x10f/0x220 bus_for_each_dev+0x7f/0xe0 driver_attach+0x1e/0x30 bus_add_driver+0x151/0x290 Deallocate array for free trees when cleaning up buddy memory manager in the same way as if going through out_free_tree label. Fixes: d4cd665c98c1 ("drm/buddy: Separate clear and dirty free block trees") Signed-off-by: Michał Grzelak <michal.grzelak@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Link: https://patch.msgid.link/20251208102714.4008260-2-michal.grzelak@intel.com
2026-01-20drm/i915/casf: Disable CASF with joinerNemesa Garg
Disable CASF with joiner as it is not supported in hardware. v2: Replace dmesg_WARN with drm_dbg_kms. [Jani] v3: Modify commit message. [Suraj] Signed-off-by: Nemesa Garg <nemesa.garg@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260115113948.641822-1-nemesa.garg@intel.com
2026-01-19Merge remote-tracking branch 'drm/drm-fixes' into drm-misc-fixesMaarten Lankhorst
Upstream is on rc5, we're still on rc1. No luck in hoping for a fast-forward, time to backmerge! Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2026-01-19drm/imagination: Warn or error on unsupported hardwareMatt Coster
Gate the use of unsupported hardware behind a new module parameter (exp_hw_support). Reviewed-by: Alessio Belle <alessio.belle@imgtec.com> Link: https://patch.msgid.link/20260113-device-support-info-v1-6-91e5db7f7294@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2026-01-19drm/imagination: KUnit test for pvr_gpuid_decode_string()Matt Coster
This is a nice self-contained function to serve as the basis of our first KUnit tests. Reviewed-by: Alessio Belle <alessio.belle@imgtec.com> Link: https://patch.msgid.link/20260113-device-support-info-v1-5-91e5db7f7294@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2026-01-19drm/imagination: Add gpuid module parameterAlexandru Dadu
The "gpuid" module parameter is used to override the gpuid read from a hardware register and is useful for testing the loading of different firmware (including processing of the firmware header) without having the hardware to hand. Signed-off-by: Alexandru Dadu <alexandru.dadu@imgtec.com> Reviewed-by: Alessio Belle <alessio.belle@imgtec.com> Link: https://patch.msgid.link/20260113-device-support-info-v1-4-91e5db7f7294@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2026-01-19drm/imagination: Load FW trace config at initMatt Coster
We have a module parameter to set the initial group mask before debugfs is available for any specific device, but don't currently use that value when initialising devices. Use the module parameter value as the initial value for group_mask. Reviewed-by: Alessio Belle <alessio.belle@imgtec.com> Link: https://patch.msgid.link/20260113-device-support-info-v1-3-91e5db7f7294@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2026-01-19drm/imagination: Validate fw trace group_maskMatt Coster
This value can come from two places: a module parameter or a debugfs file. In both cases, validate it early to provide feedback to userspace at the time the value is set instead of deferring until the value is used. Reviewed-by: Alessio Belle <alessio.belle@imgtec.com> Link: https://patch.msgid.link/20260113-device-support-info-v1-2-91e5db7f7294@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2026-01-19drm/imagination: Simplify module parametersMatt Coster
We had a whole load of bloaty infrastructure to deal with module parameters in a way that's wholly unnecessary. Strip it all back to basics to make adding new parameters less of a headache. Reviewed-by: Alessio Belle <alessio.belle@imgtec.com> Link: https://patch.msgid.link/20260113-device-support-info-v1-1-91e5db7f7294@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2026-01-19drm/imagination: Wait for FW trace update command completionBrajesh Gupta
Possibility of no FW trace available after update in the fw_trace_mask due to asynchronous mode of command consumption in the FW. To ensure FW trace is available after update, wait for FW trace log update command completion from the FW. Fixes: cc1aeedb98ad ("drm/imagination: Implement firmware infrastructure and META FW support") Signed-off-by: Brajesh Gupta <brajesh.gupta@imgtec.com> Reviewed-by: Matt Coster <matt.coster@imgtec.com> Link: https://patch.msgid.link/20260108040936.129769-1-brajesh.gupta@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2026-01-19drm/debug: don't register files for unsupported HDMI InfoFramesDmitry Baryshkov
Having debugfs files for the InfoFrames that are not supported by the driver is confusing, stop registering those in the debugfs. Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://patch.msgid.link/20260107-limit-infoframes-2-v4-10-213d0d3bd490@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-01-19drm/display: bridge_connector: dynamically generate HDMI callbacksDmitry Baryshkov
The rest of the DRM framework uses presence of the callbacks to check if the particular infoframe is supported. Register HDMI callbacks dynamically, basing on the corresponding drm_bridge ops. Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://patch.msgid.link/20260107-limit-infoframes-2-v4-9-213d0d3bd490@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-01-19drm/display: hdmi_state_helper: don't generate unsupported InfoFramesDmitry Baryshkov
There is little point in generating InfoFrames which are not supported by the driver. Skip generating the unsupported InfoFrames, making sure that the kernel never tries to write the unsupported frame. As there are no remaining usecases, change write_infoframe / clear_infoframe helpers return an error if the corresponding callback is NULL. Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://patch.msgid.link/20260107-limit-infoframes-2-v4-8-213d0d3bd490@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-01-19drm/display: hdmi_state_helper: reject Audio IF updates if it's not supportedDmitry Baryshkov
Updating the InfoFrame if it can not be sent over the wire makes no sense. Change drm_atomic_helper_connector_hdmi_update_audio_infoframe() and drm_atomic_helper_connector_hdmi_clear_audio_infoframe() to return an error if Audio InfoFrame callbacks are not implemented. Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://patch.msgid.link/20260107-limit-infoframes-2-v4-7-213d0d3bd490@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-01-19drm/display: hdmi_state_helper: split InfoFrame functions per typeDmitry Baryshkov
Havign a single set of InfoFrame callbacks doesn't provide enough information to the DRM framework about the InfoFrame types that are actually supported. Also it's not really future-proof: it provides a way to program only a single Vendor-Specific frame, however we might need to support multiple VSIs at the same time (e.g. HDMI vs HDMI Forum VSIs). Provide separate sets of callbacks, one per the InfoFrame type. Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://patch.msgid.link/20260107-limit-infoframes-2-v4-6-213d0d3bd490@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-01-19drm/bridge: refactor HDMI InfoFrame callbacksDmitry Baryshkov
Having only a single set of callbacks, hdmi_clear_infoframe and hdmi_write_infoframe, bridge drivers don't have an easy way to signal to the DRM framework, which InfoFrames are actually supported by the hardware and by the driver and which are not. Also, it makes it extremely easy for HDMI bridge drivers to skip implementing the seemingly required InfoFrames (e.g. HDMI VSI). Last, but not least, those callbacks take a single 'type' parameter, which makes it impossible to implement support for multiple VSIs (which will be required once we start working on HDMI Forum VSI). Split the callbacks into a per-InfoFrame-kind pairs, letting the bridge drivers actually signal supported features. The implementation follows the overall drm_bridge design, where the bridge has a single drm_bridge_funcs implementation and signals, which functions are to be called using the drm_bridge->ops flags. The AVI and HDMI VSI are assumed to be required for a normal HDMI operation (with the drivers getting a drm_warn_once() stub implementation if one is missing). The Audio InfoFrame is handled by the existing DRM_BRIDGE_OP_HDMI_AUDIO, while the SPD and HDR DRM InfoFrames got new drm_bridge_ops values. Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://patch.msgid.link/20260107-limit-infoframes-2-v4-5-213d0d3bd490@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-01-19drm/connector: make clear_infoframe callback mandatory for HDMI connectorsDmitry Baryshkov
We already require both hdmi_write_infoframe and hdmi_clear_infoframe for bridges implementing DRM_BRIDGE_OP_HDMI. It makes sense to require the clear_infoframes callback for HDMI connectors utilizing drmm_connector_hdmi_init(). Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://patch.msgid.link/20260107-limit-infoframes-2-v4-4-213d0d3bd490@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-01-19drm/sun4i: hdmi_enc: implement clear_infoframe stubDmitry Baryshkov
In preparation to making clear_infoframes callbacks required, add a stub to the sun4i driver. Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://patch.msgid.link/20260107-limit-infoframes-2-v4-3-213d0d3bd490@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-01-19drm/vc4: hdmi: implement clear_infoframeDmitry Baryshkov
Implement the clear_infoframe callback, disabling corresponding InfoFrame type. Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://patch.msgid.link/20260107-limit-infoframes-2-v4-2-213d0d3bd490@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-01-19drm/tests: hdmi: check the infoframes behaviourDmitry Baryshkov
Verify the InfoFrames behaviour. Check that reporting InfoFrame as unsupported doesn't result in a commit error. Also check that HDR and Audio InfoFrames are not triggered if corresponding features are not enabled. Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://patch.msgid.link/20260107-limit-infoframes-2-v4-1-213d0d3bd490@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-01-19drm/v3d: Convert v3d logging to device-based DRM helpersMaíra Canal
Replace legacy DRM_DEBUG/INFO/WARN/ERROR logging with the corresponding device-based drm_dbg(), drm_info(), drm_warn() and drm_err() helpers. For some messages, adjust the log level to better reflect their severity. This allows filtering via drm.debug, reduces log spam, and helps differentiate v3d logs from vc4 logs. Reviewed-by: Iago Toral Quiroga <itoral@igalia.com> Link: https://patch.msgid.link/20260112-v3d-drm-debug-v2-2-8ef6244c97bb@igalia.com Signed-off-by: Maíra Canal <mcanal@igalia.com>
2026-01-19drm/v3d: Consolidate CPU job validation in a functionMaíra Canal
All CPU job extension parsers duplicate the same validation procedure: ensure the extension is attached to a CPU job (not a GPU job) and that only a single CPU job extension is associated with a given job. Create a function to consolidate these checks and reduce the boilerplate across the various CPU job extension handlers. While here, convert the legacy DRM_DEBUG with a more appropriate drm_dbg(). Reviewed-by: Iago Toral Quiroga <itoral@igalia.com> Link: https://patch.msgid.link/20260112-v3d-drm-debug-v2-1-8ef6244c97bb@igalia.com Signed-off-by: Maíra Canal <mcanal@igalia.com>
2026-01-19drm/i915/psr: Don't enable Panel Replay on sink if globally disabledJouni Högander
With some panels informing support for Panel Replay we are observing problems if having Panel Replay enable bit set on sink when forced to use PSR instead of Panel Replay. Avoid these problems by not setting Panel Replay enable bit in sink when Panel Replay is globally disabled during link training. I.e. disabled by module parameter. The enable bit is still set when disabling Panel Replay via debugfs interface. Added note comment about this. Fixes: 68f3a505b367 ("drm/i915/psr: Enable Panel Replay on sink always when it's supported") Cc: Mika Kahola <mika.kahola@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: <stable@vger.kernel.org> # v6.15+ Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Link: https://patch.msgid.link/20260115070039.368965-1-jouni.hogander@intel.com (cherry picked from commit c5a52cd04e24f0ae53fda26f74ab027b8c548e0e) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2026-01-19Merge tag 'mediatek-drm-next-20260117' of ↵Dave Airlie
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux into drm-next Mediatek DRM Next - 20260117 1. mtk_hdmi_v2: Remove unneeded semicolon 2. Move DP training to hotplug thread 3. Convert legacy DRM logging to drm_* helpers in mtk_crtc.c 4. mtk_dsi: Add support for High Speed (HS) mode 5. Add HDMI support for Mediatek Genio 510/700/1200-EVK and Radxa NIO-12L boards Signed-off-by: Dave Airlie <airlied@redhat.com> From: Chun-Kuang Hu <chunkuang.hu@kernel.org> Link: https://patch.msgid.link/20260117005152.3770-1-chunkuang.hu@kernel.org
2026-01-19drm/i915/dp: Avoid joiner for eDP if not enabled in VBTAnkit Nautiyal
For eDP, enable the Pipe Joiner feature only if VBT explicitly allows it. If VBT disables the feature, skip joiner for eDP, even if the hardware supports it. Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14616 Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260108124141.1407760-3-ankit.k.nautiyal@intel.com
2026-01-19drm/i915/vbt: Add edp pipe joiner enable/disable bitsAnkit Nautiyal
Add VBT support to enable/disable eDP Pipe Joiner feature. The OEMs can choose to enable/disable the feature from VBT. ARL - VBTs default this field to disabled. PTL+ - VBTs default this field to enabled. Bspec:20142 Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260108124141.1407760-2-ankit.k.nautiyal@intel.com
generated by cgit v1.2.3 (git 2.39.1) at 2026-08-13 10:17:43 +0000