[Intel-gfx] [PATCH 25/33] drm/i915: Use VMA for wa_ctx tracking

[Joonas Lahtinen]

On to, 2016-08-11 at 12:02 +0100, Chris Wilson wrote:
> On Thu, Aug 11, 2016 at 01:53:40PM +0300, Joonas Lahtinen wrote:
> > 
> > On su, 2016-08-07 at 15:45 +0100, Chris Wilson wrote:
> > > 
> > > @@ -2019,9 +2023,9 @@ populate_lr_context(struct i915_gem_context *ctx,
> > >  			       RING_INDIRECT_CTX(engine->mmio_base), 0);
> > >  		ASSIGN_CTX_REG(reg_state, CTX_RCS_INDIRECT_CTX_OFFSET,
> > >  			       RING_INDIRECT_CTX_OFFSET(engine->mmio_base), 0);
> > > -		if (engine->wa_ctx.obj) {
> > > +		if (engine->wa_ctx.vma) {
> > >  			struct i915_ctx_workarounds *wa_ctx = &engine->wa_ctx;
> > > -			uint32_t ggtt_offset = i915_gem_obj_ggtt_offset(wa_ctx->obj);
> > > +			u32 ggtt_offset = wa_ctx->vma->node.start;
> > lower_32_bits()?
> I considered, I didn't to keep the changes to a minimum plus I've a
> slight unease about making it seem like we don't care about the upper 32
> bits.
> 
> static inline u32 i915_ggtt_offset(vma)
> {
> 	GEM_BUG_ON(upper_32_bits(vma->node.start));
> 	return lower_32_bits(vma->node.start);
> }
> 

I was about to suggest this, it could maybe even take u64, depending on
how the respective locations look after the VMA overhaul.

Regards, Joonas

> is possibly overkill but stops me feeling uneasy about the
> seeming truncation. Is this something that UBSAN detects?
> -Chris
> 
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation