Re: [PATCH 0/3] fbdev no more!

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

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@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel