make fbdev/fbcon switchable per driver?

make fbdev/fbcon switchable per driver?

[Gerd Hoffmann]

[-- Attachment #1: Type: text/plain, Size: 548 bytes --]

  Hi folks,

Problem at hand:  A virtual machine, equipped with two display devices,
one virtual, one physical (using pci pass-through, or kvmgt-based vgpu).

There is no easy way for the user to configure which of the two display
devices fbcon should run on.  i915 happens to win over bochs-drm or qxl,
so you can't use the emulated gfx device as text console.

One way out would be to add a module option to each driver, to turn off
fbdev emulation.  Attached patch does that for i915.

Comments?  Better ideas?

cheers,
  Gerd


[-- Attachment #2: 0001-drm-i915-add-fbdev-option.patch --]
[-- Type: text/x-patch, Size: 1363 bytes --]

From 19236e412a6f0e9390c1ce77d8702bbdb5511174 Mon Sep 17 00:00:00 2001
From: Gerd Hoffmann <kraxel@redhat.com>
Date: Fri, 27 Jan 2017 08:05:40 +0100
Subject: [PATCH] drm i915: add fbdev option

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
 drivers/gpu/drm/i915/intel_fbdev.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_fbdev.c b/drivers/gpu/drm/i915/intel_fbdev.c
index 3e3632c..cc0ba3e 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -45,6 +45,11 @@
 #include <drm/i915_drm.h>
 #include "i915_drv.h"
 
+static bool enable_fbdev = true;
+module_param_named(fbdev, enable_fbdev, bool, 0600);
+MODULE_PARM_DESC(fbdev,
+		 "Enable legacy fbdev emulation [default=true]");
+
 static int intel_fbdev_set_par(struct fb_info *info)
 {
 	struct drm_fb_helper *fb_helper = info->par;
@@ -706,6 +711,9 @@ int intel_fbdev_init(struct drm_device *dev)
 	struct drm_i915_private *dev_priv = to_i915(dev);
 	int ret;
 
+	if (!enable_fbdev)
+		return 0;
+
 	if (WARN_ON(INTEL_INFO(dev)->num_pipes == 0))
 		return -ENODEV;
 
@@ -747,6 +755,8 @@ void intel_fbdev_initial_config_async(struct drm_device *dev)
 {
 	struct intel_fbdev *ifbdev = to_i915(dev)->fbdev;
 
+	if (!ifbdev)
+		return;
 	ifbdev->cookie = async_schedule(intel_fbdev_initial_config, ifbdev);
 }
 
-- 
1.8.3.1


[-- Attachment #3: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: make fbdev/fbcon switchable per driver?

[Daniel Vetter]

On Fri, Jan 27, 2017 at 11:00:38AM +0100, Gerd Hoffmann wrote:
>   Hi folks,
> 
> Problem at hand:  A virtual machine, equipped with two display devices,
> one virtual, one physical (using pci pass-through, or kvmgt-based vgpu).
> 
> There is no easy way for the user to configure which of the two display
> devices fbcon should run on.  i915 happens to win over bochs-drm or qxl,
> so you can't use the emulated gfx device as text console.
> 
> One way out would be to add a module option to each driver, to turn off
> fbdev emulation.  Attached patch does that for i915.
> 
> Comments?  Better ideas?

fbcon can be switched between different fbdev afaik, but don't ask me how.
I'd say if you want to keep fbcon (and not switch to something like
kmscon), then that's where this logic should be. Might even exist already.
Having a per-driver knob won't work, since then the next person complains
about his multi-amd setup using the wrong gpu :-)
-Daniel

> 
> cheers,
>   Gerd
> 

> From 19236e412a6f0e9390c1ce77d8702bbdb5511174 Mon Sep 17 00:00:00 2001
> From: Gerd Hoffmann <kraxel@redhat.com>
> Date: Fri, 27 Jan 2017 08:05:40 +0100
> Subject: [PATCH] drm i915: add fbdev option
> 
> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
> ---
>  drivers/gpu/drm/i915/intel_fbdev.c | 10 ++++++++++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_fbdev.c b/drivers/gpu/drm/i915/intel_fbdev.c
> index 3e3632c..cc0ba3e 100644
> --- a/drivers/gpu/drm/i915/intel_fbdev.c
> +++ b/drivers/gpu/drm/i915/intel_fbdev.c
> @@ -45,6 +45,11 @@
>  #include <drm/i915_drm.h>
>  #include "i915_drv.h"
>  
> +static bool enable_fbdev = true;
> +module_param_named(fbdev, enable_fbdev, bool, 0600);
> +MODULE_PARM_DESC(fbdev,
> +		 "Enable legacy fbdev emulation [default=true]");
> +
>  static int intel_fbdev_set_par(struct fb_info *info)
>  {
>  	struct drm_fb_helper *fb_helper = info->par;
> @@ -706,6 +711,9 @@ int intel_fbdev_init(struct drm_device *dev)
>  	struct drm_i915_private *dev_priv = to_i915(dev);
>  	int ret;
>  
> +	if (!enable_fbdev)
> +		return 0;
> +
>  	if (WARN_ON(INTEL_INFO(dev)->num_pipes == 0))
>  		return -ENODEV;
>  
> @@ -747,6 +755,8 @@ void intel_fbdev_initial_config_async(struct drm_device *dev)
>  {
>  	struct intel_fbdev *ifbdev = to_i915(dev)->fbdev;
>  
> +	if (!ifbdev)
> +		return;
>  	ifbdev->cookie = async_schedule(intel_fbdev_initial_config, ifbdev);
>  }
>  
> -- 
> 1.8.3.1
> 

> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel


-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: make fbdev/fbcon switchable per driver?

[Liviu Dudau]

On Fri, Jan 27, 2017 at 03:02:42PM +0100, Daniel Vetter wrote:
> On Fri, Jan 27, 2017 at 11:00:38AM +0100, Gerd Hoffmann wrote:
> >   Hi folks,
> > 
> > Problem at hand:  A virtual machine, equipped with two display devices,
> > one virtual, one physical (using pci pass-through, or kvmgt-based vgpu).
> > 
> > There is no easy way for the user to configure which of the two display
> > devices fbcon should run on.  i915 happens to win over bochs-drm or qxl,
> > so you can't use the emulated gfx device as text console.
> > 
> > One way out would be to add a module option to each driver, to turn off
> > fbdev emulation.  Attached patch does that for i915.
> > 
> > Comments?  Better ideas?
> 
> fbcon can be switched between different fbdev afaik, but don't ask me how.

Hint: Documentation/fb/fbcon.txt says fbcon=map:<ttynumbers>

Best regards,
Liviu

> I'd say if you want to keep fbcon (and not switch to something like
> kmscon), then that's where this logic should be. Might even exist already.
> Having a per-driver knob won't work, since then the next person complains
> about his multi-amd setup using the wrong gpu :-)
> -Daniel
> 
> > 
> > cheers,
> >   Gerd
> > 
> 
> > From 19236e412a6f0e9390c1ce77d8702bbdb5511174 Mon Sep 17 00:00:00 2001
> > From: Gerd Hoffmann <kraxel@redhat.com>
> > Date: Fri, 27 Jan 2017 08:05:40 +0100
> > Subject: [PATCH] drm i915: add fbdev option
> > 
> > Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
> > ---
> >  drivers/gpu/drm/i915/intel_fbdev.c | 10 ++++++++++
> >  1 file changed, 10 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_fbdev.c b/drivers/gpu/drm/i915/intel_fbdev.c
> > index 3e3632c..cc0ba3e 100644
> > --- a/drivers/gpu/drm/i915/intel_fbdev.c
> > +++ b/drivers/gpu/drm/i915/intel_fbdev.c
> > @@ -45,6 +45,11 @@
> >  #include <drm/i915_drm.h>
> >  #include "i915_drv.h"
> >  
> > +static bool enable_fbdev = true;
> > +module_param_named(fbdev, enable_fbdev, bool, 0600);
> > +MODULE_PARM_DESC(fbdev,
> > +		 "Enable legacy fbdev emulation [default=true]");
> > +
> >  static int intel_fbdev_set_par(struct fb_info *info)
> >  {
> >  	struct drm_fb_helper *fb_helper = info->par;
> > @@ -706,6 +711,9 @@ int intel_fbdev_init(struct drm_device *dev)
> >  	struct drm_i915_private *dev_priv = to_i915(dev);
> >  	int ret;
> >  
> > +	if (!enable_fbdev)
> > +		return 0;
> > +
> >  	if (WARN_ON(INTEL_INFO(dev)->num_pipes == 0))
> >  		return -ENODEV;
> >  
> > @@ -747,6 +755,8 @@ void intel_fbdev_initial_config_async(struct drm_device *dev)
> >  {
> >  	struct intel_fbdev *ifbdev = to_i915(dev)->fbdev;
> >  
> > +	if (!ifbdev)
> > +		return;
> >  	ifbdev->cookie = async_schedule(intel_fbdev_initial_config, ifbdev);
> >  }
> >  
> > -- 
> > 1.8.3.1
> > 
> 
> > _______________________________________________
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
-------------------
   .oooO
   (   )
    \ (  Oooo.
     \_) (   )
          ) /
         (_/

 One small step
   for me ...
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: make fbdev/fbcon switchable per driver?

[Alex Williamson]

On Fri, 27 Jan 2017 11:00:38 +0100
Gerd Hoffmann <kraxel@redhat.com> wrote:

>   Hi folks,
> 
> Problem at hand:  A virtual machine, equipped with two display devices,
> one virtual, one physical (using pci pass-through, or kvmgt-based vgpu).
> 
> There is no easy way for the user to configure which of the two display
> devices fbcon should run on.  i915 happens to win over bochs-drm or qxl,
> so you can't use the emulated gfx device as text console.
> 
> One way out would be to add a module option to each driver, to turn off
> fbdev emulation.  Attached patch does that for i915.
> 
> Comments?  Better ideas?

The vgaarb code has a concept of a vga_default_device(), it's rather
PCI-centric, but maybe better than nothing.  This is typically the
first VGA class code device found with I/O and MMIO enabled.  If fbcon
defaulted to running on the vga_default_device(), a user could select
which to use by re-ordering the VM hardware.

The problem isn't absent on bare metal, though re-ordering hardware
isn't always as simple, or necessarily possible.  The problem might run
deeper there too dealing with vesafb and simplefb, as well as the more
device specific drivers.  Rerouting legacy resources isn't always an
option, but some sort of primary selection for non-encumbered devices
would be useful.  Thanks,

Alex
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: make fbdev/fbcon switchable per driver?

[Gerd Hoffmann]

  Hi,

> The vgaarb code has a concept of a vga_default_device(), it's rather
> PCI-centric, but maybe better than nothing.  This is typically the
> first VGA class code device found with I/O and MMIO enabled.  If fbcon
> defaulted to running on the vga_default_device(), a user could select
> which to use by re-ordering the VM hardware.

The qemu drivers don't register as vgaarb clients though.  Which easily
explains why igd always wins the primary selection, no matter how you
order your hardware.

So, should they register?  The drivers don't need access to the vga
registers[1][2].

cheers,
  Gerd

[1] Well, except cirrus, but that is deprecated anyway.
[2] And bochs-drm, when running on old qemu versions, where the
    stdvga has no mmio bar yet.  But those qemu versions don't
    support igd pass-through.

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: make fbdev/fbcon switchable per driver?

[Alex Williamson]

On Mon, 30 Jan 2017 09:15:50 +0100
Gerd Hoffmann <kraxel@redhat.com> wrote:

>   Hi,
> 
> > The vgaarb code has a concept of a vga_default_device(), it's rather
> > PCI-centric, but maybe better than nothing.  This is typically the
> > first VGA class code device found with I/O and MMIO enabled.  If fbcon
> > defaulted to running on the vga_default_device(), a user could select
> > which to use by re-ordering the VM hardware.  
> 
> The qemu drivers don't register as vgaarb clients though.  Which easily
> explains why igd always wins the primary selection, no matter how you
> order your hardware.
> 
> So, should they register?  The drivers don't need access to the vga
> registers[1][2].

The VGA arbiter sets up a notifier on the PCI bus and will add any VGA
class code devices it finds.  So even if the driver doesn't
participate, it'll still be tracked and might be marked as primary.  If
a graphics driver claims a VGA device that does not depend on VGA
region access then the driver should configure the device not to claim
VGA accesses (maybe only relevant for integrated graphics - i915 gets
this wrong), and register with the arbiter to opt-out of VGA
arbitration.  Picking a "primary" can be done w/o any of that latter if
we agree on the arbiter algorithm of picking the first device with VGA
routing to it (or it can be overridden by arch/platform code).  Thanks,

Alex
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: make fbdev/fbcon switchable per driver?

[Daniel Vetter]

On Mon, Jan 30, 2017 at 10:45:22AM -0700, Alex Williamson wrote:
> On Mon, 30 Jan 2017 09:15:50 +0100
> Gerd Hoffmann <kraxel@redhat.com> wrote:
> 
> >   Hi,
> > 
> > > The vgaarb code has a concept of a vga_default_device(), it's rather
> > > PCI-centric, but maybe better than nothing.  This is typically the
> > > first VGA class code device found with I/O and MMIO enabled.  If fbcon
> > > defaulted to running on the vga_default_device(), a user could select
> > > which to use by re-ordering the VM hardware.  
> > 
> > The qemu drivers don't register as vgaarb clients though.  Which easily
> > explains why igd always wins the primary selection, no matter how you
> > order your hardware.
> > 
> > So, should they register?  The drivers don't need access to the vga
> > registers[1][2].
> 
> The VGA arbiter sets up a notifier on the PCI bus and will add any VGA
> class code devices it finds.  So even if the driver doesn't
> participate, it'll still be tracked and might be marked as primary.  If
> a graphics driver claims a VGA device that does not depend on VGA
> region access then the driver should configure the device not to claim
> VGA accesses (maybe only relevant for integrated graphics - i915 gets
> this wrong), and register with the arbiter to opt-out of VGA
> arbitration.  Picking a "primary" can be done w/o any of that latter if
> we agree on the arbiter algorithm of picking the first device with VGA
> routing to it (or it can be overridden by arch/platform code).  Thanks,

Fyi we don't get this wrong, we indeed need vga access in some cases.
Broken hw :( The other issue is that the X server asks for vga access (or
at least did in the past) for every render op, even if it's a kms driver.
Which makes X crawl if you have multi-gpu system. Those two things
combined means vgaarb is essentially dead on any system with intel gfx.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: make fbdev/fbcon switchable per driver?

[Gerd Hoffmann]

  Hi,

> > The VGA arbiter sets up a notifier on the PCI bus and will add any VGA
> > class code devices it finds.  So even if the driver doesn't
> > participate, it'll still be tracked and might be marked as primary.  If
> > a graphics driver claims a VGA device that does not depend on VGA
> > region access then the driver should configure the device not to claim
> > VGA accesses (maybe only relevant for integrated graphics - i915 gets
> > this wrong), and register with the arbiter to opt-out of VGA
> > arbitration.  Picking a "primary" can be done w/o any of that latter if
> > we agree on the arbiter algorithm of picking the first device with VGA
> > routing to it (or it can be overridden by arch/platform code).  Thanks,
> 
> Fyi we don't get this wrong, we indeed need vga access in some cases.
> Broken hw :( The other issue is that the X server asks for vga access (or
> at least did in the past) for every render op, even if it's a kms driver.
> Which makes X crawl if you have multi-gpu system. Those two things
> combined means vgaarb is essentially dead on any system with intel gfx.
> -Daniel

Various qemu display devices exist in vga and non-vga variants.  So we
can sidestep the vgaarb issues by using one of those, so igd is the only
CLASS_DISPLAY_VGA device in the system.

That causes some other problems though.  First the vga variants are
supported better by the firmware because it is easy to create a simple
framebuffer with them.  With the non-vga variants you usually don't have
a display until the linux kms driver loads.  Also the vgaarb will not
pick them up, so they will not be considered as primary display.

With the vga variants primary selection by ordering the devices works
for me.  kms drivers for both igd and emulated graphics must be loaded.
fbcon will pick up whatever vgaarb declared as boot device.

cheers,
  Gerd

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel