On Fri, Jun 5, 2009 at 12:43 AM, Peter Jones[off-list ref] wrote:

On 06/04/2009 12:46 AM, Dave Airlie wrote:

quoted

From: Dave Airlie <airlied@redhat.com>

With KMS we have ran into an issue where we really want the KMS fb driver
to be the one running the console, so panics etc can be shown by switching
out of X etc.

However with vesafb/efifb built-in, we end up with those on fb0 and the
KMS fb driver on fb1, driving the same piece of hw, so this adds an fb info
flag to denote a firmware fbdev, and adds a new aperture base/size range
which can be compared when the hw drivers are installed to see if there
is a conflict with a firmware driver, and if there is the firmware driver is
unregistered and the hw driver takes over.

It uses new aperture_base/size members instead of comparing on the fix
smem_start/length, as smem_start/length might for example only cover the
first 1MB of the PCI aperture, and we could allocate the kms fb from 8MB
into the aperture, thus they would never overlap.

Signed-off-by: Dave Airlie <airlied@redhat.com>
---
 drivers/gpu/drm/i915/intel_fb.c |    8 ++++++++
 drivers/video/efifb.c           |    5 ++++-
 drivers/video/fbmem.c           |   24 ++++++++++++++++++++++++
 drivers/video/vesafb.c          |    6 +++++-
 include/linux/fb.h              |    9 ++++++++-
 5 files changed, 49 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_fb.c b/drivers/gpu/drm/i915/intel_fb.c
index e4652dc..f1849d3 100644
--- a/drivers/gpu/drm/i915/intel_fb.c
+++ b/drivers/gpu/drm/i915/intel_fb.c

@@ -504,6 +504,14 @@ static int intelfb_create(struct drm_device *dev, uint32_t fb_width,

      info->fbops = &intelfb_ops;

      info->fix.line_length = fb->pitch;
+
+     /* setup aperture base/size for vesafb takeover */
+     info->aperture_base = dev->mode_config.fb_base;
+     if (IS_I9XX(dev))
+             info->aperture_size = pci_resource_len(dev->pdev, 2);
+     else
+             info->aperture_size = pci_resource_len(dev->pdev, 0);
+
      info->fix.smem_start = dev->mode_config.fb_base + obj_priv->gtt_offset;
      info->fix.smem_len = size;

diff --git a/drivers/video/efifb.c b/drivers/video/efifb.c
index 8dea2bc..eb12182 100644
--- a/drivers/video/efifb.c
+++ b/drivers/video/efifb.c

@@ -280,6 +280,9 @@ static int __init efifb_probe(struct platform_device *dev)

      info->pseudo_palette = info->par;
      info->par = NULL;

+     info->aperture_base = efifb_fix.smem_start;
+     info->aperture_size = size_total;
+

It seems like we aught to be looking up the PCI BAR here, reserving it, and
using that as aperture_{base,size} -- though that's not strictly required by
fb_compare_aperture_sizes() .

Probably no need, they'll overlap at some point, and we can't always assume
you'll have a PCI device behind it (well you probably can for efifb.)

quoted

+static bool fb_compare_aperture_sizes(struct fb_info *gen, struct fb_info *hw)

The name here seems weird -- something like fb_do_apertures_overlap() or even just fb_compare_apertures() would be more clear to me.

Changed in v2.

quoted

+             if (registered_fb[i]->flags & FBINFO_MISC_FIRMWARE) {
+                     if (fb_compare_aperture_sizes(registered_fb[i], fb_info)) {
+                             printk("fb: conflicting fb hw usage - removing generic driver\n", registered_fb[i]->aperture_base, fb_info->aperture_base);
+                             unregister_framebuffer(registered_fb[i]);
+                             break;
+                     }
+             }
+     }

Seems like we should we also have a "nomodeset" check in this codepath.

Shouldn't matter, the kms drivers won't create an fbdev if nomodeset
is specified so we never get to this point

I've sent v2 which is probably ready for inclusion, not sure what the
path upstream is,

After its merged you can add an efifb fb_destroy function, and the
powerpc people can add offb support.

Dave.

------------------------------------------------------------------------------
OpenSolaris 2009.06 is a cutting edge operating system for enterprises 
looking to deploy the next generation of Solaris that includes the latest 
innovations from Sun and the OpenSource community. Download a copy and 
enjoy capabilities such as Networking, Storage and Virtualization. 
Go to: http://p.sf.net/sfu/opensolaris-get