[Intel-gfx] [PATCH v3] drm/i915: resize the GuC WOPCM for rc6

[Dave Gordon]

On 06/05/16 10:37, Nick Hoath wrote:
> On 05/05/2016 16:04, Dave Gordon wrote:
>> On 05/05/2016 15:02, Antoine, Peter wrote:
>>> The attached version still does not explain that the WOPCM_TOP is to
>>> tell the GuC not to use that space.
>>
>> That's NOT what WOPCM_TOP means. The GuC is allowed to use the space up
>> to the value stored in the GUC_WOPCM_SIZE register (as the comment above
>> the #define says). Architecturally, this is allowed to be any value
>> greater than (16K+sizeof internal SRAM (64, 128, or 256K)) and less than
>> or equal to GUC_WOPCM_TOP (which is a platform-independent constant), so
>> we normally choose the maximm allowed. Howver on BXT, we need to leave
>> some space at the top for the RC6 image, hence the logic (and comments!)
>> in guc_wopcm_size().
>>
>>> The extra information does not aid anybody as the information is used
>>> internally within the GuC.
>> It may help the next person who has to figure out what's gone wrong on
>> some future chip that needs more than 64K for RC6!
>>
>> .Dave.
>>>
>>> But, I have not actual objection to the patch.
>>>
>>> Peter.
>>>
>>
> Unfortunately Dave's patch locked my test system on bootup, so I've t-b
> & r-b'd Peter's.

They're equivalent, unless your firmware happens to be between 458752 
and 491520 bytes in size (in which case you have a problem anyway).

To check, I've run both versions, with debug printing the value chosen 
(on SKL) and the value that would have been chosen on BXT, and they're 
identical (and both work). So I think your build had some other problem 
unrelated to the specific patch.

I've no problem with using Peter's patch for now, but it's not just a 
matter of the comments; there's also the other use(s) of 
GUC_WOP_(TOP,SIZE_VALUE), with ad-hoc additions or subtractions. So it 
still needs fixing properly.

.Dave.