forked from Minki/linux
0faa4a8777
So if we survey kms drivers there's a bunch of things they commonly do in ->lastclose - delayed processing of vga switcheroo requests (i915, nouveau, radeon) - force-restoring the fbcon (most) - resetting a bunch properties to make fbcon work better (omap) - disabling all outputs (vmwgfx) In short besides the semantically important vga switcheroo stuff they all try very hard to keep fbcon working in case X dies. But none of them try to not do this at driver unload time safe for vmwgfx, and digging through logs I couldn't find any reason for why vmwgfx is special. Since ->firstopen has lots of potential for abuse with kms drivers (like delaying driver setup to pamper over races in the load sequence) it's imo very much worth it to remove this logic so that we can stop using the ->firstopen callback for kms drivers. Also module unloading is rather a debug feature and developers should know how to restore the display to a sane configuration. Cc: Jakob Bornecrantz <jakob@vmware.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com> |
||
|---|---|---|
| .. | ||
| Kconfig | ||
| Makefile | ||
| svga3d_reg.h | ||
| svga3d_surfacedefs.h | ||
| svga_escape.h | ||
| svga_overlay.h | ||
| svga_reg.h | ||
| svga_types.h | ||
| vmwgfx_buffer.c | ||
| vmwgfx_context.c | ||
| vmwgfx_dmabuf.c | ||
| vmwgfx_drv.c | ||
| vmwgfx_drv.h | ||
| vmwgfx_execbuf.c | ||
| vmwgfx_fb.c | ||
| vmwgfx_fence.c | ||
| vmwgfx_fence.h | ||
| vmwgfx_fifo.c | ||
| vmwgfx_gmr.c | ||
| vmwgfx_gmrid_manager.c | ||
| vmwgfx_ioctl.c | ||
| vmwgfx_irq.c | ||
| vmwgfx_kms.c | ||
| vmwgfx_kms.h | ||
| vmwgfx_ldu.c | ||
| vmwgfx_marker.c | ||
| vmwgfx_overlay.c | ||
| vmwgfx_reg.h | ||
| vmwgfx_resource_priv.h | ||
| vmwgfx_resource.c | ||
| vmwgfx_scrn.c | ||
| vmwgfx_surface.c | ||
| vmwgfx_ttm_glue.c | ||