Menu
▾
▴
Re: [Linux-fbdev-devel] [PATCH] fb: add support for handoff from firmware to hw framebuffers
|
From: Dave A. <ai...@gm...> - 2009-06-05 06:09:49
|
On Fri, Jun 5, 2009 at 12:43 AM, Peter Jones<pj...@re...> wrote:
> On 06/04/2009 12:46 AM, Dave Airlie wrote:
>> From: Dave Airlie <ai...@re...>
>>
>> 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 <ai...@re...>
>> ---
>> 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.)
>
>>
>> +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.
>> + 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.
|
