Re: [Intel-gfx] [PATCH 0/3] fbdev no more!
On Mon, Jun 17, 2013 at 4:33 PM, Konrad Rzeszutek Wilk konrad.w...@oracle.com 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-de...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/3] fbdev no more!
Hi On Sun, Jun 16, 2013 at 4:57 PM, Daniel Vetter daniel.vet...@ffwll.ch 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. Hint: Take a look at fbdev ref-counting or sysfs integration. Totally broken, too. I sometimes really wonder how that still works. So I've decided to instead rip it all out. It seems to work \o/ Yep, works for me pretty well, too. 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 ;-) I used CONFIG_VT=n for quite a while with user-space VTs as replacement. But what we really need is a system-compositor (even if it's not really a compositor). But for that we need dynamic modeset nodes or we end up with the same problems as with VTs. It's on my TODO list after render/modeset nodes are done. With user-space VTs this is even backwards-compatible. 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. Plymouth should work just fine with KMS (afaik it was even airlied who wrote the backends). It doesn't support GPU hotplugging, though. So it's probably started before i915 is loaded and so doesn't pick up the DRM device. Or with initrd user-space is started early without waiting for device-initialization to finish. So even with i915 built-in it may run before card0 shows up. The journal-log should probably help debugging this. Btw., It has /dev/dri/card0 hard-coded and only tries opening it once during startup. So just a small step here really, but imo into the right direction. Now, please bring on the flames! Please, apply it! Now! Thanks David 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-de...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/3] fbdev no more!
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-de...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/3] fbdev no more!
Hi On Mon, Jun 17, 2013 at 10:47 PM, Andy Lutomirski l...@amacapital.net wrote: On 06/16/2013 07:57 AM, 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/ I wonder how badly this breaks on EFI systems. Currently, efifb is an fbdev driver. When i915 calls register_framebuffer, the fbdev core removes efifb's framebuffer. (This is scary already -- what if i915 has reused that memory for something else beforehand?) But now, if i915 doesn't call register_framebuffer, the efifb framebuffer might stick around forever. See the i915 Patch (2/3). It still calls remove_conflicting_framebuffers() if CONFIG_FB is enabled. This will kick out efifb regardless whether i915-fbdev support is enabled or not. Presumably, efifb ought to become a framebuffer-only drm driver and there should be a saner way to hand control from efifb (or vesa?) to a real driver. Already working on it. Regards David ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
