[Intel-gfx] [PATCH 2/2] drm/i915: Function per early graphics quirk

[Chris Wilson]

On Fri, Apr 22, 2016 at 03:07:42PM +0300, Joonas Lahtinen wrote:
> On pe, 2016-04-22 at 12:55 +0100, Chris Wilson wrote:
> > On Fri, Apr 22, 2016 at 02:25:07PM +0300, Joonas Lahtinen wrote:
> > > 
> > > Move graphics stolen memory related early quirk into a function to
> > > allow easy adding of other graphics quirks to fix memory maps on
> > > machines running old BIOS versions.
> > > 
> > > While at it;
> > > - _funcs -> _ops to follow de facto naming
> > > - make the iteration code tad more readable
> > > - remove unused variables
> > > 
> > > Cc: Chris Wilson <chris at chris-wilson.co.uk>
> > > Cc: Mika Kuoppala <mika.kuoppala at intel.com>
> > > Cc: Ville Syrjälä <ville.syrjala at linux.intel.com>
> > > Cc: Tvrtko Ursulin <tvrtko.ursulin at linux.intel.com>
> > > Signed-off-by: Joonas Lahtinen <joonas.lahtinen at linux.intel.com>
> > Mechanical again, and less quirky,
> > Reserved-by: Chris Wilson <chris at chris-wilson.co.uk>
> 
> A new type of R-b? :)

I'm tired. :|

> > > -static void __init intel_graphics_stolen(int num, int slot, int func)
> > > +static void __init
> > > +intel_graphics_stolen(int num, int slot, int func,
> > > +		      const struct intel_early_ops *early_ops)
> > >  {
> > > +	phys_addr_t base;
> > >  	size_t size;
> > > +
> > > +	size = early_ops->stolen_size(num, slot, func);
> > > +	base = early_ops->stolen_base(num, slot, func, size);
> > > +
> > > +	if (!size || !base)
> > > +		return;
> > if (size + base < base)
> > 	return;
> > 
> > Just in case? Hmm, not sure if the integer sizes will always be suitable
> > for the test, so probably just trust the hardware registers?
> 
> (This was actually the test used by earlier version of code too.
> Intention was to not change the resulting logic that much. So I'd add
> this check as a follow-up.)
> 
> I don't see how this could happen, the original hardware registers are
> unlikely to cause an overflow of the phys_addr_t. If we want to add a
> check, we should rather test against e820_end_of_ram_pfn() or so.

It can't happen. But I know better than to trust a BIOS or our own
interpretation of the guides. From off the top of my head, stolen will
always be below 4G, and doing a sanity check that it is may or may not
be worth the infuriation if it ever moves above 4G.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre