summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-06-28drm/fourcc: Add RGB161616 and BGR161616 formatsJacopo Mondi
Add FourCC definitions for the 48-bit RGB/BGR formats to the DRM/KMS uapi. The format will be used by the Raspberry Pi PiSP Back End, supported by a V4L2 driver in kernel space and by libcamera in userspace, which uses the DRM FourCC identifiers. Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: Rob Clark <robin.clark@oss.qualcomm.com> Reviewed-by: Simon Ser <contact@emersion.fr> Reviewed-by: Naushir Patuck <naush@raspberrypi.com> Link: https://lore.kernel.org/r/20240226132544.82817-1-jacopo.mondi@ideasonboard.com Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
2025-06-27drm/format-helper: Split off byte swapping from drm_fb_xrgb8888_to_rgb565()Thomas Zimmermann
Move big-endian support from drm_fb_xrgb8888_to_rgb565() into the new helper drm_xrgb8888_to_rgb565be(). The functionality is required for displays with big-endian byte order. Update all callers. With the change applied, drm_fb_xrgb8888_to_rgb565() has the same signature as the other conversion functions, which is required for further updates to drm_fb_blit(). Also makes the format-conversion helper available to panic handlers, if necessary. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/20250625114911.1121301-1-tzimmermann@suse.de
2025-06-27drm/bridge: samsung-dsim: Use HZ_PER_MHZ macro from units.hPhilipp Zabel
Drop the custom MHZ macro and replace it with HZ_PER_MHZ. Reviewed-by: Alexander Stein <alexander.stein@ew.tq-group.com> Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de> Link: https://lore.kernel.org/r/20250527-samsung-dsim-v1-2-5be520d84fbb@pengutronix.de Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2025-06-27drm/bridge: samsung-dsim: use while loop in samsung_dsim_transfer_startPhilipp Zabel
Turn the open-coded goto-again construct into a while loop, to make samsung_dsim_transfer_start() a bit shorter and easier to read. Hold the spinlock when looping back around and avoid the duplicated list_empty() check. Reviewed-by: Alexander Stein <alexander.stein@ew.tq-group.com> Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de> Link: https://lore.kernel.org/r/20250527-samsung-dsim-v1-1-5be520d84fbb@pengutronix.de Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2025-06-27firmware: sysfb: Don't use "proxy" headersAndy Shevchenko
Update header inclusions to follow IWYU (Include What You Use) principle. Note that kernel.h is discouraged to be included as it's written at the top of that file. Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20250627103454.702606-1-andriy.shevchenko@linux.intel.com Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
2025-06-27drm/fourcc: Add 32b float formatsRob Clark
Add 1, 2, 3, and 4 component 32b float formats, so that buffers with these formats can be imported/exported with fourcc+modifier, and/or created by gbm. These correspond to PIPE_FORMAT_{R32,R32G32,R32G32B32,R32G32B32A32}_FLOAT in mesa. v2: Fix comment describing float32 layout [Sima] Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com> Acked-by: Simona Vetter <simona@ffwll.ch> Acked-by: Daniel Stone <daniels@collabora.com> Link: https://lore.kernel.org/r/20250625173712.116446-3-robin.clark@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2025-06-27drm/fourcc: Add missing half-float formatsRob Clark
Not something that is likely to be scanned out, but GPUs usually support half-float formats with 1, 2, or possibly 3 components, and it is useful to be able to import/export them with a valid fourcc, and/or use gbm to create them. These correspond to PIPE_FORMAT_{R16,R16G16,R16G16B16}_FLOAT in mesa. Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com> Acked-by: Simona Vetter <simona@ffwll.ch> Acked-by: Daniel Stone <daniels@collabora.com> Link: https://lore.kernel.org/r/20250625173712.116446-2-robin.clark@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2025-06-26drm/ttm, drm_xe, Implement ttm_lru_walk_for_evict() using the guarded LRU ↵Thomas Hellström
iteration To avoid duplicating the tricky bo locking implementation, Implement ttm_lru_walk_for_evict() using the guarded bo LRU iteration. To facilitate this, support ticketlocking from the guarded bo LRU iteration. v2: - Clean up some static function interfaces (Christian König) - Fix Handling -EALREADY from ticketlocking in the loop by skipping to the next item. (Intel CI) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://lore.kernel.org/r/20250623155313.4901-4-thomas.hellstrom@linux.intel.com
2025-06-26drm/ttm, drm/xe: Modify the struct ttm_bo_lru_walk_cursor initializationThomas Hellström
Instead of the struct ttm_operation_ctx, Pass a struct ttm_lru_walk_arg to enable us to easily extend the walk functionality, and to implement ttm_lru_walk_for_evict() using the guarded LRU iteration. Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://lore.kernel.org/r/20250623155313.4901-3-thomas.hellstrom@linux.intel.com
2025-06-26drm/ttm: Use a struct for the common part of struct ttm_lru_walk and struct ↵Thomas Hellström
ttm_bo_lru_cursor Let the locking functions take the new struct ttm_lru_walk_arg as argument in order for them to be easily used from both types of walk. v2: - Whitespace fix Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://lore.kernel.org/r/20250623155313.4901-2-thomas.hellstrom@linux.intel.com
2025-06-26drm/panel-edp: Add CMN N116BCJ-EAKLangyan Ye
Add support for the CMN N116BCJ-EAK, pleace the EDID here for subsequent reference. 00 ff ff ff ff ff ff 00 0d ae 63 11 00 00 00 00 19 22 01 04 95 1a 0e 78 02 67 75 98 59 53 90 27 1c 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 da 1d 56 e2 50 00 20 30 30 20 a6 00 00 90 10 00 00 18 00 00 00 fe 00 4e 31 31 36 42 43 4a 2d 45 41 4b 0a 20 00 00 00 fe 00 43 4d 4e 0a 20 20 20 20 20 20 20 20 20 00 00 00 fe 00 4e 31 31 36 42 43 4a 2d 45 41 4b 0a 20 00 80 Signed-off-by: Langyan Ye <yelangyan@huaqin.corp-partner.google.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20250626122854.193239-1-yelangyan@huaqin.corp-partner.google.com
2025-06-26drm/bridge: ti-sn65dsi86: remove unnecessary GPIO line direction checkBartosz Golaszewski
As of commit 92ac7de3175e3 ("gpiolib: don't allow setting values on input lines"), the GPIO core makes sure values cannot be set on input lines. Remove the unnecessary check. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20250620074951.32758-1-brgl@bgdev.pl
2025-06-26drm/bridge: add warning for bridges not using devm_drm_bridge_alloc()Luca Ceresoli
To the best of my knowledge, all drivers in the mainline kernel adding a DRM bridge are now converted to using devm_drm_bridge_alloc() for allocation and initialization. Among others this ensures initialization of the bridge refcount, allowing dynamic allocation lifetime. devm_drm_bridge_alloc() is now mandatory for all new bridges. Code using the old pattern ([devm_]kzalloc + filling the struct fields + drm_bridge_add) is not allowed anymore. Any drivers that might have been missed during the conversion, patches in flight towards mainline and out-of-tre drivers still using the old pattern will already be caught by a warning looking like: ------------[ cut here ]------------ refcount_t: addition on 0; use-after-free. WARNING: CPU: 2 PID: 83 at lib/refcount.c:25 refcount_warn_saturate+0x120/0x148 [...] Call trace: refcount_warn_saturate+0x120/0x148 (P) drm_bridge_get.part.0+0x70/0x98 [drm] drm_bridge_add+0x34/0x108 [drm] sn65dsi83_probe+0x200/0x480 [ti_sn65dsi83] [...] This warning comes from the refcount code and happens because drm_bridge_add() is increasing the refcount, which is uninitialized and thus initially zero. Having a warning and the corresponding stack trace is surely useful, but the warning text does not clarify the root problem nor how to fix it. Add a DRM_WARN() just before increasing the refcount, so the log will be much more readable: [drm] DRM bridge corrupted or not allocated by devm_drm_bridge_alloc() ------------[ cut here ]------------ refcount_t: addition on 0; use-after-free. [...etc...] A DRM_WARN is used because drm_warn and drm_WARN require a struct drm_device pointer which is not yet available when adding a bridge. Do not print the dev_name() in the warning because struct drm_bridge has no pointer to the struct device. The affected driver should be easy to catch based on the following stack trace however. Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://lore.kernel.org/r/20250620-drm-bridge-alloc-getput-drm-bridge-c-v9-3-ca53372c9a84@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2025-06-26drm/bridge: get/put the bridge reference in drm_bridge_attach/detach()Luca Ceresoli
drm_bridge_attach() adds the bridge to the encoder chain, so take a reference for that. Vice versa in drm_bridge_detach(). Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://lore.kernel.org/r/20250620-drm-bridge-alloc-getput-drm-bridge-c-v9-2-ca53372c9a84@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2025-06-26drm/bridge: get/put the bridge reference in drm_bridge_add/remove()Luca Ceresoli
drm_bridge_add() adds the bridge to the global bridge_list, so take a reference for that. Vice versa in drm_bridge_remove(). Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://lore.kernel.org/r/20250620-drm-bridge-alloc-getput-drm-bridge-c-v9-1-ca53372c9a84@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2025-06-26drm/tidss: Add OLDI bridge supportAradhya Bhatia
The AM62x and AM62Px SoCs feature 2 OLDI TXes each, which makes it possible to connect them in dual-link or cloned single-link OLDI display modes. The current OLDI support in tidss_dispc.c can only support for a single OLDI TX, connected to a VP and doesn't really support configuration of OLDIs in the other modes. The current OLDI support in tidss_dispc.c also works on the principle that the OLDI output can only be served by one, and only one, DSS video-port. This isn't the case in the AM62Px SoC, where there are 2 DSS controllers present that share the OLDI TXes. Having their own devicetree and their own bridge entity will help support the various display modes and sharing possiblilities of the OLDI hardware. For all these reasons, add support for the OLDI TXes as DRM bridges. Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com> Signed-off-by: Aradhya Bhatia <aradhya.bhatia@linux.dev> Tested-by: Michael Walle <mwalle@kernel.org> # on am67a Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://lore.kernel.org/r/20250528122544.817829-5-aradhya.bhatia@linux.dev Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
2025-06-26drm/tidss: Mark AM65x OLDI code separatelyAradhya Bhatia
The dss dt schema and the tidss driver have kept the single-link OLDI in AM65x integrated with the parent video-port (VP) from DSS (as the OLDI configuration happens from the source VP only). To help configure the dual-lvds modes that the OLDI has to offer in devices AM62x and later, a new OLDI bridge driver will be introduced. Mark the existing OLDI code separately by renaming all the current OLDI identifiers with the 'AM65X_' prefix in tidss driver, to help distinguish from the upcoming OLDI bridge driver. Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Aradhya Bhatia <aradhya.bhatia@linux.dev> Link: https://lore.kernel.org/r/20250528122544.817829-4-aradhya.bhatia@linux.dev Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
2025-06-26dt-bindings: display: ti: Add schema for AM625 OLDI TransmitterAradhya Bhatia
The OLDI transmitters (TXes) do not have registers of their own, and are dependent on the source video-ports (VPs) from the DSS to provide configuration data. This hardware doesn't directly sit on the internal bus of the SoC, but does so via the DSS. Hence, the OLDI TXes are supposed to be child nodes under the DSS, and not independent devices. Two of the OLDI TXes can function in tandem to output dual-link OLDI output, or cloned single-link outputs. In these cases, one OLDI will be the primary OLDI, and the other one, a companion. The following diagram represents such a configuration. +-----+-----+ +-------+ | | | | | | | VP1 +----+--->+ OLDI0 | (Primary - may need companion) | | | | | | | DSS +-----+ | +-------+ | | | | | | VP2 | | +-------+ | | | | | | +-----+-----+ +--->+ OLDI1 | (Companion OLDI) | | +-------+ The DSS in AM625 SoC has a configuration like the one above. The AM625 DSS VP1 (port@0) can connect and control 2 OLDI TXes, to use them in dual-link or cloned single-link OLDI modes. It is only the VP1 that can connect to either OLDI TXes for the AM625 DSS, and not the VP2. Alternatively, on some future TI SoCs, along with the above configuration, the OLDI TX can _also_ connect to separate video sources, making them work entirely independent of each other. In this case, neither of the OLDIs are "companion" or "secondary" OLDIs, and nor do they require one. They both are independent and primary OLDIs. The following diagram represents such a configuration. +-----+-----+ +-------+ | | | | | | | VP1 +--+----------->+ OLDI0 | (Primary - may need companion) | | | | | | | +-----+ | +-------+ | | | | | | VP2 | | | | | | | DSS +-----+ | +---+ +-------+ | | | +-->+ M | | | | | VP3 +----->+ U +--->+ OLDI1 | (Companion or Primary) | | | | X | | | | +-----+ +---+ +-------+ | | | | | VP4 | | | | +-----+-----+ Note that depending on the mux configuration, the OLDIs can either be working together in tandem - sourced by VP1, OR, they could be working independently sourced by VP1 and VP3 respectively. The idea is to support all the configurations with this OLDI TX schema. The OLDI functionality is further supported by a system-control module, which contains a few registers to control OLDI IO power and other electrical characteristics of the IO lanes. Add devicetree binding schema for the OLDI TXes to support various configurations, and extend their support to the AM625 DSS. Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com> Signed-off-by: Aradhya Bhatia <aradhya.bhatia@linux.dev> Reviewed-by: "Rob Herring (Arm)" <robh@kernel.org> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://lore.kernel.org/r/20250528122544.817829-3-aradhya.bhatia@linux.dev Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
2025-06-26dt-bindings: display: ti,am65x-dss: Re-indent the exampleAradhya Bhatia
Reduce tab size from 8 spaces to 4 spaces to make the bindings consistent, and easy to expand. Acked-by: "Rob Herring (Arm)" <robh@kernel.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com> Signed-off-by: Aradhya Bhatia <aradhya.bhatia@linux.dev> Link: https://lore.kernel.org/r/20250528122544.817829-2-aradhya.bhatia@linux.dev Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
2025-06-25drm/nouveau/disp: Use dev->dev to get the deviceSakari Ailus
The local variable dev points to drm->dev already, use dev directly. Link: https://lore.kernel.org/r/20250409103344.3661603-1-sakari.ailus@linux.intel.com Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-06-23drm/connector: move HDR sink metadata to display infoJani Nikula
Information parsed from the display EDID should be stored in display info. Move HDR sink metadata there. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250519112900.1383997-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-06-23drm/ci: Add jobs to run KUnit testsVignesh Raman
Add jobs to run KUnit tests using tools/testing/kunit/kunit.py tool. Signed-off-by: Vignesh Raman <vignesh.raman@collabora.com> Acked-by: Helen Koike <helen.fornazier@gmail.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://lore.kernel.org/r/20250623085033.39680-3-vignesh.raman@collabora.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-06-23drm/ci: Add jobs to validate devicetreesVignesh Raman
Add jobs to run dt_binding_check and dtbs_check. If warnings are seen, exit with a non-zero error code while configuring them as warning in the GitLab CI pipeline. Signed-off-by: Vignesh Raman <vignesh.raman@collabora.com> Acked-by: Helen Koike <helen.fornazier@gmail.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Acked-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250623085033.39680-2-vignesh.raman@collabora.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-06-23drm/bochs: Add support for drm_panicRyosuke Yasuoka
Add drm_panic module for bochs drm so that panic screen can be displayed on panic. Signed-off-by: Ryosuke Yasuoka <ryasuoka@redhat.com> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/20250613132023.106946-1-ryasuoka@redhat.com Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
2025-06-20arm64: dts: mediatek: mt8370: Enable gpu supportLouis-Alexis Eyraud
Add a new gpu node in mt8370.dtsi to enable support for the ARM Mali G57 MC2 GPU (Valhall-JM) found on the MT8370 SoC, using the Panfrost driver. On a Mediatek Genio 510 EVK board, the panfrost driver probed with the following message: ``` panfrost 13000000.gpu: clock rate = 390000000 panfrost 13000000.gpu: mali-g57 id 0x9093 major 0x0 minor 0x0 status 0x0 panfrost 13000000.gpu: features: 00000000,000019f7, issues: 00000003, 80000400 panfrost 13000000.gpu: Features: L2:0x08130206 Shader:0x00000000 Tiler:0x00000809 Mem:0x1 MMU:0x00002830 AS:0xff JS:0x7 panfrost 13000000.gpu: shader_present=0x5 l2_present=0x1 [drm] Initialized panfrost 1.3.0 for 13000000.gpu on minor 0 ``` Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://lore.kernel.org/r/20250509-mt8370-enable-gpu-v6-5-2833888cb1d3@collabora.com
2025-06-20drm/panfrost: Add support for Mali on the MT8370 SoCLouis-Alexis Eyraud
Add a compatible for the MediaTek MT8370 SoC, with an integrated ARM Mali G57 MC2 GPU (Valhall-JM, dual core), with new platform data for its support in the panfrost driver. It uses the same data as MT8186 for the power management features to describe power supplies, pm_domains and enablement (one regulator, two power domains) but also sets the FORCE_AARCH64_PGTABLE flag in the GPU configuration quirks bitfield to enable AARCH64 4K page table format mode. As MT8186 and MT8370 SoC have different GPU architecture (Mali G52 2EE MC2 for MT8186), making them not compatible, and this mode is only enabled for Mediatek SoC that are Mali G57 based (compatible with mediatek,mali-mt8188 or mediatek,mali-8192), having specific platform data allows to set this flag for MT8370 without modifying MT8186 configuration and behaviour. Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://lore.kernel.org/r/20250509-mt8370-enable-gpu-v6-4-2833888cb1d3@collabora.com
2025-06-20drm/panfrost: Commonize Mediatek power domain array definitionsLouis-Alexis Eyraud
In the panfrost driver, the platform data of several Mediatek SoC declares and uses several different power domains arrays according to GPU core number present in the SoC: - mediatek_mt8186_pm_domains (2 cores) - mediatek_mt8183_pm_domains (3 cores) - mediatek_mt8192_pm_domains (5 cores) As they all are fixed arrays, starting with the same entries and the platform data also has a power domains array length field (num_pm_domains), they can be replaced by a single array, containing all entries, if the num_pm_domains field of the platform data is also set to the matching core number. So, create a generic power domain array (mediatek_pm_domains) and use it in the mt8183(b), mt8186, mt8188 and mt8192 platform data instead. Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://lore.kernel.org/r/20250509-mt8370-enable-gpu-v6-3-2833888cb1d3@collabora.com
2025-06-20drm/panfrost: Drop duplicated Mediatek supplies arraysLouis-Alexis Eyraud
In the panfrost driver, the platform data of several Mediatek SoC declares and uses custom supplies array definitions (mediatek_mt8192_supplies, mediatek_mt8183_b_supplies), that are the same as default_supplies (used by default platform data). So drop these duplicated definitions and use default_supplies instead. Also, rename mediatek_mt8183_supplies to a more generic name too (legacy_supplies). Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://lore.kernel.org/r/20250509-mt8370-enable-gpu-v6-2-2833888cb1d3@collabora.com
2025-06-20dt-bindings: gpu: mali-bifrost: Add compatible for MT8370 SoCLouis-Alexis Eyraud
Add a compatible for the MediaTek MT8370 SoC, with an integrated ARM Mali G57 MC2 GPU (Valhall-JM, dual core). None of the already existing SoC specific compatibles is usable as fallback, as those either do not match the number of cores (and number of power domains), or are for a different GPU architecture. Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://lore.kernel.org/r/20250509-mt8370-enable-gpu-v6-1-2833888cb1d3@collabora.com
2025-06-19drm/bridge: tc358767: convert to devm_drm_bridge_alloc() APILuca Ceresoli
This is the new API for allocating DRM bridges. Converting this driver is a bit complex because the drm_bridge funcs pointer differs based on the bridge mode. So the current code does: * tc_probe() * devm_kzalloc() private struct embedding drm_bridge * call tc_probe_bridge_endpoint() which * parses DT description into struct fields * computes the mode * calls different bridge init functions based on the mode * each sets a different bridge.funcs pointer The new API expects the funcs pointer to be known at alloc time, which does not fit in the current code structure. Solve this by splitting tc_probe_bridge_endpoint() in two functions: * tc_probe_get_mode(), computing the mode without needing the private driver structure * tc_probe_bridge_endpoint(), only initializing the endpoints So now the mode is known before allocation and so is the funcs pointer, while all other operations are still happening after allocation, directly into the private struct data, as they used to. The new code flow is: * tc_probe() * tc_probe_get_mode() * parses DT description * computes and returns the mode * based onf the mode, pick the funcs pointer * devm_drm_bridfge_alloc(..., funcs) * call tc_probe_bridge_endpoint() which * calls different bridge init functions based on the mode * these don't set the funcs pointer, it was done by _alloc This solution is chosen to minimize the changes in the driver logical code flow. The drawback is we now iterate twice over the endpoints during probe. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250528-drm-bridge-convert-to-alloc-api-v4-1-f04e698c9a77@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2025-06-18drm/format-helper: Move drm_fb_build_fourcc_list() to sysfb helpersThomas Zimmermann
Only sysfb drivers use drm_fb_build_fourcc_list(). Move the function to sysfb helpers and rename it accordingly. Update drivers and tests. v3: - update naming in tests v2: - select DRM_SYSFB_HELPER (kernel test robot) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: José Expósito <jose.exposito89@gmail.com> Acked-by: Maxime Ripard <mripard@kernel.org> Acked-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20250616083846.221396-4-tzimmermann@suse.de
2025-06-18drm/tests: Test drm_fb_build_fourcc_list() in separate test suiteThomas Zimmermann
Only sysfb drivers use drm_fb_build_fourcc_list(). The helper will be moved from format helpers to sysfb helpers. Moving the related tests to their own test suite. v3: - rename tests according to filename (José) v2: - rename filename to match tested code (Maxime) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: José Expósito <jose.exposito89@gmail.com> Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://lore.kernel.org/r/20250616083846.221396-3-tzimmermann@suse.de
2025-06-18drm/tests: Do not use drm_fb_blit() in format-helper testsThomas Zimmermann
Export additional helpers from the format-helper library and open-code drm_fb_blit() in tests. Prepares for the removal of drm_fb_blit(). Only sysfb drivers use drm_fb_blit(). The function will soon be removed from format helpers and be refactored within sysfb helpers. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: José Expósito <jose.exposito89@gmail.com> Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://lore.kernel.org/r/20250616083846.221396-2-tzimmermann@suse.de
2025-06-17drm/vmwgfx: Fix Host-Backed userspace on Guest-Backed kernelIan Forbes
Running 3D applications with SVGA_FORCE_HOST_BACKED=1 or using an ancient version of mesa was broken because the buffer was pinned in VMW_BO_DOMAIN_SYS and could not be moved to VMW_BO_DOMAIN_MOB during validation. The compat_shader buffer should not pinned. Fixes: 668b206601c5 ("drm/vmwgfx: Stop using raw ttm_buffer_object's") Signed-off-by: Ian Forbes <ian.forbes@broadcom.com> Reviewed-by: Maaz Mombasawala <maaz.mombasawala@broadcom.com> Signed-off-by: Zack Rusin <zack.rusin@broadcom.com> Link: https://lore.kernel.org/r/20250429203427.1742331-1-ian.forbes@broadcom.com
2025-06-17drm/vmwgfx: Implement dma_fence_ops properlyIan Forbes
vmwgfx's fencing predates dma_fence and as a result dma_fence_ops was never properly implemented, especially with respect to enabling signaling. Because of this dma_fence callbacks don't work properly. This change implements enable_signaling properly so that dma_fence callbacks now work as expected. It also removes vmwgfx's custom implementation of fence callbacks and removes vmwgfx's custom dma_fence_ops::wait function which is no longer necessary now that enable_signaling works. Signed-off-by: Ian Forbes <ian.forbes@broadcom.com> Signed-off-by: Zack Rusin <zack.rusin@broadcom.com> Link: https://lore.kernel.org/r/20250530183510.733175-2-ian.forbes@broadcom.com
2025-06-17drm/vmwgfx: Update last_read_seqno under the fence lockIan Forbes
There was a possible race in vmw_update_seqno. Because of this race it was possible for last_read_seqno to go backwards. Remove this function and replace it with vmw_update_fences which now sets and returns the last_read_seqno while holding the fence lock. This serialization via the fence lock ensures that last_read_seqno is monotonic again. Signed-off-by: Ian Forbes <ian.forbes@broadcom.com> Signed-off-by: Zack Rusin <zack.rusin@broadcom.com> Link: https://lore.kernel.org/r/20250530183510.733175-1-ian.forbes@broadcom.com
2025-06-17drm/amdgpu: Make use of drm_wedge_task_infoAndré Almeida
To notify userspace about which task (if any) made the device get in a wedge state, make use of drm_wedge_task_info parameter, filling it with the task PID and name. Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://lore.kernel.org/r/20250617124949.2151549-7-andrealmeid@igalia.com Signed-off-by: André Almeida <andrealmeid@igalia.com>
2025-06-17drm: amdgpu: Use struct drm_wedge_task_info inside of struct amdgpu_task_infoAndré Almeida
To avoid a cast when calling drm_dev_wedged_event(), replace pid and task name inside of struct amdgpu_task_info with struct drm_wedge_task_info. Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://lore.kernel.org/r/20250617124949.2151549-6-andrealmeid@igalia.com Signed-off-by: André Almeida <andrealmeid@igalia.com>
2025-06-17drm/doc: Add a section about "Task information" for the wedge APIAndré Almeida
Add a section about "Task information" for the wedge API. Reviewed-by: Krzysztof Karas <krzysztof.karas@intel.com> Reviewed-by: Raag Jadav <raag.jadav@intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://lore.kernel.org/r/20250617124949.2151549-5-andrealmeid@igalia.com Signed-off-by: André Almeida <andrealmeid@igalia.com>
2025-06-17drm: Create a task info option for wedge eventsAndré Almeida
When a device get wedged, it might be caused by a guilty application. For userspace, knowing which task was involved can be useful for some situations, like for implementing a policy, logs or for giving a chance for the compositor to let the user know what task was involved in the problem. This is an optional argument, when the task info is not available, the PID and TASK string won't appear in the event string. Sometimes just the PID isn't enough giving that the task might be already dead by the time userspace will try to check what was this PID's name, so to make the life easier also notify what's the task's name in the user event. Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Krzysztof Karas <krzysztof.karas@intel.com> Reviewed-by: Raag Jadav <raag.jadav@intel.com> Acked-by: Christian König <christian.koenig@amd.com> Link: https://lore.kernel.org/r/20250617124949.2151549-4-andrealmeid@igalia.com Signed-off-by: André Almeida <andrealmeid@igalia.com>
2025-06-17drm: amdgpu: Create amdgpu_vm_print_task_info()André Almeida
To avoid repetitive code in amdgpu, create a function that prints the content of struct amdgpu_task_info. Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://lore.kernel.org/r/20250617124949.2151549-3-andrealmeid@igalia.com Signed-off-by: André Almeida <andrealmeid@igalia.com>
2025-06-17drm: amdgpu: Allow NULL pointers at amdgpu_vm_put_task_info()André Almeida
Allow NULL pointers at amdgpu_vm_put_task_info() as it common practice for "put" or "free" functions. This avoid an extra check for NULL for callers. Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://lore.kernel.org/r/20250617124949.2151549-2-andrealmeid@igalia.com Signed-off-by: André Almeida <andrealmeid@igalia.com>
2025-06-16accel/amdxdna: Revise device bo creation and freeLizhi Hou
The device bo is allocated from the device heap memory. (a trunk of memory dedicated to device) Rename amdxdna_gem_insert_node_locked to amdxdna_gem_heap_alloc and move related sanity checks into it. Add amdxdna_gem_dev_obj_free and move device bo free code into it. Calculate the kernel virtual address of device bo by the device heap memory address and offset. Reviewed-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> Signed-off-by: Lizhi Hou <lizhi.hou@amd.com> Link: https://lore.kernel.org/r/20250616091418.2605476-1-lizhi.hou@amd.com
2025-06-16drm/bridge: ti-sn65dsi86: use new GPIO line value setter callbacksBartosz Golaszewski
struct gpio_chip now has callbacks for setting line values that return an integer, allowing to indicate failures. Convert the driver to using them. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20250610-gpiochip-set-rv-gpu-v1-1-ac0a21e74b71@linaro.org
2025-06-16drm/bridge: ti-sn65dsi86: use the auxiliary deviceJerome Brunet
The auxiliary device creation of this driver is simple enough to use the available auxiliary device creation helper. Use it and remove some boilerplate code. Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20250218-aux-device-create-helper-v4-3-c3d7dfdea2e6@baylibre.com
2025-06-16accel/ivpu: Add turbo flag to the DRM_IVPU_CMDQ_CREATE ioctlAndrzej Kacprowski
Introduce a new parameter to the DRM_IVPU_CMDQ_CREATE ioctl, enabling turbo mode for jobs submitted via the command queue. Turbo mode allows jobs to run at higher frequencies, potentially improving performance for demanding workloads. Also adds the IVPU_TEST_MODE_TURBO_DISABLE flag to allow test mode to explicitly disable turbo mode requested by the application. The IVPU_TEST_MODE_TURBO mode has been renamed to IVPU_TEST_MODE_TURBO_ENABLE for clarity and consistency. Signed-off-by: Andrzej Kacprowski <Andrzej.Kacprowski@intel.com> Signed-off-by: Maciej Falkowski <maciej.falkowski@linux.intel.com> Reviewed-by: Jeff Hugo <jeff.hugo@oss.qualcomm.com> Signed-off-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> Link: https://lore.kernel.org/r/20250605162001.1237789-1-maciej.falkowski@linux.intel.com
2025-06-16accel/ivpu: Add initial Wildcat Lake supportMaciej Falkowski
Add support for Wildcat Lake (WCL) CPUs. Wildcat Lake contains NPU5 just like Panther Lake hence the initial support is very simple and adds only PCI IDs. Signed-off-by: Maciej Falkowski <maciej.falkowski@linux.intel.com> Reviewed-by: Jeff Hugo <jeff.hugo@oss.qualcomm.com> Signed-off-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> Link: https://lore.kernel.org/r/20250605161947.1237727-1-maciej.falkowski@linux.intel.com
2025-06-16video: Make global edid_info depend on CONFIG_FIRMWARE_EDIDThomas Zimmermann
Protect global edid_info behind CONFIG_FIRMWARE_EDID and remove the config tests for CONFIG_X86. Makes edid_info available iff its option has been enabled. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Helge Deller <deller@gmx.de> Link: https://lore.kernel.org/r/20250602075537.137759-3-tzimmermann@suse.de
2025-06-16video: Make CONFIG_FIRMWARE_EDID generally availableThomas Zimmermann
DRM drivers such as efidrm and vesadrm can export firmware EDID data to userspace. Make the related option CONFIG_FIRMWARE_EDID available without CONFIG_FB. Make it depend on X86, which is currently the only architecture providing EDID information. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Helge Deller <deller@gmx.de> Link: https://lore.kernel.org/r/20250602075537.137759-2-tzimmermann@suse.de
2025-06-16fbdev/viafb: Do not include <linux/export.h>Thomas Zimmermann
Fix the compile-time warning drivers/video/fbdev/via/via-gpio.c: warning: EXPORT_SYMBOL() is not used, but #include <linux/export.h> is present Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Helge Deller <deller@gmx.de> Fixes: 7d95680d64ac ("scripts/misc-check: check unnecessary #include <linux/export.h> when W=1") Cc: Masahiro Yamada <masahiroy@kernel.org> Cc: Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20250612081738.197826-15-tzimmermann@suse.de
generated by cgit (git 2.34.1) at 2025-09-08 18:10:47 +0000