aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2026-07-27drm/panel: simple: Add Ampire AM-800480N3TZQW-00HPaul Louvel1-0/+33
Add support for the Ampire AM-800480N3TZQW-00H 5" WVGA TFT LCD panel. Signed-off-by: Paul Louvel <paul.louvel@bootlin.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260723-support-am-800480n3tzqw-00h-v1-2-6a4ae0575a19@bootlin.com
2026-07-27drm/panel: st7703: Add AYANEO Pocket DS Lower Panel SupportAlexandre Hamamdjian1-0/+96
Add support for the lower (secondary) panel of the AYANEO Pocket DS, a dual-screen QCS8550 (Snapdragon 8 Gen 2) handheld. It is a 5.0" 1024x768 4:3 IPS LCD driven by a Sitronix ST7703 DDIC: every command in the vendor init sequence maps to an ST7703 manufacturer command (SETEXTC, SETMIPI, SETRGBIF, SETSCR, SETPOWER, SETGAMMA, SETGIP1/2), and the SETMIPI and SETRGBIF payloads are near-identical to the already-supported Powkiddy RGB10MAX3. The panel is mounted in portrait (768x1024) and rotated 270 degrees in the device, expressed through the panel rotation property. The SETEXTC unlock password ends in 0x87 rather than the canonical 0x83; this is the value shipped by the vendor firmware and is kept verbatim. Init sequence extracted from the AYANEO Pocket DS BSP kernel, via the ROCKNIX SM8550 port. Signed-off-by: Alexandre Hamamdjian <azkali.limited@gmail.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260723-b4-st7703-pocketds-lower-v1-2-e3db246589f4@gmail.com
2026-07-27drm: panel: jd9365da: Add DCLTek 300250 9.35in displayMarc-Olivier Champagne1-0/+246
The DCLTek dt300250 is a LCD panel using the jd9365da controller. Add the panel to the driver. Suggested-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Marc-Olivier Champagne <marc-olivier.champagne@savoirfairelinux.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260722173840.3576444-5-marc-olivier.champagne@savoirfairelinux.com
2026-07-27drm: panel: jd9365da: Enable LPM modeMarc-Olivier Champagne1-1/+2
The JD9365DA-H3 uses DSI LPM for command transmissions, make sure this is configured correctly in the DSI mode flags. Suggested-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Marc-Olivier Champagne <marc-olivier.champagne@savoirfairelinux.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260722173840.3576444-2-marc-olivier.champagne@savoirfairelinux.com
2026-07-27drm/nouveau: allow allocating NVDEC channels via abi16Dave Airlie2-5/+13
Add NOUVEAU_FIFO_ENGINE_NVDEC to the abi16 uAPI and accept it in channel allocation, mapping it to the NVDEC engine runlist. Skip the Turing copy-engine workaround object for NVDEC channels: the copy engines are not part of the NVDEC runlist, so the workaround object cannot be instantiated on such channels (and is not needed there). This is required for NVK to implement Vulkan Video H.264 decode on top of the NVDEC engine: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31867 Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patch.msgid.link/20260725035912.1016464-1-daniel.almeida@collabora.com
2026-07-24drm/xe/eustall: Add WA 14027054324 support for graphics IP 35.11Harish Chegondi3-3/+37
WA 14027054324 is implemented in the firmware and is applied before EU stall sampling and reverted after EU stall sampling. The driver needs to notify the firmware whenever EU stall sampling is being enabled/disabled so that the firmware takes the necessary action. The driver uses a scratch pad register to communicate with the firmware. Before enabling EU stall sampling, write 0x20 to the SWF scratch pad register to request the firmware to apply the workaround. The firmware applies the workaround and sets the scratch pad register to 0x60 as an ACK. Before disabling EU stall sampling, write 0x40 to the SWF scratch pad register to request the firmware to revert the workaround. The firmware reverts the workaround and sets the scratch pad register to 0 as an ACK. The firmware is expected to take about 1 ms to apply/revert the workaround. 10 ms timeout is used in the driver while waiting for an ack from the firmware to have adequate grace period. Bspec update for the SWF scratch pad register is still pending, but has been confirmed offline with the firmware team. Bspec: 53188 Signed-off-by: Harish Chegondi <harish.chegondi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/16b6b972691943daddebad6e7b93b9d73add5249.1784745545.git.harish.chegondi@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2026-07-25Merge tag 'drm-misc-next-2026-07-24' of https://gitlab.freedesktop.org/drm/misc/kernel into drm-nextDave Airlie95-250/+2310
drm-misc-next for v7.3: UAPI Changes: cgroup: - dmem: accept one region per limit drm: - send per-connector hotplug events Core Changes: buddy: - tests: test buffer clearence on resume panel: - implement ref counting for struct drm_panel throughout the DRM tree Driver Changes: etnaviv: - force flush on power register ops gma: - replace simple-kms helpers with regular atomic helpers - clean up host1x: - support Tegra264 plus DT bindings - fix minor issues throughout driver hypervdrm: - clean up PCI-device binding imagination: - mark BXM-4-64 MC1 (36.52.104.182) as supported - clean up ivpu: - clean up nouveau: - remove redundant call to pm_runtime_mark_last_busy() panel: - support Novatek NT36536 plus DT bindings - sofef00: fix backlight updates - osd101t2587: use mipi_dsi_*_multi interface - panel-edp: adjust timing for AUO displays - panel-lvds: support Opto Logic SCX1001511GGC49 - panel-simple: support Kyocera tcg070wvlq panfrost: - clean up solomon: - clean up variables tve200: - add OF module alias for autoloading v3d: - fix job BO handling vc4: - ref i2c-adapter module Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260724082204.GA18774@linux.fritz.box
2026-07-24drm/panthor: reject firmware sections with oversized dataOsama Abdelkader1-2/+9
In panthor_fw_load_section_entry(), the data size to copy is calculated without validating it against the allocated section_size: section->data.size = hdr.data.end - hdr.data.start; If a crafted firmware sets data.size larger than the allocated memory, this could cause a heap buffer overflow in panthor_fw_init_section_mem() memcpy(section->mem->kmap, section->data.buf, section->data.size); Additionally, if the section->data.size exceeds the BO size, could this memset underflow the size calculation, leading to a massive out-of-bounds zeroing of kernel memory? memset(section->mem->kmap + section->data.size, 0, panthor_kernel_bo_size(section->mem) - section->data.size); Reject section entries whose initial data is larger than the section size. Fixes: 2718d91816ee ("drm/panthor: Add the FW logical block") Cc: stable@vger.kernel.org Signed-off-by: Osama Abdelkader <osama.abdelkader@gmail.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://patch.msgid.link/20260716143939.21903-1-osama.abdelkader@gmail.com Signed-off-by: Steven Price <steven.price@arm.com>
2026-07-24drm/panthor: return PTR_ERR() from devm_drm_dev_alloc()Osama Abdelkader1-1/+1
devm_drm_dev_alloc() returns an ERR_PTR() on failure, but panthor_probe() always converts that failure to -ENOMEM. Preserve the actual error code returned by the DRM core instead. Fixes: 4bdca1150792 ("drm/panthor: Add the driver frontend block") Signed-off-by: Osama Abdelkader <osama.abdelkader@gmail.com> Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://patch.msgid.link/20260716140337.10679-1-osama.abdelkader@gmail.com
2026-07-24drm/panel-edp: take i2c adapter module referenceJohan Hovold1-2/+2
The i2c subsystem currently blocks during adapter deregistration whenever there are consumers holding a reference. Switch to using of_get_i2c_adapter_by_node() which also takes a reference to the adapter module so that an attempt to unload the module while in use fails gracefully instead of blocking uninterruptibly. Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patch.msgid.link/20260717143119.1815106-3-johan@kernel.org
2026-07-24drm/panel-edp: fix i2c adapter leak on probe failureJohan Hovold1-6/+13
Make sure to drop the i2c adapter reference on probe failure (e.g. probe deferral) and on driver unbind also if a devicetree redundantly uses the 'ddc-i2c-bus' property to point to the aux ddc bus. Fixes: cc5a3fc041f0 ("drm/panel: panel-simple: Stash DP AUX bus; allow using it for DDC") Cc: stable@vger.kernel.org # 5.15 Reported-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/CAD=FV=VZPhzHU+Pet2m3L+Pqc7mOPfZC-f5p0OuNL79wNZPxRg@mail.gmail.com Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patch.msgid.link/20260717143119.1815106-2-johan@kernel.org
2026-07-24drm/amd/display: Fix missing DCE check in dm_gpureset_toggle_interrupts()Leo Li1-1/+2
This line was lost when cping from amd-staging-drm-next to drm-fixes. So add it back. Cc: stable@vger.kernel.org Fixes: 8382cd234981 ("drm/amd/display: consolidate DCN vblank/flip handling onto vupdate_no_lock") Reported-by: Lu Yao <yaolu@kylinos.cn> Signed-off-by: Leo Li <sunpeng.li@amd.com> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Link: https://patch.msgid.link/20260723134450.13838-1-sunpeng.li@amd.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
2026-07-24drm/amd/display: Fix flip-done timeouts on mode1 resetLeo Li1-2/+11
The vblank on/off callbacks mixed use of amdgpu_irq_get/put() and amdgpu_dm_crtc_set_vupdate_irq() to enable and disable IRQs. With get/put, base driver will callback into DC to disable IRQs when refcount == 0. With set_vupdate_irq(), DC is called directly to disable IRQs, bypassing base driver's refcount tracking. During gpu reset, base driver can restore IRQs via amdgpu_irq_gpu_reset_resume_helper() > amdgpu_irq_update(). So if get/put() is not used (i.e. refcount == 0), then vupdate_irq will be disabled. This is problematic if DRM requests vblank on before amdgpu_irq_update() is called: drm_vblank_on() > set_vupdate_irq() enables vupdate_irq, but the refcount is still 0. gpu_reset_resume_helper() > irq_update() then immediately disables it, thus leading to flip done timeouts. This is made worse on DCN since VUPDATE_NO_LOCK is the only IRQ enabled. Prior to 8382cd234981, a combination of GRPH_FLIP and VSTARTUP IRQs were used, and they used get/put(). This explains why 8382cd234981 exposed this issue. Fix by using get/put() instead of set_vupdate_irq(). DCE is unchanged, since it relies on unbalanced enable/disable calls based on VRR status, and hence requires direct set_vupdate_irq(). Plus, it also uses GRPH_FLIP and VLINE IRQs, which are properly tracked by get/put(). Cc: stable@vger.kernel.org Fixes: 8382cd234981 ("drm/amd/display: consolidate DCN vblank/flip handling onto vupdate_no_lock") Signed-off-by: Leo Li <sunpeng.li@amd.com> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Link: https://patch.msgid.link/20260723180159.52121-1-sunpeng.li@amd.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
2026-07-24drm/i915/fbc: No surface size restrictions from LNL onwardsVinod Govindapillai1-0/+3
From xe2_lpd+ platforms, enabling FBC do not depend on the surface size. So remove the check. v2: changes to patch description Bspec: 69560 Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patch.msgid.link/20260722132448.318112-3-vinod.govindapillai@intel.com
2026-07-24drm/i915/fbc: No need of any hardcoded plane width limit from LNL+Vinod Govindapillai1-4/+12
In xe2_lpd+ platforms, there are no restrictions to enable FBC on planes with respect to the plane width - width can be as per the platform's maximum supported resolution. v2: patches squashed and changes in patch descriptions Bspec: 69560 Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patch.msgid.link/20260722132448.318112-2-vinod.govindapillai@intel.com
2026-07-24drm/xe/display: Expose plane max width/height helpers to global scopeVinod Govindapillai2-8/+17
Enabling features like FBC on platforms may depend on a plane's maximum supported resolutions or some other arbitrary constant values because of hw restrictions. Currently the helpers that report a plane's max width and height are private to skl_plane / skl_universal_plane. Change the scope to golbal so that this can be queried from other areas as well. v2: function parameter alignment fixes Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patch.msgid.link/20260722132448.318112-1-vinod.govindapillai@intel.com
2026-07-24Merge tag 'drm-misc-fixes-2026-07-24' of https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixesDave Airlie18-110/+292
drm-misc-fixes for v7.2-rc5: - Improve damage handling in appletbdrm. - Fix harmful fragmenting of MM by backing up TTM pages at native page order. - Fix timeout handling in amdxdna. - Fix imagination locking for map/unmap operations. - Fix mm leak in gpusvm eviction. - Properly zero page array in gpusvm mm scanning. - Prevent trusted shader bo's from being mapped again in vc4. - Validate shader array size in vmwgfx. - Fix length calculation bugs in ethosu. - Better error handling during pagemap migration. - Improve v3d suspend. - Kconfig updates for some panels. - Handle missing iovcc in ili9881c panel. - Fix vc4 unbind. - Add i2c error handling in gma500. - Fix kunit tests on pp64le and s390x. - Prevent rearming vc4 timer on shutdown. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patch.msgid.link/07284633-6b9b-40f9-8949-b1516a42a34c@linux.intel.com
2026-07-24drm/imagination: Fix value of HWRT address in pvr_job_create tracepointAlessio Belle1-3/+13
The pvr_job_create tracepoint was using pvr_fw_object::fw_addr_offset to display the firmware address of the render target structure attached to a job, but that's an offset into the firmware heap, not the expected full address, which is more useful in general e.g. for cross referencing against firmware logs. Use pvr_fw_object_get_fw_addr() to get the full firmware address. Fixes: c1079aebb4de ("drm/imagination: Add support for trace points") Reviewed-by: Brajesh Gupta <brajesh.gupta@imgtec.com> Link: https://patch.msgid.link/20260720-fix-pvr-job-trace-hwrt-v1-1-b24551802efb@imgtec.com Signed-off-by: Alessio Belle <alessio.belle@imgtec.com>
2026-07-24drm/imagination: promote BXM-4-64 MC1 (36.52.104.182) to supported statusFrank Binns2-3/+2
Support for this GPU is now in a very good state, with only a handful of Vulkan CTS tests still failing when testing using CTS version 1.4.5.3 on the BeagleV-Ahead SBC. With the firmware having been upstreamed [1], now is the time to promote this GPU from experimental to supported. [1] https://gitlab.com/kernel-firmware/linux-firmware/-/merge_requests/1138 Signed-off-by: Frank Binns <frank.binns@imgtec.com> Reviewed-by: Alessio Belle <alessio.belle@imgtec.com> Link: https://patch.msgid.link/20260720-promote-bxm-4-64-v1-2-39abcd1cf263@imgtec.com Signed-off-by: Alessio Belle <alessio.belle@imgtec.com>
2026-07-24drm/imagination: update GPU support documentationFrank Binns1-2/+2
The list of supported GPUs contains the GPU model, along with the SoCs they're found in. The SoC information can easily get out of date, as typically GPU models will be integrated into many different SoCs and upstream support for these can potentially happen over a long stretch of time without necessarily requiring any GPU driver changes. Replace the SoC information with the BVNC instead. This uniquely identifies a GPU implementation and is useful in cases where a GPU model may have multiple implementations due to, e.g. hardware errata having been fixed, and the driver doesn't yet support all of them. Signed-off-by: Frank Binns <frank.binns@imgtec.com> Reviewed-by: Alessio Belle <alessio.belle@imgtec.com> Link: https://patch.msgid.link/20260720-promote-bxm-4-64-v1-1-39abcd1cf263@imgtec.com Signed-off-by: Alessio Belle <alessio.belle@imgtec.com>
2026-07-24drm/tve200: add OF module alias for autoloadingCan Peng1-0/+1
The TVE200 DRM driver can be built as a module and uses tve200_of_match as its OF match table, but the table is not exported for module alias generation. Add the MODULE_DEVICE_TABLE(of, ...) entry so modpost can generate OF module aliases for OF based module autoloading. Fixes: 179c02fe90a4 ("drm/tve200: Add new driver for TVE200") Signed-off-by: Can Peng <pengcan@kylinos.cn> Signed-off-by: Linus Walleij <linusw@kernel.org> Link: https://patch.msgid.link/20260715024130.186416-1-pengcan@kylinos.cn
2026-07-24Revert "drm/pagemap: Guard HPAGE_PMD_ORDER use with CONFIG_ARCH_ENABLE_THP_MIGRATION"Maarten Lankhorst1-10/+3
This reverts commit 04b177544a040cbafab760d6b766381c6b22e0a8. The original author requested it to be reverted, as it conflicts with changes in the -next branch for MM: "I'm not sure who is doing the drm-misc-fixes PR, but if you are can you omit this patch: https://patchwork.freedesktop.org/series/170865/ I guess this conflicts with MM changes in their next tree and it easy enough on our side to do this slightly differently to avoid a conflict so going to post revert + a different change. If this is already sent nbd." Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2026-07-24drm/i915/dp: Ignore the sink's DSC max FRL rate without a PCON DSC encoderAlexander Kaplan1-1/+8
intel_dp_hdmi_sink_max_frl() limits the sink's max FRL rate by its DSC max FRL rate whenever the sink supports DSC 1.2. However, the DSC max FRL rate (HF-VSDB DSC_Max_FRL_Rate) only applies to compressed video transport, which requires a DSC 1.2 encoder in the PCON (configured via intel_dp_pcon_dsc_configure()). Without such an encoder the HDMI link always carries uncompressed video, for which the regular Max_FRL_Rate is the correct limit. Applying the DSC limit unconditionally trains the FRL link at a lower rate than both the PCON and the sink support. E.g. an LG OLED G4 (Max_FRL_Rate 48 Gbps, DSC_Max_FRL_Rate 24 Gbps) behind a Synaptics VMM7100 PCON (PCON max FRL bw 48 Gbps, no DSC encoder): Sink max rate from EDID = 24 Gbps FRL trained with : 24 Gbps while Windows/macOS train the same hardware at 40/48 Gbps. The too low FRL rate needlessly constrains the formats available to the sink. Only apply the sink's DSC max FRL rate if the PCON has a DSC 1.2 encoder, matching the gate in intel_dp_pcon_dsc_configure(). PCONs with a DSC encoder keep the current conservative behavior, since the link is trained once and compressed transport may be used for any subsequent mode. With this the setup above trains at 48 Gbps. Tested on PTL (xe) with the above PCON/sink combo. Fixes: 10fec80b48c5 ("drm/i915/display: Configure PCON for DSC1.1 to DSC1.2 encoding") Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Alexander Kaplan <alexander.kaplan@sms-medipool.de> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patch.msgid.link/20260718105207.5565-3-alexander.kaplan@sms-medipool.de
2026-07-24drm/i915/dp: Prefer DSC over 6 bpc uncompressed output for HDMI sinksAlexander Kaplan1-0/+14
For modes which fit through the link uncompressed only with a 6 bpc pipe BPP, the link config currently selects 6 bpc with dithering even if the sink supports DSC. For HDMI sinks behind a DP to HDMI protocol converter this is the wrong preference: HDMI knows no 6 bpc transport format, so the converter has to expand the dithered 6 bpc stream back to 8 bpc for the HDMI link anyway, and DSC with an at least 8 bpc input provides a better output quality than that. Prefer DSC, following the pattern commit ba49a4643cf5 ("drm/i915/dp: Set min_bpp limit to 30 in HDR mode") uses for HDR: keep the uncompressed minimum pipe BPP at 8 bpc if the sink supports DSC, making the uncompressed link config fail for such modes and the mode fall back to DSC. As there, if the DSC computation fails, the mode falls back to YCbCr 4:2:0 where supported, or gets rejected. Besides the output quality, some converters can't even display a 6 bpc stream at high pixel clocks. Synaptics VMM PCON based DP to HDMI 2.1 adapters from two device families (branch device IDs SYNAq and SYNAa) output corrupted FRL timings for an uncompressed RGB 6 bpc 4k120 (1188 MHz) stream, resulting in a black screen, while the same mode works with DSC (12 bpc input) and 6 bpc works at lower pixel clocks. Windows and macOS drive 4k120 on these devices only via DSC. A lower bpc limit explicitly requested via the max bpc connector property is still honored. This keeps the current uAPI behavior (exercised by IGT kms_dither) and provides an escape hatch for sinks with a broken DSC implementation. DP and eDP sinks, and HDMI sinks without DSC support, are not affected and keep falling back to 6 bpc. Tested on PTL (xe) with the above PCONs and an LG OLED G4. Cc: Imre Deak <imre.deak@intel.com> Cc: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Alexander Kaplan <alexander.kaplan@sms-medipool.de> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patch.msgid.link/20260718105207.5565-2-alexander.kaplan@sms-medipool.de
2026-07-24gpu: nova-core: reserve vGPU WPR2 heapZhi Wang5-8/+32
GSP-RM needs a larger WPR2 heap when booting in vGPU mode. The heap size is firmware-dependent, so it should come from the generated firmware bindings instead of being open-coded in nova-core. Pass the detected vGPU state into the framebuffer layout calculation. Keep baremetal boots on the existing heap sizing path, and use the 570.144 vGPU default heap binding only when vGPU is enabled. The same state match also sets the VF partition count, so disabled and invalid 0/1-VF states do not enter the vGPU heap path. Cc: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Zhi Wang <zhiw@nvidia.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260722073913.1807677-7-zhiw@nvidia.com [ Use checked arithmetic to calculate wpr2_heap_addr. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-07-24gpu: nova-core: set RMSetSriovMode for vGPUZhi Wang4-4/+14
The GSP registry setup needs to advertise SR-IOV mode when nova-core boots GSP for an enabled vGPU configuration. Without the registry entry, GSP-RM is not told to initialize in the mode required by NVIDIA vGPU. Append RMSetSriovMode to the SetRegistry command when the vGPU state detected before GSP boot is enabled. Keep the existing registry entries unchanged for non-vGPU boots. Cc: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Zhi Wang <zhiw@nvidia.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260722073913.1807677-6-zhiw@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-07-24gpu: nova-core: detect and store vGPU stateZhi Wang8-1/+159
GSP boot needs a stable view of vGPU state before it starts building the boot-time data structures that depend on SR-IOV and firmware policy. That state must be derived once from the PCI VF count and the FSP PRC vGPU mode knob before booting GSP. Add VgpuManager to detect and retain the vGPU state during GPU construction. Keep the manager separate from the detected state because later vGPU milestones will add vGPU resources and lifecycle state to it. Keep the vGPU capability gate local to the vGPU module with per-chip HAL modules. Treat failures to detect the optional vGPU state as disabled so they do not prevent a bare-metal probe, and log both the failure and the detected state where the manager is constructed. Cc: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Zhi Wang <zhiw@nvidia.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260722073913.1807677-5-zhiw@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-07-24gpu: nova-core: read vGPU mode from FSP via PRC protocolZhi Wang2-0/+172
vGPU boot needs to know whether firmware reports vGPU mode as active. FSP's Management Partition exposes PRC (Product Reconfiguration Control) as an API for reading device configuration knobs without firmware updates. The vGPU mode knob is one such configuration value. Add typed PRC request and response payloads for the vGPU mode object, add the PRC NVDM type, and parse the returned knob value into VgpuMode. Signed-off-by: Zhi Wang <zhiw@nvidia.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260722073913.1807677-4-zhiw@nvidia.com [ FspPrcMessage is small and short-lived; stack-allocate it instead of using KBox. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-07-23drm/vc4: Shut down BO cache timer before teardownLinmao Li1-1/+1
The BO cache timer callback schedules time_work, and time_work can rearm the timer through vc4_bo_cache_free_old(). vc4_bo_cache_destroy() deletes the timer and then cancels the work, which does not break that cycle: the work being cancelled can rearm the timer, and the timer then queues work again after teardown. Use timer_shutdown_sync() instead, so the timer cannot be rearmed and the cycle ends with cancel_work_sync(). Fixes: c826a6e10644 ("drm/vc4: Add a BO cache.") Cc: stable@vger.kernel.org Signed-off-by: Linmao Li <lilinmao@kylinos.cn> Link: https://patch.msgid.link/20260720084426.1632508-1-lilinmao@kylinos.cn Reviewed-by: Maíra Canal <mcanal@igalia.com> Signed-off-by: Maíra Canal <mcanal@igalia.com>
2026-07-23drm/mediatek: mtk_hdmi_common: take i2c adapter module referenceJohan Hovold1-2/+9
The i2c subsystem currently blocks during adapter deregistration whenever there are consumers holding a reference. Switch to using of_get_i2c_adapter_by_node() which also takes a reference to the adapter module so that an attempt to unload the module while in use fails gracefully instead of blocking uninterruptibly. Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: CK Hu <ck.hu@mediatek.com> Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20260716132103.1564995-1-johan@kernel.org/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2026-07-24Merge tag 'drm-xe-fixes-2026-07-23' of https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixesDave Airlie6-16/+49
Driver Changes: - Skip invalidation for purgeable state updates (Arvind) - Add drm_dev guards when detaching CCS read / write buffers (Satyanarayana) - Alloc per domain unique i2c id (Raag) - Fix SVM leak on resv obj alloc failure in xe_vm_create (Shuicheng) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Hellstrom <thomas.hellstrom@linux.intel.com> Link: https://patch.msgid.link/amJ5-WUA_OS_RBAp@fedora
2026-07-23drm/tests: shmem: Set DMA mask to 64-bit in drm_gem_shmemJosé Expósito1-6/+10
drm_gem_shmem_test_purge [1] and drm_gem_shmem_test_get_pages_sgt [2] intermittently fail on ppc64le and s390x CI systems with a DMA address overflow: DMA addr 0x0000000100307000+4096 overflow (mask ffffffff, bus limit 0) WARNING: kernel/dma/direct.h:114 dma_direct_map_sg+0x778/0x920 drm_gem_shmem_test_purge: ASSERTION FAILED at drivers/gpu/drm/tests/drm_gem_shmem_test.c:330 Expected sgt is not error, but is: -5 The call chain leading to the failure is: drm_gem_shmem_test_purge() / drm_gem_shmem_test_get_pages_sgt() drm_gem_shmem_get_pages_sgt() drm_gem_shmem_get_pages_sgt_locked() [drm_gem_shmem_helper.c] dma_map_sgtable() [mapping.c] __dma_map_sg_attrs() dma_direct_map_sg() [direct.c] dma_direct_map_phys() [kernel/dma/direct.h] dma_capable() Checks addr against DMA mask -> FAILS: addr > 0xFFFFFFFF The root cause is that KUnit devices are initialized with a 32-bit DMA mask (DMA_BIT_MASK(32)) in lib/kunit/device.c. On ppc64le and s390x systems with physical memory above 4GB, page allocations can land at addresses that exceed this mask. When drm_gem_shmem_get_pages_sgt() attempts to DMA-map these pages via dma_map_sgtable(), the DMA layer rejects the mapping because the physical address overflows the 32-bit mask. The failure is intermittent because pages may or may not be allocated above 4GB on any given run depend on memory pressure. Fix by setting a 64-bit DMA mask on the device before calling drm_gem_shmem_get_pages_sgt() for all tests, following the same pattern already used in drm_gem_shmem_test_obj_create_private(). [1] https://s3.amazonaws.com/arr-cki-prod-trusted-artifacts/trusted-artifacts/2643976103/test_s390x/15128551935/artifacts/jobwatch/logs/recipes/21561049/tasks/220716793/results/1014626315/logs/dmesg.log [2] https://s3.amazonaws.com/arr-cki-prod-trusted-artifacts/trusted-artifacts/2643976103/test_ppc64le/15128551933/artifacts/jobwatch/logs/recipes/21561041/tasks/220716705/results/1014628163/logs/dmesg.log Fixes: 93032ae634d4 ("drm/test: add a test suite for GEM objects backed by shmem") Closes: https://datawarehouse.cki-project.org/issue/5345 Closes: https://datawarehouse.cki-project.org/issue/3184 Assisted-by: Claude:claude-4.6-opus Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: José Expósito <jose.exposito@redhat.com> Link: https://patch.msgid.link/20260703150808.3832-1-jose.exposito89@gmail.com
2026-07-23drm/etnaviv: force flush on power register opsRandolph Sapp2-5/+11
Add gpu_write_power_sync to verify that power register modifications have reached the endpoint device in sequence specific sections that do not validate device state. These sequence specific areas have been detected experimentally with an am57xx-evm through numerous boot and module load+unload cycles. Signed-off-by: Randolph Sapp <rs@ti.com> Reviewed-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Link: https://patch.msgid.link/20251013170122.1145387-2-rs@ti.com
2026-07-23drm/xe/vm: Fix SVM leak on resv obj alloc failure in xe_vm_create()Shuicheng Lin1-4/+4
Commit 9e9787414882 ("drm/xe/userptr: replace xe_hmm with gpusvm") made xe_svm_init() unconditional in xe_vm_create() and extended it to also initialize a "simple" gpusvm state for non-fault-mode VMs. The matching xe_svm_fini() call in xe_vm_close_and_put() was updated to run unconditionally, but the error unwind path in xe_vm_create() was not. On the drm_gpuvm_resv_object_alloc() failure path, xe_svm_init() has already succeeded but xe_svm_fini() is only called when XE_VM_FLAG_FAULT_MODE is set. For non-fault-mode VMs this leaves vm->svm.gpusvm partially initialized and leaks the resources allocated by drm_gpusvm_init(). For fault-mode VMs, xe_svm_init() additionally acquires the pagemap owner via drm_pagemap_acquire_owner() and the pagemaps via xe_svm_get_pagemaps(). Those resources are released by xe_svm_close(), not xe_svm_fini(). On the same error path, xe_svm_close() is not called either, so fault-mode VMs leak the pagemap owner and pagemaps. Fix both leaks: - Call xe_svm_fini() unconditionally on the err_svm_fini path, matching the unconditional xe_svm_init() call. Move the vm->size = 0 assignment out of the conditional so the xe_vm_is_closed() assert in xe_svm_fini() (and xe_svm_close()) holds for both modes. - Call xe_svm_close() for fault-mode VMs before xe_svm_fini(), matching the ordering used in xe_vm_close_and_put(). Fixes: 9e9787414882 ("drm/xe/userptr: replace xe_hmm with gpusvm") Cc: Matthew Auld <matthew.auld@intel.com> Assisted-by: Claude:claude-opus-4.7 Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260721205516.4058959-2-shuicheng.lin@intel.com Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com> (cherry picked from commit ca2a3587d577ba764e0fe628fb676244fc33ddd4) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2026-07-23drm/xe/i2c: Allow per domain unique idRaag Jadav1-1/+4
PCI bus, device and function can be same for devices existing across different domains. Allow per domain unique identifier while registering platform device to prevent name conflict. Fixes: f0e53aadd702 ("drm/xe: Support for I2C attached MCUs") Signed-off-by: Raag Jadav <raag.jadav@intel.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://patch.msgid.link/20260721113438.651100-1-raag.jadav@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com> (cherry picked from commit a79f6abc8b516b5bd906e2eca8121e3549ee163f) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2026-07-23gpu: nova-core: wait for RISC-V HALTED on FSP unloadEliot Courtney5-2/+36
Currently the code waits for "not active" but this is not the same as halted as there are more than two states. Match openrm here and wait for halted instead. Fixes: c7fea1f70944 ("gpu: nova-core: add non-sec2 unload path") Signed-off-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260703-blackwell-fixes-v2-10-8e3d8bc32bb9@nvidia.com [acourbot: s/imply/guarantee.] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-07-23gpu: nova-core: correct RISC-V HALTED fieldEliot Courtney1-1/+1
This uses the incorrect value, so update it. Fixes: bb58d1aee608 ("gpu: nova-core: falcon: Add support to check if RISC-V is active") Signed-off-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260703-blackwell-fixes-v2-9-8e3d8bc32bb9@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-07-23gpu: nova-core: gsp: ensure LibOS DMA allocation lives long enoughEliot Courtney2-13/+12
Currently, `GspSequencer` stores a raw DMA handle. Instead, store a reference to `Coherent` to statically ensure that the allocation lives long enough. Signed-off-by: Eliot Courtney <ecourtney@nvidia.com> Reviewed-by: Alistair Popple <apopple@nvidia.com> Link: https://patch.msgid.link/20260703-blackwell-fixes-v2-4-8e3d8bc32bb9@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-07-23gpu: nova-core: gsp: ensure lifetime for FMC boot DMA allocationsEliot Courtney3-28/+29
Currently, `FmcBootArgs` takes DMA handles directly, rather than references to the `Coherent` for them. This is error prone, so instead store lifetime'd references to the `Coherent` allocation. Signed-off-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260703-blackwell-fixes-v2-3-8e3d8bc32bb9@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-07-23gpu: nova-core: fsp: catch bogus queue pointer issuesEliot Courtney1-6/+10
Currently, `poll_msgq` will report a message of size 4 if the queue pointers are broken. It's easy to catch this if it occurs, so have `poll_msgq` return an error in this case. Signed-off-by: Eliot Courtney <ecourtney@nvidia.com> Reviewed-by: Alistair Popple <apopple@nvidia.com> Link: https://patch.msgid.link/20260703-blackwell-fixes-v2-2-8e3d8bc32bb9@nvidia.com [acourbot: explicitly mention the error, add paragraph separator.] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-07-22drm/xe/nvls: Drop force_probe requirementGustavo Sousa1-1/+0
NVL-S is stable enough for us to drop force_probe requirement. Let's do that. Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/20260722-nvl_s-drop-force_probe-v1-1-db944d940cff@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2026-07-22drm/mediatek: mtk_hdmi: Fix DDC adapter double put in v2Guangshuo Li1-8/+0
mtk_hdmi_common_probe() gets the DDC adapter with of_find_i2c_adapter_by_node() and registers a devm action to release the adapter device reference with put_device(). The HDMI v2 remove callback also calls i2c_put_adapter() on the same DDC adapter. This is not paired with of_find_i2c_adapter_by_node(): it drops the adapter device reference before the devm action drops it again, and it also puts a module reference that was never taken. Remove the extra i2c_put_adapter() call and drop the now-empty HDMI v2 remove callback. The common devm action releases the adapter device reference. Fixes: 8d0f79886273 ("drm/mediatek: Introduce HDMI/DDC v2 for MT8195/MT8188") Cc: stable@vger.kernel.org Reviewed-by: Johan Hovold <johan@kernel.org> Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com> Reviewed-by: CK Hu <ck.hu@mediatek.com> Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20260713112957.884640-1-lgs201920130244@gmail.com/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2026-07-22drm/mediatek: Check CRTC state before freeingRuoyu Wang1-3/+3
mtk_crtc_reset() destroys the current CRTC state only when crtc->state is non-NULL, but it always converts crtc->state to struct mtk_crtc_state and passes the result to kfree(). When reset is called without an existing state, container_of(NULL, ...) does not produce NULL. Keep the mtk state free in the same crtc->state guard as the helper state destruction. This issue was found by a static analysis checker and confirmed by manual source review. Fixes: 2d267b81898e ("drm/mtk: Use __drm_atomic_helper_crtc_reset") Signed-off-by: Ruoyu Wang <ruoyuw560@gmail.com> Reviewed-by: CK Hu <ck.hu@mediatek.com> Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20260707150528.2270739-1-ruoyuw560@gmail.com/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2026-07-22drm/xe/vm: Use regular comment for GSC VM lockdep note in xe_vm_create()Shuicheng Lin1-1/+1
The block comment describing the GSC VM lockdep annotation uses the kernel-doc opening marker (/**), but it is an in-function implementation note rather than API documentation. Per Documentation/doc-guide/kernel-doc.rst, /** is reserved for kernel-doc comments describing functions, structs, and other API elements, and using it for other comments can confuse kernel-doc tooling. Switch it to a regular block comment (/*). No functional change. Cc: Matthew Brost <matthew.brost@intel.com> Assisted-by: Claude:claude-opus-4.7 Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260721205516.4058959-4-shuicheng.lin@intel.com Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
2026-07-22drm/xe/vm: Remove redundant INIT_WORK() for rebind_work in xe_vm_create()Shuicheng Lin1-3/+1
xe_vm_create() initializes vm->preempt.rebind_work twice for LR-mode VMs: once in the LR-mode setup block before xe_svm_init(), and again inside the xe_validation_guard() block. The second call is a no-op on top of the first since the work is never queued between them, but re-initializing a work item is unnecessary and makes lifetime and ordering harder to reason about (e.g., any future change that queues the work earlier would be silently corrupted by the second INIT_WORK). Drop the duplicate INIT_WORK() and keep only the batch_invalidate_tlb flag handling in the later LR-mode block. The single INIT_WORK() call in the earlier LR-mode setup block remains the sole initialization. No functional change. Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Assisted-by: Claude:claude-opus-4.7 Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260721205516.4058959-3-shuicheng.lin@intel.com Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
2026-07-22drm/xe/vm: Fix SVM leak on resv obj alloc failure in xe_vm_create()Shuicheng Lin1-4/+4
Commit 9e9787414882 ("drm/xe/userptr: replace xe_hmm with gpusvm") made xe_svm_init() unconditional in xe_vm_create() and extended it to also initialize a "simple" gpusvm state for non-fault-mode VMs. The matching xe_svm_fini() call in xe_vm_close_and_put() was updated to run unconditionally, but the error unwind path in xe_vm_create() was not. On the drm_gpuvm_resv_object_alloc() failure path, xe_svm_init() has already succeeded but xe_svm_fini() is only called when XE_VM_FLAG_FAULT_MODE is set. For non-fault-mode VMs this leaves vm->svm.gpusvm partially initialized and leaks the resources allocated by drm_gpusvm_init(). For fault-mode VMs, xe_svm_init() additionally acquires the pagemap owner via drm_pagemap_acquire_owner() and the pagemaps via xe_svm_get_pagemaps(). Those resources are released by xe_svm_close(), not xe_svm_fini(). On the same error path, xe_svm_close() is not called either, so fault-mode VMs leak the pagemap owner and pagemaps. Fix both leaks: - Call xe_svm_fini() unconditionally on the err_svm_fini path, matching the unconditional xe_svm_init() call. Move the vm->size = 0 assignment out of the conditional so the xe_vm_is_closed() assert in xe_svm_fini() (and xe_svm_close()) holds for both modes. - Call xe_svm_close() for fault-mode VMs before xe_svm_fini(), matching the ordering used in xe_vm_close_and_put(). Fixes: 9e9787414882 ("drm/xe/userptr: replace xe_hmm with gpusvm") Cc: Matthew Auld <matthew.auld@intel.com> Assisted-by: Claude:claude-opus-4.7 Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260721205516.4058959-2-shuicheng.lin@intel.com Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
2026-07-22drm/gma500: return errors from Oaktrail HDMI I2C readsPengpeng Hou1-5/+16
xfer_read() waits for the HDMI I2C transaction to reach I2C_TRANSACTION_DONE, but it ignores both timeout and signal returns from wait_for_completion_interruptible_timeout(). If the interrupt never advances the transaction state, the loop can wait forever. Return -ETIMEDOUT when the completion wait expires, propagate interrupted waits, and make the I2C master_xfer callback return the first transfer error instead of reporting a successful message count. Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn> Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Link: https://patch.msgid.link/20260625003240.6923-1-pengpeng@iscas.ac.cn
2026-07-22drm/xe/i2c: Allow per domain unique idRaag Jadav1-1/+4
PCI bus, device and function can be same for devices existing across different domains. Allow per domain unique identifier while registering platform device to prevent name conflict. Fixes: f0e53aadd702 ("drm/xe: Support for I2C attached MCUs") Signed-off-by: Raag Jadav <raag.jadav@intel.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://patch.msgid.link/20260721113438.651100-1-raag.jadav@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2026-07-22drm/vc4: hvs/v3d: Fix null dereference in unbindGregor Herburger2-2/+2
The hvs and v3d drivers use dev_get_drvdata(master) in their unbind functions. Since the vc4-drm gets removed before its dependent drivers (vc4_hvs/vc4_v3d) the vc4_hvs_unbind/vc4_v3d_unbind functions try to get drvdata of its master and fails with a null dereference error. Use the data pointer passed to the unbind functions directly instead of dev_get_drvdata(master). This avoids using potentially freed memory. Fixes: d3f5168a0810 ("drm/vc4: Bind and initialize the V3D engine.") Fixes: c8b75bca92cb ("drm/vc4: Add KMS support for Raspberry Pi.") Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de> Link: https://patch.msgid.link/20260721-rpi-vc4-fix-v2-1-b813dcd01dc7@linutronix.de Reviewed-by: Maíra Canal <mcanal@igalia.com> Signed-off-by: Maíra Canal <mcanal@igalia.com>
2026-07-22drm/panel: fix unmet dependency bug for DRM_PANEL_HIMAX_HX83121AJulian Braha1-0/+1
Currently, DRM_PANEL_HIMAX_HX83121A selects DRM_DISPLAY_DSC_HELPER without also ensuring DRM_DISPLAY_HELPER is enabled, causing an unmet dependency: WARNING: unmet direct dependencies detected for DRM_DISPLAY_DSC_HELPER Depends on [n]: HAS_IOMEM [=y] && DRM [=m] && DRM_DISPLAY_HELPER [=n] Selected by [m]: - DRM_PANEL_HIMAX_HX83121A [=m] && HAS_IOMEM [=y] && DRM [=m] && DRM_PANEL [=y] && OF [=y] && DRM_MIPI_DSI [=y] && BACKLIGHT_CLASS_DEVICE [=m] - DRM_PANEL_ILITEK_ILI9882T [=m] && HAS_IOMEM [=y] && DRM [=m] && DRM_PANEL [=y] && OF [=y] && DRM_MIPI_DSI [=y] && BACKLIGHT_CLASS_DEVICE [=m] Many other DRM_PANEL_* options select DRM_DISPLAY_HELPER when selecting DRM_DISPLAY_DSC_HELPER, let's do the same here. This unmet dependency bug was found by kconfirm, a static analysis tool for Kconfig. Fixes: defab7b01e08 ("drm/panel: hx83121a: select DRM_DISPLAY_DSC_HELPER") Signed-off-by: Julian Braha <julianbraha@gmail.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260711234230.2236041-1-julianbraha@gmail.com
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.