Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1278846 > unrolled thread

[PATCH RESEND 2/2] drm/i915: prevent the vgacon from ever reloading

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [PATCH RESEND 2/2] drm/i915: prevent the vgacon from ever reloading Daniel Vetter <daniel.vetter@ffwll.ch> - 2015-11-27 16:20 +0100
    Re: [PATCH RESEND 2/2] drm/i915: prevent the vgacon from ever reloading Emil Velikov <emil.l.velikov@gmail.com> - 2015-11-27 16:50 +0100
      Re: [PATCH RESEND 2/2] drm/i915: prevent the vgacon from ever reloading Ilia Mirkin <imirkin@alum.mit.edu> - 2015-11-28 01:40 +0100
        Re: [PATCH RESEND 2/2] drm/i915: prevent the vgacon from ever  reloading Daniel Vetter <daniel@ffwll.ch> - 2015-11-29 13:50 +0100
          Re: [PATCH RESEND 2/2] drm/i915: prevent the vgacon from ever reloading Emil Velikov <emil.l.velikov@gmail.com> - 2015-11-29 15:20 +0100

#1278846 — [PATCH RESEND 2/2] drm/i915: prevent the vgacon from ever reloading

It only leads to bloodshed and tears - we don't bother to restore a
working legacy vga hw setup.

On haswell with the new dynamic power well code this leads to even
more hilarity since for some configurations the hardware is simply no
longer there.

The actual implementation is a bit a hack - we realy on fbcon to kick
out the vgacon. To make this also work with I915_FBDEV=n (or FBCON=n)
and VGA_CONSOLE=y i915 already unregisters the vga console manually
early in the driver load sequence.

Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Paulo Zanoni <przanoni@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67813
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
---
 drivers/gpu/drm/i915/i915_dma.c    | 1 +
 drivers/gpu/drm/i915/intel_fbdev.c | 3 +++
 drivers/video/console/vgacon.c     | 9 +++++++++
 include/linux/console.h            | 2 ++
 4 files changed, 15 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index a81c76603544..c6a154dc1070 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -45,6 +45,7 @@
 #include <linux/pnp.h>
 #include <linux/vga_switcheroo.h>
 #include <linux/slab.h>
+#include <linux/console.h>
 #include <acpi/video.h>
 #include <linux/pm.h>
 #include <linux/pm_runtime.h>
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c b/drivers/gpu/drm/i915/intel_fbdev.c
index 7ccde58f8c98..0ca6d3852f4f 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -717,6 +717,9 @@ static void intel_fbdev_initial_config(void *data, async_cookie_t cookie)
 	if (drm_fb_helper_initial_config(&ifbdev->helper,
 					 ifbdev->preferred_bpp))
 		intel_fbdev_fini(dev_priv->dev);
+
+	/* Need to do this after fbcon setup for "smooth" takeover. */
+	vgacon_unregister();
 }
 
 void intel_fbdev_initial_config_async(struct drm_device *dev)
diff --git a/drivers/video/console/vgacon.c b/drivers/video/console/vgacon.c
index 517f565b65d7..86aef3195135 100644
--- a/drivers/video/console/vgacon.c
+++ b/drivers/video/console/vgacon.c
@@ -1416,6 +1416,15 @@ static int vgacon_dummy(struct vc_data *c)
 	return 0;
 }
 
