summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2026-01-20drm/panel: jd9365da: Support for Anbernic RG-DS PanelChris Morgan1-2/+269
Add support for both panels used in the Anbernic RG-DS. These panels are physically identical and differ only with a single instruction in the init sequence. The init sequence commands suggest it uses an identical controller as the jd9365da. Additionally, allow specifying per-panel dsi->mode_flags that can override the default values. Co-developed-by: Alexander Weinzerl <aweinzerl13@yahoo.com> Signed-off-by: Alexander Weinzerl <aweinzerl13@yahoo.com> Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patch.msgid.link/20260113195721.151205-4-macroalpha82@gmail.com
2026-01-20dt-bindings: display: panel: Add compatible for Anbernic RG-DSChris Morgan1-0/+2
The Anbernic RG-DS uses two (mostly) identical panels as a top and bottom panel which appear to use the same controller as the Jadard JD9365DA-H3. The panels differ with a parameter defined differently in the init sequence. Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Acked-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patch.msgid.link/20260113195721.151205-3-macroalpha82@gmail.com
2026-01-20drm: panel: jd9365da: Use gpiod_set_value_cansleep()Chris Morgan1-5/+5
Change instances of gpiod_set_value() to gpiod_set_value_cansleep(). Uses of gpiod_set_value() generates warnings when used in instances where desc->gdev->can_sleep is true. Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patch.msgid.link/20260113195721.151205-2-macroalpha82@gmail.com
2026-01-20drm/rockchip: vop2: Add mode valid callback for crtcAndy Yan1-0/+12
The different Video Ports support different maximum resolutions. Reject resolutions that are not supported by a specific VP. Only the output width is checked because the hardware itself does not have a hard output height limit. Filter the mode that can't output by the VP/crtc. Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> # Sige5 Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patch.msgid.link/20260117020738.294825-1-andyshrk@163.com
2026-01-20drm/rockchip: dw_hdmi_qp: Optimize RK3588 HPD interrupt handlingCristian Ciocaltea1-5/+1
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 Ciocaltea1-6/+1
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 Baryshkov1-1/+1
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 Li1-0/+2
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 Li1-2/+5
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 Li4-0/+33
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 Li5-4/+80
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/buddy: release free_trees array on buddy mm teardownMichał Grzelak1-0/+1
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-19dma-buf: Remove DMA-BUF sysfs statsT.J. Mercier8-312/+0
Commit bdb8d06dfefd ("dmabuf: Add the capability to expose DMA-BUF stats in sysfs") added dmabuf statistics to sysfs in 2021 under CONFIG_DMABUF_SYSFS_STATS. After being used in production, performance problems were discovered leading to its deprecation in 2022 in commit e0a9f1fe206a ("dma-buf: deprecate DMABUF_SYSFS_STATS"). Some of the problems with this interface were discussed in my LPC 2025 talk. [1][2] Android was probably the last user of the interface, which has since been migrated to use the dmabuf BPF iterator [3] to obtain the same information more cheaply. As promised in that series, now that the longterm stable 6.18 kernel has been released let's remove the sysfs dmabuf statistics from the kernel. [1] https://www.youtube.com/watch?v=D83qygudq9c [2] https://lpc.events/event/19/contributions/2118/ [3] https://lore.kernel.org/all/20250522230429.941193-1-tjmercier@google.com/ Signed-off-by: T.J. Mercier <tjmercier@google.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org> Link: https://patch.msgid.link/20260116190517.3268458-1-tjmercier@google.com
2026-01-19dma-buf: system_heap: account for system heap allocation in memcgEric Chanudet1-2/+5
The system dma-buf heap lets userspace allocate buffers from the page allocator. However, these allocations are not accounted for in memcg, allowing processes to escape limits that may be configured. Pass __GFP_ACCOUNT for system heap allocations, based on the dma_heap.mem_accounting parameter, to use memcg and account for them. Signed-off-by: Eric Chanudet <echanude@redhat.com> Reviewed-by: T.J. Mercier <tjmercier@google.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org> Link: https://patch.msgid.link/20260116-dmabuf-heap-system-memcg-v3-2-ecc6b62cc446@redhat.com
2026-01-19dma-buf: heaps: add parameter to account allocations using cgroupEric Chanudet2-0/+7
Add a parameter to enable dma-buf heaps allocation accounting using cgroup for heaps that implement it. It is disabled by default as doing so incurs caveats based on how memcg currently accounts for shared buffers. Signed-off-by: Eric Chanudet <echanude@redhat.com> Reviewed-by: T.J. Mercier <tjmercier@google.com> Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org> Link: https://patch.msgid.link/20260116-dmabuf-heap-system-memcg-v3-1-ecc6b62cc446@redhat.com
2026-01-19drm/imagination: Warn or error on unsupported hardwareMatt Coster1-1/+72
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 Coster5-2/+97
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 Dadu2-10/+114
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 Coster1-2/+7
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 Coster1-14/+62
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 Coster8-248/+42
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/debug: don't register files for unsupported HDMI InfoFramesDmitry Baryshkov1-0/+7
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 Baryshkov1-49/+45
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 Baryshkov1-2/+8
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 Baryshkov1-2/+2
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 Baryshkov8-185/+455
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 Baryshkov11-422/+706
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 Baryshkov4-1/+42
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 Baryshkov1-0/+9
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 Baryshkov1-0/+25
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 Baryshkov3-0/+749
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 Canal7-54/+62
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 Canal1-48/+26
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-16drm: Account property blob allocations to memcgXiao Kan1-1/+1
DRM_IOCTL_MODE_CREATEPROPBLOB allows userspace to allocate arbitrary-sized property blobs backed by kernel memory. Currently, the blob data allocation is not accounted to the allocating process's memory cgroup, allowing unprivileged users to trigger unbounded kernel memory consumption and potentially cause system-wide OOM. Mark the property blob data allocation with GFP_KERNEL_ACCOUNT so that the memory is properly charged to the caller's memcg. This ensures existing cgroup memory limits apply and prevents uncontrolled kernel memory growth without introducing additional policy or per-file limits. Signed-off-by: Xiao Kan <814091656@qq.com> Signed-off-by: Xiao Kan <xiao.kan@samsung.com> Link: https://patch.msgid.link/tencent_D12AA2DEDE6F359E1AF59405242FB7A5FD05@qq.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2026-01-16drm: renesas: rz-du: mipi_dsi: fix kernel panic when rebooting for some panelsHugo Villeneuve1-0/+8
Since commit 56de5e305d4b ("clk: renesas: r9a07g044: Add MSTOP for RZ/G2L") we may get the following kernel panic, for some panels, when rebooting: systemd-shutdown[1]: Rebooting. Call trace: ... do_serror+0x28/0x68 el1h_64_error_handler+0x34/0x50 el1h_64_error+0x6c/0x70 rzg2l_mipi_dsi_host_transfer+0x114/0x458 (P) mipi_dsi_device_transfer+0x44/0x58 mipi_dsi_dcs_set_display_off_multi+0x9c/0xc4 ili9881c_unprepare+0x38/0x88 drm_panel_unprepare+0xbc/0x108 This happens for panels that need to send MIPI-DSI commands in their unprepare() callback. Since the MIPI-DSI interface is stopped at that point, rzg2l_mipi_dsi_host_transfer() triggers the kernel panic. Fix by moving rzg2l_mipi_dsi_stop() to new callback function rzg2l_mipi_dsi_atomic_post_disable(). With this change we now have the correct power-down/stop sequence: systemd-shutdown[1]: Rebooting. rzg2l-mipi-dsi 10850000.dsi: rzg2l_mipi_dsi_atomic_disable(): entry ili9881c-dsi 10850000.dsi.0: ili9881c_unprepare(): entry rzg2l-mipi-dsi 10850000.dsi: rzg2l_mipi_dsi_atomic_post_disable(): entry reboot: Restarting system Suggested-by: Biju Das <biju.das.jz@bp.renesas.com> Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Tested-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://patch.msgid.link/20260112154333.655352-1-hugo@hugovil.com Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
2026-01-14accel/amdxdna: Fix notifier_wq flushing warningLizhi Hou1-1/+1
Create notifier_wq with WQ_MEM_RECLAIM flag to fix the possible warning. workqueue: WQ_MEM_RECLAIM amdxdna_js:drm_sched_free_job_work [gpu_sched] is flushing !WQ_MEM_RECLAIM notifier_wq:0x0 Fixes: e486147c912f ("accel/amdxdna: Add BO import and export") Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Reviewed-by: Maciej Falkowski <maciej.falkowski@linux.intel.com> Signed-off-by: Lizhi Hou <lizhi.hou@amd.com> Link: https://patch.msgid.link/20260113173624.256053-1-lizhi.hou@amd.com
2026-01-14drm/tegra: dsi: fix device leak on probeJohan Hovold1-4/+2
Make sure to drop the reference taken when looking up the companion (ganged) device and its driver data during probe(). Note that holding a reference to a device does not prevent its driver data from going away so there is no point in keeping the reference. Fixes: e94236cde4d5 ("drm/tegra: dsi: Add ganged mode support") Fixes: 221e3638feb8 ("drm/tegra: Fix reference leak in tegra_dsi_ganged_probe") Cc: stable@vger.kernel.org # 3.19: 221e3638feb8 Cc: Thierry Reding <treding@nvidia.com> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patch.msgid.link/20251121164201.13188-1-johan@kernel.org
2026-01-14drm/rockchip: DRM_ROCKCHIP should depend on ARCH_ROCKCHIPGeert Uytterhoeven1-0/+1
Rockchip display hardware is only available on Rockchip SoCs. Hence add a dependency on ARCH_ROCKCHIP, to prevent asking the user about this driver when configuring a kernel without Rockchip platform support. Before, this dependency was implicit through a hard dependency on ROCKCHIP_IOMMU. Fixes: 0244539f9a4f3b56 ("drm/rockchip: Drop ROCKCHIP_IOMMU depend for DRM_ROCKCHIP") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Chaoyi Chen <chaoyi.chen@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patch.msgid.link/5db192d31cc51f027f107c01c01a353a0569ebf4.1768310045.git.geert+renesas@glider.be
2026-01-14drm/atomic: verify that gamma/degamma LUTs are not too bigDmitry Baryshkov1-2/+20
The kernel specifies LUT table sizes in a separate property, however it doesn't enforce it as a maximum. Some drivers implement max size check on their own in the atomic_check path. Other drivers simply ignore the issue. Perform LUT size validation in the generic place. Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260106-drm-fix-lut-checks-v3-3-f7f979eb73c8@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-01-14drm/atomic: add max_size check to drm_property_replace_blob_from_id()Dmitry Baryshkov4-17/+27
The function drm_property_replace_blob_from_id() allows checking whether the blob size is equal to a predefined value. In case of variable-size properties (like the gamma / degamma LUTs) we might want to check for the blob size against the maximum, allowing properties of the size lesser than the max supported by the hardware. Extend the function in order to support such checks. Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260106-drm-fix-lut-checks-v3-2-f7f979eb73c8@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-01-14drm/mode_object: add drm_object_immutable_property_get_value()Dmitry Baryshkov2-0/+28
We have a helper to get property values for non-atomic drivers and another one default property values for atomic drivers. In some cases we need the ability to get value of immutable property, no matter what kind of driver it is. Implement new property-related helper, drm_object_immutable_property_get_value(), which lets the caller to get the value of the immutable property. Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260106-drm-fix-lut-checks-v3-1-f7f979eb73c8@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-01-13drm/panthor: Implement reading shader_present from nvmemNicolas Frattaroli1-6/+30
On some platforms, notably MediaTek MT8196, the shader_present bitmask in the Mali GPU register for it has cores enabled that may be faulty. The true shader_present bitmask is found in an efuse instead. Implement reading shader_present from an nvmem cell if one is present, falling back to the Mali register if it's absent. The error codes are trickled up through to the probe function so that probe deferral works. Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Steven Price <steven.price@arm.com> Link: https://patch.msgid.link/20251220-mt8196-shader-present-v2-3-45b1ff1dfab0@collabora.com Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
2026-01-13dt-bindings: gpu: mali-valhall-csf: Add shader-present nvmem cellNicolas Frattaroli1-0/+14
On the MediaTek MT8196 SoC, the bitmask for which shader cores are present and functional is not the one in the Mali GPU's registers, but in an external efuse. Add the nvmem cell properties to describe such a setup, and make them required on MT8196. Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Link: https://patch.msgid.link/20251220-mt8196-shader-present-v2-1-45b1ff1dfab0@collabora.com Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
2026-01-13host1x: Convert to bus methodsUwe Kleine-König1-34/+33
The callbacks .probe(), .remove() and .shutdown() for device_drivers should go away. So migrate to bus methods. There are two differences that need addressing: - The bus remove callback returns void while the driver remove callback returns int (the actual value is ignored by the core). - The bus shutdown callback is also called for unbound devices, so an additional check for dev->driver != NULL is needed. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com> # tegra20 tegra-video Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patch.msgid.link/dd55d034c68953268ea416aa5c13e41b158fcbb4.1765355236.git.u.kleine-koenig@baylibre.com
2026-01-13host1x: Make remove callback return voidUwe Kleine-König5-11/+5
The return value of struct device_driver::remove is ignored by the core (see device_remove() in drivers/base/dd.c). So it doesn't make sense to let the host1x remove callback return an int just to ignore it later. So make the callback return void. All current implementors return 0, so they are easily converted. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com> # tegra20 tegra-video Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patch.msgid.link/d364fd4ec043d36ee12e46eaef98c57658884f63.1765355236.git.u.kleine-koenig@baylibre.com
2026-01-13drm/panel: himax-hx83102: change to gpiod_set_value_cansleepVladimir Yakovlev1-6/+6
It's better to use gpiod_set_value_cansleep because the panel can be connected via i2c/spi expander or similar external devices for reference see Documentation/driver-api/gpio/consumer.rst Signed-off-by: Vladimir Yakovlev <vovchkir@gmail.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20251208161613.3763049-1-vovchkir@gmail.com
2026-01-13dt-bindings: display: panel-simple: Allow "data-mapping" for ↵Rob Herring (Arm)1-1/+3
"yes-optoelectronics,ytc700tlag-05-201c" The "data-mapping" property is in use already with the "yes-optoelectronics,ytc700tlag-05-201c" panel, so allow it in the schema. Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260105193220.3166778-1-robh@kernel.org
2026-01-13drm/panel: mantix: Don't turn on MIPI peripheralSebastian Krzyszkowiak1-2/+0
It's not necessary with these panels. Signed-off-by: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260105-mantix-halo-fixes-v1-5-1ebc9b195a34@puri.sm
2026-01-13drm/panel: mantix: Drop bank 9 initializationSebastian Krzyszkowiak1-4/+2
This command is part of LIC sequence included in FT8006P firmware. There's no need to repeat it here. Signed-off-by: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260105-mantix-halo-fixes-v1-4-1ebc9b195a34@puri.sm
2026-01-13drm/panel: mantix: Improve power off sequenceSebastian Krzyszkowiak1-4/+8
According to the sequence from section 7.3.4 of FT8006P datasheet, TP_RSTN and RESX should be asserted after disabling AVDD and AVEE and together with VDDI. Also, AVEE power down needs to happen at least 150ms after entering sleep mode. Signed-off-by: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260105-mantix-halo-fixes-v1-3-1ebc9b195a34@puri.sm
generated by cgit v1.2.3 (git 2.39.0) at 2026-05-04 09:27:58 +0300