similar to: [PATCH v2 0/9] drm/{amdgpu,nouveau}: Remove old fbdev hooks

After switching all drivers' fbdev emulation to DRM client, the old fbdev hooks are now obsolete. Only amgdpu and nouveau still use them in a several places. Remove the hooks from the drivers and the DRM core. The series would ideally be merged at once via drm-misc-next. Thomas Zimmermann (8): drm/fbdev-helper: Do delayed switcheroo in lastclose helper drm/amdgpu: Do not set struct

The old callbacks lastclose and output_poll_changed are deprecated and unused. Remove them from the documentation. Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de> --- drivers/gpu/drm/drm_fb_helper.c | 22 +++++++--------------- 1 file changed, 7 insertions(+), 15 deletions(-) diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c index

Remove the implementation of struct drm_driver.lastclose. The hook was only necessary before in-kernel DRM clients existed, but is now obsolete. The code in amdgpu_driver_lastclose_kms() is performed by drm_lastclose(). v2: - update commit message Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de> --- drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 -

The function is unused. Remove it. Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de> --- drivers/gpu/drm/drm_fb_helper.c | 15 --------------- include/drm/drm_fb_helper.h | 6 ------ 2 files changed, 21 deletions(-) diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c index fe5667477839..29c53f9f449c 100644 --- a/drivers/gpu/drm/drm_fb_helper.c +++

On Mon, Aug 12, 2024 at 4:30?AM Thomas Zimmermann <tzimmermann at suse.de> wrote: > > Remove the implementation of struct drm_driver.lastclose. The hook > was only necessary before in-kernel DRM clients existed, but is now > obsolete. The code in amdgpu_driver_lastclose_kms() is performed by > drm_lastclose(). > > v2: > - update commit message > > Signed-off-by:

Remove the implementation of struct drm_driver.lastclose. The hook was only necessary before in-kernel DRM clients existed, but is now obsolete. The code in nouveau_vga_lastclose() is performed by drm_lastclose(). v2: - update commit description Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de> --- drivers/gpu/drm/nouveau/nouveau_drm.c | 1 - drivers/gpu/drm/nouveau/nouveau_vga.c

Amdgpu and nouveau call vga_switcheroo_process_delayed_switch() from their lastclose callbacks. Call it from drm_lastclose(), so that the driver functions can finally be removed. Only PCI devices with enabled switcheroo do the delayed switching. The call has no effect on other hardware. v2: - move change to drm_lastclose() (Sima) - update docs for vga_switcheroo_process_delayed_switch()

This is a trimmed down version of https://patchwork.freedesktop.org/series/46637/ with all of the review comments addressed. The last version of this series had fixes for the i2c and DP aux busses to ensure that the GPU would be turned on whenever anything tried to access the i2c/aux busses. Unfortunately: one of the fixes apparently contained some very incorrect usage of Linux's runtime PM

On Wed, Jul 18, 2018 at 04:56:39PM -0400, Lyude Paul wrote: > When DP MST hubs get confused, they can occasionally stop responding for > a good bit of time up until the point where the DRM driver manages to > do the right DPCD accesses to get it to start responding again. In a > worst case scenario however, this process can take upwards of 10+ > seconds. > > Currently we use

Replace the call to drm_fb_helper_output_poll_changed() with a call to drm_client_dev_hotplug(). It is equivalent in functionality, but uses the DRM client infrastructure. v2: - fix commit description Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de> Reviewed-by: Daniel Vetter <daniel.vetter at ffwll.ch> --- drivers/gpu/drm/nouveau/nouveau_vga.c | 3 ++- 1 file changed, 2

On Mon, Aug 12, 2024 at 10:28:22AM +0200, Thomas Zimmermann wrote: > Amdgpu and nouveau call vga_switcheroo_process_delayed_switch() from > their lastclose callbacks. Call it from drm_lastclose(), so that the > driver functions can finally be removed. Only PCI devices with enabled > switcheroo do the delayed switching. The call has no effect on other > hardware. > > v2: >

On 8/12/24 10:28 AM, Thomas Zimmermann wrote: > Replace the call to drm_fb_helper_output_poll_changed() with a call > to drm_client_dev_hotplug(). It is equivalent in functionality, but > uses the DRM client infrastructure. > > v2: > - fix commit description > > Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de> > Reviewed-by: Daniel Vetter

Hi Am 12.08.24 um 14:17 schrieb Danilo Krummrich: > On 8/12/24 10:28 AM, Thomas Zimmermann wrote: >> Replace the call to drm_fb_helper_output_poll_changed() with a call >> to drm_client_dev_hotplug(). It is equivalent in functionality, but >> uses the DRM client infrastructure. >> >> v2: >> - fix commit description >> >> Signed-off-by: Thomas

On Mon, Aug 12, 2024 at 11:23:44AM +0200, Daniel Vetter wrote: > On Mon, Aug 12, 2024 at 10:28:22AM +0200, Thomas Zimmermann wrote: > > Amdgpu and nouveau call vga_switcheroo_process_delayed_switch() from > > their lastclose callbacks. Call it from drm_lastclose(), so that the > > driver functions can finally be removed. Only PCI devices with enabled > > switcheroo do

Hi Am 12.08.24 um 12:18 schrieb Daniel Vetter: > On Mon, Aug 12, 2024 at 11:23:44AM +0200, Daniel Vetter wrote: >> On Mon, Aug 12, 2024 at 10:28:22AM +0200, Thomas Zimmermann wrote: >>> Amdgpu and nouveau call vga_switcheroo_process_delayed_switch() from >>> their lastclose callbacks. Call it from drm_lastclose(), so that the >>> driver functions can finally be

On Mon, Aug 12, 2024 at 12:41:39PM +0200, Thomas Zimmermann wrote: > Hi > > Am 12.08.24 um 12:18 schrieb Daniel Vetter: > > On Mon, Aug 12, 2024 at 11:23:44AM +0200, Daniel Vetter wrote: > > > On Mon, Aug 12, 2024 at 10:28:22AM +0200, Thomas Zimmermann wrote: > > > > Amdgpu and nouveau call vga_switcheroo_process_delayed_switch() from > > > > their

On Mon, Jul 30, 2018 at 08:39:48PM -0400, Lyude Paul wrote: > I'm sure I don't need to tell you that fb_helper's locking is a mess. > That being said; fb_helper's locking mess can seriously complicate the > runtime suspend/resume operations of drivers because it can invoke > atomic commits and connector probing from anywhere that calls >

This is the latest version of https://patchwork.freedesktop.org/series/46815/ I moved everything out of fb_helper and back into nouveau, because it seems that other drivers actually do have this handled already as far as I can tell. Lyude Paul (13): drm/nouveau: Fix bogus drm_kms_helper_poll_enable() placement drm/nouveau: Remove duplicate poll_enable() in pmops_runtime_suspend()

This is the next version of https://patchwork.freedesktop.org/series/46815/ With a lot more thought put into it so as to avoid the potential deadlock scenarios I missed. This also required fixing some bogus DRM helper usage. Try and deadlock me now, nouveau. I dare you!!! Lyude Paul (8): drm/nouveau: Fix bogus drm_kms_helper_poll_enable() placement drm/nouveau: Enable polling even if we

On Mon, Aug 13, 2018 at 03:16:43PM -0400, Lyude Paul wrote: > I'm sure I don't need to tell you that fb_helper's locking is a mess. Uh, loaded statement :-) Especially since we've just reworked all the fbdev locking to untangle it from drm_modeset locking. What's still a mess about it? It's documented, and very clearly wrapped around all the drm_modeset locks. If