+/*
+ * Used by drivers which wreak utter havoc to the legacy vga state to prevent
+ * the vga console driver from ever reloading.
+ */
+void vgacon_unregister(void)
+{
+	give_up_console(&vga_con);
+}
+EXPORT_SYMBOL(vgacon_unregister);
 #define DUMMY (void *) vgacon_dummy
 
 const struct consw vga_con = {
diff --git a/include/linux/console.h b/include/linux/console.h
index 44b7fe8a2dbb..79fb65b6beb7 100644
--- a/include/linux/console.h
+++ b/include/linux/console.h
@@ -190,8 +190,10 @@ void vcs_remove_sysfs(int index);
 
 #ifdef CONFIG_VGA_CONSOLE
 extern bool vgacon_text_force(void);
+extern void vgacon_unregister(void);
 #else
 static inline bool vgacon_text_force(void) { return false; }
+static inline void vgacon_unregister(void) {}
 #endif
 
 #endif /* _LINUX_CONSOLE_H */
-- 
2.5.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1278855

On 27 November 2015 at 15:10, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> It only leads to bloodshed and tears - we don't bother to restore a
> working legacy vga hw setup.
>
> On haswell with the new dynamic power well code this leads to even
> more hilarity since for some configurations the hardware is simply no
> longer there.
>
> The actual implementation is a bit a hack - we realy on fbcon to kick
> out the vgacon. To make this also work with I915_FBDEV=n (or FBCON=n)
> and VGA_CONSOLE=y i915 already unregisters the vga console manually
> early in the driver load sequence.
>
Interesting... nv50 and later GPUs are in a roughly similar shame
afaict. They lack the dedicated hardware and no one really bothered
figuring out how to restore things to a working shape [1].

Then again, upon sequential load of the nouveau module the GPU gets
initialised properly, where you can get X (weston?) up and running
without issues. Am I thinking about a different thing ?

I take it that you guys do less of the (re)initialisation dance, to
ensure faster boot times ?

Thanks,
Emil

[1] http://nouveau.freedesktop.org/wiki/KernelModeSetting/#deactivatingkmsandunloadingnouveau
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1279047

On Fri, Nov 27, 2015 at 10:40 AM, Emil Velikov <emil.l.velikov@gmail.com> wrote:
> On 27 November 2015 at 15:10, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
>> It only leads to bloodshed and tears - we don't bother to restore a
>> working legacy vga hw setup.
>>
>> On haswell with the new dynamic power well code this leads to even
>> more hilarity since for some configurations the hardware is simply no
>> longer there.
>>
>> The actual implementation is a bit a hack - we realy on fbcon to kick
>> out the vgacon. To make this also work with I915_FBDEV=n (or FBCON=n)
>> and VGA_CONSOLE=y i915 already unregisters the vga console manually
>> early in the driver load sequence.
>>
> Interesting... nv50 and later GPUs are in a roughly similar shame
> afaict. They lack the dedicated hardware and no one really bothered
> figuring out how to restore things to a working shape [1].
>
> Then again, upon sequential load of the nouveau module the GPU gets
> initialised properly, where you can get X (weston?) up and running
> without issues. Am I thinking about a different thing ?
>
> I take it that you guys do less of the (re)initialisation dance, to
> ensure faster boot times ?
>
> Thanks,
> Emil
>
> [1] http://nouveau.freedesktop.org/wiki/KernelModeSetting/#deactivatingkmsandunloadingnouveau

FWIW it's possible to unload nouveau, at which point your screen turns
off (because we can't restore the vga emulation junk... haven't the
faintest clue how it works), and then reload it, at which point fbcon
gets rebound and is completely happy. I can't tell what this patch is
doing, but for your own sanity, you should support unloading/reloading
i915 as well.

  -ilia
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1279329 — Re: [PATCH RESEND 2/2] drm/i915: prevent the vgacon from ever reloading

On Fri, Nov 27, 2015 at 07:37:53PM -0500, Ilia Mirkin wrote:
> On Fri, Nov 27, 2015 at 10:40 AM, Emil Velikov <emil.l.velikov@gmail.com> wrote:
> > On 27 November 2015 at 15:10, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> >> It only leads to bloodshed and tears - we don't bother to restore a
> >> working legacy vga hw setup.
> >>
> >> On haswell with the new dynamic power well code this leads to even
> >> more hilarity since for some configurations the hardware is simply no
> >> longer there.
> >>
> >> The actual implementation is a bit a hack - we realy on fbcon to kick
> >> out the vgacon. To make this also work with I915_FBDEV=n (or FBCON=n)
> >> and VGA_CONSOLE=y i915 already unregisters the vga console manually
> >> early in the driver load sequence.
> >>
> > Interesting... nv50 and later GPUs are in a roughly similar shame
> > afaict. They lack the dedicated hardware and no one really bothered
> > figuring out how to restore things to a working shape [1].
> >
> > Then again, upon sequential load of the nouveau module the GPU gets
> > initialised properly, where you can get X (weston?) up and running
> > without issues. Am I thinking about a different thing ?
> >
> > I take it that you guys do less of the (re)initialisation dance, to
> > ensure faster boot times ?
> >
> > Thanks,
> > Emil
> >
> > [1] http://nouveau.freedesktop.org/wiki/KernelModeSetting/#deactivatingkmsandunloadingnouveau
> 
> FWIW it's possible to unload nouveau, at which point your screen turns
> off (because we can't restore the vga emulation junk... haven't the
> faintest clue how it works), and then reload it, at which point fbcon
> gets rebound and is completely happy. I can't tell what this patch is
> doing, but for your own sanity, you should support unloading/reloading
> i915 as well.

We do of course support unloading/reloading. And we do the same "shut
everything down" like nouveau seems to do. The problem though on some hw
is that if vgacon then tries to access the registers the hw dies. So the
problem we have with not restoring VGA functionality isn't that the screen
is black when i915.ko is unloaded, but that the machine dies. This patch
fixes that.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1279342

On 29 November 2015 at 12:47, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Fri, Nov 27, 2015 at 07:37:53PM -0500, Ilia Mirkin wrote:
>> On Fri, Nov 27, 2015 at 10:40 AM, Emil Velikov <emil.l.velikov@gmail.com> wrote:
>> > On 27 November 2015 at 15:10, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
>> >> It only leads to bloodshed and tears - we don't bother to restore a
>> >> working legacy vga hw setup.
>> >>
>> >> On haswell with the new dynamic power well code this leads to even
>> >> more hilarity since for some configurations the hardware is simply no
>> >> longer there.
>> >>
>> >> The actual implementation is a bit a hack - we realy on fbcon to kick
>> >> out the vgacon. To make this also work with I915_FBDEV=n (or FBCON=n)
>> >> and VGA_CONSOLE=y i915 already unregisters the vga console manually
>> >> early in the driver load sequence.
>> >>
>> > Interesting... nv50 and later GPUs are in a roughly similar shame
>> > afaict. They lack the dedicated hardware and no one really bothered
>> > figuring out how to restore things to a working shape [1].
>> >
>> > Then again, upon sequential load of the nouveau module the GPU gets
>> > initialised properly, where you can get X (weston?) up and running
>> > without issues. Am I thinking about a different thing ?
>> >
>> > I take it that you guys do less of the (re)initialisation dance, to
>> > ensure faster boot times ?
>> >
>> > Thanks,
>> > Emil
>> >
>> > [1] http://nouveau.freedesktop.org/wiki/KernelModeSetting/#deactivatingkmsandunloadingnouveau
>>
>> FWIW it's possible to unload nouveau, at which point your screen turns
>> off (because we can't restore the vga emulation junk... haven't the
>> faintest clue how it works), and then reload it, at which point fbcon
>> gets rebound and is completely happy. I can't tell what this patch is
>> doing, but for your own sanity, you should support unloading/reloading
>> i915 as well.
>
> We do of course support unloading/reloading. And we do the same "shut
> everything down" like nouveau seems to do. The problem though on some hw
> is that if vgacon then tries to access the registers the hw dies. So the
> problem we have with not restoring VGA functionality isn't that the screen
> is black when i915.ko is unloaded, but that the machine dies. This patch
> fixes that.
I see. Thank you for the explanation!

-Emil
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web