summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2024-01-08Revert "drm/i915: Annotate dma_fence_work"Daniel Vetter1-4/+0
This reverts commit 7fbc6eca6f0db8244cddc39471d71471a2f30254. I need working lockdep back
2024-01-08drm/i915: Annotate dma_fence_workDaniel Vetter1-0/+4
i915 does tons of allocations from this worker, which lockdep catches. Also generic infrastructure like this with big potential for how dma_fence or other cross driver contracts work, really should be reviewed on dri-devel. Implementing custom wheels for everything within the driver is a classic case of "platform problem" [1]. Which in upstream we really shouldn't have. Since there's no quick way to solve these splats (dma_fence_work is used a bunch in basic buffer management and command submission) like for amdgpu, I'm giving up at this point here. Annotating i915 scheduler and gpu reset could would be interesting, but since lockdep is one-shot we can't see what surprises would lurk there. 1: https://lwn.net/Articles/443531/ Cc: linux-media@vger.kernel.org Cc: linaro-mm-sig@lists.linaro.org Cc: linux-rdma@vger.kernel.org Cc: amd-gfx@lists.freedesktop.org Cc: intel-gfx@lists.freedesktop.org Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Christian König <christian.koenig@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2024-01-08drm/rcar-du: Annotate dma-fence critical section in commit pathDaniel Vetter1-0/+2
Ends right after drm_atomic_helper_commit_hw_done(), absolutely nothing fancy going on here. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Cc: linux-renesas-soc@vger.kernel.org
2024-01-08drm/vblank: Annotate with dma-fence signalling sectionDaniel Vetter1-1/+7
This is rather overkill since currently all drivers call this from hardirq (or at least timers). But maybe in the future we're going to have thread irq handlers and what not, doesn't hurt to be prepared. Plus this is an easy start for sprinkling these fence annotations into shared code. Cc: linux-media@vger.kernel.org Cc: linaro-mm-sig@lists.linaro.org Cc: linux-rdma@vger.kernel.org Cc: amd-gfx@lists.freedesktop.org Cc: intel-gfx@lists.freedesktop.org Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Christian König <christian.koenig@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2024-01-08drm/atomic-helpers: remove legacy_cursor_update hacksDaniel Vetter3-13/+29
The stuff never really worked, and leads to lots of fun because it out-of-order frees atomic states. Which upsets KASAN, among other things. For async updates we now have a more solid solution with the ->atomic_async_check and ->atomic_async_commit hooks. Support for that for msm and vc4 landed. nouveau and i915 have their own commit routines, doing something similar. For everyone else it's probably better to remove the use-after-free bug, and encourage folks to use the async support instead. The affected drivers which register a legacy cursor plane and don't either use the new async stuff or their own commit routine are: amdgpu, atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and vmwgfx. Inspired by an amdgpu bug report. v2: Drop RFC, I think with amdgpu converted over to use atomic_async_check/commit done in commit 674e78acae0dfb4beb56132e41cbae5b60f7d662 Author: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Date: Wed Dec 5 14:59:07 2018 -0500 drm/amd/display: Add fast path for cursor plane updates we don't have any driver anymore where we have userspace expecting solid legacy cursor support _and_ they are using the atomic helpers in their fully glory. So we can retire this. v3: Paper over msm and i915 regression. The complete_all is the only thing missing afaict. v4: Fixup i915 fixup ... v5: Unallocate the crtc->event in msm to avoid hitting a WARN_ON in dpu_crtc_atomic_flush(). This is a bit a hack, but simplest way to untangle this all. Thanks to Abhinav Kumar for the debug help. Cc: Abhinav Kumar <quic_abhinavk@quicinc.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Maxime Ripard <maxime@cerno.tech> References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 References: https://lore.kernel.org/all/20220221134155.125447-9-maxime@cerno.tech/ References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 Cc: Maxime Ripard <maxime@cerno.tech> Tested-by: Maxime Ripard <maxime@cerno.tech> Cc: mikita.lipski@amd.com Cc: Michel Dänzer <michel@daenzer.net> Cc: harry.wentland@amd.com Cc: Rob Clark <robdclark@gmail.com> Cc: "Kazlauskas, Nicholas" <nicholas.kazlauskas@amd.com> Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Cc: Sean Paul <sean@poorly.run> Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: linux-arm-msm@vger.kernel.org Cc: freedreno@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-mediatek@lists.infradead.org Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2024-01-08drm: Complain if drivers still use the ->load callbackDaniel Vetter2-0/+9
Kinda time to get this sorted. The locking around this really is not nice. Thomas mentioned in his review that the only drivers left unconverted are radeon and amdgpu. Cc: Harry Wentland <harry.wentland@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2024-01-08drm/tiny/st7735r: set drvdata before registeringDaniel Vetter1-2/+2
Otherwise things might go boom. Not a big chance of that happening since we don't implement suspend/resume support.
2024-01-08input/psmouse: Don't hold the mutex while calling ->disconnectDaniel Vetter1-0/+2
At least trackpoint_disconnect wants to remove some sysfs files, and we can't remove sysfs files while holding psmouse_mutex: ====================================================== WARNING: possible circular locking dependency detected 4.16.0-rc5-g613eb885b69e-drmtip_1+ #1 Tainted: G U ------------------------------------------------------ kworker/0:3/102 is trying to acquire lock: (kn->count#130){++++}, at: [<000000009679748b>] kernfs_remove_by_name_ns+0x3b/0x80 but task is already holding lock: (psmouse_mutex){+.+.}, at: [<0000000014f44bcc>] psmouse_disconnect+0x62/0x160 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (psmouse_mutex){+.+.}: psmouse_attr_set_helper+0x28/0x140 kernfs_fop_write+0xfe/0x180 __vfs_write+0x1e/0x130 vfs_write+0xbd/0x1b0 SyS_write+0x40/0xa0 do_syscall_64+0x65/0x1a0 entry_SYSCALL_64_after_hwframe+0x42/0xb7 -> #0 (kn->count#130){++++}: __kernfs_remove+0x243/0x2b0 kernfs_remove_by_name_ns+0x3b/0x80 remove_files.isra.0+0x2b/0x60 sysfs_remove_group+0x38/0x80 sysfs_remove_groups+0x24/0x40 trackpoint_disconnect+0x2c/0x50 psmouse_disconnect+0x8f/0x160 serio_disconnect_driver+0x28/0x40 serio_driver_remove+0xc/0x10 device_release_driver_internal+0x15b/0x230 serio_handle_event+0x1c8/0x260 process_one_work+0x215/0x620 worker_thread+0x48/0x3a0 kthread+0xfb/0x130 ret_from_fork+0x3a/0x50 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(psmouse_mutex); lock(kn->count#130); lock(psmouse_mutex); lock(kn->count#130); *** DEADLOCK *** 6 locks held by kworker/0:3/102: #0: ((wq_completion)"events_long"){+.+.}, at: [<000000002e408bfa>] process_one_work+0x191/0x620 #1: (serio_event_work){+.+.}, at: [<000000002e408bfa>] process_one_work+0x191/0x620 #2: (serio_mutex){+.+.}, at: [<00000000c8a49847>] serio_handle_event+0x23/0x260 #3: (&dev->mutex){....}, at: [<00000000b55eee75>] device_release_driver_internal+0x2f/0x230 #4: (&serio->drv_mutex){+.+.}, at: [<000000009719f997>] serio_disconnect_driver+0x16/0x40 #5: (psmouse_mutex){+.+.}, at: [<0000000014f44bcc>] psmouse_disconnect+0x62/0x160 stack backtrace: CPU: 0 PID: 102 Comm: kworker/0:3 Tainted: G U 4.16.0-rc5-g613eb885b69e-drmtip_1+ #1 Hardware name: LENOVO 74591P0/74591P0, BIOS 6DET28WW (1.05 ) 07/30/2008 Workqueue: events_long serio_handle_event Call Trace: dump_stack+0x5f/0x86 print_circular_bug.isra.18+0x1d0/0x2c0 __lock_acquire+0x14ae/0x1b60 ? kernfs_remove_by_name_ns+0x20/0x80 ? lock_acquire+0xaf/0x200 lock_acquire+0xaf/0x200 ? kernfs_remove_by_name_ns+0x3b/0x80 __kernfs_remove+0x243/0x2b0 ? kernfs_remove_by_name_ns+0x3b/0x80 ? kernfs_name_hash+0xd/0x70 ? kernfs_find_ns+0x7e/0x100 kernfs_remove_by_name_ns+0x3b/0x80 remove_files.isra.0+0x2b/0x60 sysfs_remove_group+0x38/0x80 sysfs_remove_groups+0x24/0x40 trackpoint_disconnect+0x2c/0x50 psmouse_disconnect+0x8f/0x160 serio_disconnect_driver+0x28/0x40 serio_driver_remove+0xc/0x10 device_release_driver_internal+0x15b/0x230 serio_handle_event+0x1c8/0x260 process_one_work+0x215/0x620 worker_thread+0x48/0x3a0 ? _raw_spin_unlock_irqrestore+0x4c/0x60 kthread+0xfb/0x130 ? process_one_work+0x620/0x620 ? _kthread_create_on_node+0x30/0x30 ret_from_fork+0x3a/0x50 Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com> Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Arvind Yadav <arvind.yadav.cs@gmail.com>
2024-01-08softdog: Obey hardlockup_all_cpu_backtrace sysctlDaniel Vetter1-0/+2
This is used by the nmi watchdog, but also useful by the softdog when we're trying to figure out where exactly we're stuck. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Imre Deak <imre.deak@intel.com> Cc: Wim Van Sebroeck <wim@iguana.be> Cc: Guenter Roeck <linux@roeck-us.net> Cc: linux-watchdog@vger.kernel.org References: https://bugs.freedesktop.org/show_bug.cgi?id=103160 Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> --- FIXME: Take the && 1 out once CI is configured to enable this. -Daniel
2024-01-08RFC: drm: Restrict vblank ioctl to masterDaniel Vetter1-3/+3
Somehow this escaped us, this is a KMS ioctl which should only be used by the master (which is the thing that's also in control of kms resources). Everything else is bound to result in fail. Clients shouldn't have a trouble coping with this, since a pile of drivers don't support vblank waits (or just randomly fall over when using them). Note that the big motivation for abusing this like mad seems to be that EGL doesn't have OML_sync, but somehow it didn't cross anyone's mind that adding OML_sync to EGL would be useful. This patch is meant to essentially start kicking that can from the back end. Update: Kodi maintainers removed this code on 7th August, to be released in Kodi v18 in Sept 2018. v2: Drop accidental hunk (Michel). v3: Also add the new crtc sequence ioctls that have been added meanwhile ... Cc: Michel Dänzer <michel@daenzer.net> Cc: fritsch@kodi.tv Cc: fernetmenta@kodi.tv Cc: Rainer Hochecker <fernetmenta@kodi.tv> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2024-01-08kernel/latencytop: Add non-scheduler interface for latency reportingDaniel Vetter2-0/+11
Some sources of significant amounts of latency aren't simple sleeps but instead busy-loops or a series of hundreds of small sleeps simply because the hardware can't do better. Unfortunately latencytop doesn't register these and so they slip under the radar. Hence expose a simplified interface to report additional latencies and export the underlying function so that modules can use this. The example I have in mind are edid reads. The drm subsystem exposes both interfaces to do full probes and to just get at the cached state from the last probe and often userspace developers don't know about the difference and incur unecessary big latencies. And usually the i2c transfer is done with busy-looping or if there is a hw engine it might only be able to transfer a few bytes per sleep/irq cycle. And edid reads take at least 12ms and with crappy hw can easily be a few hundred ms. v2: Simplify #ifdefs a bit (Chris). Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2024-01-08drm-tip: 2024y-01m-08d-08h-41m-48s UTC integration manifestDaniel Vetter1-0/+30
2024-01-08Merge remote-tracking branch 'drm-intel/topic/core-for-CI' into drm-tipDaniel Vetter20-65/+149
2024-01-08Merge remote-tracking branch 'drm-intel/drm-intel-gt-next' into drm-tipDaniel Vetter25-186/+177
2024-01-08Merge remote-tracking branch 'drm-intel/drm-intel-next' into drm-tipDaniel Vetter27-406/+387
2024-01-08Merge remote-tracking branch 'drm-misc/drm-misc-next' into drm-tipDaniel Vetter63-641/+2884
2024-01-08Merge remote-tracking branch 'drm-misc/drm-misc-next-fixes' into drm-tipDaniel Vetter1-3/+1
2024-01-08Merge remote-tracking branch 'drm/drm-next' into drm-tipDaniel Vetter1515-23042/+129715
# Conflicts: # drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c # drivers/gpu/drm/i915/display/intel_dmc.c
2024-01-08drm/i915/display: Use helper to select C20 MPLLA/BMika Kahola1-6/+11
We used to select between MPLLA/B with the following state->tx[0] & C20_PHY_USE_MPLLB Since this is used a few places within C20 PLL setting, let's introduce a helper function to clean up the code a bit. Signed-off-by: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240105112243.224199-1-mika.kahola@intel.com
2024-01-07drm/sched: Return an error code only as a constant in drm_sched_init()Markus Elfring1-3/+3
Return an error code without storing it in an intermediate variable. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Link: https://patchwork.freedesktop.org/patch/msgid/85f8004e-f0c9-42d9-8c59-30f1b4e0b89e@web.de Reviewed-by: Luben Tuikov <ltuikov89@gmail.com> Signed-off-by: Luben Tuikov <ltuikov89@gmail.com>
2024-01-07drm/sched: One function call less in drm_sched_init() after error detectionMarkus Elfring1-2/+3
The kfree() function was called in one case by the drm_sched_init() function during error handling even if the passed data structure member contained a null pointer. This issue was detected by using the Coccinelle software. Thus adjust a jump target. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Link: https://patchwork.freedesktop.org/patch/msgid/85066512-983d-480c-a44d-32405ab1b80e@web.de Reviewed-by: Luben Tuikov <ltuikov89@gmail.com> Signed-off-by: Luben Tuikov <ltuikov89@gmail.com>
2024-01-05drm/i915/huc: Allow for very slow HuC loadingJohn Harrison2-11/+63
A failure to load the HuC is occasionally observed where the cause is believed to be a low GT frequency leading to very long load times. So a) increase the timeout so that the user still gets a working system even in the case of slow load. And b) report the frequency during the load to see if that is the cause of the slow down. Also update the similar code on the GuC load to not use uncore->gt when there is a local gt available. The two should match, but no need for unnecessary de-referencing. Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240102222202.310495-1-John.C.Harrison@Intel.com
2024-01-05drm/rockchip: vop2: Drop unused if_dclk_rate variableCristian Ciocaltea1-2/+1
Commit 5a028e8f062f ("drm/rockchip: vop2: Add support for rk3588") introduced a variable which ended up being unused: rockchip_drm_vop2.c:1688:23: warning: variable ‘if_dclk_rate’ set but not used [-Wunused-but-set-variable] This has been initially used as part of a formula to compute the clock dividers, but eventually it has been replaced by static values. Drop the variable declaration and move its assignment to the comment block, to serve as documentation of how the constants have been generated. Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20240105174007.98054-1-cristian.ciocaltea@collabora.com
2024-01-05drm: Move drm_set_preferred_mode() helper from drm_edid to drm_modesJavier Martinez Canillas4-24/+24
The helper is generic, it doesn't use the opaque EDID type struct drm_edid and is also used by drivers that only support non-probeable displays such as fixed panels. These drivers add a list of modes using drm_mode_probed_add() and then set a preferred mode using the drm_set_preferred_mode() helper. It seems more logical to have the helper definition in drm_modes.o instead of drm_edid.o, since the former contains modes helper while the latter has helpers to manage the EDID information. Since both drm_edid.o and drm_modes.o object files are built-in the drm.o object, there are no functional changes. But besides being a more logical place for this helper, it could also allow to eventually make drm_edid.o optional and not included in drm.o if only fixed panels must be supported in a given system. Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240102122208.3103597-1-javierm@redhat.com
2024-01-05drm/i915/xelpg: Add workaround 14019877138Tejas Upadhyay1-0/+3
WA 14019877138 needed for Graphics 12.70/71 both V2(Jani): - Use drm/i915 Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240103053111.763172-1-tejas.upadhyay@intel.com
2024-01-05drm/i915: Disable DSB in Xe KMDJosé Roberto de Souza1-0/+4
Often getting DSB overflows when starting Xorg or Wayland compositors when running Xe KMD. Issue was reported but nothing was done, so disabling DSB as whole until properly fixed in Xe KMD. v2: - move check to HAS_DSB(Jani) v3: - use IS_ENABLED(I915) check in intel_dsb_prepare() Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/989 Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1031 Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1072 Cc: Animesh Manna <animesh.manna@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Francois Dugast <francois.dugast@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240104162411.56085-1-jose.souza@intel.com
2024-01-05drm/i915/tv: use DISPLAY_VER instead of GRAPHICS_VERJani Nikula1-1/+1
Display code should not care about graphics version. It's only comments here, but update anyway. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240104174350.823605-5-jani.nikula@intel.com
2024-01-05drm/i915/display: use IS_DISPLAY_VER instead of IS_GRAPHICS_VERJani Nikula1-1/+1
Display code should not care about graphics version. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240104174350.823605-4-jani.nikula@intel.com
2024-01-05drm/i915/hdcp: use DISPLAY_VER instead of GRAPHICS_VERJani Nikula1-13/+15
Display code should not care about graphics version. While at it, abstract the version check to a separate macro. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240104174350.823605-3-jani.nikula@intel.com
2024-01-05drm/i915/dmc: use DISPLAY_VER instead of GRAPHICS_VERJani Nikula1-1/+1
Display code should not care about graphics version. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240104174350.823605-2-jani.nikula@intel.com
2024-01-05drm/i915/irq: use DISPLAY_VER instead of GRAPHICS_VERJani Nikula1-1/+1
Display code should not care about graphics version. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240104174350.823605-1-jani.nikula@intel.com
2024-01-05drm/i915: don't make assumptions about intel_wakeref_t typeJani Nikula1-2/+2
intel_wakeref_t is supposed to be a mostly opaque cookie to its users. It should only be checked for being non-zero and set to zero. Debug logging its actual value is meaningless. Switch to just debug logging whether the async_put_wakeref is non-zero. The issue dates back to much earlier than commit b49e894c3fd8 ("drm/i915: Replace custom intel runtime_pm tracker with ref_tracker library"), but this is the one that brought about a build failure due to the printf format. Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Closes: https://lore.kernel.org/r/20240102111222.2db11208@canb.auug.org.au Fixes: b49e894c3fd8 ("drm/i915: Replace custom intel runtime_pm tracker with ref_tracker library") Cc: Andrzej Hajda <andrzej.hajda@intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240104164600.783371-1-jani.nikula@intel.com
2024-01-05drm/edid: prefer forward declarations over includes in drm_edid.hJani Nikula1-7/+5
There's no need to include either linux/hdmi.h or drm/drm_mode.h. They can be removed by using forward declarations. While at it, group the forward declarations together, and remove the unnecessary ones. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20240104211028.1129606-1-jani.nikula@intel.com
2024-01-05drm/nouveau/dp: Honor GSP link training retry timeoutsLyude Paul1-22/+42
Turns out that one of the ways that Nvidia's driver handles the pre-LT timeout for eDP panels is by providing a retry timeout in their link training callbacks that we're expected to wait for. Up until now we didn't pay any attention to this parameter. So, start honoring the timeout if link training fails - and retry up to 3 times. The "3 times" bit comes from OpenRM's link training code. [airlied: this fixes the panel on one of my laptops] Signed-off-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231222043308.3090089-12-airlied@gmail.com
2024-01-05nouveau: push event block/allowing out of the fence contextDave Airlie2-6/+27
There is a deadlock between the irq and fctx locks, the irq handling takes irq then fctx lock the fence signalling takes fctx then irq lock This splits the fence signalling path so the code that hits the irq lock is done in a separate work queue. This seems to fix crashes/hangs when using nouveau gsp with i915 primary GPU. Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231222043308.3090089-11-airlied@gmail.com
2024-01-05nouveau/gsp: always free the alloc messages on r535Dave Airlie1-2/+1
Fixes a memory leak seen with kmemleak. Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231222043308.3090089-10-airlied@gmail.com
2024-01-05nouveau/gsp: don't free ctrl messages on errorsDave Airlie3-61/+100
It looks like for some messages the upper layers need to get access to the results of the message so we can interpret it. Rework the ctrl push interface to not free things and cleanup properly whereever it errors out. Requested-by: Lyude Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231222043308.3090089-9-airlied@gmail.com
2024-01-05nouveau/gsp: convert gsp errors to generic errorsDave Airlie1-5/+21
This should let the upper layers retry as needed on EAGAIN. There may be other values we will care about in the future, but this covers our present needs. Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231222043308.3090089-8-airlied@gmail.com
2024-01-05drm/nouveau/gsp: Fix ACPI MXDM/MXDS method invocationsLyude Paul1-2/+8
Currently we get an error from ACPI because both of these arguments expect a single argument, and we don't provide one. I'm not totally clear on what that argument does, but we're able to find the missing value from _acpiCacheMethodData() in src/kernel/platform/acpi_common.c in nvidia's driver. So, let's add that - which doesn't get eDP displays to power on quite yet, but gets rid of the argument warning at least. Signed-off-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231222043308.3090089-7-airlied@gmail.com
2024-01-05nouveau/gsp: free userd allocation.Dave Airlie1-0/+1
This was being leaked. Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231222043308.3090089-6-airlied@gmail.com
2024-01-05nouveau/gsp: free acpi object after useDave Airlie1-0/+1
This fixes a memory leak for the acpi dod object. Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231222043308.3090089-5-airlied@gmail.com
2024-01-05nouveau: fix disp disabling with GSPDave Airlie1-2/+4
This func ptr here is normally static allocation, but gsp r535 uses a dynamic pointer, so we need to handle that better. This fixes a crash with GSP when you use config=disp=0 to avoid disp problems. Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231222043308.3090089-4-airlied@gmail.com
2024-01-05nouveau/gsp: drop some acpi related debugDave Airlie2-16/+0
These were leftover debug, if we need to bring them back do so for debugging later. Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231222043308.3090089-3-airlied@gmail.com
2024-01-05nouveau/gsp: add three notifier callbacks that we see in normal operation (v2)Dave Airlie1-2/+5
Add NULL callbacks for some things GSP calls that we don't handle, but know about so we avoid the logging. v2: Timur suggested allowing null fn. Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231222043308.3090089-2-airlied@gmail.com
2024-01-05Merge tag 'amd-drm-fixes-6.7-2024-01-04' of ↵Dave Airlie9-85/+400
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes amdgpu: - DP MST fix - SMU 13.0.6 fixes - Fix displays on macbooks using vega12 - Fix VSC and colorimetry on DP/eDP Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240104152139.4931-1-alexander.deucher@amd.com
2024-01-05Merge tag 'drm-misc-next-fixes-2024-01-04' of ↵Dave Airlie5-65/+79
git://anongit.freedesktop.org/drm/drm-misc into drm-next One fix for drm/plane to avoid a use-after-free and some additional warnings to prevent more of these occurences, a lock inversion dependency fix and an indentation fix for drm/rockchip, and some doc warning fixes for imagination and gpuvm. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maxime Ripard <mripard@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/enhl33v2oeihktta2yfyc4exvezdvm3eexcuwxkethc5ommrjo@lkidkv2kwakq
2024-01-04drm/i915/dp: Fix the PSR debugfs entries wrt. MST connectorsImre Deak1-5/+5
MST connectors don't have a static attached encoder, as their encoder can change depending on the pipe they use; so the encoder for an MST connector can't be retrieved using intel_dp_attached_encoder() (which may return NULL for MST). Most of the PSR debugfs entries depend on a static connector -> encoder mapping which is only true for eDP and SST DP connectors and not for MST. These debugfs entries were enabled for MST connectors as well recently to provide PR information for them, but handling MST connectors needs more changes. Fix this by not adding for now the PSR entries on MST connectors. To make things more uniform add the entries for SST connectors on all platforms, not just on platforms supporting DP2.0. v2: - Keep adding the entries for SST connectors. (Jouni) - Add a TODO: comment for MST support. Fixes: ef75c25e8fed ("drm/i915/panelreplay: Debugfs support for panel replay") Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9850 Cc: Animesh Manna <animesh.manna@intel.com> Cc: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240103152609.2434100-1-imre.deak@intel.com
2024-01-04drm/rockchip: vop2: Drop superfluous includeCristian Ciocaltea1-1/+0
The rockchip_drm_fb.h header contains just a single function which is not directly used by the VOP2 driver. Drop the unnecessary include. Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20240104143951.85219-1-cristian.ciocaltea@collabora.com
2024-01-04drm/panel: ltk050h3146w: use dev_err_probe wherever possibleQuentin Schulz1-12/+5
This is only a cosmetic change. This replaces a hand-crafted EPROBE_DEFER handling for deciding to print an error message with dev_err_probe. A side-effect is that dev_err_probe also adds a debug message when it's not EPROBE_DEFER, but this is seen as an improvement. Cc: Quentin Schulz <foss+kernel@0leil.net> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com> Reviewed-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20240104-ltk-dev_err_probe-v1-2-8ef3c0b585d8@theobroma-systems.com
2024-01-04drm/panel: ltk050h3146w: only print message when GPIO getting is not ↵Quentin Schulz1-4/+2
EPROBE_DEFER devm_gpiod_get_optional may return EPROBE_DEFER in case the GPIO controller isn't yet probed when the panel driver is being probed. In that case, a spurious and confusing error message about not being able to get the reset GPIO is printed even though later on the device actually manages to get probed. Use dev_err_probe instead so that the message is only printed when it truly matters. Cc: Quentin Schulz <foss+kernel@0leil.net> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com> Reviewed-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20240104-ltk-dev_err_probe-v1-1-8ef3c0b585d8@theobroma-systems.com