summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2025-03-05drm/msm/dpu: fill CRTC resources in dpu_crtc.cDmitry Baryshkov
Stop poking into CRTC state from dpu_encoder.c, fill CRTC HW resources from dpu_crtc_assign_resources(). Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> [quic_abhinavk@quicinc.com: cleaned up formatting] Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Jessica Zhang <quic_jesszhan@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/637485/ Link: https://lore.kernel.org/r/20250214-concurrent-wb-v6-1-a44c293cf422@quicinc.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2025-03-05drm/msm/dpu: don't set crtc_state->mode_changed from atomic_check()Dmitry Baryshkov
The MSM driver uses drm_atomic_helper_check() which mandates that none of the atomic_check() callbacks toggles crtc_state->mode_changed. Perform corresponding check before calling the drm_atomic_helper_check() function. Fixes: 8b45a26f2ba9 ("drm/msm/dpu: reserve cdm blocks for writeback in case of YUV output") Reported-by: Simona Vetter <simona.vetter@ffwll.ch> Closes: https://lore.kernel.org/dri-devel/ZtW_S0j5AEr4g0QW@phenom.ffwll.local/ Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com> [DB: dropped the WARN_ON] Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/633400/ Link: https://lore.kernel.org/r/20250123-drm-dirty-modeset-v2-4-bbfd3a6cd1a4@linaro.org
2025-03-04drm/xe: Fix GT "for each engine" workaroundsTvrtko Ursulin
Any rules using engine matching are currently broken due RTP processing happening too in early init, before the list of hardware engines has been initialised. Fix this by moving workaround processing to later in the driver probe sequence, to just before the processed list is used for the first time. Looking at the debugfs gt0/workarounds on ADL-P we notice 14011060649 should be present while we see, before: GT Workarounds 14011059788 14015795083 And with the patch: GT Workarounds 14011060649 14011059788 14015795083 Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: stable@vger.kernel.org # v6.11+ Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250227101304.46660-2-tvrtko.ursulin@igalia.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> (cherry picked from commit 25d434cef791e03cf40680f5441b576c639bfa84) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-03-04drm/xe/userptr: properly setup pfn_flags_maskMatthew Auld
Currently we just leave it uninitialised, which at first looks harmless, however we also don't zero out the pfn array, and with pfn_flags_mask the idea is to be able set individual flags for a given range of pfn or completely ignore them, outside of default_flags. So here we end up with pfn[i] & pfn_flags_mask, and if both are uninitialised we might get back an unexpected flags value, like asking for read only with default_flags, but getting back write on top, leading to potentially bogus behaviour. To fix this ensure we zero the pfn_flags_mask, such that hmm only considers the default_flags and not also the initial pfn[i] value. v2 (Thomas): - Prefer proper initializer. Fixes: 81e058a3e7fd ("drm/xe: Introduce helper to populate userptr") Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Thomas Hellström <thomas.hellstrom@intel.com> Cc: <stable@vger.kernel.org> # v6.10+ Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Tejas Upadhyay <tejas.upadhyay@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250226174748.294285-2-matthew.auld@intel.com (cherry picked from commit dd8c01e42f4c5c1eaf02f003d7d588ba6706aa71) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-03-04drm/i915/mst: update max stream count to match number of pipesJani Nikula
We create the stream encoders and attach connectors for each pipe we have. As the number of pipes has increased, we've failed to update the topology manager maximum number of payloads to match that. Bump up the max stream count to match number of pipes, enabling the fourth stream on platforms that support four pipes. Cc: stable@vger.kernel.org Cc: Imre Deak <imre.deak@intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250226135626.1956012-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit 15bccbfb78d63a2a621b30caff8b9424160c6c89) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-03-04drm/xe: Remove double pageflipMaarten Lankhorst
This is already handled below in the code by fixup_initial_plane_config. Fixes: a8153627520a ("drm/i915: Try to relocate the BIOS fb to the start of ggtt") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241210083111.230484-3-dev@lankhorst.se Signed-off-by: Maarten Lankhorst <dev@lankhorst.se> (cherry picked from commit 2218704997979fbf11765281ef752f07c5cf25bb) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-03-04drm/rockchip: lvds: lower log severity for missing pinctrl settingsHeiko Stuebner
While missing lvds pinctrl is unexpected and is reported, we nevertheless don't fail setting up the device and instead continue without explicit pinctrl handling. So lower the log-level from error to warning to reflect that. Suggested-by: Quentin Schulz <quentin.schulz@cherry.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de> Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20250304124418.111061-4-heiko@sntech.de
2025-03-04drm/rockchip: lvds: Hide scary error messages on probe deferralHeiko Stuebner
Commit 52d11c863ac9 ("drm/rockchip: lvds: do not print scary message when probing defer") already started hiding scary messages that are not relevant if the requested supply just returned EPROBE_DEFER, but there are more possible sources - like the phy. So modernize the whole logging in the probe path by replacing the remaining deprecated DRM_DEV_ERROR with appropriate dev_err(_probe) and drm_err calls. The distinction here is that all messages talking about mishaps of the lvds element use dev_err(_probe) while messages caused by interaction with the main Rockchip drm-device use drm_err. Reviewed-by: Andy Yan <andy.yan@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de> Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20250304124418.111061-3-heiko@sntech.de
2025-03-04drm/rockchip: lvds: move pclk preparation in with clk_getHeiko Stuebner
The LVDS block needs a separate pclk only on some socs, so currently requests and prepares it in the soc-specific probe function, but common code is required to unprepare it in the error path or on driver remove. While this works because clk_unprepare just does nothing if clk is NULL, this mismatch of who is responsible still is not very nice. The clock-framework already has a helper for clk-get-and-prepare even with devres support in devm_clk_get_prepared(). This will get and prepare the clock and also unprepare it on driver removal, saving the driver from having to handle it "manually". Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de> Reviewed-by: Andy Yan <andy.yan@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20250304124418.111061-2-heiko@sntech.de
2025-03-04drm/sched: stop passing non struct drm_device to drm_err() and friendsJani Nikula
The expectation is that the struct drm_device based logging helpers get passed an actual struct drm_device pointer rather than some random struct pointer where you can dereference the ->dev member. Convert drm_err(sched, ...) to dev_err(sched->dev, ...) and similar. This matches current usage, as struct drm_device is not available, but drops "[drm]" or "[drm] *ERROR*" prefix from logging. Unfortunately, there's no dev_WARN_ON(), so the conversion is not exactly the same. Reviewed-by: Simona Vetter <simona.vetter@ffwll.ch> Acked-by: Philipp Stanner <phasta@kernel.org> Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/fe441dd1469d2b03e6b2ff247078bdde2011c6e3.1737644530.git.jani.nikula@intel.com
2025-03-04drm/rockchip: stop passing non struct drm_device to drm_err() and friendsJani Nikula
The expectation is that the struct drm_device based logging helpers get passed an actual struct drm_device pointer rather than some random struct pointer where you can dereference the ->dev member. Convert drm_err(hdmi, ...) to dev_err(hdmi->dev, ...). This matches current usage, but drops "[drm] *ERROR*" prefix from logging. Reviewed-by: Simona Vetter <simona.vetter@ffwll.ch> Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/f42da4c9943a2f2a9de4272b7849e72236d4c3f9.1737644530.git.jani.nikula@intel.com
2025-03-04drm/mipi-dsi: stop passing non struct drm_device to drm_err() and friendsJani Nikula
The expectation is that the struct drm_device based logging helpers get passed an actual struct drm_device pointer rather than some random struct pointer where you can dereference the ->dev member. Convert drm_err(host, ...) to dev_err(host->dev, ...). This matches current usage, as struct drm_device is not available, but drops "[drm] *ERROR*" from logs. Reviewed-by: Simona Vetter <simona.vetter@ffwll.ch> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/842f97ade87d6f0c4b1de12e8ed5610a1b07fd8c.1737644530.git.jani.nikula@intel.com
2025-03-04drm/appletbdrm: Fix format specifier for size_t variablesNathan Chancellor
When building for a 32-bit platform, there are some warnings (or errors with CONFIG_WERROR=y) due to an incorrect specifier for 'size_t' variables, which is typedef'd as 'unsigned int' for these architectures: drivers/gpu/drm/tiny/appletbdrm.c:171:17: error: format specifies type 'unsigned long' but the argument has type 'size_t' (aka 'unsigned int') [-Werror,-Wformat] 170 | drm_err(drm, "Actual size (%d) doesn't match expected size (%lu)\n", | ~~~ | %zu 171 | actual_size, size); | ^~~~ ... drivers/gpu/drm/tiny/appletbdrm.c:212:17: error: format specifies type 'unsigned long' but the argument has type 'size_t' (aka 'unsigned int') [-Werror,-Wformat] 211 | drm_err(drm, "Actual size (%d) doesn't match expected size (%lu)\n", | ~~~ | %zu 212 | actual_size, size); | ^~~~ Use '%zu' as suggested, clearing up the warnings. Fixes: 0670c2f56e45 ("drm/tiny: add driver for Apple Touch Bars in x86 Macs") Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Aditya Garg <gargaditya08@live.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250304-appletbdrm-fix-size_t-specifier-v1-1-94fe1d2c91f8@kernel.org Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-03-04drm/i915: Reoder gen9+ timestamp freq register bitsVille Syrjälä
We customarily define the bits of a register in big endian order. Reorder the gen9+ timestamp freq register bits to match. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250211231941.22769-13-ville.syrjala@linux.intel.com
2025-03-04drm/i915: Use REG_BIT() & co. for gen9+ timestamp freq registersVille Syrjälä
Convert the gen9+ timestamo frequency related registers to the modern REG_BIT()/etc. style. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250211231941.22769-12-ville.syrjala@linux.intel.com
2025-03-04drm/i915: Reoder BDW+ EU/slice fuse bitsVille Syrjälä
We customarily define the bits of a register in big endian order. Reorder the BDW+ fuse bits to match. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250211231941.22769-11-ville.syrjala@linux.intel.com
2025-03-04drm/i915: Use REG_BIT() & co. for BDW+ EU/slice fuse bitsVille Syrjälä
Convert the BDW+ EU/slice fuse bits to the modern REG_BIT()/etc. style. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250211231941.22769-10-ville.syrjala@linux.intel.com
2025-03-04drm/i915: Reoder CHV EU/slice fuse bitsVille Syrjälä
We customarily define the bits of a register in big endian order. Reorder the CHV fuse bits to match. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250211231941.22769-9-ville.syrjala@linux.intel.com
2025-03-04drm/i915: Use REG_BIT() & co. for CHV EU/slice fuse bitsVille Syrjälä
Convert the CHV EU/slice fuse bits to the modern REG_BIT()/etc. style. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250211231941.22769-8-ville.syrjala@linux.intel.com
2025-03-04drm/i915: Extract gen8_report_fault()Ville Syrjälä
gen8_check_faults() and xehp_check_faults() are nearly identical. Refactor the common bits into gen8_report_fault(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250211231941.22769-7-ville.syrjala@linux.intel.com
2025-03-04drm/i915: Introduce RING_FAULT_VADDR_MASKVille Syrjälä
Add a proper bitmask definition for the pre-bdw fault virtual address bits insted of abusing PAGE_MASK. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250211231941.22769-6-ville.syrjala@linux.intel.com
2025-03-04drm/i915: Document which RING_FAULT bits apply to which platformsVille Syrjälä
The RING_FAULT bits have change a bit over the years. Document which platforms use which bits. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250211231941.22769-5-ville.syrjala@linux.intel.com
2025-03-04drm/i915: Use REG_BIT() & co. for ring fault registersVille Syrjälä
Update the ring fault registers to use the modern REG_BIT() stuff. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250211231941.22769-4-ville.syrjala@linux.intel.com
2025-03-04drm/i915: Relocate RING_FAULT bitsVille Syrjälä
We share the bit definitions between the older RING_FAULT registers and their various gen12+ counterparts. Currently the bits are defined next to the new registers which isn't what we typically do. Move the bit definitions next the older register offsets, and leave breadcrumbs around the gen12+ registers to make it easier to find the right bits. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250211231941.22769-3-ville.syrjala@linux.intel.com
2025-03-04drm/i915: Bump RING_FAULT engine ID bitsVille Syrjälä
The fault engine ID field has been 5 bits since icl. Bump our define to match. The extra bits were unused before icl so we should be able to use the larger mask unconditionally. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250211231941.22769-2-ville.syrjala@linux.intel.com
2025-03-03drm/rockchip: vop2: add missing bitfield.h includeHeiko Stuebner
Commit 328e6885996c ("drm/rockchip: vop2: Add platform specific callback") moved per soc configuration code to the other per-soc data into rockchip_vop2_reg.c, but forgot to also include bitfield.h for the used FIELD_PREP macro. Add this missing include. Fixes: 328e6885996c ("drm/rockchip: vop2: Add platform specific callback") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202503040135.fgoyWdLB-lkp@intel.com/ Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20250303182256.1727178-1-heiko@sntech.de
2025-03-03drm/rockchip: vop2: Add support for rk3576Andy Yan
VOP2 on rk3576: Three video ports: VP0 Max 4096x2160 VP1 Max 2560x1600 VP2 Max 1920x1080 2 4K Cluster windows with AFBC/RFBC, line RGB and YUV 4 Esmart windows with line RGB/YUV support: Esmart0/1: 4K Esmart2/3: 2k, or worked together as a single 4K plane at shared line buffer mode. Compared to the previous VOP, another difference is that each VP has its own independent vsync interrupt number. Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Tested-by: Michael Riesch <michael.riesch@wolfvision.net> # on RK3568 Tested-by: Detlev Casanova <detlev.casanova@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20250303034436.192400-8-andyshrk@163.com
2025-03-03drm/rockchip: vop2: Add uv swap for cluster windowAndy Yan
The Cluster windows of upcoming VOP on rk3576 also support linear YUV support, we need to set uv swap bit for it. As the VOP2_WIN_UV_SWA register defined on rk3568/rk3588 is 0xffffffff, so this register will not be touched on these two platforms. Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Tested-by: Michael Riesch <michael.riesch@wolfvision.net> # on RK3568 Tested-by: Detlev Casanova <detlev.casanova@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20250303034436.192400-4-andyshrk@163.com
2025-03-03drm/rockchip: vop2: Set plane possible crtcs by possible vp maskAndy Yan
In the upcoming VOP of rk3576, a window cannot attach to all Video Ports, we introduce a possible_vp_mask for every window to indicate which Video Ports this window can attach to. Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Tested-by: Michael Riesch <michael.riesch@wolfvision.net> # on RK3568 Tested-by: Detlev Casanova <detlev.casanova@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20250303034436.192400-3-andyshrk@163.com
2025-03-03drm/rockchip: vop2: Register the primary plane and overlay plane separatelyAndy Yan
In the upcoming VOP of rk3576, a Window cannot attach to all Video Ports, so make sure all VP find it's suitable primary plane, then register the remain windows as overlay plane will make code easier. Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Tested-by: Michael Riesch <michael.riesch@wolfvision.net> # on RK3568 Tested-by: Detlev Casanova <detlev.casanova@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20250303034436.192400-2-andyshrk@163.com
2025-03-03drm: adp: Add Apple Display Pipe driverSasha Finkelstein
This display controller is present on M-series chips and is used to drive the touchbar display. Co-developed-by: Janne Grunau <j@jannau.net> Signed-off-by: Janne Grunau <j@jannau.net> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Neal Gompa <neal@gompa.dev> Signed-off-by: Sasha Finkelstein <fnkl.kernel@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250224-adpdrm-v8-2-cccf96710f0f@gmail.com Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2025-03-03drm/tiny: add driver for Apple Touch Bars in x86 MacsKerem Karabay
The Touch Bars found on x86 Macs support two USB configurations: one where the device presents itself as a HID keyboard and can display predefined sets of keys, and one where the operating system has full control over what is displayed. This commit adds support for the display functionality of the second configuration. Functionality for the first configuration has been merged in the HID tree. Note that this driver has only been tested on T2 Macs, and only includes the USB device ID for these devices. Testing on T1 Macs would be appreciated. Credit goes to Ben (Bingxing) Wang on GitHub for reverse engineering most of the protocol. Also, as requested by Andy, I would like to clarify the use of __packed structs in this driver: - All the packed structs are aligned except for appletbdrm_msg_information. - We have to pack appletbdrm_msg_information since it is requirement of the protocol. - We compared binaries compiled by keeping the rest structs __packed and not __packed using bloat-o-meter, and __packed was not affecting code generation. - To maintain consistency, rest structs have been kept __packed. I would also like to point out that since the driver was reverse-engineered the actual data types of the protocol might be different, including, but not limited to, endianness. Link: https://github.com/imbushuo/DFRDisplayKm Signed-off-by: Kerem Karabay <kekrby@gmail.com> Co-developed-by: Atharva Tiwari <evepolonium@gmail.com> Signed-off-by: Atharva Tiwari <evepolonium@gmail.com> Co-developed-by: Aditya Garg <gargaditya08@live.com> Signed-off-by: Aditya Garg <gargaditya08@live.com> Signed-off-by: Aun-Ali Zaidi <admin@kodeit.net> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/FCAC702C-F84A-47F9-8C78-BBBB34D08500@live.com
2025-03-03drm/format-helper: Add conversion from XRGB8888 to BGR888Kerem Karabay
Add XRGB8888 emulation helper for devices that only support BGR888. Signed-off-by: Kerem Karabay <kekrby@gmail.com> Signed-off-by: Aditya Garg <gargaditya08@live.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/9A67EA95-9BC7-4D56-8F87-05EAC1C166AD@live.com
2025-03-03drm/sched: Fix preprocessor guardPhilipp Stanner
When writing the header guard for gpu_scheduler_trace.h, a typo, apparently, occurred. Fix the typo and document the scope of the guard. Fixes: 353da3c520b4 ("drm/amdgpu: add tracepoint for scheduler (v2)") Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20250218124149.118002-2-phasta@kernel.org
2025-03-03drm/vc4: hdmi: Fix some NULL vs IS_ERR() bugsDan Carpenter
The devm_platform_ioremap_resource_byname() function doesn't return NULL, it returns error pointers. Update the checking to match. Fixes: b93f07cf090a ("drm/vc4: move to devm_platform_ioremap_resource() usage") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/a952e2b4-d4b8-49ac-abd9-9967c50f4a80@stanley.mountain Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-03-03drm/tests: Drop drm_kunit_helper_acquire_ctx_alloc()Maxime Ripard
lockdep complains when a lock is released in a separate thread the lock is taken in, and it turns out that kunit does run its actions in a separate thread than the test ran in. This means that drm_kunit_helper_acquire_ctx_alloc() just cannot work as it's supposed to, so let's just get rid of it. Suggested-by: Simona Vetter <simona.vetter@ffwll.ch> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20250220132537.2834168-1-mripard@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-03-03drm/i915/fbc: handle dirty rect coords for the first frameVinod Govindapillai
During enabling FBC, for the very first frame, the prepare dirty rect routine wouldnt have executed as at that time the plane reference in the fbc_state would be NULL. So this could make driver program some invalid entries as the damage area. Though fbc hw ignores the dirty rect values programmed for the first frame after enabling FBC, driver must ensure that valid dirty rect coords are programmed. So ensure that for the first frame correct dirty rect coords are updated to the HW. Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250228093802.27091-10-vinod.govindapillai@intel.com
2025-03-03drm/i915/fbc: disable FBC if PSR2 selective fetch is enabledVinod Govindapillai
It is not recommended to have both FBC dirty rect and PSR2 selective fetch be enabled at the same time. Mark FBC as not possible, if PSR2 selective fetch is enabled. v2: fix the condition to disable FBC if PSR2 enabled (Jani) v3: use HAS_FBC_DIRTY_RECT() v4: Update to patch description Bspec: 68881 Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250228093802.27091-9-vinod.govindapillai@intel.com
2025-03-03drm/i915/fbc: dirty rect support for FBCVinod Govindapillai
Dirty rectangle feature allows FBC to recompress a subsection of a frame. When this feature is enabled, display will read the scan lines between dirty rectangle start line and dirty rectangle end line in subsequent frames. Use the merged damage clip stored in the plane state to configure the FBC dirty rect areas. v2: - Move dirty rect handling to fbc state (Ville) v3: - Use intel_fbc_dirty_rect_update_noarm (Ville) - Split plane damage collection and dirty rect preparation - Handle case where dirty rect fall outside the visible region v4: - A state variable to check if we need to update dirty rect registers in case intel_fbc_can_flip_nuke() (Ville) v5: - No need to use a separate valid flag, updates to the conditions for prepare damage rect (Ville) - Usage of locks in fbc dirty rect related functions (Ville) v6: - updates dirty rect handling (Ville) v7: - Loop through all planes in atomic state is good enough (Ville) Bspec: 68881, 71675, 73424 Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250228093802.27091-8-vinod.govindapillai@intel.com
2025-03-03drm/i915/fbc: avoid calling fbc activate if fbc is activeVinod Govindapillai
If FBC is already active, we don't need to call FBC activate routine again unless there are changes to the fences. So skip this on all platforms that don't have fences. Any FBC register updates done after enabling the dirty rect support in xe3 will trigger nuke by FBC which is counter productive to the fbc dirty rect feature. The front buffer rendering sequence will call intel_fbc_flush() and which will call intel_fbc_nuke() or intel_fbc_activate() based on FBC status explicitly and won't get impacted by this change. v2: use HAS_FBC_DIRTY_RECT() move this functionality within intel_fbc_activate() v3: update to intel_fbc_activate logic (Ville) update to the patch description Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250228093802.27091-7-vinod.govindapillai@intel.com
2025-03-03drm/i915/fbc: introduce HAS_FBC_DIRTY_RECT() for FBC dirty rect supportVinod Govindapillai
Introduce a macro to check if the platform supports FBC dirty rect capability. v2: - update to the patch subject Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250228093802.27091-6-vinod.govindapillai@intel.com
2025-03-03drm/i915/fbc: add register definitions for fbc dirty rect supportVinod Govindapillai
Register definitions for FBC dirty rect support v2: - update to the patch subject Bspec: 71675, 73424 Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250228093802.27091-5-vinod.govindapillai@intel.com
2025-03-03drm/i915/display: update and store the plane damage clipsVinod Govindapillai
Userspace can pass damage area clips per plane to track changes in a plane and some display components can utilze these damage clips for efficiently handling use cases like FBC, PSR etc. A merged damage area is generated and its coordinates are updated relative to viewport and HW and stored in the plane_state. This merged damage areas will be used for FBC dirty rect support in xe3 in the follow-up patch. Big thanks to Ville Syrjala for his contribuitions in shaping up of this series. v1: - Move damage_merged helper to cover bigjoiner case and use the correct plane state for damage find helper (Ville) - Damage handling code under HAS_FBC_DIRTY_RECT() so the the related part will be executed only for xe3+ - Changed dev_priv to i915 in one of the functions v2: - damage reported is stored in the plane state after coords adjustmentments irrespective of fbc dirty rect support. - Damage to be empty in case of plane not visible (Ville) - Handle fb could be NULL and plane not visible cases (Ville) v3: - No need to empty damage in case disp ver < 12 (Ville) - update to the patch subject Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250228093802.27091-4-vinod.govindapillai@intel.com
2025-03-03drm/damage-helper: add const qualifier in drm_atomic_helper_damage_merged()Vinod Govindapillai
Add a const qualifier for the "state" parameter as well as we could use this helper to get the combined damage in cases of const drm_plane_state as well. Needed mainly for xe driver big joiner cases where we need to track the damage from immutable plane state. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250228093802.27091-3-vinod.govindapillai@intel.com
2025-03-03drm/i915/fbc: remove one duplicate forward declarationVinod Govindapillai
Remove the duplicate "intel_display"declaration from intel_fbc.h Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250228093802.27091-2-vinod.govindapillai@intel.com
2025-03-03drm/imagination: Fix timestamps in firmware tracesAlessio Belle
When firmware traces are enabled, the firmware dumps 48-bit timestamps for each trace as two 32-bit values, highest 32 bits (of which only 16 useful) first. The driver was reassembling them the other way round i.e. interpreting the first value in memory as the lowest 32 bits, and the second value as the highest 32 bits (then truncated to 16 bits). Due to this, firmware trace dumps showed very large timestamps even for traces recorded shortly after GPU boot. The timestamps in these dumps would also sometimes jump backwards because of the truncation. Example trace dumped after loading the powervr module and enabling firmware traces, where each line is commented with the timestamp value in hexadecimal to better show both issues: [93540092739584] : Host Sync Partition marker: 1 // 0x551300000000 [28419798597632] : GPU units deinit // 0x19d900000000 [28548647616512] : GPU deinit // 0x19f700000000 Update logic to reassemble the timestamps halves in the correct order. Fixes: cb56cd610866 ("drm/imagination: Add firmware trace to debugfs") Signed-off-by: Alessio Belle <alessio.belle@imgtec.com> Reviewed-by: Matt Coster <matt.coster@imgtec.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250221-fix-fw-trace-timestamps-v1-1-dba4aeb030ca@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2025-03-03drm/imagination: only init job done fences onceBrendan King
Ensure job done fences are only initialised once. This fixes a memory manager not clean warning from drm_mm_takedown on module unload. Cc: stable@vger.kernel.org Fixes: eaf01ee5ba28 ("drm/imagination: Implement job submission and scheduling") Signed-off-by: Brendan King <brendan.king@imgtec.com> Reviewed-by: Matt Coster <matt.coster@imgtec.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250226-init-done-fences-once-v2-1-c1b2f556b329@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2025-03-03drm/imagination: Hold drm_gem_gpuva lock for unmapBrendan King
Avoid a warning from drm_gem_gpuva_assert_lock_held in drm_gpuva_unlink. The Imagination driver uses the GEM object reservation lock to protect the gpuva list, but the GEM object was not always known in the code paths that ended up calling drm_gpuva_unlink. When the GEM object isn't known, it is found by calling drm_gpuva_find to lookup the object associated with a given virtual address range, or by calling drm_gpuva_find_first when removing all mappings. Cc: stable@vger.kernel.org Fixes: 4bc736f890ce ("drm/imagination: vm: make use of GPUVM's drm_exec helper") Signed-off-by: Brendan King <brendan.king@imgtec.com> Reviewed-by: Matt Coster <matt.coster@imgtec.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250226-hold-drm_gem_gpuva-lock-for-unmap-v2-1-3fdacded227f@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2025-03-03drm/imagination: avoid deadlock on fence releaseBrendan King
Do scheduler queue fence release processing on a workqueue, rather than in the release function itself. Fixes deadlock issues such as the following: [ 607.400437] ============================================ [ 607.405755] WARNING: possible recursive locking detected [ 607.415500] -------------------------------------------- [ 607.420817] weston:zfq0/24149 is trying to acquire lock: [ 607.426131] ffff000017d041a0 (reservation_ww_class_mutex){+.+.}-{3:3}, at: pvr_gem_object_vunmap+0x40/0xc0 [powervr] [ 607.436728] but task is already holding lock: [ 607.442554] ffff000017d105a0 (reservation_ww_class_mutex){+.+.}-{3:3}, at: dma_buf_ioctl+0x250/0x554 [ 607.451727] other info that might help us debug this: [ 607.458245] Possible unsafe locking scenario: [ 607.464155] CPU0 [ 607.466601] ---- [ 607.469044] lock(reservation_ww_class_mutex); [ 607.473584] lock(reservation_ww_class_mutex); [ 607.478114] *** DEADLOCK *** Cc: stable@vger.kernel.org Fixes: eaf01ee5ba28 ("drm/imagination: Implement job submission and scheduling") Signed-off-by: Brendan King <brendan.king@imgtec.com> Reviewed-by: Matt Coster <matt.coster@imgtec.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250226-fence-release-deadlock-v2-1-6fed2fc1fe88@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2025-03-03drm/i915: split out i915_gtt_view_types.h from i915_vma_types.hJani Nikula
In the interest of limiting the display dependencies on i915 core headers, split out i915_gtt_view_types.h from i915_vma_types.h, and only include the new header from intel_display_types.h. Reuse the new header from xe compat code too, failing build if partial view is used in display code. Side note: Why would we ever have set enum i915_gtt_view_type values to size of each type?! What an insane hack. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/bb31885c32dbddad76d634c6fdb98a73b546b42e.1740412806.git.jani.nikula@intel.com
generated by cgit v1.2.3 (git 2.25.1) at 2026-03-11 03:42:46 +0000