summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
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
2026-01-19Merge tag 'drm-intel-gt-next-2026-01-16' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/i915/kernel into drm-next Driver Changes: - Bump recommended GuC version for DG2 and MTL - Fix for syzkaller found NULL deref in execbuf (Krzyssztof, Gangmin) - Use designated initializers in debugfs code (Sebastian) - Selftest and static checker fixes (Ard, Sk) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patch.msgid.link/aWnzOx78S4Vh38QE@jlahtine-mobl
2026-01-18drm/mediatek: mtk_gem: Partial refactor and use drm_gem_dma_objectAngeloGioacchino Del Regno
Partially refactor mtk_gem to stop using (and remove) the unneeded custom mtk_gem_obj structure and migrate drivers to use the API defined drm_gem_dma_object structure instead, and to align all of the functions to be similar to the logic from drm_gem_dma_helper. Unfortunately, for this driver it wasn't possible to directly use the drm_gem_dma_helper callbacks (apart from .print_info), as the DMA mapping here is done on specific dma devices instead of the main DRM device. Also, since the mtk_gem_obj structure is no more, also migrate the mtk_plane.c code to grab the DMA address from a drm_gem_dma_object and replace the inclusion of the custom mtk_gem.h header (as it is now unneeded) with the DRM API provided drm_gem_dma_helper. While at it, also set DRM_GEM_DMA_HELPER as an unconditional dependency (remove the `if DRM_FBDEV_EMULATION` from the select DRM_GEM_DMA_HELPER statement in Kconfig). This resolves an issue pointed by UBSAN, as when using drm_fbdev_dma the drm_gem_object is supposed to be child of a drm_gem_dma_object instead of a custom mtk_gem_obj (or the mtk_gem_obj should have been reordered to have the same fields as drm_gem_dma_object, but that would have been too fragile and generally a bad idea anyway). Fixes: 0992284b4fe4 ("drm/mediatek: Use fbdev-dma") Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://patchwork.kernel.org/project/dri-devel/patch/20251111085114.9752-1-angelogioacchino.delregno@collabora.com/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2026-01-18drm/mediatek: dpi: Find next bridge during probeChen-Yu Tsai
Trying to find the next bridge and deferring probe in the bridge attach callback is much too late. At this point the driver has already finished probing and is now running the component bind code path. What's even worse is that in the specific case of the DSI host being the last component to be added as part of the dsi_host_attach callback, the code path that this is in: -> devm_drm_of_get_bridge() mtk_dpi_bridge_attach() drm_bridge_attach() mtk_dpi_bind() ... component_add() mtk_dsi_host_attach() anx7625_attach_dsi() anx7625_link_bridge() - done_probing callback for of_dp_aux_populate_bus() of_dp_aux_populate_bus() anx7625_i2c_probe() _cannot_ return probe defer: anx7625 4-0058: [drm:anx7625_bridge_attach] drm attach mediatek-drm mediatek-drm.15.auto: bound 14014000.dsi (ops mtk_dsi_component_ops) mediatek-drm mediatek-drm.15.auto: error -EPROBE_DEFER: failed to attach bridge /soc/dpi@14015000 to encoder TMDS-37 [drm:mtk_dsi_host_attach] *ERROR* failed to add dsi_host component: -517 anx7625 4-0058: [drm:anx7625_link_bridge] *ERROR* fail to attach dsi to host. panel-simple-dp-aux aux-4-0058: DP AUX done_probing() can't defer panel-simple-dp-aux aux-4-0058: probe with driver panel-simple-dp-aux failed with error -22 anx7625 4-0058: [drm:anx7625_i2c_probe] probe done This results in the whole display driver failing to probe. Perhaps this was an attempt to mirror the structure in the DSI driver; but in the DSI driver the next bridge is retrieved in the DSI attach callback, not the bridge attach callback. Move the code finding the next bridge back to the probe function so that deferred probing works correctly. Also rework the fallback to the old OF graph endpoint numbering scheme so that deferred probing logs in both cases. This issue was found on an MT8183 Jacuzzi device with an extra patch enabling the DPI-based external display pipeline. Also tested on an MT8192 Hayato device with both DSI and DPI display pipelines enabled. Fixes: 4c932840db1d ("drm/mediatek: Implement OF graphs support for display paths") Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Reviewed-by: CK Hu <ck.hu@mediatek.com> Link: https://patchwork.kernel.org/project/dri-devel/patch/20260114092243.3914836-1-wenst@chromium.org/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2026-01-19Merge tag 'amd-drm-next-6.20-2026-01-16' of ↵Dave Airlie
https://gitlab.freedesktop.org/agd5f/linux into drm-next amd-drm-next-6.20-2026-01-16: amdgpu: - SR-IOV fixes - Rework SMU mailbox handling - Drop MMIO_REMAP domain - UserQ fixes - MES cleanups - Panel Replay updates - HDMI fixes - Backlight fixes - SMU 14.x fixes - SMU 15 updates amdkfd: - Fix a memory leak - Fixes for systems with non-4K pages - LDS/Scratch cleanup - MES process eviction fix Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patch.msgid.link/20260116202609.23107-1-alexander.deucher@amd.com
2026-01-18drm/xe: Disable timestamp WA on VFsMatthew Brost
The timestamp WA does not work on a VF because it requires reading MMIO registers, which are inaccessible on a VF. This timestamp WA confuses LRC sampling on a VF during TDR, as the LRC timestamp would always read as 1 for any active context. Disable the timestamp WA on VFs to avoid this confusion. Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Fixes: 617d824c5323 ("drm/xe: Add WA BB to capture active context utilization") Link: https://patch.msgid.link/20260110012739.2888434-7-matthew.brost@intel.com (cherry picked from commit efffd56e4bd894e0935eea00e437f233b6cebc0d) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2026-01-18drm/xe/vm: fix xe_vm_validation_exec() kernel-docJani Nikula
Fix kernel-doc warnings on xe_vm_validation_exec(): Warning: ../drivers/gpu/drm/xe/xe_vm.h:392 expecting prototype for xe_vm_set_validation_exec(). Prototype was for xe_vm_validation_exec() instead Fixes: 0131514f9789 ("drm/xe: Pass down drm_exec context to validation") Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20260107155401.2379127-4-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit b3a7767989e6519127ac5e0cde682c50ad587f3b) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2026-01-18drm/xe/xe_late_bind_fw: fix enum xe_late_bind_fw_id kernel-docJani Nikula
Fix kernel-doc warnings on enum xe_late_bind_fw_id: Warning: ../drivers/gpu/drm/xe/xe_late_bind_fw_types.h:19 cannot understand function prototype: 'enum xe_late_bind_fw_id' Fixes: 45832bf9c10f ("drm/xe/xe_late_bind_fw: Initialize late binding firmware") Cc: Badal Nilawar <badal.nilawar@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Badal Nilawar <badal.nilawar@intel.com> Link: https://patch.msgid.link/20260107155401.2379127-3-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit a857e6102970c7bd8f2db967fe02d76741179d14) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2026-01-18drm/xe/vf: fix struct xe_gt_sriov_vf_migration kernel-docJani Nikula
Fix kernel-doc warnings on struct xe_gt_sriov_vf_migration: Warning: ../drivers/gpu/drm/xe/xe_gt_sriov_vf_types.h:47 cannot understand function prototype: 'struct xe_gt_sriov_vf_migration' Fixes: e1d2e2d878bf ("drm/xe/vf: Add xe_gt_recovery_pending helper") Cc: Matthew Brost <matthew.brost@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Tomasz Lis <tomasz.lis@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20260107155401.2379127-2-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit 44393331c79f5df14c1ff25f4a355f439a2dc8a2) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2026-01-18drm/xe: fix WQ_MEM_RECLAIM passed as max_active to alloc_workqueue()Marco Crivellari
Workqueue xe-ggtt-wq has been allocated using WQ_MEM_RECLAIM, but the flag has been passed as 3rd parameter (max_active) instead of 2nd (flags) creating the workqueue as per-cpu with max_active = 8 (the WQ_MEM_RECLAIM value). So change this by set WQ_MEM_RECLAIM as the 2nd parameter with a default max_active. Fixes: 60df57e496e4 ("drm/xe: Mark GGTT work queue with WQ_MEM_RECLAIM") Cc: stable@vger.kernel.org Signed-off-by: Marco Crivellari <marco.crivellari@suse.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260108180148.423062-1-marco.crivellari@suse.com (cherry picked from commit aa39abc08e77d66ebb0c8c9ec4cc8d38ded34dc9) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
generated by cgit v1.2.3 (git 2.39.1) at 2026-08-13 20:32:50 +0000