[Intel-gfx] [PATCH 0/3] fbdev no more!
Konrad Rzeszutek Wilk
konrad.wilk at oracle.com
Mon Jun 17 16:33:31 CEST 2013
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?
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 at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
More information about the Intel-gfx
mailing list