summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-06-06drm/bridge: cdns-dsi: Use pre_enable/post_disable to enable/disableAradhya Bhatia
The cdns-dsi controller requires that it be turned on completely before the input DPI's source has begun streaming[0]. Not having that, allows for a small window before cdns-dsi enable and after cdns-dsi disable where the previous entity (in this case tidss's videoport) to continue streaming DPI video signals. This small window where cdns-dsi is disabled but is still receiving signals causes the input FIFO of cdns-dsi to get corrupted. This causes the colors to shift on the output display. The colors can either shift by one color component (R->G, G->B, B->R), or by two color components (R->B, G->R, B->G). Since tidss's videoport starts streaming via crtc enable hooks, we need cdns-dsi to be up and running before that. Now that the bridges are pre_enabled before crtc is enabled, and post_disabled after crtc is disabled, use the pre_enable and post_disable hooks to get cdns-dsi ready and running before the tidss videoport to get pass the color shift issues. [0]: See section 12.6.5.7.3 "Start-up Procedure" in J721E SoC TRM TRM Link: http://www.ti.com/lit/pdf/spruil1 Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Tested-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> Tested-by: Devarsh Thakkar <devarsht@ti.com> Link: https://lore.kernel.org/r/20250605171524.27222-5-aradhya.bhatia@linux.dev Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-06-06drm/atomic-helper: Re-order bridge chain pre-enable and post-disableAradhya Bhatia
Move the bridge pre_enable call before crtc enable, and the bridge post_disable call after the crtc disable. The sequence of enable after this patch will look like: bridge[n]_pre_enable ... bridge[1]_pre_enable crtc_enable encoder_enable bridge[1]_enable ... bridge[n]_enable And, the disable sequence for the display pipeline will look like: bridge[n]_disable ... bridge[1]_disable encoder_disable crtc_disable bridge[1]_post_disable ... bridge[n]_post_disable The definition of bridge pre_enable hook says that, "The display pipe (i.e. clocks and timing signals) feeding this bridge will not yet be running when this callback is called". Since CRTC is also a source feeding the bridge, it should not be enabled before the bridges in the pipeline are pre_enabled. Fix that by re-ordering the sequence of bridge pre_enable and bridge post_disable. While at it, update the drm bridge API documentation as well. Acked-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Tested-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Tested-by: Alexander Sverdlin <alexander.sverdlin@siemens.com> Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com> Signed-off-by: Aradhya Bhatia <aradhya.bhatia@linux.dev> Tested-by: Devarsh Thakkar <devarsht@ti.com> Link: https://lore.kernel.org/r/20250605171524.27222-4-aradhya.bhatia@linux.dev Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-06-06drm/atomic-helper: Separate out bridge pre_enable/post_disable from ↵Aradhya Bhatia
enable/disable The encoder-bridge ops occur by looping over the new connector states of the display pipelines. The enable sequence runs as follows - - pre_enable(bridge), - enable(encoder), - enable(bridge), while the disable sequnce runs as follows - - disable(bridge), - disable(encoder), - post_disable(bridge). Separate out the pre_enable(bridge), and the post_disable(bridge) operations into separate functions each. This patch keeps the sequence same for any singular disaplay pipe, but changes the sequence across multiple display pipelines. This patch is meant to be an interim patch, to cleanly pave the way for the sequence re-ordering patch, and maintain bisectability in the process. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Jayesh Choudhary <j-choudhary@ti.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Tested-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Tested-by: Alexander Sverdlin <alexander.sverdlin@siemens.com> Signed-off-by: Aradhya Bhatia <aradhya.bhatia@linux.dev> Tested-by: Devarsh Thakkar <devarsht@ti.com> Link: https://lore.kernel.org/r/20250605171524.27222-3-aradhya.bhatia@linux.dev Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-06-06drm/atomic-helper: Refactor crtc & encoder-bridge op loops into separate ↵Aradhya Bhatia
functions The way any singular display pipeline, in need of a modeset, gets enabled is as follows - crtc enable (all) bridge pre-enable encoder enable (all) bridge enable - and the disable sequence is exactly the reverse of this. The crtc operations occur by looping over the old and new crtc states, while the encoder and bridge operations occur together, by looping over the connector states of the display pipelines. Refactor these operations - crtc enable/disable, and encoder & bridge (pre/post) enable/disable - into separate functions each, to make way for the re-ordering of the enable/disable sequences. This patch doesn't alter the sequence of crtc/encoder/bridge operations in any way, but helps to cleanly pave the way for the next two patches, by maintaining logical bisectability. Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Tested-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Tested-by: Alexander Sverdlin <alexander.sverdlin@siemens.com> Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com> Signed-off-by: Aradhya Bhatia <aradhya.bhatia@linux.dev> Tested-by: Devarsh Thakkar <devarsht@ti.com> Link: https://lore.kernel.org/r/20250605171524.27222-2-aradhya.bhatia@linux.dev Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-06-06drm/panthor: Clean up 64-bit register definitionsKarunika Choo
With the introduction of 64-bit register accessors, the separate *_HI definitions are no longer necessary. This change removes them and renames the corresponding *_LO entries for cleaner and more consistent register definitions. Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Suggested-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Karunika Choo <karunika.choo@arm.com> Link: https://lore.kernel.org/r/20250606101835.41840-3-boris.brezillon@collabora.com Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
2025-06-06drm/panthor: Add 64-bit and poll register accessorsKarunika Choo
This patch adds 64-bit register accessors to simplify register access in Panthor. It also adds 32-bit and 64-bit variants for read_poll_timeout. This patch also updates Panthor to use the new 64-bit accessors and poll functions. Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Karunika Choo <karunika.choo@arm.com> Link: https://lore.kernel.org/r/20250606101835.41840-2-boris.brezillon@collabora.com Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
2025-06-06drm/panthor: Fix the user MMIO offset logic for emulatorsBoris Brezillon
Currently, we pick the MMIO offset based on the size of the pgoff_t type seen by the process that manipulates the FD, such that a 32-bit process can always map the user MMIO ranges. But this approach doesn't work well for emulators like FEX, where the emulator is a 64-bit binary which might be executing 32-bit code. In that case, the kernel thinks it's the 64-bit process and assumes DRM_PANTHOR_USER_MMIO_OFFSET_64BIT is in use, but the UMD library expects DRM_PANTHOR_USER_MMIO_OFFSET_32BIT, because it can't mmap() anything above the pgoff_t size. In order to solve that, we need a way to explicitly set the user MMIO offset from the UMD, such that the kernel doesn't have to guess it from the TIF_32BIT flag set on user thread. We keep the old behavior if DRM_PANTHOR_SET_USER_MMIO_OFFSET is never called. Changes in v2: - Drop the lock/immutable fields and allow SET_USER_MMIO_OFFSET requests to race with mmap() requests - Don't do the is_user_mmio_offset test twice in panthor_mmap() - Improve the uAPI docs Changes in v3: - Bump to version 1.5 instead of 1.4 after rebasing - Add R-bs - Fix/rephrase comment as suggested by Liviu Reviewed-by: Adrián Larumbe <adrian.larumbe@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://lore.kernel.org/r/20250606080932.4140010-3-boris.brezillon@collabora.com Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
2025-06-06drm/panthor: Add missing explicit padding in drm_panthor_gpu_infoBoris Brezillon
drm_panthor_gpu_info::shader_present is currently automatically offset by 4 byte to meet Arm's 32-bit/64-bit field alignment rules, but those constraints don't stand on 32-bit x86 and cause a mismatch when running an x86 binary in a user emulated environment like FEX. It's also generally agreed that uAPIs should explicitly pad their struct fields, which we originally intended to do, but a mistake slipped through during the submission process, leading drm_panthor_gpu_info::shader_present to be misaligned. This uAPI change doesn't break any of the existing users of panthor which are either arm32 or arm64 where the 64-bit alignment of u64 fields is already enforced a the compiler level. Changes in v2: - Rename the garbage field into pad0 and adjust the comment accordingly - Add Liviu's A-b Changes in v3: - Add R-bs Fixes: 0f25e493a246 ("drm/panthor: Add uAPI") Acked-by: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Adrián Larumbe <adrian.larumbe@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Link: https://lore.kernel.org/r/20250606080932.4140010-2-boris.brezillon@collabora.com Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
2025-06-05drm/hyperv: Add support for drm_panicRyosuke Yasuoka
Add drm_panic module for hyperv 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/20250526090117.80593-2-ryasuoka@redhat.com Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
2025-06-05drm/panel-edp: Clarify the `prepare_to_enable` description in commentsDouglas Anderson
It's unclear why I originally wrote in the description of `prepare_to_enable` that "This is not specified in a standard way on eDP timing diagrams" and then also wrote "It is effectively the time from HPD going high till you can turn on the backlight." It seems pretty clear that it's (T4+T5+T6+T8)-min. Either I was confused when I wrote this or I was looking at some strange panel datasheet that I can no longer find. Update the description of the field so it's easier for people to fill this in. Couch the description with "usually" in case there really was some weird datasheet where things were specified in a different way. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20250521173204.1.Ic0375a9360698592f27afbf1f60f4996d504ed4f@changeid
2025-06-05drm/panel: himax-hx8394: Add Support for Huiling hl055fhav028cChris Morgan
Add support for the Huiling hl055fhav028c panel as used on the Gameforce Ace handheld gaming console. This panel uses a Himax HX8399C display controller and requires a sparsely documented vendor provided init sequence. The display resolution is 1080x1920 and is 70mm by 127mm as stated in the manufacturer's documentation. Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20250603193930.323607-2-macroalpha82@gmail.com
2025-06-05dt-bindings: display: himax-hx8394: Add Huiling hl055fhav028cChris Morgan
Add compatible string for the Huiling hl055fhav028c. This panel is based on the Himax HX8399C display controller which is extremely similar to the existing HX8394. Add a new constant for himax,hx8399c for this new display controller as well. Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20250603193930.323607-3-macroalpha82@gmail.com
2025-06-05dt-bindings: vendor-prefixes: Add prefix for HuilingChris Morgan
Shenzhen Huiling Information Technology Co. Ltd. specializes in the research and manufacturing of display and touch screens for industrial usage. https://en.szhuiling.com/ Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20250603193930.323607-2-macroalpha82@gmail.com
2025-06-05drm/panel-simple: add AUO P238HAN01 panel entryMichael Walle
Timings taken from the datasheet and the display is working in DE mode, thus the datasheet only specifies the blanking period. sync, back porch and front porch are arbitrarily chosen. The datasheet can be found at [1] but for reference these are the relevant timings: sym | | min | typ | max | unit | ------|--------------+------+------+------+------+ Tv | V period | 1094 | 1130 | 1836 | Th | | V active | 1080 | 1080 | 1080 | Th | | V blanking | 14 | 50 | 756 | Th | Fv | V frequency | 49 | 60 | 76 | Hz | Th | H period | 1000 | 1050 | 1678 | Tclk | | H active | 960 | 960 | 960 | Tclk | | H blanking | 40 | 90 | 718 | Tclk | Fh | H frequency | 53.7 | 67.8 | 90.0 | kHz | Tclk | LVDS clock | 53.7 | 71.2 | 90.0 | MHz | Keep in mind that this is a dual link LVDS panel and the horizontal timings are only for one half of the panel. [1] https://www.fortec-integrated.de/fileadmin/pdf/produkte/TFT-Displays/AUO/P238HAN01.0_Datasheet.pdf Signed-off-by: Michael Walle <mwalle@kernel.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20250520074439.655749-2-mwalle@kernel.org
2025-06-05dt-bindings: display: simple: add AUO P238HAN01 panelMichael Walle
Add AUO P238HAN01 23.8" 1920x1080 LVDS panel compatible string. Signed-off-by: Michael Walle <mwalle@kernel.org> Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20250520074439.655749-1-mwalle@kernel.org
2025-06-05drm/panel: ili9341: Remove unused member from struct ili9341Andy Shevchenko
struct device *dev from struct ili9341 is not used anywhere, remove it. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20250519133345.257138-1-andriy.shevchenko@linux.intel.com
2025-06-05MAINTAINERS: Update my email address for DRM Panel reviewsJessica Zhang
Update my email with *.qualcomm.com address Signed-off-by: Jessica Zhang <jessica.zhang@oss.qualcomm.com> Acked-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20250603-panel-maintainer-update-v1-1-224aaa222d99@oss.qualcomm.com
2025-06-05drm/ttm: handle undefined printf arg evaluation order in debugfsDave Airlie
When you read this debugfs file it's isn't guaranteed the count will happen before the scan, but I think the intent is that it does. printf argument evaluation order is undefined. Cc: Christian Koenig <christian.koenig@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://lore.kernel.org/r/20250603220901.1217161-1-airlied@gmail.com
2025-06-04drm/ttm: Fix build with CONFIG_DEBUG_FS=nLucas De Marchi
Move the define outside the ifdef for CONFIG_DEBUG_FS to fix the build. This currently breaks drm kunit tests: $ ./tools/testing/kunit/kunit.py run --kunitconfig drivers/gpu/drm/ttm/tests/.kunitconfig ERROR:root:../drivers/gpu/drm/ttm/ttm_pool.c: In function ‘ttm_pool_mgr_init’: ../drivers/gpu/drm/ttm/ttm_pool.c:1335:30: error: ‘TTM_SHRINKER_BATCH’ undeclared (first use in this function) 1335 | mm_shrinker->batch = TTM_SHRINKER_BATCH; Fixes: 22b929b25293 ("drm/ttm: Increase pool shrinker batch target") Cc: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Christian König <christian.koenig@amd.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20250603184750.3304647-2-lucas.demarchi@intel.com
2025-06-04ttm/pool: allow debugfs dumps for numa pools.Dave Airlie
Currently you can't see per-device numa aware pools properly. Cc: Christian König <christian.koenig@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://lore.kernel.org/r/20250602204013.1104258-1-airlied@gmail.com
2025-06-03drm/i915: Use dma-fence driver and timeline name helpersTvrtko Ursulin
Access the dma-fence internals via the previously added helpers. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20250515095004.28318-6-tvrtko.ursulin@igalia.com
2025-06-03sync_file: Use dma-fence driver and timeline name helpersTvrtko Ursulin
Access the dma-fence internals via the previously added helpers. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20250515095004.28318-5-tvrtko.ursulin@igalia.com
2025-06-03dma-fence: Add helpers for accessing driver and timeline nameTvrtko Ursulin
Add some helpers in order to enable preventing dma-fence users accessing the implementation details directly and make the implementation itself use them. This will also enable later adding some asserts to a consolidated location. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20250515095004.28318-4-tvrtko.ursulin@igalia.com
2025-06-03dma-fence: Use a flag for 64-bit seqnosTvrtko Ursulin
With the goal of reducing the need for drivers to touch (and dereference) fence->ops, we move the 64-bit seqnos flag from struct dma_fence_ops to the fence->flags. Drivers which were setting this flag are changed to use new dma_fence_init64() instead of dma_fence_init(). v2: * Streamlined init and added kerneldoc. * Rebase for amdgpu userq which landed since. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Reviewed-by: Christian König <christian.koenig@amd.com> # v1 Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20250515095004.28318-3-tvrtko.ursulin@igalia.com
2025-06-03drm/ttm: Increase pool shrinker batch targetTvrtko Ursulin
The default core shrink target of 128 pages (SHRINK_BATCH) is quite low relative to how cheap TTM pool shrinking is, and how the free pages are distributed in page order pools. We can make the target a bit more aggressive by making it roughly the average number of pages across all pools, freeing more of the cached pages every time shrinker core invokes our callback. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Christian König <christian.koenig@amd.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20250603112750.34997-3-tvrtko.ursulin@igalia.com
2025-06-03drm/ttm: Respect the shrinker core free targetTvrtko Ursulin
Currently the TTM shrinker aborts shrinking as soon as it frees pages from any of the page order pools and by doing so it can fail to respect the freeing target which was configured by the shrinker core. We use the wording "can fail" because the number of freed pages will depend on the presence of pages in the pools and the order of the pools on the LRU list. For example if there are no free pages in the high order pools the shrinker core may require multiple passes over the TTM shrinker before it will free the default target of 128 pages (assuming there are free pages in the low order pools). This inefficiency can be compounded by the pool LRU where multiple further calls into the TTM shrinker are required to end up looking at the pool with pages. Improve this by never freeing less than the shrinker core has requested. At the same time we start reporting the number of scanned pages (freed in this case), which prevents the core shrinker from giving up on the TTM shrinker too soon and moving on. v2: * Simplify loop logic. (Christian) * Improve commit message. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Christian König <christian.koenig@amd.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20250603112750.34997-2-tvrtko.ursulin@igalia.com
2025-06-03Merge drm-next-2025-05-28 into drm-misc-nextMaxime Ripard
Christian needs a recent drm-next branch to merge fence patches. Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-06-03drm/udl: use DRM_GEM_SHMEM_DRIVER_OPS_NO_MAP_SGTShixiong Ou
Import dmabuf without mapping its sg_table to avoid issues likes: udl 2-1.4:1.0: swiotlb buffer is full (sz: 2097152 bytes), total 65536 (slots), used 1 (slots) Signed-off-by: Shixiong Ou <oushixiong@kylinos.cn> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://lore.kernel.org/r/20250522070714.439824-3-oushixiong1025@163.com
2025-06-03drm/ast: use DRM_GEM_SHMEM_DRIVER_OPS_NO_MAP_SGTShixiong Ou
Import dmabuf without mapping its sg_table to avoid issues likes: ast 0000:07:00.0: swiotlb buffer is full (sz: 3145728 bytes), total 32768 (slots), used 0 (slots) Signed-off-by: Shixiong Ou <oushixiong@kylinos.cn> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://lore.kernel.org/r/20250522070714.439824-2-oushixiong1025@163.com
2025-06-03drm/shmem-helper: Import dmabuf without mapping its sg_tableShixiong Ou
[WHY] 1. Drivers using DRM_GEM_SHADOW_PLANE_HELPER_FUNCS and DRM_GEM_SHMEM_DRIVER_OPS (e.g., udl, ast) do not require sg_table import. They only need dma_buf_vmap() to access the shared buffer's kernel virtual address. 2. On certain Aspeed-based boards, a dma_mask of 0xffff_ffff may trigger SWIOTLB during dmabuf import. However, IO_TLB_SEGSIZE restricts the maximum DMA streaming mapping memory, resulting in errors like: ast 0000:07:00.0: swiotlb buffer is full (sz: 3145728 bytes), total 32768 (slots), used 0 (slots) [HOW] Provide a gem_prime_import implementation without sg_table mapping to avoid issues (e.g., "swiotlb buffer is full"). Drivers that do not require sg_table can adopt this. Signed-off-by: Shixiong Ou <oushixiong@kylinos.cn> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://lore.kernel.org/r/20250522070714.439824-1-oushixiong1025@163.com
2025-06-02drm/panfrost: Fix panfrost device variable name in devfreqAdrián Larumbe
Commit 64111a0e22a9 ("drm/panfrost: Fix incorrect updating of current device frequency") was a Panfrost port of a similar fix in Panthor. Fix the Panfrost device pointer variable name so that it follows Panfrost naming conventions. Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com> Fixes: 64111a0e22a9 ("drm/panfrost: Fix incorrect updating of current device frequency") Reviewed-by: Boris Brezillon <boris.brezillon@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/20250520174634.353267-6-adrian.larumbe@collabora.com
2025-06-02drm/panfrost: show device-wide list of DRM GEM objects over DebugFSAdrián Larumbe
This change is essentially a Panfrost port of commit a3707f53eb3f ("drm/panthor: show device-wide list of DRM GEM objects over DebugFS"). The DebugFS file is almost the same as in Panthor, minus the GEM object usage flags, since Panfrost has no kernel-only BO's. Two additional GEM state flags which are displayed but aren't relevant to Panthor are 'Purged' and 'Purgeable', since Panfrost implements an explicit shrinker and a madvise ioctl to flag objects as reclaimable. Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com> Reviewed-by: Boris Brezillon <boris.brezillon@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/20250520174634.353267-5-adrian.larumbe@collabora.com
2025-06-02drm/panfrost: Add driver IOCTL for setting BO labelsAdrián Larumbe
Allow UM to label a BO for which it possesses a DRM handle. Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://lore.kernel.org/r/20250520174634.353267-4-adrian.larumbe@collabora.com
2025-06-02drm/panfrost: Internally label some BOsAdrián Larumbe
Perfcnt samples buffer is not exposed to UM, but we would like to keep a tag on it as a potential debug aid. PRIME imported GEM buffers are UM exposed, but since the usual Panfrost UM driver code path is not followed in their creation, they might remain unlabelled for their entire lifetime, so a generic tag was deemed preferable. The tag is assigned before a UM handle is created so it doesn't contradict the logic about labelling internal BOs. Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com> Reviewed-by: Boris Brezillon <boris.brezillon@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/20250520174634.353267-3-adrian.larumbe@collabora.com
2025-06-02drm/panfrost: Add BO labelling to PanfrostAdrián Larumbe
Functions for labelling UM-exposed an internal BOs are provided. An example of the latter would be the Perfcnt sample buffer. This commit is done in preparation of a following one that will allow UM to set BO labels through a new ioctl(). Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://lore.kernel.org/r/20250520174634.353267-2-adrian.larumbe@collabora.com
2025-06-02accel/ivpu: Add inference_timeout_ms module parameterKarol Wachowski
Add new inference_timeout_ms parameter that allows specifying maximum allowed duration in milliseconds that inference can take before triggering a recovery. Calculate maximum number of heartbeat retries based on ratio between inference timeout and tdr timeout. Signed-off-by: Karol Wachowski <karol.wachowski@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/20250515093128.252041-1-jacek.lawrynowicz@linux.intel.com
2025-06-02dma-buf: Add forward declaration of struct seq_file in dma-fence.hHerbert Xu
Add forward declaration of struct seq_file before using it in function prototype. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com> Link: https://lore.kernel.org/r/aDlu5TGyA1WuMsvw@gondor.apana.org.au
2025-06-02drm/sched/tests: Use one lock for fence contextPhilipp Stanner
There is no need for separate locks for single jobs and the entire scheduler. The dma_fence context can be protected by the scheduler lock, allowing for removing the jobs' locks. This simplifies things and reduces the likelyhood of deadlocks etc. Replace the jobs' locks with the mock scheduler lock. Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://lore.kernel.org/r/20250527101029.56491-2-phasta@kernel.org
2025-06-02drm/tests: hdmi: Add test for unsuccessful fallback to YUV420Cristian Ciocaltea
Provide test to verify a mandatory fallback to YUV420 output cannot succeed when driver doesn't advertise YUV420 support. Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://lore.kernel.org/r/20250527-hdmi-conn-yuv-v5-19-74c9c4a8ac0c@collabora.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-06-02drm/tests: hdmi: Add max TMDS rate fallback tests for YUV420 modeCristian Ciocaltea
Provide tests to verify drm_atomic_helper_connector_hdmi_check() helper fallback behavior when using YUV420 output format. Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://lore.kernel.org/r/20250527-hdmi-conn-yuv-v5-18-74c9c4a8ac0c@collabora.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-06-02drm/tests: hdmi: Provide EDID supporting 4K@30Hz with RGB/YUVCristian Ciocaltea
Create a test EDID advertising the following capabilities: Max resolution: 3840x2160@30Hz with RGB, YUV444, YUV422, YUV420 Max BPC: 16 for all modes Max TMDS clock: 340 MHz Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://lore.kernel.org/r/20250527-hdmi-conn-yuv-v5-17-74c9c4a8ac0c@collabora.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-06-02drm/tests: hdmi: Rename max TMDS rate fallback testsCristian Ciocaltea
In preparation to extend the max TMDS rate fallback tests for covering YUV420 output, update the rather generic function names drm_test_check_max_tmds_rate_{bpc|format}_fallback() to properly indicate the intended test cases. Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://lore.kernel.org/r/20250527-hdmi-conn-yuv-v5-16-74c9c4a8ac0c@collabora.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-06-02drm/tests: hdmi: Add limited range tests for YUV420 modeCristian Ciocaltea
Provide tests to verify that drm_atomic_helper_connector_hdmi_check() helper behaviour when using YUV420 output format is to always set the limited RGB quantization range to 'limited', no matter what the value of Broadcast RGB property is. Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://lore.kernel.org/r/20250527-hdmi-conn-yuv-v5-15-74c9c4a8ac0c@collabora.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-06-02drm/tests: hdmi: Provide EDID supporting 4K@30Hz with YUV420 onlyCristian Ciocaltea
Create a test EDID advertising the following capabilities: Max resolution: - 1920x1080@60Hz with RGB, YUV444, YUV422 - 3840x2160@30Hz with YUV420 only Max BPC: 16 for all modes Max TMDS clock: 200 MHz Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://lore.kernel.org/r/20250527-hdmi-conn-yuv-v5-14-74c9c4a8ac0c@collabora.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-06-02drm/tests: hdmi: Switch to drm_atomic_get_new_connector_state() where possibleCristian Ciocaltea
Replace the calls to drm_atomic_get_connector_state() with drm_atomic_get_new_connector_state() for cases which do not require allocating the connector state, e.g. after drm_atomic_check_only() when the intent is to only read the new connector state. The rational is to avoid the need to handle the potential EDEADLK error returned by the former helper, which would require restarting the entire atomic sequence. Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://lore.kernel.org/r/20250527-hdmi-conn-yuv-v5-13-74c9c4a8ac0c@collabora.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-06-02drm/tests: hdmi: Setup ycbcr_420_allowed before initializing connectorCristian Ciocaltea
Initializing HDMI connector via drmm_connector_hdmi_init() requires its ->ycbcr_420_allowed flag to be adjusted according to the supported formats passed as function argument, prior to the actual invocation. In order to allow providing test coverage for YUV420 modes, ensure the flag is properly setup. Reviewed-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://lore.kernel.org/r/20250527-hdmi-conn-yuv-v5-12-74c9c4a8ac0c@collabora.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-06-02drm/tests: hdmi: Drop unused drm_kunit_helper_connector_hdmi_init_funcs()Cristian Ciocaltea
After updating the code to make use of the new EDID setup helper, drm_kunit_helper_connector_hdmi_init_funcs() became unused, hence drop it. Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://lore.kernel.org/r/20250527-hdmi-conn-yuv-v5-11-74c9c4a8ac0c@collabora.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-06-02drm/tests: hdmi: Replace open coded EDID setupCristian Ciocaltea
Make use of the recently introduced macros to reduce boilerplate code around EDID setup. This also helps dropping the redundant calls to set_connector_edid(). No functional changes intended. Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://lore.kernel.org/r/20250527-hdmi-conn-yuv-v5-10-74c9c4a8ac0c@collabora.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-06-02drm/tests: hdmi: Add macro to simplify EDID setupCristian Ciocaltea
Factor out the HDMI connector initialization from drm_kunit_helper_connector_hdmi_init_funcs() into a common __connector_hdmi_init() function, while extending its functionality to allow setting custom (i.e. non-default) EDID data. Introduce a macro as a wrapper over the new helper to allow dropping the open coded EDID setup from all test cases. The actual conversion will be handled separately; for now just apply it to drm_kunit_helper_connector_hdmi_init() helper. Reviewed-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://lore.kernel.org/r/20250527-hdmi-conn-yuv-v5-9-74c9c4a8ac0c@collabora.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-06-02drm/tests: hdmi: Switch to 'void *' type for EDID dataCristian Ciocaltea
Replace 'const char *' with 'const void *' type for current_edid member in struct drm_atomic_helper_connector_hdmi_priv, as well as for the edid parameter of set_connector_edid() function. Suggested-by: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://lore.kernel.org/r/20250527-hdmi-conn-yuv-v5-8-74c9c4a8ac0c@collabora.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
generated by cgit (git 2.34.1) at 2025-09-08 08:51:19 +0000