Re: [PATCH] drm/i915: kick any firmware framebuffers before claiming the gtt

[Chris Wilson <chris@chris-wilson.co.uk>]

On Mon, 11 Jun 2012 18:28:12 +0200, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> Especially vesafb likes to map everything as uc- (yikes), and if that
> mapping hangs around still while we try to map the gtt as wc the
> kernel will downgrade our request to uc-, resulting in abyssal
> performance.
> 
> Unfortunately we can't do this as early as readon does (i.e. as the
> first thing we do when initializing the hw) because our fb/mmio space
> region moves around on a per-gen basis. So I've had to move it below
> the gtt initialization, but that seems to work, too. The important
> thing is that we do this before we set up the gtt wc mapping.
> 
> Now an altogether different question is why people compile their
> kernels with vesafb enabled, but I guess making things just work isn't
> bad per se ...
> 
> v2:
> - s/radeondrmfb/inteldrmfb/
> - fix up error handling
> 
> Reported-and-tested-by: "Kilarski, Bernard R" <bernard.r.kilarski@intel.com>
> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> ---
>  drivers/gpu/drm/i915/i915_dma.c |   35 ++++++++++++++++++++++++++++-------
>  1 file changed, 28 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index 262a74d..379cb14 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -1401,6 +1401,25 @@ i915_mtrr_setup(struct drm_i915_private *dev_priv, unsigned long base,
>  	}
>  }
>  
> +static void i915_kick_out_firmware_fb(struct drm_i915_private *dev_priv)
> +{
> +	struct apertures_struct *ap;
> +	struct pci_dev *pdev = dev_priv->dev->pdev;
> +	bool primary = false;
> +
> +	ap = alloc_apertures(1);

Potential malloc failure needs handling.

> +	ap->ranges[0].base = dev_priv->dev->agp->base;
> +	ap->ranges[0].size =
> +		dev_priv->mm.gtt->gtt_mappable_entries << PAGE_SHIFT;
> +
> +#ifdef CONFIG_X86
> +	primary = pdev->resource[PCI_ROM_RESOURCE].flags & IORESOURCE_ROM_SHADOW;

That seems fraught with danger. Do we still get the ROM_SHADOW flag for
a primary device with no rom? Would checking the pci_dev for the VGA
class be safer (and not introduce a CONFIG_X86 :)?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre