[Intel-gfx] [PATCH 07/23] drm/i915: Move HAS_GUC_UCODE definition to platform definition

[Dave Gordon]

On 02/08/16 15:16, Daniel Vetter wrote:
> On Tue, Aug 02, 2016 at 11:10:46AM +0100, Dave Gordon wrote:
>> On 21/07/16 18:10, Dave Gordon wrote:
>>> On 21/07/16 11:38, Tvrtko Ursulin wrote:
>>>>
>>>> On 20/07/16 22:07, Rodrigo Vivi wrote:
>>>>> please kill this _ucode variation that is just a alias to guc
>>>>> instead....
>>>>
>>>> Not sure, it was added with a particular goal. Cc Dave in case he wants
>>>> to comment.
>>>>
>>>> Regards,
>>>> Tvrtko
>>>
>>> The comment is already in the source code, just above the lines that
>>> this patch changes.
>>>
>>> .Dave.
>>
>> Which is to say that,
>> +   having a GuC that can be used for command submission
>> +   having a GuC that requires firmware before use
>> are logically distinct properties, and are both subsets of
>> * having GuC hardware.
>>
>> We can *imagine* products that might:
>>
>> (1) have a GuC that requires firmware before use ...
>> (2) have a GuC with predefined but reloadable firmware ...
>> (3) have a GuC that contains a permanent firmware image ...
>>  x
>> (a) ... which supports command submission but not SLPC
>> (b) ... which supports both command submission and SLPC
>> (c) ... which supports SLPC but not command submission
>>
>> where all combinations are logically plausible, even though we only have
>> (1a) in today's devices. So we might as well make future development easier
>> rather than more difficult; it is always easier to make different things
>> equivalent than to separate identical things into different cases.
>
> Let's please not add code for everything we can imagine. If there's a
> product in the pipeline for which the above is true then sure, makes sense
> (but needs one of the generic "needed for future platforms" notice in the
> commit message). Otherwise I'll vote to nuke the difference.
> -Daniel

I didn't say you had to *store* three different flags for these; for 
now, they could all be the same flag. And they involve no "code" at all, 
just one (or three) bit flags. But they *will* be distinguished at the 
point-of-use by by having different MACRO names, even if they all alias 
to the same bit. This helps the reader understand what property of the 
GuC (or other h/w)  is relevant to a particular bit of code, which will 
become ever more important as more auxiliary processors are added and 
more functions offloaded into them. Remember how much confusion has 
previously been caused by, for example, conflating "nonprivileged 
execution" with "private address space" or "ring of CS commands" with 
"command dispatcher". So looking ahead a little and remembering that a 
single blob of hardware may support multiple logically independent 
functions can save a lot of work in the long run.

.Dave.