Re: [PATCH 19/49] drm/i915/bdw: Populate LR contexts (somewhat)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux