On Mon, Jun 17, 2013 at 4:33 PM, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> wrote: > On Sun, Jun 16, 2013 at 04:57:17PM +0200, Daniel Vetter wrote: >> Hi all, >> >> So I've taken a look again at the locking mess in our fbdev support and cried. >> Fixing up the console_lock mess around the fbdev notifier will be real work, >> semanatically the fbdev layer does lots of stupid things (like the radeon resume >> issue I've just debugged) and the panic notifier is pretty much a lost cause. >> >> So I've decided to instead rip it all out. It seems to work \o/ > > > When you say 'locking mess in our fbdev support' you mean the general > core fbdev driver? Not neccessarily the i915 driver? > > I am asking b/c that would imply that the other fbdev drivers still hit > the locking mess? Yeah, the recent thing I've stumbled over is how the the fbdev/fbcon locking proliferates console_lock protected sections like mad. Which means that the initial modeset (for fbcon) is all done with the console_lock held. Which makes debugging things in that rather tricky code a mess. So nothing i915-specifc. -Daniel > > Thanks! >> >> Of course a general purpose distro propably wants David's kmscon for any >> fallbacks needs and a system compositor to ditch the VT subsystem - atm my >> machine here runs with the dummy console so that VT switching between different >> X sessions still works ;-) >> >> Oh and: At least fedora's boot splash seems to be unhappy about the lack of an >> fbdev (it doesn't seem to do anything), which breaks early disk encryption a >> bit. The black screen itself shouldn't be a big issue at least for i915, since >> with all the fastboot work we can just hang onto the current config and >> framebuffer (one missing patch from Chris for the fb preservartion). So as long >> as the bios/grub put up something nice, it'll look ok. >> >> So just a small step here really, but imo into the right direction. Now, please >> bring on the flames! >> >> Aside: We can hide the #ifdef mess a bit better in drm/i915 I think, but I'd >> like to wait for a bit of feedback first. And one more: This also removes the >> console_lock completely from our critical path in suspend/resume! >> >> One thing I haven't wasted a single thought about is kgdb and panic notifier >> support. But since the current code is pretty decently broken already (we have >> _tons_ of mutex grabbing and waits in there) I don't think people care that much >> about it anyway. Using a sprite to smash the kgdb/panic output on top of >> whatever's currently displaying might be an approach. >> >> Cheers, Daniel >> >> Daniel Vetter (3): >> drm: Add separate Kconfig option for fbdev helpers >> drm/i915: Kconfig option to disable the legacy fbdev support >> drm/i915: rename intel_fb.c to intel_fbdev.c >> >> drivers/gpu/drm/Kconfig | 57 ++----- >> drivers/gpu/drm/Makefile | 3 +- >> drivers/gpu/drm/ast/Kconfig | 1 + >> drivers/gpu/drm/cirrus/Kconfig | 1 + >> drivers/gpu/drm/exynos/Kconfig | 1 + >> drivers/gpu/drm/gma500/Kconfig | 1 + >> drivers/gpu/drm/i915/Kconfig | 56 +++++++ >> drivers/gpu/drm/i915/Makefile | 3 +- >> drivers/gpu/drm/i915/i915_debugfs.c | 4 +- >> drivers/gpu/drm/i915/i915_dma.c | 8 +- >> drivers/gpu/drm/i915/i915_drv.h | 2 + >> drivers/gpu/drm/i915/intel_display.c | 12 +- >> drivers/gpu/drm/i915/intel_drv.h | 39 ++++- >> drivers/gpu/drm/i915/intel_fb.c | 314 ----------------------------------- >> drivers/gpu/drm/i915/intel_fbdev.c | 314 +++++++++++++++++++++++++++++++++++ >> drivers/gpu/drm/mgag200/Kconfig | 1 + >> drivers/gpu/drm/nouveau/Kconfig | 1 + >> drivers/gpu/drm/omapdrm/Kconfig | 1 + >> drivers/gpu/drm/qxl/Kconfig | 1 + >> drivers/gpu/drm/shmobile/Kconfig | 1 + >> drivers/gpu/drm/tilcdc/Kconfig | 1 + >> drivers/gpu/drm/udl/Kconfig | 1 + >> drivers/gpu/host1x/drm/Kconfig | 1 + >> drivers/staging/imx-drm/Kconfig | 1 + >> 24 files changed, 452 insertions(+), 373 deletions(-) >> create mode 100644 drivers/gpu/drm/i915/Kconfig >> delete mode 100644 drivers/gpu/drm/i915/intel_fb.c >> create mode 100644 drivers/gpu/drm/i915/intel_fbdev.c >> >> -- >> 1.7.11.7 >> >> _______________________________________________ >> dri-devel mailing list >> dri-devel@xxxxxxxxxxxxxxxxxxxxx >> http://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
