2015-11-27 15:10:17

by Daniel Vetter

[permalink] [raw]
Subject: [PATCH RESEND 1/2] vgacon: dummy implementation for vgacon_text_force

This allows us to ditch a ton of ugly #ifdefs from a bunch of drm modeset
drivers.

v2: Make the dummy function actually return a sane value, spotted by
Ville.

Cc: Ville Syrjälä <[email protected]>
Cc: Andrew Morton <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
---
drivers/gpu/drm/ast/ast_drv.c | 2 --
drivers/gpu/drm/cirrus/cirrus_drv.c | 2 --
drivers/gpu/drm/i915/i915_drv.c | 2 --
drivers/gpu/drm/mgag200/mgag200_drv.c | 2 --
drivers/gpu/drm/nouveau/nouveau_drm.c | 2 --
drivers/gpu/drm/qxl/qxl_drv.c | 2 --
drivers/gpu/drm/radeon/radeon_drv.c | 2 --
include/linux/console.h | 2 ++
8 files changed, 2 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_drv.c b/drivers/gpu/drm/ast/ast_drv.c
index 9a32d9dfdd26..fcd9c0714836 100644
--- a/drivers/gpu/drm/ast/ast_drv.c
+++ b/drivers/gpu/drm/ast/ast_drv.c
@@ -218,10 +218,8 @@ static struct drm_driver driver = {

static int __init ast_init(void)
{
-#ifdef CONFIG_VGA_CONSOLE
if (vgacon_text_force() && ast_modeset == -1)
return -EINVAL;
-#endif

if (ast_modeset == 0)
return -EINVAL;
diff --git a/drivers/gpu/drm/cirrus/cirrus_drv.c b/drivers/gpu/drm/cirrus/cirrus_drv.c
index b1619e29a564..b394e6d8f01e 100644
--- a/drivers/gpu/drm/cirrus/cirrus_drv.c
+++ b/drivers/gpu/drm/cirrus/cirrus_drv.c
@@ -162,10 +162,8 @@ static struct pci_driver cirrus_pci_driver = {

static int __init cirrus_init(void)
{
-#ifdef CONFIG_VGA_CONSOLE
if (vgacon_text_force() && cirrus_modeset == -1)
return -EINVAL;
-#endif

if (cirrus_modeset == 0)
return -EINVAL;
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 90faa8e03fca..79681b328e9f 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1767,10 +1767,8 @@ static int __init i915_init(void)
if (i915.modeset == 0)
driver.driver_features &= ~DRIVER_MODESET;

-#ifdef CONFIG_VGA_CONSOLE
if (vgacon_text_force() && i915.modeset == -1)
driver.driver_features &= ~DRIVER_MODESET;
-#endif

if (!(driver.driver_features & DRIVER_MODESET)) {
/* Silently fail loading to not upset userspace. */
diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.c b/drivers/gpu/drm/mgag200/mgag200_drv.c
index b0af77454d52..ebb470ff7200 100644
--- a/drivers/gpu/drm/mgag200/mgag200_drv.c
+++ b/drivers/gpu/drm/mgag200/mgag200_drv.c
@@ -116,10 +116,8 @@ static struct pci_driver mgag200_pci_driver = {

static int __init mgag200_init(void)
{
-#ifdef CONFIG_VGA_CONSOLE
if (vgacon_text_force() && mgag200_modeset == -1)
return -EINVAL;
-#endif

if (mgag200_modeset == 0)
return -EINVAL;
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 1d3ee5179ab8..14fb49c6c76c 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -1072,10 +1072,8 @@ nouveau_drm_init(void)
nouveau_display_options();

if (nouveau_modeset == -1) {
-#ifdef CONFIG_VGA_CONSOLE
if (vgacon_text_force())
nouveau_modeset = 0;
-#endif
}

if (!nouveau_modeset)
diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
index 7307b07fe06b..dc9df5fe50ba 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.c
+++ b/drivers/gpu/drm/qxl/qxl_drv.c
@@ -272,10 +272,8 @@ static struct drm_driver qxl_driver = {

static int __init qxl_init(void)
{
-#ifdef CONFIG_VGA_CONSOLE
if (vgacon_text_force() && qxl_modeset == -1)
return -EINVAL;
-#endif

if (qxl_modeset == 0)
return -EINVAL;
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c b/drivers/gpu/drm/radeon/radeon_drv.c
index 5b6a6f5b3619..502973b819b6 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -636,12 +636,10 @@ static struct pci_driver radeon_kms_pci_driver = {

static int __init radeon_init(void)
{
-#ifdef CONFIG_VGA_CONSOLE
if (vgacon_text_force() && radeon_modeset == -1) {
DRM_INFO("VGACON disable radeon kernel modesetting.\n");
radeon_modeset = 0;
}
-#endif
/* set to modesetting by default if not nomodeset */
if (radeon_modeset == -1)
radeon_modeset = 1;
diff --git a/include/linux/console.h b/include/linux/console.h
index bd194343c346..44b7fe8a2dbb 100644
--- a/include/linux/console.h
+++ b/include/linux/console.h
@@ -190,6 +190,8 @@ void vcs_remove_sysfs(int index);

#ifdef CONFIG_VGA_CONSOLE
extern bool vgacon_text_force(void);
+#else
+static inline bool vgacon_text_force(void) { return false; }
#endif

#endif /* _LINUX_CONSOLE_H */
--
2.5.1


2015-11-27 15:10:21

by Daniel Vetter

[permalink] [raw]
Subject: [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 <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Paulo Zanoni <[email protected]>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67813
Signed-off-by: Daniel Vetter <[email protected]>
---
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

2015-11-27 15:29:55

by Emil Velikov

[permalink] [raw]
Subject: Re: [PATCH RESEND 1/2] vgacon: dummy implementation for vgacon_text_force

On 27 November 2015 at 15:10, Daniel Vetter <[email protected]> wrote:
> This allows us to ditch a ton of ugly #ifdefs from a bunch of drm modeset
> drivers.
>
> v2: Make the dummy function actually return a sane value, spotted by
> Ville.
>
> Cc: Ville Syrjälä <[email protected]>
> Cc: Andrew Morton <[email protected]>
> Cc: Greg Kroah-Hartman <[email protected]>
> Signed-off-by: Daniel Vetter <[email protected]>
> ---
> drivers/gpu/drm/ast/ast_drv.c | 2 --
> drivers/gpu/drm/cirrus/cirrus_drv.c | 2 --
> drivers/gpu/drm/i915/i915_drv.c | 2 --
> drivers/gpu/drm/mgag200/mgag200_drv.c | 2 --
> drivers/gpu/drm/nouveau/nouveau_drm.c | 2 --
> drivers/gpu/drm/qxl/qxl_drv.c | 2 --
> drivers/gpu/drm/radeon/radeon_drv.c | 2 --
> include/linux/console.h | 2 ++

The new drivers seems to be missing the conversion. Namely amdgpu and
virtio_gpu.

> --- a/drivers/gpu/drm/nouveau/nouveau_drm.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
> @@ -1072,10 +1072,8 @@ nouveau_drm_init(void)
> nouveau_display_options();
>
> if (nouveau_modeset == -1) {
> -#ifdef CONFIG_VGA_CONSOLE
> if (vgacon_text_force())
> nouveau_modeset = 0;
> -#endif
It's kind of interesting how nouveau differs from everyone else. The
force toggle has lower priority than the nouveau specific one :-)
Obviously not something you should address or anything.

Another interesting fact is how none of the SoC honour the modeset fla :-\

Regards,
Emil

2015-11-27 15:40:38

by Emil Velikov

[permalink] [raw]
Subject: Re: [PATCH RESEND 2/2] drm/i915: prevent the vgacon from ever reloading

On 27 November 2015 at 15:10, Daniel Vetter <[email protected]> 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

2015-11-28 00:37:57

by Ilia Mirkin

[permalink] [raw]
Subject: Re: [PATCH RESEND 2/2] drm/i915: prevent the vgacon from ever reloading

On Fri, Nov 27, 2015 at 10:40 AM, Emil Velikov <[email protected]> wrote:
> On 27 November 2015 at 15:10, Daniel Vetter <[email protected]> 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

2015-11-29 12:47:51

by Daniel Vetter

[permalink] [raw]
Subject: 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 <[email protected]> wrote:
> > On 27 November 2015 at 15:10, Daniel Vetter <[email protected]> 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

2015-11-29 12:49:09

by Daniel Vetter

[permalink] [raw]
Subject: Re: [PATCH RESEND 1/2] vgacon: dummy implementation for vgacon_text_force

On Fri, Nov 27, 2015 at 03:29:52PM +0000, Emil Velikov wrote:
> On 27 November 2015 at 15:10, Daniel Vetter <[email protected]> wrote:
> > This allows us to ditch a ton of ugly #ifdefs from a bunch of drm modeset
> > drivers.
> >
> > v2: Make the dummy function actually return a sane value, spotted by
> > Ville.
> >
> > Cc: Ville Syrj?l? <[email protected]>
> > Cc: Andrew Morton <[email protected]>
> > Cc: Greg Kroah-Hartman <[email protected]>
> > Signed-off-by: Daniel Vetter <[email protected]>
> > ---
> > drivers/gpu/drm/ast/ast_drv.c | 2 --
> > drivers/gpu/drm/cirrus/cirrus_drv.c | 2 --
> > drivers/gpu/drm/i915/i915_drv.c | 2 --
> > drivers/gpu/drm/mgag200/mgag200_drv.c | 2 --
> > drivers/gpu/drm/nouveau/nouveau_drm.c | 2 --
> > drivers/gpu/drm/qxl/qxl_drv.c | 2 --
> > drivers/gpu/drm/radeon/radeon_drv.c | 2 --
> > include/linux/console.h | 2 ++
>
> The new drivers seems to be missing the conversion. Namely amdgpu and
> virtio_gpu.

Just shows how old this patch is ;-) And it's not going to cause a
problem since this patch simply makes the #ifdef redundant.

Greg, do you prefer a respin or a fixup patch?

Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

2015-11-29 14:10:22

by Emil Velikov

[permalink] [raw]
Subject: Re: [PATCH RESEND 2/2] drm/i915: prevent the vgacon from ever reloading

On 29 November 2015 at 12:47, Daniel Vetter <[email protected]> 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 <[email protected]> wrote:
>> > On 27 November 2015 at 15:10, Daniel Vetter <[email protected]> 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