On Wed, Apr 16, 2014 at 12:32 AM, Jeff McGee <jeff.mcgee@xxxxxxxxx> wrote: >> > Reflecting on my initial confusion, would it be clearer to provide names for >> > each dword position in the context image, rather than using an unnamed offset >> > like CTX_R_PWR_CLK_STATE+1? Example: >> > >> > reg_state[CTX_R_PWR_CLK_STATE_ADDR] = 0x20c8 >> > reg_state[CTX_R_PWR_CLK_STATE_DATA] = 0; >> >> Usually when we emit batches in userspace (and the context is nothing else >> really) we have some OUT_BATCH macro which writes the dword and increments >> the pointer. Since MI_LOAD_REGISTER_IMM is multi-length we could add a >> OUT_BATCH_REG_WRITE(reg, value) which does both dword emissions. >> >> That should clarify a lot what's going on here. We might even completely >> drop all the offset #defines and replace them with a few comments or so. >> -Daniel >> > OK, now I get it. My mistake was in thinking the context image is just pure > state that hardware already knows how to restore. But as you say it is more > like a batch which includes the state *and* the MI_LOAD_REGISTER_IMM commands > required to restore. So in that sense I understand that the approach here to > initilize the context is much like constructing a batch. But later when we > want to update the value of a context field we have (in a later patch of this > series): > > reg_state[CTX_RING_TAIL+1] = value; > > This is a bit obscure when occurring by itself and not in the flow of > initializing the context (batch). The same will be true when we add management > of the CTX_R_PWR_CLK_STATE value dword. The approach thus far for this stuff has been to save the hidden offset value when you get around to write this dword somewhere, e.g. for relocation processing or similar. Or maybe add an assert that the contstant we #defined matches the running offset when we expect it to. Dunno really whether going with an OUT_BATCH approach really makes sense, was just an idea. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
