search for: rmfb

...reasons we've stopped doing that, but that turned out to be a mistake. It's fixed since commit f2d580b9a8149735cbc4b59c4a8df60173658140 Author: Maarten Lankhorst <maarten.lankhorst at linux.intel.com> Date: Wed May 4 14:38:26 2016 +0200 drm/core: Do not preserve framebuffer on rmfb, v4. Your patch shouldn't be needed with that any more. If it still is it's most likely the fbdev cleanup done too late, but you /should/ get a big WARNING splat in that case from drm_mode_config_cleanup(). -Daniel > --- > drivers/gpu/drm/drm_crtc.c | 13 ++++++++++++- > 1 file...

...be >> a mistake. It's fixed since >> >> commit f2d580b9a8149735cbc4b59c4a8df60173658140 >> Author: Maarten Lankhorst <maarten.lankhorst at linux.intel.com> >> Date: Wed May 4 14:38:26 2016 +0200 >> >> drm/core: Do not preserve framebuffer on rmfb, v4. >> >> Your patch shouldn't be needed with that any more. If it still is it's >> most likely the fbdev cleanup done too late, but you /should/ get a big >> WARNING splat in that case from drm_mode_config_cleanup(). > > I tested it and at least with nouveau,...

...t, but that turned out to be > a mistake. It's fixed since > > commit f2d580b9a8149735cbc4b59c4a8df60173658140 > Author: Maarten Lankhorst <maarten.lankhorst at linux.intel.com> > Date: Wed May 4 14:38:26 2016 +0200 > > drm/core: Do not preserve framebuffer on rmfb, v4. > > Your patch shouldn't be needed with that any more. If it still is it's > most likely the fbdev cleanup done too late, but you /should/ get a big > WARNING splat in that case from drm_mode_config_cleanup(). I tested it and at least with nouveau, the above-mentioned com...

...s fixed since > >> > >> commit f2d580b9a8149735cbc4b59c4a8df60173658140 > >> Author: Maarten Lankhorst <maarten.lankhorst at linux.intel.com> > >> Date: Wed May 4 14:38:26 2016 +0200 > >> > >> drm/core: Do not preserve framebuffer on rmfb, v4. > >> > >> Your patch shouldn't be needed with that any more. If it still is it's > >> most likely the fbdev cleanup done too late, but you /should/ get a big > >> WARNING splat in that case from drm_mode_config_cleanup(). > > > > I tested...

...t, but that turned out to be > a mistake. It's fixed since > > commit f2d580b9a8149735cbc4b59c4a8df60173658140 > Author: Maarten Lankhorst <maarten.lankhorst at linux.intel.com> > Date: Wed May 4 14:38:26 2016 +0200 > > drm/core: Do not preserve framebuffer on rmfb, v4. Okay, I will test it. May I ask you a question while you have this topic swapped into your brain: nouveau, radeon and amdgpu currently hold one runtime pm ref if any crtc is turned on. I'm pondering how to make this work for muxed dual GPU laptops. When switching GPUs, the now inactive G...

In preparation for runtime pm on muxed dual GPU laptops, I've fixed all runtime pm ref leaks I could find in nouveau, radeon and amdgpu. To ease reviewing, I've pushed this series to GitHub: https://github.com/l1k/linux/commits/drm_runpm_fixes_v1 @Alex Deucher: I do not have an AMD GPU so couldn't test this beyond verifying that it compiles. Please double-check the patches and test

...t; > > >> commit f2d580b9a8149735cbc4b59c4a8df60173658140 > > >> Author: Maarten Lankhorst <maarten.lankhorst at linux.intel.com> > > >> Date: Wed May 4 14:38:26 2016 +0200 > > >> > > >> drm/core: Do not preserve framebuffer on rmfb, v4. > > >> > > >> Your patch shouldn't be needed with that any more. If it still is it's > > >> most likely the fbdev cleanup done too late, but you /should/ get a big > > >> WARNING splat in that case from drm_mode_config_cleanup(). > &gt...

Hi all, First thing first: It works, I now no longer have a few dropped frames every 10s on my testbox here with the pageflip i-g-t tests. Random notes: - New design has per-crtc locks to protect the crtc input-side (pageflip, cursor) for r/w and the output state of the crtc (mode, dpms) as read-only. It also required completely revamped fb lifecycle management, those are now refcounted