summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2023-12-12drm/xe/gt: Fix min() with u32 and u64Lucas De Marchi
Fix the following error while building for 32b: In file included from ../drivers/gpu/drm/xe/xe_gt.c:6: ../drivers/gpu/drm/xe/xe_gt.c: In function ‘gt_ttm_mgr_init’: ../include/linux/minmax.h:20:35: error: comparison of distinct pointer types lacks a cast [-Werror] 20 | (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1))) | ^~ Cast it to u64 so size of the second operand matches the first one when building it for 32 bits. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-12drm/xe: Fix tracepoints on 32bLucas De Marchi
Leave the types as u64, but cast the pointers to unsigned long before assigning so the compiler doesn't throw warning about casting a pointer to integer of different size. Also, size_t should use %zu, not %ld. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-12drm/xe/mmio: Use non-atomic writeq/readq variant for 32bLucas De Marchi
writeq() and readq() and other functions working on 64 bit variables are not provided by 32b arch. For that it's needed to choose between linux/io-64-nonatomic-hi-lo.h and linux/io-64-nonatomic-lo-hi.h, spliting the read/write in 2 accesses. For xe driver, it doesn't matter much, so just choose one and include in xe_mmio.h. This also removes some ifdef CONFIG_64BIT we had around because of the missing 64bit functions. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-12drm/xe: Fix some log messages on 32bLucas De Marchi
Either use the proper format or cast up to 64b depending on the case. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-12drm/xe/ggtt: Use BIT_ULL() for 64bitLucas De Marchi
Make sure it's 64bit value in both 32b and 64b arch. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-12drm/xe: fix xe_mmio_total_vram_sizePhilippe Lecluse
As also cause issue on PVC, moving back to what we did before stolen was introduced Signed-off-by: Philippe Lecluse <philippe.lecluse@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-12drm/xe/pcode: fix pcode error checkMatthew Auld
On DG2 we are now getting: [ 104.456607] xe 0000:03:00.0: [drm] *ERROR* PCODE timeout, retrying with preemption disabled Looks like we just need to invert the error check for xe_pcode_try_request(), which returns zero on success. Signed-off-by: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-12drm/xe: enforce GSMBASE for DG1 instead of BAR2Philippe Lecluse
On DG1, BAR2 is not reliable for reporting Vram size, need to use GSMBASE. Simplify xe_mmio_total_vram_size to report vram size and usable size. Signed-off-by: Philippe Lecluse <philippe.lecluse@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-12drm/xe: Fix hidden gotcha regression with bo createMaarten Lankhorst
The bo_create ioctl relied on the internal ordering of memory regions to be the same, make sure we don't allocate stolen instead of VRAM0. Also remove a debug warning left in. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Philippe Lecluse <philippe.lecluse1@gmail.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-12drm/xe/guc: Add support GuC MMIO send / recvMatthew Brost
SRIOV has a use case of GuC MMIO send / recv, add a function for it. Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Philippe Lecluse <philippe.lecluse1@gmail.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-12drm/xe/guc: s/xe_guc_send_mmio/xe_guc_mmio_sendMatthew Brost
Now aligns with the xe_guc_ct_send naming. Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Philippe Lecluse <philippe.lecluse1@gmail.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-12drm/xe/guc: Report submission version of GuC firmwareMatthew Brost
Starting in 70.6.* GuC firmware the CSS header includes the submission version, pull this from the CSS header. Prior 70.* versions accidentally omitted this informatio so hard code to the correct values. This information will be used by VFs when communicating with the PF. Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Philippe Lecluse <philippe.lecluse1@gmail.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-12drm/xe: Fake pulling gt->info.engine_mask from hwconfig blobMatthew Brost
The blob doesn't fully support this yet, so fake for now to ensure our driver load order is correct. Once the blob supports pulling gt->info.engine_mask from the blob, this patch can be removed. Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-12drm/xe: Ensure VMA not userptr before calling xe_bo_is_stolenMatthew Brost
Fix the below splat: [ 142.510525] [IGT] xe_exec_basic: starting subtest once-userptr [ 142.511339] BUG: kernel NULL pointer dereference, address: 0000000000000228 [ 142.518311] #PF: supervisor read access in kernel mode [ 142.523458] #PF: error_code(0x0000) - not-present page [ 142.528604] PGD 0 P4D 0 [ 142.531153] Oops: 0000 [#1] PREEMPT SMP NOPTI [ 142.535518] CPU: 4 PID: 1199 Comm: kworker/u16:8 Not tainted 6.1.0-rc1-xe+ #1 [ 142.542656] Hardware name: Intel Corporation Tiger Lake Client Platform/TigerLake U DDR4 SODIMM RVP, BIOS TGLSFWI1.R00.3243.A01.2006102133 06/10/2020 [ 142.556033] Workqueue: events_unbound async_op_work_func [xe] [ 142.561810] RIP: 0010:xe_bo_is_stolen+0x0/0x20 [xe] [ 142.566709] Code: 20 c8 75 05 83 fa 07 74 05 c3 cc cc cc cc 48 8b 87 08 02 00 00 0f b6 80 2c ff ff ff c3 cc cc cc cc 66 0f 1f 84 00 00 00 00 00 <48> 8b 87 28 02 00 00 83 78 10 07 0f 94 c0 c3 cc cc cc cc 66 66 2e [ 142.585447] RSP: 0018:ffffc900019eb888 EFLAGS: 00010246 [ 142.590678] RAX: 0000000000000002 RBX: 0000000000000000 RCX: ffff88813f6a2108 [ 142.597821] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 142.604962] RBP: ffffc900019ebbc0 R08: 0000000000000001 R09: 0000000000000000 [ 142.612101] R10: 0000000000000001 R11: 0000000000000001 R12: ffff88814107d600 [ 142.619242] R13: ffffc900019eba20 R14: ffff888140442000 R15: 0000000000000000 [ 142.626378] FS: 0000000000000000(0000) GS:ffff88849fa00000(0000) knlGS:0000000000000000 [ 142.634468] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 142.640219] CR2: 0000000000000228 CR3: 000000010a4c0006 CR4: 0000000000770ee0 [ 142.647361] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 142.654505] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 142.661639] PKRU: 55555554 [ 142.664367] Call Trace: [ 142.666830] <TASK> [ 142.668947] __xe_pt_bind_vma+0x1a1/0xa50 [xe] [ 142.673417] ? unwind_next_frame+0x187/0x770 [ 142.677699] ? __thaw_task+0xc0/0xc0 [ 142.681293] ? __lock_acquire+0x5e4/0x26e0 [ 142.685409] ? lockdep_hardirqs_on+0xbf/0x140 [ 142.689779] ? lock_acquire+0xd2/0x310 [ 142.693548] ? mark_held_locks+0x49/0x80 [ 142.697485] ? xe_vm_bind_vma+0xf1/0x3d0 [xe] [ 142.701866] xe_vm_bind_vma+0xf1/0x3d0 [xe] [ 142.706082] xe_vm_bind+0x76/0x140 [xe] [ 142.709944] vm_bind_ioctl+0x26f/0xb40 [xe] [ 142.714161] ? async_op_work_func+0x20c/0x450 [xe] [ 142.718974] async_op_work_func+0x20c/0x450 [xe] [ 142.723620] process_one_work+0x263/0x580 [ 142.727645] ? process_one_work+0x580/0x580 [ 142.731839] worker_thread+0x4d/0x3b0 [ 142.735518] ? process_one_work+0x580/0x580 [ 142.739714] kthread+0xeb/0x120 [ 142.742872] ? kthread_complete_and_exit+0x20/0x20 [ 142.747671] ret_from_fork+0x1f/0x30 [ 142.751264] </TASK> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-12drm/xe: Implement stolen memory.Maarten Lankhorst
This adds support for stolen memory, with the same allocator as vram_mgr. This allows us to skip a whole lot of copy-paste, by re-using parts of xe_ttm_vram_mgr. The stolen memory may be bound using VM_BIND, so it performs like any other memory region. We should be able to map a stolen BO directly using the physical memory location instead of through GGTT even on old platforms, but I don't know what the effects are on coherency. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-12drm/xe: Take memory ref on kernel job creationMatthew Brost
When a job is inflight we may access memory to read the hardware seqno. All user jobs have VM open which has a ref but kernel jobs do not require VM so it is possible to not have memory ref. To avoid this, take a memory ref on kernel job creation. Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-12drm/xe/migrate: Add kerneldoc for the migrate subsystemThomas Hellström
Add kerneldoc for structs and external functions. Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-12-12drm/xe: Remove i915_utils dependency from xe_pcode.Rodrigo Vivi
Expand xe_mmio_wait32 to accept atomic and then use that directly when possible, and create own routine to wait for the pcode status. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com>
2023-12-12drm/xe: Convert xe_mmio_wait32 to us so we can stop using wait_for_us.Rodrigo Vivi
Another clean-up towards killing the usage of i915_utils.h Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com>
2023-12-12drm/xe: Let's avoid i915_utils in the xe_force_wake.Rodrigo Vivi
We can run the bit operation locally without yet another macro. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com>
2023-12-12drm/xe: Stop using i915_utils in xe_wopcm.Rodrigo Vivi
We don't need any macro for a simple check we can do explicitly and clear. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com>
2023-12-12drm/xe: Remove i915_utils dependency from xe_guc_pc.Rodrigo Vivi
To make it simpler, all of the status checks also waits and times out. Also, no ktime precision is needed in this case, and we can use usleep_range because we are not in atomic paths here. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com>
2023-12-12drm/xe: Wait for success on guc done.Rodrigo Vivi
Rather than a constant check on proto and wait not busy, let's wait for the expected success and then check the protocol afterwards. With this, we can now use the regular xe_mmio_wait32 and kill this local need for the wait_for. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com>
2023-12-12drm/xe: Convert guc_ready to regular xe_mmio_wait32Rodrigo Vivi
Possible now that the wait function returns the last read value. So we can remove the users of i915's wait_for one by one... Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com>
2023-12-12drm/xe: Let's return last value read on xe_mmio_wait32.Rodrigo Vivi
This is already useful because it avoids some extra reads where registers might have changed after the timeout decision. But also, it will be important to end the kill of i915's wait_for. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com>
2023-12-12drm/xe: Stop using i915's range_overflows_t macro.Rodrigo Vivi
Let's do it directly. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com>
2023-12-12drm/xe: Implement a local xe_mmio_wait32Rodrigo Vivi
Then, move the i915_utils.h include to its user. The overall goal is to kill all the usages of the i915_utils stuff. Yes, wait_for also depends on <linux/delay.h>, so they go together to where it is needed. It will be likely needed anyway directly for udelay or usleep_range. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com>
2023-12-12drm/xe: Introduce a new DRM driver for Intel GPUsMatthew Brost
Xe, is a new driver for Intel GPUs that supports both integrated and discrete platforms starting with Tiger Lake (first Intel Xe Architecture). The code is at a stage where it is already functional and has experimental support for multiple platforms starting from Tiger Lake, with initial support implemented in Mesa (for Iris and Anv, our OpenGL and Vulkan drivers), as well as in NEO (for OpenCL and Level0). The new Xe driver leverages a lot from i915. As for display, the intent is to share the display code with the i915 driver so that there is maximum reuse there. But it is not added in this patch. This initial work is a collaboration of many people and unfortunately the big squashed patch won't fully honor the proper credits. But let's get some git quick stats so we can at least try to preserve some of the credits: Co-developed-by: Matthew Brost <matthew.brost@intel.com> Co-developed-by: Matthew Auld <matthew.auld@intel.com> Co-developed-by: Matt Roper <matthew.d.roper@intel.com> Co-developed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Co-developed-by: Francois Dugast <francois.dugast@intel.com> Co-developed-by: Lucas De Marchi <lucas.demarchi@intel.com> Co-developed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Co-developed-by: Philippe Lecluse <philippe.lecluse@intel.com> Co-developed-by: Nirmoy Das <nirmoy.das@intel.com> Co-developed-by: Jani Nikula <jani.nikula@intel.com> Co-developed-by: José Roberto de Souza <jose.souza@intel.com> Co-developed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Co-developed-by: Dave Airlie <airlied@redhat.com> Co-developed-by: Faith Ekstrand <faith.ekstrand@collabora.com> Co-developed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Co-developed-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com>
2023-12-12drm/amd/display: Disable PSR-SU on Parade 0803 TCON againMario Limonciello
When screen brightness is rapidly changed and PSR-SU is enabled the display hangs on panels with this TCON even on the latest DCN 3.1.4 microcode (0x8002a81 at this time). This was disabled previously as commit 072030b17830 ("drm/amd: Disable PSR-SU on Parade 0803 TCON") but reverted as commit 1e66a17ce546 ("Revert "drm/amd: Disable PSR-SU on Parade 0803 TCON"") in favor of testing for a new enough microcode (commit cd2e31a9ab93 ("drm/amd/display: Set minimum requirement for using PSR-SU on Phoenix")). As hangs are still happening specifically with this TCON, disable PSR-SU again for it until it can be root caused. Cc: stable@vger.kernel.org Cc: aaron.ma@canonical.com Cc: binli@gnome.org Cc: Marc Rossi <Marc.Rossi@amd.com> Cc: Hamza Mahfooz <Hamza.Mahfooz@amd.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2046131 Acked-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-12-12drm/amd/display: Populate dtbclk from bounding boxFangzhi Zuo
dtbclk is unavaliable from pmfw. Try to grab the value from bounding box Reviewed-by: Charlene Liu <charlene.liu@amd.com> Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Fangzhi Zuo <jerry.zuo@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-12-12drm/amd/display: Revert "Fix conversions between bytes and KB"Taimur Hassan
[Why & How] HostVMMinPageSize is expected to be in KB according to spec, the checks later down the line reflect this as well. Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Taimur Hassan <syed.hassan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-12-12drm/amdgpu/jpeg: configure doorbell for each playbackSaleemkhan Jamadar
Doorbell is configured during start of each playback. v1 - add comment for the doorbell programming change Signed-off-by: Saleemkhan Jamadar <saleemkhan.jamadar@amd.com> Acked-by: Leo Liu <leo.liu@amd.com> Reviewed-by: Veerabadhran Gopalakrishnan <Veerabadhran.Gopalakrishnan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-12-12iommu/tegra: Use tegra_dev_iommu_get_stream_id() in the remaining placesJason Gunthorpe
This API was defined to formalize the access to internal iommu details on some Tegra SOCs, but a few callers got missed. Add them. The helper already masks by 0xFFFF so remove this code from the callers. Suggested-by: Thierry Reding <thierry.reding@gmail.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/7-v2-16e4def25ebb+820-iommu_fwspec_p1_jgg@nvidia.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2023-12-12drm/exynos: dpi: Change connector type to DPIPaul Cercueil
When exynos_drm_dpi.c was written, DRM_MODE_CONNECTOR_DPI did not exist yet and I guess that's the reason why DRM_MODE_CONNECTOR_VGA was used as the connector type. However, now it makes more sense to use DRM_MODE_CONNECTOR_DPI as the connector type. Signed-off-by: Paul Cercueil <paul@crapouillou.net> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2023-12-12drm/exynos: Convert to platform remove callback returning voidUwe Kleine-König
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> fix merge conflict and drop duplicated patch description. Signed-off-by: Inki Dae <inki.dae@samsung.com>
2023-12-12drm/exynos: Call drm_atomic_helper_shutdown() at shutdown/unbind timeDouglas Anderson
Based on grepping through the source code this driver appears to be missing a call to drm_atomic_helper_shutdown() at system shutdown time and at driver unbind time. Among other things, this means that if a panel is in use that it won't be cleanly powered off at system shutdown time. The fact that we should call drm_atomic_helper_shutdown() in the case of OS shutdown/restart and at driver remove (or unbind) time comes straight out of the kernel doc "driver instance overview" in drm_drv.c. A few notes about this fix: - When adding drm_atomic_helper_shutdown() to the unbind path, I added it after drm_kms_helper_poll_fini() since that's when other drivers seemed to have it. - Technically with a previous patch, ("drm/atomic-helper: drm_atomic_helper_shutdown(NULL) should be a noop"), we don't actually need to check to see if our "drm" pointer is NULL before calling drm_atomic_helper_shutdown(). We'll leave the "if" test in, though, so that this patch can land without any dependencies. It could potentially be removed later. - This patch also makes sure to set the drvdata to NULL in the case of bind errors to make sure that shutdown can't access freed data. Suggested-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2023-12-12Merge tag 'exynos-drm-next-for-v6.7-rc5' of ↵Inki Dae
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into exynos-drm-next Two fixups - Fix a potential error pointer dereference by checking the return value of exynos_drm_crtc_get_by_type() function before accessing to crtc object. - Fix a wrong error checking in exynos_drm_dma.c modules, which was reported by Dan[1] [1] https://lore.kernel.org/all/33e52277-1349-472b-a55b-ab5c3462bfcf@moroto.mountain/
2023-12-12Backmerge tag 'v6.7-rc5' into drm-nextDave Airlie
Linux 6.7-rc5 Alex requested this for some amdkfd work relying on the symbols exports. Signed-off-by: Dave Airlie <airlied@redhat.com>
2023-12-11drm/i915/display: do not use cursor size reduction on MTLAndrzej Hajda
Cursor size reduction is not supported since MTL. Signed-off-by: Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231124-cur_size_reduction-v1-1-30495dba475f@intel.com
2023-12-11drm/amd/display: Restore guard against default backlight value < 1 nitMario Limonciello
Mark reports that brightness is not restored after Xorg dpms screen blank. This behavior was introduced by commit d9e865826c20 ("drm/amd/display: Simplify brightness initialization") which dropped the cached backlight value in display code, but also removed code for when the default value read back was less than 1 nit. Restore this code so that the backlight brightness is restored to the correct default value in this circumstance. Reported-by: Mark Herbert <mark.herbert42@gmail.com> Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3031 Cc: stable@vger.kernel.org Cc: Camille Cho <camille.cho@amd.com> Cc: Krunoslav Kovac <krunoslav.kovac@amd.com> Cc: Hamza Mahfooz <hamza.mahfooz@amd.com> Fixes: d9e865826c20 ("drm/amd/display: Simplify brightness initialization") Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-12-11drm/amd/display: fix hw rotated modes when PSR-SU is enabledHamza Mahfooz
We currently don't support dirty rectangles on hardware rotated modes. So, if a user is using hardware rotated modes with PSR-SU enabled, use PSR-SU FFU for all rotated planes (including cursor planes). Cc: stable@vger.kernel.org Fixes: 30ebe41582d1 ("drm/amd/display: add FB_DAMAGE_CLIPS support") Reported-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/2952 Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Tested-by: Bin Li <binli@gnome.org> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-12-11drm/amd/pm: fix pp_*clk_od typoDmitrii Galantsev
Fix pp_dpm_sclk_od and pp_dpm_mclk_od typos. Those were defined as pp_*clk_od but used as pp_dpm_*clk_od instead. This change removes the _dpm part. Fixes: 8cfd6a05750c ("drm/amd/pm: Hide irrelevant pm device attributes") Signed-off-by: Dmitrii Galantsev <dmitrii.galantsev@amd.com> Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2023-12-11drm/amdgpu: fix buffer funcs setting order on suspend harderAlex Deucher
Part of commit dab96d8b61aa ("drm/amdgpu: fix buffer funcs setting order on suspend") got dropped accidently. Add it back. Fixes: dab96d8b61aa ("drm/amdgpu: fix buffer funcs setting order on suspend") Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-12-11drm/msm/dpu: move encoder status to standard encoder debugfs dirDmitry Baryshkov
Now as we have standard per-encoder debugfs directory, move DPU encoder status file to that directory. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/570219/ Link: https://lore.kernel.org/r/20231203115315.1306124-4-dmitry.baryshkov@linaro.org
2023-12-11drm/bridge: ti-sn65dsi86: Associate PWM device to auxiliary deviceUwe Kleine-König
It's the ti_sn65dsi86.pwm auxiliary driver that creates the pwmchip, so let the auxiliary device be the parent of the pwm device. Note that getting a reference to the ti-sn65dsi86's pwm using pwm_get() isn't affected by this change as ti_sn65dsi86_add_aux_device() sets the auxiliary device's of_node to that of the main device. Also change PM runtime tracking and diagnostic messages to use that one. After enabling runtime PM operation for the auxiliary device, all works as expected as parent devices are handled just fine. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Tested-by: Nikita Travkin <nikita@trvn.ru> # Acer Aspire 1 Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20231209153108.1988551-2-u.kleine-koenig@pengutronix.de
2023-12-11drm/mediatek: Fix access violation in mtk_drm_crtc_dma_dev_getStuart Lee
Add error handling to check NULL input in mtk_drm_crtc_dma_dev_get function. While display path is not configured correctly, none of crtc is established. So the caller of mtk_drm_crtc_dma_dev_get may pass input parameter *crtc as NULL, Which may cause coredump when we try to get the container of NULL pointer. Fixes: cb1d6bcca542 ("drm/mediatek: Add dma dev get function") Signed-off-by: Stuart Lee <stuart.lee@mediatek.com> Cc: stable@vger.kernel.org Reviewed-by: AngeloGioacchino DEl Regno <angelogioacchino.delregno@collabora.com> Tested-by: Macpaul Lin <macpaul.lin@mediatek.com> Link: https://patchwork.kernel.org/project/dri-devel/patch/20231110012914.14884-2-stuart.lee@mediatek.com/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2023-12-11drm/edid: also call add modes in EDID connector update fallbackJani Nikula
When the separate add modes call was added back in commit c533b5167c7e ("drm/edid: add separate drm_edid_connector_add_modes()"), it failed to address drm_edid_override_connector_update(). Also call add modes there. Reported-by: bbaa <bbaa@bbaa.fun> Closes: https://lore.kernel.org/r/930E9B4C7D91FDFF+29b34d89-8658-4910-966a-c772f320ea03@bbaa.fun Fixes: c533b5167c7e ("drm/edid: add separate drm_edid_connector_add_modes()") Cc: <stable@vger.kernel.org> # v6.3+ Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231207093821.2654267-1-jani.nikula@intel.com
2023-12-11drm/i915/edp: don't write to DP_LINK_BW_SET when using rate selectJani Nikula
The eDP 1.5 spec adds a clarification for eDP 1.4x: > For eDP v1.4x, if the Source device chooses the Main-Link rate by way > of DPCD 00100h, the Sink device shall ignore DPCD 00115h[2:0]. We write 0 to DP_LINK_BW_SET (DPCD 100h) even when using DP_LINK_RATE_SET (DPCD 114h). Stop doing that, as it can cause the panel to ignore the rate set method. Moreover, 0 is a reserved value for DP_LINK_BW_SET, and should not be used. v2: Improve the comments (Ville) Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9081 Tested-by: Animesh Manna <animesh.manna@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231205180551.2476228-1-jani.nikula@intel.com (cherry picked from commit 23b392b94acb0499f69706c5808c099f590ebcf4) Cc: stable@vger.kernel.org Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2023-12-11drm/i915: Fix ADL+ tiled plane stride when the POT stride is smaller than ↵Ville Syrjälä
the original plane_view_scanout_stride() currently assumes that we had to pad the mapping stride with dummy pages in order to align it. But that is not the case if the original fb stride exceeds the aligned stride used to populate the remapped view, which is calculated from the user specified framebuffer width rather than the user specified framebuffer stride. Ignore the original fb stride in this case and just stick to the POT aligned stride. Getting this wrong will cause the plane to fetch the wrong data, and can lead to fault errors if the page tables at the bogus location aren't even populated. TODO: figure out if this is OK for CCS, or if we should instead increase the width of the view to cover the entire user specified fb stride instead... Cc: Imre Deak <imre.deak@intel.com> Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231204202443.31247-1-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> (cherry picked from commit 01a39f1c4f1220a4e6a25729fae87ff5794cbc52) Cc: stable@vger.kernel.org Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2023-12-11drm/i915: Fix intel_atomic_setup_scalers() plane_state handlingVille Syrjälä
Since the plane_state variable is declared outside the scaler_users loop in intel_atomic_setup_scalers(), and it's never reset back to NULL inside the loop we may end up calling intel_atomic_setup_scaler() with a non-NULL plane state for the pipe scaling case. That is bad because intel_atomic_setup_scaler() determines whether we are doing plane scaling or pipe scaling based on plane_state!=NULL. The end result is that we may miscalculate the scaler mode for pipe scaling. The hardware becomes somewhat upset if we end up in this situation when scanning out a planar format on a SDR plane. We end up programming the pipe scaler into planar mode as well, and the result is a screenfull of garbage. Fix the situation by making sure we pass the correct plane_state==NULL when calculating the scaler mode for pipe scaling. Cc: stable@vger.kernel.org Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231207193441.20206-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit e81144106e21271c619f0c722a09e27ccb8c043d) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
generated by cgit v1.2.3 (git 2.25.1) at 2026-05-15 05:13:40 +0000